背景

在分布式系统中，一次构建、发布、上线是非常非常重的一个过程，它不像单机时代那样重启一台机器、一个进程就可以了，在分布式系统中，它涉及到将软件包分发到可能超过几千台机器，然后将几千台机器上的应用进程一一重启，这么一个过程，一个应用一次完整的发布过程需要多长时间，相信很多核心系统的同学都深有体会；
而在不停应用集群的前提下，调整应用集群的运行特征，是作为一个分布式系统必须解决的一个问题。
从这个角度来看：统一配置中心是一个分布式系统都必须具有的一个角色。

配置中心架构

image.png

配置中心关注点

• 配置中心的弱依赖
  应用应该弱依赖于配置中心，如果配置中心挂掉，不能影响应用的正常运行
  所以客户端应该缓存配置数据
• 配置存储应该做好容灾备份
  配置中心的数据是不能丢失的，如果丢失了，估计几百个配置项就无法寻回，这种是无法允许的
• 推送时延和推送成功率
  如上节使用zookeeper来说，watcher机制并不能保证每一次配置的更改都推送给客户端，这种对于应用也是一件无法允许的事情
• 灰度
  如果使用zookeeper来做配置中心，做灰度是一件很难的事情，不是说不能做，是需要客户端去配合过滤一些不必要的数据，而这种造成了网络的垃圾开销及客户端的复杂度，下文会详细说
• 集中入口及变更审计能力

Zookeeper配置管理的局限性

• 配置数据大小的问题
  对于Zookeeper来说，数据大小直接影响了它的读写性能，身单个节点数据越大，对网络方面的吞吐就会造成影响，而zookeeper也添加了单个节点数据内容不能超过1M的限制，这个问题带来的解决方案有：
  1）一个应用一个节点，节点的内容存放所有配置数据，结果是一个节点数据估计有几十K，当Zookeeper进行数据同步时，带宽估计会被它全部吃掉；例子有：
  http://blog.jobbole.com/112233/
  2）一个Key一个节点，节点内容对应于Value，一个应用估计对应于几十个节点，运维管理成本大幅上升
• 配置数据环境属性不同的问题
  在现实中，配置数据是要具有环境属性的，相当一部分配置在不同的环境必须设定不同的值，但是也有相当的另一部分配置在不同的环境要设定为完全一致的值。所以从某个应用的视角看，其100个配置项，可能有50个是每个环境要不同的值的，而另50个是不区分环境；而zookeeper只要把数据写入了znode中，必然会把数据通知给各个客户端，这种做法带来了两个问题：
  1）垃圾网络开销；
  2）应用需要按照规则进行过滤不需要的配置信息；
• 集群下（Observer模式）同步的问题
  zookeeper为了提升写性能，增加了一直Observer的部署节点，该类型节点下不参与投票选举，只接收投票结果，该种模式一般多用于跨数据中心的部署，然而涉及到跨数据中心，就意味着网络抖动的问题，每一次网络抖动都会导致数据同步的重新进行（无论是差异化同步或者全部同步），这种情况下会导致连接到observer节点的数据不是最新的，从而导致配置数据无法及时通知到达
• Watcher注册机制
  许多人选择使用zookeeper做配置中心关键的一点就是watcher机制，但是使用watcher有几个要注意点：
  1. Watches通知是一次性的，必须重复注册.
  2. 发生CONNECTIONLOSS之后，只要在session_timeout之内再次连接上（即不发生SESSIONEXPIRED），那么这个连接注册的watches依然在。
  3. 节点数据的版本变化会触发NodeDataChanged，注意，这里特意说明了是版本变化。存在这样的情况，只要成功执行了setData()方法，无论内容是否和之前一致，都会触发NodeDataChanged。
  4. 对某个节点注册了watch，但是节点被删除了，那么注册在这个节点上的watches都会被移除。
  5. 同一个zk客户端对某一个节点注册相同的watch，只会收到一次通知。即
     Watcher对象只会保存在客户端，不会传递到服务端。

另外最主要一点就是zookeeper并不保证每次节点的变化都会通知到客户端，原因是因为当一次数据修改，通知客户端，客户端再次注册watch，在这个过程中，可能数据已经发生了许多次数据修改