反熵

Consul使用了先进的方法来维护服务和健康信息。 本篇文章的将详细介绍下服务和服务检查是如何被注册地，Catalog又是如何被填充地，以及当服务健康状况变化是，服务健康信息是如何更新地。

»Components（组件）

首先，了解下服务和健康检查涵盖的两个比较重要的概念： Agent(代理)和Catalog（服务目录）; 接下来描述的也将使反熵更容易理解。

»Agent（代理）

每个Consul代理（Agent） 都有自己的一套服务(services) 和 检查(checks) 的注册信息，以及健康状况(status)信息。代理负责执行健康检查以及更新本地状态。

代理上下文中的服务和检查有丰富的配置选项可用。 这是因为代理负责通过使用运行状况检查生成有关其服务及其运行状况的信息。

»Catalog（目录）

Consul的服务发现是由服务目录(Catalog)支持的。此目录是通过聚合代理(Agent)提交的信息而形成的。目录维护集群的高级视图，包括哪些服务可用、哪些节点运行这些服务、运行状况信息等等。目录用来暴露这些信息， 通过consul提供的各种接口（包括DNS和HTTP）。

与代理相比，目录上下文中的服务和检查的字段集要有限得多。这是因为目录只负责记录和返回有关服务、节点和运行状况的信息.

»Anti-Entropy（反熵）

Consul反熵模型

熵是系统变得越来越无序的趋势。Consul的反熵机制旨在对抗这种趋势，即使在组件发生故障的情况下也能保持集群的有序状态。

如上文所述，Consul在全局服务目录和代理的本地状态之间有明确的分隔。反熵机制协调了这两种世界观：反熵是本地代理状态和目录的同步。例如，当用户向代理注册新服务或检查时，代理又通知目录此新检查存在。类似地，当从代理中删除检查时，它也会从目录中删除。

反熵还用于更新可用性信息。当代理运行健康检查时，节点和服务的状态可能会更改，在这种情况下，新的新状态将同步到目录。使用这些信息，目录可以根据节点和服务的可用性返回他们的最新的状态。

在此同步过程中，目录还将检查目录的正确性。如果目录中存在代理没有的任何服务或检查，它们将自动从目录中删除，以使目录正确地反映该代理的服务和运行状况。Consul数将代理的状态视为权威；如果代理和目录视图之间存在任何差异，则始终使用代理本地视图。

»Periodic Synchronization（周期性同步）

除了在代理发生更改时运行之外，反熵也是一个长期运行的进程，它定期唤醒以同步服务和检查状态到目录。这样可以确保目录与代理的真实状态紧密匹配。这也允许Consul在完全数据丢失的情况下重新填充服务目录。

为了避免饱和，周期性反熵运行之间的时间量将根据集群大小而变化。下表定义了群集大小与同步间隔之间的关系：（PS: 数量其实是 Agent 数量）

集群大小	周期性同步间隔
1-128	1分钟
129-256	2分钟
257-512	3分钟
513-1024	4分钟
...

上面的间隔是近似的。每一个Consul 代理都会在间隔时间内随机选择一个交错的开始时间，以避免都挤到一起。

»Best-effort sync （最大努力同步）

反熵在许多情况下都可能失败，包括代理或其操作环境的错误配置、I/O问题（完整磁盘、文件系统权限等）、网络问题（代理无法与服务器通信）等等。因此，代理尝试以最大努力的方式进行同步。

如果在反熵运行期间遇到错误，将记录该错误并继续运行代理。反熵机制定期运行，以自动从这些类型的瞬态故障中恢复。

PS: 我理解的意思是说， 如果遇到错误，将继续运行代理。 下个周期可能将自动恢复。

»Enable Tag Override(启动标签覆盖)

可以部分修改服务注册的同步，以允许外部代理更改服务的标记。这在外部监视服务需要作为标记信息的真实来源的情况下非常有用。比如Redis数据库和它的监控服务Redis Sentinel就有这种关系。Redis实例负责其大部分配置，但是sentinel决定Redis实例是主实例还是辅助实例。使用Consul服务配置项enable_tag_override，可以指示运行Redis数据库的consul代理在反熵同步期间不更新标记。有关更多信息，请参阅服务页。