Spring Cloud微服务架构实战之Consul注册中心01

Netflix Eureka 2.X 官方宣告中止开发，但其实对国内的用户影响甚小，一方面国内大都使用的是 Eureka 1.X 系列，而且官方也在积极维护 1.X。

 The existing open source work on eureka 2.0 is discontinued. The code base and artifacts that were released as part of the existing repository of work on the 2.x branch is considered use at your own risk.
Eureka 1.x is a core part of Netflix's service discovery system and is still an active project.

翻译：

有关 eureka 2.0 的现有开源工做已中止。在 2.x 分支上做为现有工做资料库的一部分发布的代码库和工件被视为使用后果自负。
Eureka 1.x 是 Netflix 服务发现系统的核心部分，仍然是一个活跃的项目。

虽然 Eureka，Hystrix 等再也不继续开发或维护，可是目前来讲不影响使用，无论怎么说感谢开源，向 Netflix 公司的开源致敬。

另外一方面 Spring Cloud 支持不少服务发现的软件，Eureka 只是其中之一，好比咱们今天要讲的主角 Consul。下面是 Spring Cloud 支持的服务发现软件以及特性对比。

一、常见的注册中心

• Netflix Eureka
• Alibaba Nacos
• HashiCorp Consul
• Apache ZooKeeper
• CoreOS Etcd
• CNCF CoreDNS

 

二、Consul 介绍

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案，Consul 的方案更“一站式”，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，再也不须要依赖其它工具（好比 ZooKeeper 等），使用起来也较为简单。

Consul 使用 Go 语言编写，所以具备自然可移植性（支持Linux、Windows 和 Mac OS）；安装包仅包含一个可执行文件，方便部署，与 Docker 等轻量级容器可无缝配合。

 

三、Consul 特性

•  Raft 算法
• 服务发现
• 健康检查
• Key/Value 存储
• 多数据中心
• 支持 http 和 dns 协议接口
• 官方提供 web 管理界面

四、Consul 角色

client：客户端，无状态，将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。
server：服务端，保存配置信息，高可用集群，每一个数据中心的 server 数量推荐为 3 个或者 5 个。

首先，图中有两个数据中心，分别为 Datacenter1 和 Datacenter2 。Consul 很是好的支持多个数据中心，每一个数据中心内，有客户端和服务器端，服务器通常为 3~5 个，这样能够在稳定和性能上达到平衡，由于更多的机器会使数据同步很慢。不过客户端是没有限制的，能够有成千上万个。

数据中心内的全部节点都会加入到 Gossip (流言)协议。这就意味着有一个 Gossip 池，其中包含这个数据中心全部的节点。客户端不须要去配置服务器地址信息，发现服务工做会自动完成。检测故障节点的工做不是放在服务器端，而是分布式的；这使得失败检测相对于本地化的心跳机制而言，更具可拓展性。在选择 leader 这种重要的事情发生的时候，数据中心被用做消息层来作消息广播。

每一个数据中心内的服务器都是单个 Raft 中节点集的一部分。这意味着他们一块儿工做，选择一个单一的领导者——一个具备额外职责的选定的服务器。leader 负责处理全部查询和事物。事物也必须做为同步协议的一部分复制到节点集中的全部节点。因为这个要求，当非 leader 服务器接收到 RPC 请求时，就会将请求其转发给集群 leader。

服务器端节点同时也做为 WAN Gossip 池的一部分，WAN 池和 LAN 池不一样的是，它针对网络高延迟作了优化，并且只包含其余Consul 服务器的节点。这个池的目的是容许数据中心以最少的消耗方式发现对方。启动新的数据中心与加入现有的 WAN Gossip 同样简单。由于这些服务器都在这个池中运行，它还支持跨数据中心请求。当服务器收到对不一样数据中心的请求时，它会将其转发到正确数据中心中的随机服务器。那个服务器可能会转发给本地的 leader。

这样会使数据中心的耦合很是低。可是因为故障检测，链接缓存和复用，跨数据中心请求相对快速可靠。

总的来讲，数据不会在不一样的数据中心之间作复制备份。当收到一个请求处于别的数据中心的资源时，本地的 Consul 服务器会发一个 RPC 请求到远端的 Consul 服务器，而后返回结果。若是远端数据中心处于不可用状态，那么这么资源也会不可用，但这不影响本地的数据中心。在一些特殊的状况下，有限的数据集会被跨数据中心复制备份，好比说 Consul 内置的 ACL 复制能力，或者像 consul-replicate 这样的外部工具。

 

五、Consul 工做原理

 

5.1 服务发现以及注册

当服务 Producer 启动时，会将本身的 Ip/host 等信息经过发送请求告知 Consul，Consul 接收到 Producer 的注册信息后，每隔 10s（默认）会向 Producer 发送一个健康检查的请求，检验 Producer 是否健康。

 

5.2 服务调用

当 Consumer 请求 Product 时，会先从 Consul 中拿到存储 Product 服务的 IP 和 Port 的临时表(temp table)，从temp table 表中任选一个· Producer 的 IP 和 Port， 而后根据这个 IP 和 Port，发送访问请求；temp table 表只包含经过了健康检查的 Producer 信息，而且每隔 10s（默认）更新。

 

六、总结

本节讲述了常见注册中心，Consul介绍、特性、角色及工做原理，下一节将继续给你们讲述Consul 入门案例，请继续关注我，有须要微服务架构实战视频教程，请点击  Spring Cloud微服务架构