微服务通常是一种架构模式,提倡将单一服务拆分成一组小的服务,每个服务运行在自己独立的进程中,服务之间采用轻量级的通信机制互相沟通,基于HTTP的RESTFUL API。
springboot专注于快速方便的开发单个个体微服务。
springcloud是关注全局的微服务协调整理框架,将springboot开发的一个个单体微服务整合并管理起来。为各个微服务之间提供配置管理,服务发现,断路器,路由等集成服务。
springboot可以离开springcloud独立开发项目,但springcloud是依赖springboot。
Dubbo的定位更侧重于是一款RPC框架,而springcloud的目标是微服务框架的一站式解决方案。
Dubbo | springcloud | |
---|---|---|
服务注册中心 | Zookeeper | Eureka |
服务调用方式 | RPC | Rest API |
服务监控 | Dubbo-monitor | admin |
断路器 | 不完善 | Hystrix |
*实体类 *
针对于ORM 的映射,即类表关系映射。
其中将实体类都放到api文件夹中,这样服务提供者和服务消费者就不需要再自己的模块下创建文件夹。
1 | import java.io.Serializable; |
mvn clean install后给其他模块引用,达到通用目的。当需要用到数据库表对应的实体类时,不用每个工程都定义一份,直接引用本模块即可。
约定 -> 配置 ->编码,先把软性的配置环境搭建好,再进行编码实践。
编写服务提供者模块
1 |
|
修改配置文件
1 | server: |
配置mybatis的xml文件
1 |
|
编写dao接口
1 | import java.util.List; |
配置mybatis下mapper中的xml文件
1 |
|
编写服务对应的接口
1 | import java.util.List; |
编写服务实现类
1 |
|
编写微服务子模块对外接口
1 | //前后端分离的架构,返回给前端字符串,之前springMVC使用Controller |
编写消费者模块
1 | import org.springframework.cloud.client.loadbalancer.LoadBalanced; |
消费者controller层
1 | //见到controller加上rest |
编写Eureka模块
provider注册到Eureka (provider-eureka)
相比较于Eureka的xml文件
1 |
|
1 |
|
相比较于Eureka的application.yml文件
1 | # eureka-client客户端 |
1 | # eureka-server服务端 |
客户端启动类
也证明了Eureka是C / S结构。
1 |
|
info内容构建
修改当前的pom文件
1 |
|
父工程的pom文件需要添加一个build模块
1 | <build> |
修改模块下的yaml文件
1 | info: |
Euraka的自我保护机制
某时刻某一个微服务不可用了,则Eureka不会立即清理,依旧会对该微服务的信息进行保存。
默认情况下,如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳,Eureka Server将会注销该实例(默认90 s)。当网络分区发生故障时,微服务与Eureka Server之间无法保证正常的通信,以上行为可能变得非常危险了。
当Eureka Server短时间内丢失多个客户端的话,那么这个节点就会进入自我保护模式,一旦进入该模式,Eureka Server就会保护注册表中的信息,不再删除服务注册表中的信息。故障恢复之后,当它收到的心跳数重新恢复到阈值以上时,则Eureka Server节点会自动退出自我保护模式。
可以通过eureka.server.enable-self-preservation = false来禁用自我保护模式
Eureka服务发现
1 | //服务发现 |
在Eureka 客户端的主启动类添加注解
1 | //服务发现 |
消费者调用服务发现
1 | "/consumer/dept/discovery") (value = |
Eureka相比于Zookeeper的好处
著名的CAP理论: 一个分布式系统不可能同时满足C(一致性),A(可用性)和P(分区容错性)。由于分区容错性P是必须保证的 ,故只能在A和C之间权衡。
- zookeeper保证的是CP;当注册中心查询服务列表时,可以容忍的是注册中心返回的是几分钟之前的注册信息,但不能接受服务直接down掉不可用。也就是说服务注册功能对可用性的要求高于一致性,但zk会出现:当master节点因为网络故障与其他节点失去联系,剩余节点会重新进行leader选举,问题在于选举leader的时间太长,一般在30-120s,选举期间zk集群是不可用的,会导致在选举期间整个注册服务处于瘫痪状态
- Eureka保证的是AP。优先保证可用性,各个节点都是平等的,几个节点挂掉之后不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务,而Eureka的客户端 在注册时如果发现连接失败,则会自动切换到其他节点,只不过查到的信息可能不是最新的(不保证强一致性),除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,则Eureka认为客户端与注册中心出现了网络故障。
- Eureka不再从注册列表中国移除因为长时间没收到心跳而应该过期的服务。
- Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点上,即保证当前节点依然可用。
- 当网络稳定时,当前实例新的注册信息会被同步到其他的节点中。
进行Ribbon的配置
所谓ribbon,主要是提供客户端的软件负载均衡算法,简单的说就是在配置文件中列出Load Balancer后面的机器。
补充消费者模块的配置文件和yaml文件
1 | eureka: |
1 | <dependency> |
在 ConfigBean 类上添加注解
1 |
|
也就是要求消费者在调用provider模块时使用的restTemplate访问restful接口自带负载均衡。
最终达到的效果是ribbon和eureka整合后consumer可以直接调用服务而不用关心地址和端口号。