consul Consul vs. ZooKeeper, doozerd, etcd

小结

1、Consul 功能更丰富；

2、 暴露http接口避免暴露系统复杂性

The Consul clients expose a simple HTTP interface and avoid exposing the complexity of the system to clients in the same way as ZooKeeper.

3、健康检查health checking的不同实现；

Consul vs. Other Software - Consul by HashiCorp https://www.consul.io/intro/vs/index.html

The problems Consul solves are varied, but each individual feature has been solved by many different systems. Although there is no single system that provides all the features of Consul, there are other options available to solve some of these problems.

Consul vs. ZooKeeper, doozerd, etcd - Consul by HashiCorp https://www.consul.io/intro/vs/zookeeper.html

Consul vs. ZooKeeper, doozerd, etcd

ZooKeeper, doozerd, and etcd are all similar in their architecture. All three have server nodes that require a quorum of nodes to operate (usually a simple majority). They are strongly-consistent and expose various primitives that can be used through client libraries within applications to build complex distributed systems.

Consul also uses server nodes within a single datacenter. In each datacenter, Consul servers require a quorum to operate and provide strong consistency. However, Consul has native support for multiple datacenters as well as a more feature-rich gossip system that links server nodes and clients.

All of these systems have roughly the same semantics when providing key/value storage: reads are strongly consistent and availability is sacrificed for consistency in the face of a network partition. However, the differences become more apparent when these systems are used for advanced cases.

The semantics provided by these systems are attractive for building service discovery systems, but it's important to stress that these features must be built. ZooKeeper et al. provide only a primitive K/V store and require that application developers build their own system to provide service discovery. Consul, by contrast, provides an opinionated framework for service discovery and eliminates the guess-work and development effort. Clients simply register services and then perform discovery using a DNS or HTTP interface. Other systems require a home-rolled solution.

A compelling service discovery framework must incorporate health checking and the possibility of failures as well. It is not useful to know that Node A provides the Foo service if that node has failed or the service crashed. Naive systems make use of heartbeating, using periodic updates and TTLs. These schemes require work linear to the number of nodes and place the demand on a fixed number of servers. Additionally, the failure detection window is at least as long as the TTL.

ZooKeeper provides ephemeral nodes which are K/V entries that are removed when a client disconnects. These are more sophisticated than a heartbeat system but still have inherent scalability issues and add client-side complexity. All clients must maintain active connections to the ZooKeeper servers and perform keep-alives. Additionally, this requires "thick clients" which are difficult to write and often result in debugging challenges.

Consul uses a very different architecture for health checking. Instead of only having server nodes, Consul clients run on every node in the cluster. These clients are part of a gossip pool which serves several functions, including distributed health checking. The gossip protocol implements an efficient failure detector that can scale to clusters of any size without concentrating the work on any select group of servers. The clients also enable a much richer set of health checks to be run locally, whereas ZooKeeper ephemeral nodes are a very primitive check of liveness. With Consul, clients can check that a web server is returning 200 status codes, that memory utilization is not critical, that there is sufficient disk space, etc. The Consul clients expose a simple HTTP interface and avoid exposing the complexity of the system to clients in the same way as ZooKeeper.

Consul provides first-class support for service discovery, health checking, K/V storage, and multiple datacenters. To support anything more than simple K/V storage, all these other systems require additional tools and libraries to be built on top. By using client nodes, Consul provides a simple API that only requires thin clients. Additionally, the API can be avoided entirely by using configuration files and the DNS interface to have a complete service discovery solution with no development at all.

https://mp.weixin.qq.com/s/S4GUx-z4lZxoIeUiNLd_Uw

个推基于Consul的配置管理

原创： 阿飞 个推技术学院 2月25日

作者：个推应用平台基础架构高级研发工程师 阿飞

在微服务架构体系中，由于微服务众多，服务之间又有互相调用关系，因此，一个通用的分布式配置管理是必不可少的。一般来说，配置管理需要解决配置集中管理、在系统运行期间可实现动态配置、配置修改后支持自动刷新等问题。

在大多数微服务体系中，都会有一个名为配置文件的功能模块来提供统一的分布式配置管理。构建配置中心，统一对应用中各个微服务进行管理，对微服务体系的意义重大。

Consul为什么适合做配置管理

Consul作为轻量级的分布式K/V存储系统，搭建方便，可用性高，并且支持多数据中心，提供Web UI进行K/V管理。此外Consul还可以结合Consul-Template或者在代码中引入Consul Client的相关依赖创建Watcher来实时Watch K/V的变化，是配置管理的不二之选。

下图为个推微服务体系基于Consul配置管理的整体设计。其中，CCenter就是在Consul的基础上进行二次开发的配置中心。

微服务体系下配置的分类和组织形式

在实践中，不同产品线的配置会放置在Consul的不同路径下，实现不同产品线配置之间的隔离。

---

按照配置的用途，可将同一产品线下的配置分为三类：

1.API网关相关配置；

2.服务注册与发现相关配置；

3.应用相关配置。

其中，每类配置会对应Consul上的不同目录。

---

按照配置的变化特性，可将配置分为两类：

1.环境相关的全局配置

