常识系列,作为一名互联网门外汉的科普系列
本来这篇文章想谈一下zookeeper，现在已经家喻户晓了。结果看到江南白衣的文章
提到配置中心就跟你讲zk,etcd的，可能是个空想玩家，或者他家系统很小；
不由得冒了两滴冷汗，高人总是一针见血。
所以还是多关注一下互联网的架构，而不是技术的细枝末节
本篇涉及到的内容包括：
- 游戏中配置中心的进化
- 什么样的配置中心才叫好
- 流行架构
- zookeeper
配置中心
什么是配置中心？简单来说，就是一种统一管理各种应用配置的基础服务组件
服务一般有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境(开发/测试/生产)一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期可能还要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。
传统配置文件方式虽然把配置项分离到单独的配置文件，但是修改一个配置项，需要提交版本管理，发布，重启。整个过程比较麻烦，特别是发布多台机器。整个配置上线流程跟修改代码没有太大区别。不利于集中式管理和动态调整。
现在一般架构中都有个配置中心了，不管是独立还是集成，都有这么一块空间，尤其在微服务流行之后，服务之间有着错综复杂的依赖关系，更是必不可少。
配置中心进化史
这儿谈的进化史，是一款月流水过亿的游戏配置中心填坑的过程。当然，那时我们还不叫配置中心，也不知这世上还有个配置中心的术语。不要笑，我们那时就是这么的无知无敌。
游戏开发中，除了基础的技术配置文件，如数据库连接配置，连接池配置；有很多的业务配置文件，如各个道具信息，怪物信息，活动信息
这此配置信息，可能是动态的，也有些是静态的。
动态配置和静态配置的区别 曾经我也傻傻分不清楚其区别是啥，这很正常。动态和静态这是一个相对的概念，海枯石烂，永远不变的那不叫配置，可能是撩妹的鬼话,即使这个配置可能是放在一个看起来很像配置文件的文本里，配置一定是可能修改其值的，而是否是动态配置主要是看这个配置是不是跟应用的版本构建发布(build-deploy lifetime)强绑定的。如果一个配置项，跟软件的版本构建是不耦合的，在应用进程运行时，可能需要变更配置值的就是动态配置，哪怕是变更频率可能非常低，也许你设计了一个配置项，发现最后下来3年也没变更过一次，那也是动态配置，相反，配置变更只发生在软件版本构建和发布的那个点，那么就是静态配置，哪怕你构建很频繁，1个小时就来一回，那也是个静态配置，举个简单的例子: build-version = 3.4.6-1569965 这个配置项，永远只在某个软件版本被构建出来时会变更其值，一旦这个版本被构建出来，并且在程序运行时，是一定没有变更诉求的，这就是一个跟构建绑定的静态配置。而文章开始时举得logLevel的例子，则是一个动态配置的例子。 所以看一下你的系统的配置项，你会发现动态配置其实更多，而跟行为演进相关的几乎都是动态配置。
第一版本
大体的架构如下：
这是一个pull模型
组成部分：
- 配置服务器
- 游戏服务器
首先配置服务器提供上传文件功能，以及被配置文件下载的能力。
比如寻宝活动 xunbaoconfig 上传时会选择对应的游戏区服，会产生两个文件
- xunbaoconfig，配置参数文件 文件中保持了文件md5值，游戏区服与文件对应关系 [gameserver1,md5,xunbaocinfig-xxxx.conf]
- xunbaoconfig-xxxx.conf 配置文件 这就是上传的最新配置文件
其次，游戏服务器需要提供支持动态配置的能力。并且定时去拉取远程配置文件，比对远程文件与当前内存中的是否一致，若不一致，重新加载配置文件
伪代码：
代码语言：javascript复制//配置文件MD5值与配置的对应关系
configMap<cofingFileMd5,Config>游戏服务器定时去拉取相应的配置参数文件，xunbaoconfig，获取当前区服配置文件的md5值以及文件名。
若md5值与缓存数据不一致，就拉取真实的xunbaoconfig-xxx.conf文件
问题
此版本，看似一切正常。
在韩服开到十几个区的时候，出现了一个问题
文件下载不完整
更换tomcat
这儿使用的web容器是tomcat，其中的原因当时没有细究了。后来让运维换成了ngnix，静态资源一律走ngnix就没有问题了
国服开到几百个区时，也出现了类似问题，每次维护后，几百个区一起开启，会有部分区，启动失败，因为加载不到配置文件；或者是没有加载到新配置，使用了老的配置。
分析下来，几百个区服几乎在同一时刻去配置服务器拉取文件，配置服务器压力即大，这也就是单点瓶颈故障。
就算没有这次的故障，后面开到几千个区服时，也会出现带宽瓶颈。大一点配置如果有5M，那一千个服就是5G，不仅是单台服务器的带宽，可能会严重阻塞整个机架的带宽。
动静分离
为了解决这个问题，不能把所有文件都放在配置中心了，需要分离，把静态的配置文件直接放到区服上，不用再去拉取。
虽然动静分离，但也只是减轻了这种状况，并没有彻底解决。
第二版本
这是push模型
第一版本，每个区服都去拉取配置，给配置服务器带来了很大的压力
现在配置不再以每个区服为单位，而是以物理服务器为单位推送配置文件。
首先，上传配置文件，与pull模型一致。
再使用rsync同步到每个区服的物理机上，原先一台物理机上会开设八台逻辑服，现在以物理机为单位，配置中心的压力大大的下降。
而且rsync不再是定时去同步，而是当配置变动时，再去主动触发
配置中心标准
什么样的配置中心才是好的配置中心
- 不能单点，以上面的进化实例，明显如果配置中心挂了，那整个游戏就失去了动态能力，如果本地没有动态配置文件备份，就完全丧失服务能力
- 支持web界面，可视化操作；这是很多技术人员的通病，直接上个shell命令，多专业，其实这降低真个系统的可用性，可维护性
- 权限管理、发布审核、操作审计；1、应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误，2、所有的操作都有审计日志，可以方便地追踪问题，回滚也方便
- 灰度发布
- 版本发布管理；所有的配置发布都有版本概念，从而可以方便地支持配置的回滚
- 实时推送；现在很多配置中心使用zk之类框架，主要就是用它的发布订阅实现实时推送能力
客户端支持
配置中心拥有这些能力，还需要客户端的支持
- 配合配置中心的实时/灰度推送，在参数变化时调用客户端自行实现的回调接口，不需要重启应用。
- 支持环境变量，JVM启动参数，配置文件，配置中心等多种来源按优先级互相覆盖，并有接口暴露最后的参数选择。
- 配置文件中支持多套profile，如开发，单元测试，集成测试，生产。
流行框架
配置中心，这么重要的组件，众目聚集，也就诞生了很多开源产品
业界也有很多比较成熟的开源项目：
- disconf: 百度开源的分布式配置管理平台。项目文档上说百度、滴滴打车、银联、网易、拉勾网等知名互联网公司在使用。挺新的项目，并且目前只支持Java语言。
- QConf: 360开源的分布式配置管理平台。跟disconf一样使用了zookeeper做配置存储，不同在于QConf使用了agent和共享内存的方式，并且支持多种语言。
- Diamond 淘宝开源的持久配置的管理系统，支持各种持久信息（比如各种规则，数据库配置等）的发布和订阅。特点是简单，存储是MySQL，并且是拉模式。
- Spring Cloud Config: 特点就是与Spring完美结合
不管是何产品，架构都可以简化为：
zookeeper
Zookeeper有两篇论文：
一篇是Zab，就是介绍Zookeeper背后使用的一致性协议的(Zookeeper atomic broadcast protocol)
一篇就是介绍Zookeeper本身的。在这两篇论文里都提到Zookeeper是一个分布式协调服务(a service for coordinating processes of distributed applications)。
这下次再开一篇，内容不少！
参考资料
服务化体系之－配置中心，在ZK或etcd之外
