Consul学习笔记之-初识Consul

1. What is consul?

根据官方文档的定义：

HashiCorp Consul is a service networking solution that enables teams to manage secure network connectivity between services and across on-prem and multi-cloud environments and runtimes. Consul offers service discovery, service mesh, traffic management, and automated updates to network infrastructure device. You can use these features individually or together in a single Consul deployment.

HashiCorp Consul 是一种服务网络解决方案，使团队能够管理服务之间以及跨本地和多云环境和运行时的安全网络连接。Consul 提供服务发现、服务网格、流量管理和网络基础设施设备的自动更新。您可以在单个 Consul 部署中单独或一起使用这些功能。

2. Consul能干什么

• 服务发现：Consul的客户端可以注册一个服务，其他客户端可以使用Consul来发现特定服务的提供者。使用DNS或HTTP，应用程序可以很容易地找到他们所依赖的服务。
• 健康检查 : Consul客户端可以提供任何数量的健康检查，要么与给定的服务相关联（如： “webserver是否返回200 OK”），要么与本地节点相关联（如： “内存利用率是否低于90%”）。这些信息可以运维人员用来监控集群的健康状况，并被服务发现组件来路由流量（比如： 仅路由到健康节点）
• KV存储 ： 应用程序可以利用Consul的层级K/V存储来实现任何目的，包括动态配置、功能标记、协调、领导者选举等。Consul提供了HTTP API，使其非常简单以用。
• 安全服务通信： Consul可以为服务生成和分发TLS（ 传输层安全性协议）证书，以建立相互的TLS连接。可以使用Intention来定义哪些服务被允许进行通信。服务隔离可以通过可以实时更改Intention策略轻松管理，而不是使用复杂的网络拓扑结构和静态防火墙规则。
• 多数据中心: Consul支持开箱即用的多数据中心。这意味着Consul的用户不必担心建立额外的抽象层来发展到多个区域。

3. Consul的架构

Consul提供了一个控制平面，用来让你注册，接入和保护你部署在网络的中应用安全。这个控制平面是网络基础设施的一部分，它维护一个中心注册表来追踪各个服务及其对应的IP地址。
当使用Consul的服务网格能力时，Consul动态的在请求路径中配置sidecar和网关代理，这样让你授权服务到服务之间的连接，路由请求到健康的服务实例上，并且强制使用mTls加密却不需要你更改你的代码。这个确保服务之间的通信是高性能且可靠的。

上图是Consul的基本架构图

上图是用Consul实现service mesh的架构图

3.1 概念

• node：节点，运行 consul 服务，可以指定名字和 ID
• agent：consul 中的核心程序，以守护进程的方式在各个节点运行，有 client 和 server 启动模式。每个 agent 维护一套服务和注册发现以及健康信息。
• client：agent 以 client 模式启动的节点。不保存数据，直接把请求向 server 转发。
• server：agent 以 server 模式启动的节点，负责 Raft、维护会员信息、注册服务、健康检查等功能。
• server leader：服务器 server 的领导者。一旦 leader 宕机，会从剩下的 server 中选举一个新的 leader。

4. Consul VS Eureka

4.1 CAP

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

• 可用性（A）：保证每个请求不管成功或者失败都有响应。

• 分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。

4.2 对比

consul提供了一致性和分区容忍性(CP)，服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功，Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。

eureka保障了高可用性和最终一致性(AC)，优点是注册速度很快，不管同步到其他节点时是否有问题，只要服务注册到主节点既代表注册成功。当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。