Consul微服务架构探索之路

Consul介绍

Consul是一个分布式的，高可用、高拓展性的，支持数据中心的服务发现和配置系统

目前比较主流的注册中心有Eureka、Consul、zookeeper、etcd等

与其它分布式服务注册与发现的方案相比，Consul 的方案更“一站式”——内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具。Consul 本身使用 go 语言开发，具有跨平台、运行高效等特点，也非常方便和 Docker 配合使用。

Consul的关键特性

服务发现(Service Discovery) Consul的客户端可用提供一个服务,比如 api 或者mysql ,另外一些客户端可用使用Consul去发现一个指定服务的提供者.通过DNS或者HTTP应用程序可用很容易的找到他所依赖的服务.
健康检查(Health Checking) Consul客户端可用提供任意数量的健康检查,指定一个服务(比如:webserver是否返回了200 OK 状态码)或者使用本地节点(比如:内存使用是否大于90%). 这个信息可由operator用来监视集群的运行状况.被服务发现组件用来避免将流量发送到不健康的主机.
Key/Value存储(KV Store) 应用程序可用根据自己的需要使用Consul的层级的Key/Value存储.比如动态配置,功能标记,协调,领袖选举等等,简单的HTTP API让他更易于使用.
多数据中心(Multi Datacenter) Consul支持支持任意数量数据中心.这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域.
安全服务通信(Secure Service Communication)
Consul可以为服务生成分布式的 TLS 证书，以建立相互的 TLS 连接。 可以使用 intentions 定义允许哪些服务进行通信。 可以使用 intentions 轻松管理服务隔离，而不是使用复杂的网络拓扑和静态防火墙规则。

Consul的优势对比

相较于现在比较流行的微服务发现组件,例如Eureka、zookeeper、etcd，与其他三款发现组件进行了对比

• Consul集群间使用了GOSSIP协议通信和raft一致性算法。 比复杂的 Paxos 算法更直接。
• 支持多数据中心，内外网的服务采用不同的端口进行监听。多数据中心集群可以避免单数据中心的单点故障，而其部署则需要考虑网络延迟, 分片等情况等。 zookeeper 和 etcd 均不提供多数据中心功能的支持。
• 支持健康检查。 etcd 不提供此功能。
• 支持 http 和 dns 协议接口。 zookeeper 的集成较为复杂, etcd 只支持 http 协议。
• 官方提供 Web 管理界面, etcd 无此功能。
• Consul 保持了 CAP 中的 CP，保持了强一致性和分区容错性。
• Consul 支持 Http\gRPC\DNS 多种访问方式。

基础架构

• Server :

1. 是consul服务端高可用集群
2. 保存配置信息, 持久化数据
3. 在局域网内与本地客户端通讯, 通过广域网(WAN Gossip)与其它数据中心通讯,转发请求给Server-Leader
4. 每个数据中心的 Server 数量推荐为 3 个或是 5 个。

• Client

1. 是consul客户端
2. 无状态，不持久化数据
3. 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。

• Agent

1. 是一个守护线程
2. Agent与一个和多个Consul Server 进行交互,