微服务 - 服务注册发现(三)Consule
Consul 集群
在consul方案中,每个提供服务的节点上都要部署和运行consul的agent,所有运行consul agent节点的集合构成consul cluster。
consul agent有两种运行模式:server和client。这里的server和client只是consul集群层面的区分,与搭建在cluster之上的应用服务无关。
以server模式运行的consul agent节点用于维护consul集群的状态,
官方建议每个consul cluster至少有3个或以上的运行在server mode的agent,client节点不限。
我们选择了Consul作为服务注册中心的实现方案,主要原因有两点:
-
最小化对已有应用的侵入性,这也是贯穿我们整个微服务化改造的原则之一
-
降低运维的复杂度,Consul Agent既可以运行在服务器模式,又可以运行在客户端模式
Consul本质上属于应用外的注册方式,但可以通过SDK简化注册流程。而服务发现恰好相反,默认依赖于SDK,但可以通过Consul Template(下文会提到)去除SDK依赖。
Consul Template
上文提到使用Consul,默认服务调用者需要依赖Consul SDK来发现服务,这就无法保证对应用的零侵入性。所幸通过Consul Template,可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置(比如nginx的upstream),这样对于服务调用者而言,只需要配置一个统一的服务调用地址即可。改造后的调用关系如下:
Consul 的优势
使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft.
支持多数据中心,内外网的服务采用不同的端口进行监听。 多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等. zookeeper 和 etcd 均不提供多数据中心功能的支持.
支持健康检查. etcd 不提供此功能.
支持 http 和 dns 协议接口. zookeeper 的集成较为复杂, etcd 只支持 http 协议.
官方提供web管理界面, etcd 无此功能.
Consul 的角色
client: 客户端, 无状态, 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群.
server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通讯, 通过广域网与其他数据中心通讯. 每个数据中心的 server 数量推荐为 3 个或是 5 个.
Spring Cloud Consul 集成
由于我们选用了Spring Boot作为统一的微服务实现框架,很自然的,可以利用Spring Cloud提供的Consul组件进一步简化服务注册流程,省去额外的服务提供端的Consul配置。
引入依赖
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-consul-discovery</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies>
链接
史上最简单的 SpringCloud 教程 | 第十四篇: 服务注册(consul)
Spring Cloud构建微服务架构:服务注册与发现(Eureka、Consul)【Dalston版】