2015 年 11 月 28 日，架构与运维的年度大趴——又拍云架构与运维大会·北京站圆满落幕了。近 1500 名来自全国各地的 IT 小伙伴们让现场热火朝天，而 23 位享誉互联网技术业界的大神们的登场，华为技术专家陈尔冬在会上作了题为《高性能运维专场：配置服务的“发迹史”》，以下是分享实录：
我今天的主题是配置服务。在华为，配置服务还处在一个起步的阶段，产生了一些经验和想法。我会根据自己的理解，和大家聊一聊构建一个环境怎么来考虑、怎么来设计、怎么来做这样的配置服务。
配置是什么
既然是配置服务，肯定会先解决配置的问题，为什么要有配置？举个例子，今天在座的男生很多，对于男生来说，就会想到汽车，一辆车可能会分为 4、5 种配置，甚至有的可能让我们自选配置：需要什么样的座椅？是电动的还是手动的？皮质还是非皮质的？而对于程序来讲道理相同：我们写程序的时候不能确认在一些场景下应该怎么样去做，比如面向小包传输和大包的吞吐，程序该怎么写？我可能只面向一端，但如果想两者兼顾，使用者就需要根据场景去设计如何去做。
配置就是解决这样的问题的，显然我们写程序需要配置，大家可能不光自己写程序，我们去用别人的程序都会有配置文件。除了配置文件之外还有其他的场景去进行配置吗？其实也有，环境变量用 java 的朋友会用得比较多，环境变量也可以做配置。我们写一个程序很多时候没办法在写程序之初就把这事情固定下来，所以我们会写一些程序，再留一些配置去把它配置出来。
我们系统架构里面可能不是一台服务器，不是对一个程序写一个配置文件就 OK 了，这种场合怎么办？服务器变多时怎么办？我们可能会引入一些配置工具、配置服务、配置系统来解决这个问题。其实这是一个比较实验性的方法，每个程序会有一个文件，我有很多服务器，中心有一个配置的系统，由这个配置系统去管理配置文件，并且把配置文件下发到相应的服务器上，能够比较简单、快速地解决这个问题。
有的公司可能不需要配置服务，但是如果服务器的规模继续往扩展，会有什么样的场景？如果系统规模变得更复杂，比如 10 万人的公司，有很多开发团队，每个开发团队之间会做一个小的模块，互相之间配合去通讯，如何怎么去通讯呢？如果不去管理，可能一个部门调 10 部门、调 100 个部门，这个时候 top 架构没法管理。所以针对这些问题，就孕育了配置服务的需求。
配置服务是什么
当服务器继续增多，云计算出现了什么不一样的东西呢？举个例子，当大规模单实例变成多实例，有很多应用有大有小，实例也很多，这个时候怎么办？云计算上面有很多很多的应用，有很多美国专家说过，云计算时代我们会面临一个很大的转变，不再去升级服务器就扩展业务。试想一下，谷歌在一个数据中心里面有 10 台服务器，如果有一两台服务器坏了，他完全不会去维修就把这台服务器直接剔掉。
如果我的公司有一两台服务器，会当作宠物去管，会细心呵护它，当它有问题、有疾病会去治疗它。但当负责服务器的数量增多、服务也增长，就像有数十万个宠物，往往就变成公牛模式，像养殖场养公牛，每个公牛不再取名字，而是取一个编号，前端机 1 号涨到前端机 10 万号，当有一台计算机损坏了怎么办？我会直接下线，如果是 Docker，直接销毁，如果是 Openstack，再起一个新的就好。仍然使用配置管理工具的情况下，这个服务可能会挂掉。
这样的变化很多，用人来做这些配置变化，显然不太能解决，这时候就会有人想一些方案，配置服务就应运而生了。而我们的配置也会扩展，除了我们传统的，比如说加一些降级开关，有吞吐，延迟两个方面的两端，可能这个服务要面向吞吐，那个服务面向延时，设置这个配置服务去解决这个问题，这个问题确实让人很挠头。可能几千台服务器有很多的配置，我希望这个配置快速生效，而且配置管理工具不能很好地解决问题，这时候就需要配置服务了。
到底配置服务是什么样的服务？离开具体的业务场景谈架构、谈系统实践都是耍流氓，我们看看具体的场景。
这是一个配置服务的场景，我把所有的服务器都向配置服务去抓取配置，这里面不一定是配置文件，可能就是一些数据，下面还可以有一些管理员，登到配置服务里面，或者是利用系统向我的配置服务里面辩证这个配置，或者有一个脚本，有一些服务依赖于这个配置服务就会同时生效。
做架构设计的时候需要考虑的原则
前一段时间我的大老板到美国谷歌去拜访。谷歌做搜索引擎、爬虫包括三件套的架构师非常有经验，所以我的大老板就问他，你认为什么样的架构是好的架构？什么样的架构适合华为？
那位架构大师认为，架构设计需要去妥协六个原则：
第一，简单。包括百度系统设计的原则也是要求简单、可依赖。对运维来讲，系统越简单就越容易运维，如果一台服务器，一个程序，用不着那些人，有问题我自己就能搞定；第二，扩展。要解决扩展问题；第三，性能。有很多人会问我，这个配置服务性能怎么样，性能其实不是问题，只要能花钱解决就不是主要的问题；第四，可靠。因为可以横向扩展，单机性能就不要那么强；第五，通用。为什么是通用问题，对于谷歌来讲可能会比较容易理解，所有其他的应用在同样需求情况下都使用一个基础服务，不会每个应用都写一个存储文件或者存这个内容，所以通用可以让整个技术团队带来更多的收益；第六，功能。我们可以看到架构设计里面最后一个环节才会讲到功能。
配置服务的数据模型
我们的配置软件大部分时候就是一个数据模型，这么简单需要 server 吗？完全不需要，想想大家的软件，大家有见过 1M 以上的吗？所有的文件加在一起有 1M 以上的吗？我相信肯定是少数，对一个数据库系统 1M 实在是太少了，你会看到很多数据库专家的分享，我们这个数据全平台有几百个 P 或者几百个 G，1M、2M 是一个太小的数据。
再看频率，大家会经常变更吗？有人说我很忙，一天会变数十次，是多还是少？非常少了，对一个数据系统来讲这个是太简单的要求，业务系统和配置系统哪个要求高？一个配置想要上线，如果线上有一段时间是上一个版本配置，基础架构好其实是没有问题，没有关系的，所以配置服务从设计来讲，技术难度非常小，数据量也不大，变更频率也不快，数据结构也简单，数据一致性要求还不高，这个系统就很简单了。
对性能的要求是什么样的？可以随时去查性能要求。但是放在一个远端网络上面要求就高了。数据的变化不高意味着很容易换，因为变化很少，如果每次变化的时候能及时通知到，这个性能需求是非常非常强的。
总结一下，配置服务对数据的模式来讲实在是太简单了，我们用一个比较成熟的存储系统就可以解决它的需求。只不过刚才我们提到了，第一，我们需要在配置这方面和读配置的程序对接起来，对接中间的协议是自己的开发团队比较习惯的方式就好了，因为它的需求实在是太简单了。设计一个配置服务，前面的接口层，后面的逻辑层，下面的存储层，都解决了。
配置服务的使用和设计
对一个配置系统，有很多技术专家在公司会存配置。微博用了 vintage，说明微博的稳定性做得不错。刚才我们分析了，这样的数据量，这样的频率，vintage OK 。性能也不是大问题了，即使后端宕机了，只要前面的数据还在，仍然可以取到数据。大家不一定要和微博一模一样，这取决于你的团队，可能系统结构里面的需求和微博不一样，配置量比较小，因为微博根本没有 1M 的配置。到底配置服务长什么样，我相信每家公司的服务配置长的都不是一样的。
微博的配置服务设计，既然有缓存，我们希望配置的生效更快一些，微博也做了一个更小的架构上的优化，当我有变更的时候，会去实时生效，这个是怎么做的呢？对于微博配置服务的客户端的展开会有一个通知器，通知器会到中心上面去抓取数据，如果发现 MD5 值不一样，就会更新配置内容。
举个例子，比如需要读配置的服务器的数量很少，只有数十台或者十百台，对一个服务器来讲是一个很简单的事情，当有配置更新的时候就推过去。但是如果数据中心的服务器的量有数亿台就不能解决这个问题，可能带来新的问题。所谓的架构设计就是在很多事情之间去做妥协，我并不能说某家公司做的系统架构一定适合你的公司，根据场景，我们会按照一个思路去考虑我们的系统。
就像我开始说的，配置服务是一个比较简单的服务，它的数据量很小，数据又不可能变化，逻辑关系又不复杂，我们去解决它，相应来讲是比较简单的。但是同样也牵扯到我所经历过的应用的理解，也许大家会有不一样的点，也欢迎有机会可以跟我面对面的交流。