如MySQL等外部依赖相关的配置和其他与环境相关的配置，这类配置在开发测试生产环境中存在差异，需要为不同环境配置不同的值。
2.应用本身的配置

一般为不经常性发生变化、可动态调整、开关的配置。这类配置比较稳定，在初始化后，只有在需要时才会改动，通常会设置默认值。这两类配置在Consul上会放在不同的子目录下。这样QA、运维只需要关注环境差异部分即可。

基于以上对配置的分类，最终Consul上的Key的格式如下：

/ProductLine_Prefix/Usage_Prefix/Environmental_Correlation_Prefix/Config_Item_Path

其中，

ProductLine_Prefix：用来隔离不同产品线的配置；

Usage_Prefix：用来区分配置的用途；

Environmental_Correlation_Prefix：用来分隔与环境相关的配置；

Config_Item_Path：具体的配置项。

配置在Consul上的组织形式有以下两种：

1.以配置文件的形式组织，Consul上的一个K/V，对应一个配置文件，如nginx的配置文件。

2.以配置项的形式组织，将配置文件模板化，拆成一个个的配置项，每个配置项对应Consul上的一个K/V，多个配置项对应一个配置文件。大部分配置文件本身都是以K/V的形式组织的，均适合模板化，模板化后即可以按照配置项的特性，在Consul上分成不同的类别进行管理。

如何实现配置更新

Consul上的K/V，要如何生成可加载的应用，或可使用的配置呢？

1.用Node和Lua实现的微服务的配置更新，使用Consul-Template来实现；

2.用Java实现的微服务的配置更新，通过Consul-Template工具（需要重启应用）和在代码中引入Consul Client的依赖创建Watcher（热更新）这两种方式来实现。

---

Consul-Template如何使用？

Consul-Template是一个后台进程，它可以根据Watch Consul上K/V的变化，更新任意数量的模板，同时生成对应的文件，之后还可以运行任意的命令。要使用Consul-Template一般需要定义两个文件：

1.模板文件

模板文件一般按照Go Template的格式进行编写，示例如下：

config-tree.ctmpl:

{{ tree /consul/path/to/configFiles | explode | toJSONPretty }}

该模板在/consul/path/to/configFiles路径下的配置发生变化时，会渲染出一个Json格式的字符串，其中包含了/consul/path/to/configFiles下所有的K/V.

config-kv.ctmpl:

return {
   host='{{ printf "%s/mysql/host" (env "CONSUL_CONFIG_PREFIX") | key }}',
   port={{ keyOrDefault (printf "%s/mysql/port" (env "CON-SUL_CONFIG_PREFIX"))  "3306" }},
    user='{{ printf "%s/mysql/user" (env "CONSUL_CONFIG_PREFIX") | key }}',
   password='{{ printf "%s/mysql/password" (env "CON-SUL_CONFIG_PREFIX") | key }}'
}

该模板是按照配置项来渲染的，在该模板中使用了Consul-Template定义两个方法key和keyOrDefault。其中，key会在Consul上对应的K/V创建后，再进行渲染模板；keyOrDefault则会在Consul上没有对应的K/V时，使用默认值代替。

模板中还使用了 " CONSUL_CONFIG_PREFIX " 这个环境变量，这样，不同的产品线便可以使用同一个模板文件，只需要修改" CONSUL_CONFIG_PREFIX "这个环境变量的值即可。

2.配置文件

配置文件是按照HashiCorp Configuration Language (HCL)编写的，示例如下：

template {
 source = "config-tree.ctmpl",
 destination = "config-tree.json",
 command  = "sh updateAndReload.sh config-tree.json”
}

template {
 source = "config-kv.ctmpl",
 destination = "config-kv.lua",
 command  = "sh updateAndReload.sh config-kv.lua”
}

该配置文件的作用是使用" source"指定的两个模板文件进行渲染，将渲染的结果分别保存在" destination"指定的文件中，保存成功后，分别运行" command"指定的命令来更新并加载配置文件。

---

配置的更新方式

在个推的微服务体系中，配置的更新方式有两种：

1.替换配置文件，reload服务

2.调用服务接口直接更新内存中的配置

而在Java实现的微服务中，热更新配置通常是在代码中引入Consul Client的依赖，在应用启动时，会初始化一个Watcher来监听Consul上对应目录下K/V的变化，相关的K/V发生变化时，Watcher会负责将其拉取下来，然后调用相关的代码进行配置的更新。

基于Consul的二次开发-CCenter

配置中心CCenter在Consul上提供了更友好的WEB UI，并且增加版本控制，每次配置的更新都会生成一个版本，在应用版本后，配置才真正生效，可以更加方便地进行配置版本间的差异比较，应用任意版本的配置。

总结

以上就是个推在微服务实践中，基于Consul实现的一套配置管理的方案，作为轻量级的分布式K/V存储系统， Consul非常适合用于配置管理，可以帮助开发者们方便、快速地搭建配置中心，结合Consul-Template则可以方便地实现配置的实时更新，在Consul的基础上进行二次开发，实现了配置版本的有效控制，对微服务的配置管理起到了良好的辅助作用。