小小配置中心释放大能量-张乐

黄晓轩

讲师 | 张乐
编辑 | 黄晓轩

讲师简介

张乐
携程中间件研发工程师

前言

为什么说配制中心很小呢。一方面是在配制上，我觉得很多人开发人员忽略配制，更多是专注于代码编写，而忽略配置怎么管理。另一方面配制中心是八大核心中间件里面是比较小的一个系统，但在行业内并没有一个能一统江湖的配制中心。释放大能量，就是我们开发者日常开发过程中可以通过配制中心做很多的事情，我觉得作为我们的运营，有时候也可以通过一些配制中心提供一些能力做一些管理。

一 被忽视的配置

我觉得很多同学并没有时间对配制专门的进行研究和分析。这一句话是在这维基百科上，简单的讲配制就是做为程序初始化的一些配制文件。他的定义我觉得是有点过时了，现在基本上每个公司都有配制中心。如果有了配制中心，配制不仅仅是做为程序初始化应用启动的配制，也可以在应用运行时通过配置来做一些控制。

这里提到在一个项目开发过程中，配置是随处可见的。
第一个最简单的就是硬编码的方式。
第二个是项目里的配置文件。一个典型的JAVA的maven项目有一个resources目录，这个目录基本上都是放置配置文件的，那么硬编码方式跟配置文件方式是没有本质的区别，为什么这么说呢？其实这两种方式你的配置都是跟着你发布的程序包。如果你要修改一个配置，你都要重新修改源代码，或者修改配置文件，然后重新上传、打包、部署，这一个流程是很繁琐的。如果你修改错了一个很重要的配置，可能就出了一个大故障。
第三个文件系统上的配置文件。比如我的应用是集群部署的，我的配置文件不是放在项目包里面，而是在这台部署应用上面的文件系统上的某个配置。那这样相比前两种方式，有一个提升，就是我把配置已经从项目里面脱离出来了，就是把配置给隔离出来了，那这样做的好处是可以动态的修改配置，我不需要每次打包重新改配置，那么程序里面最简单的写一个定时器就可以更新配置。但这种方式有一个很大的问题，就是我改配置的时候假设这个应用有10台机器，需要登陆每一台机器一个一个去更改，这明显是不靠谱的。
第四种方式是网络上的配置文件。有两种方式，第一种就是大部分如果一个公司没有一个统一的配置中心的话，很多公司，很多项目团队都会自己把配置放在数据库里面。通过放在数据库里面，也可以做到第三种的方式。但是还有一个好处，如果你放在数据库里面的话，就相当于把配置文件集中化管理的，只需要改一下数据库，程序里面所有读到的配置也能一下子生效，就不需要一个个登机器修改配置了。那另外一种网络配置文件就是配置中心了。
除了应用的配置之外，还有很多其他的配置。比如说JVM参数，应用启动参数，另外操作系统的配置，可能也是运维更关心这方面的配置。

我一开始讲到，很多开发人员是忽略配置的。我这两年一直做配置中心，所以对配置有过更深入的理解。
第一个配置是等于代码。配置应该像代码一样，也是需要review、测试、发布，一个环境一个环境走上去得，并不是改一下配置很简单而不重视。我相信很多公司都出现过因为配置的更改导致生产事故。
第二个配置又不等于代码，为什么这么说呢？首先，配置是没有逻辑的，不像代码可以通过上下文看代码的逻辑，猜测这行代码是什么意思。但是配置只能通过你的名字去辨别我的配置什么意思，所以说一旦你的配置不管理好的话，其实是很头疼的。其次，配置其实更多的是一种约定的规定，大家知道，不管学习任何一个框架，或者使用任何一个系统，换一个角度讲，我们大部分情况下是学习怎么配置这个系统。如果一个系统或者一个中间件它的配置定义的很不好，而且配置烦琐的话，那么他的使用门槛是很高的。所以说你是作为一个中间件的开发者，或者一个系统的研发者，一样管理好你的配置，让你的用户更好的配置你的系统，是非常重要的。说白了这是一种约定的规则，而不是逻辑。

配置的最佳实践：

• 尽可能的减少配置、配置文件，甚至是零配置。
  不知道大家有没有了解过JAVA最流行的一个技术栈spring boot，相比传统的java项目是特别干净，默认情况下只有一个配置文件，所以他的项目是特别特别的干净。比如我一个系统交接给另外一位同学，配置少的话交接起来也会特别的顺利，如果大家都用就有很明显的感触，如果配置特别多的话，基本上很难理解和维护，因为他不像代码可以跳来跳去，通过一定的方式推测出来。
• 优雅、简单的配置方式。
• 配置名比代码命名更具有可读性。
  因为配置是没有逻辑的，所以一个用户怎么配置基本上是通过配置名字去判断的。

二 配置中心概述

第二部分就是刚才提到的配置中心。配置中心有哪些能力，怎么更好的管理我们的配置，怎么更好的去解决上述提到的，就是前面几种方式配置的一些痛点呢？

• 集中管理不同环境、集群的配置。
  这是配置中心解决两大核心问题的第一个问题。因为每个公司都有很多的环境，有一些配置是需要每个环境配置是不一样的。一些传统的做法就是我通过运维的一些工具，通过打包的时候，每个环境打不同的包，每个配置值是在打包的时候传入的。通过配置中心之后，我就可以做到一个发布包能随便发到任何一个环境，不需要多次打包发布。这也是网络上的配置文件的一个优势，就是配置跟代码是隔离开的。
• 权限治理。
  我们配置也应该像代码一样需要review，测试，发布。这就涉及到了权限管理。如果配置都统一管理起来的，我做权限管理是很好控制的。一般配置系统有三个权限，配置更改、审核、发布。每个公司他们权限定义是不一样的，有些说是我开发就可以做到，所以这三个步骤都是开发做的，有些公司说我的配置发布应该是运维做的。我就很难理解，我的理解是运维不懂你的应用里面某一个配置项是什么意思，你让他发布会帮你做审核，做一些其他事情呢，我觉得未必，最多就是点一下按纽发布一下。单单是从这个方面控制权限是没有意义的。另外权限跟易用性是向背的。如果你的权限控制的很严，那整个流程和效率就会降低，所以这也是考量的一个步骤。
• 配置变更历史。
  这个很好理解，每次配置变更和发布，都是有记录存下来的。当由于配置变更导致故障时，可以很快的查到变更内容。
• 配置版本化管理。
• 灰度发布。
  很好理解，假设一个应用有十台机器，例如JVM调优需要在生产上某一台机器上先测试一下，如果性能OK的话才会一批一批的发布，把我的配置应用到所有的机器上去。这也是一种很好的方式。大部分市面上的配置中心，他只能做到以IP的粒度进行灰度，在阿波罗里面就有一些公共的配置，他可能是需要按应用的粒度去灰度的。
• 私有配置跟公共配置。
  大部分的应用，我的配置文件是不希望被其它应用给读取到的，我自己应用下面的配置只能被我自己读取，其它应用是不能读取的。相对公共的配置，其实用的比较多的是一些公共的组件，或者是一些中间件，比如说MQ的客户端，它是运行在不同的应用下面，所以它没有一个自己的APP的概念，这样的场景它就是需要取公共配置。
• 共配置可继承覆盖。
  这也是非常实用的功能。刚才提到的MQ，我们一个MQ的系统默认消费线程数是一个，某一个应用，这时候消息团队，在配置中心上提供了一份默认的配置，这个配置消费线程数就是1。那么突然某一天，某一个业务方找过来了，说我的消费有积压了，怎么提高我的消费能力。最直观的方式，通过增加消费线程数解决这个问题，怎么做呢？只需要在业务方配置中心上面继承一下提供的默认配置文件，然后将消费线程数改成10并覆盖掉这个配置项，就可以在业务应用不重启的情况下，立马就调成了10，所以是非常方便的。如果你不覆盖的话，大家都默认用一个消费线程的。
• 开放平台API。
  配置中心对客户端来说，更多是只读的API，不应该简单的把配置的更改发布也开放到客户端里面去。那你的配置管理就没有意义了，但是有很多时候是有这种场景需求的。也就是说需要我的代码去更改配置，而不是人去改配置，这种场景是非常多的。怎么做呢，可以通过配置中心提供了开放平台API的方式接入，控制某一个应用，比如我给你发一个token，你只能管理这几个应用下面的配置。

配置的坐标维度有哪些呢？

• 应用。
  一般配置中心都是以应用做为一个最大的坐标。
• 文件。
• Profile。
  这个就是刚才提到的环境也可能是集群。现在大公司，很多时候都是多机房部署的，比如说携程，有些配置在机房A下面的配置，跟机房B下面配置的值是不一样。配置中心就可以支持这种场景。
• 配置项。

通过这四个维度可以精确的定位到一个配置。

配置中心客户端都有哪些功能？

• 提供多语言原生客户端。因为大家都知道携程是国内最大的.net公司，最近又做JAVA比较多。在做中间件时，就比较麻烦，两个都要考虑。
• 支持Http REST方式获取配置。
• 集成Spring。
• 配置变更回调。这也是非常重要的功能。有时候我的应用需要在配置变更的时候做一些事情，比如说重新初始化我的数据源，我是不是要重新去初始化我应用的连接词。那这样做到一个点，就是我需要在我配置变更的时候监听到一个事件，然后去做某些事情。

配置中心第二个核心特性就是热发布。就是配置实时生效。如果没有配置中心，大家每个业务自己做一个配置中心的话，把配置放到数据库里面，最简单的方式就是写一个轮询，比如1分钟到数据库load一下配置。如果有了配置中心之后，可以做到实时，比如一秒钟之内，配置就能下发到这个应用下的所有机器，所以是非常核心的功能。

三 配置中心在实际场景中启到的大作用

场景一：功能开关

我统计了一下在携程内部，它的配置的类型，发现60%、70%都是开关类的配置。我以前也是做业务开发的，这个也是非常好理解。举个最简单例子，比如在携程页面上，新增加了携程的酒店详情页，新增加了业务模块，然后我的做法就是加一个开关，一旦发现有问题有投诉，我立马到配置中心把这个开关关掉，我的页面上马上这块功能就消失掉了，就回退掉了，所以这个是很常见的一个场景。所以在以前点评的时候，就发现很多这种开关，其实这几行代码都是没用的代码，换句话说有了便利就任意妄为了，就带来其他的问题。

场景二：就是ABTest、业务灰度

大一点的公司，他公司内部可能有单独的一套ABTest的框架，如果没有的话，通过配置中心也是很好做的。比如说以携程酒店为例，如果这是新增加了一个功能，但这个功能不想一下子全国都铺广开来。那在配置中心上面增加一个配置项叫“开放的城市列表”，我可以先让部分城市生效，如果发现有问题了，立马关掉，都回退了。如果发现还不错，那我就扩大开放的城市。这样做的好处就是说开通这种城市，不需要重新发布我的应用，只需要在配置中心上面点一下发布按纽就OK了，这个效率其实是非常高的。

场景三：动态数据源

动态数据源也是很常见的一个通过配置中心应用的例子。携程最近也在做。比如业务的数据库，发现性能不行了，或者硬件某个磁盘坏了，传统的方式就是通过一堆十几分钟的操作才解决这个问题，可能十几分钟都算快的。如果有了动态数据源就很方便，我把我的数据源切到DBA新起的一个数据库实例，通过配置中心把连接串更改，所有的流量都导到新的库里面去，这个操作对业务来说也是透明的，也是非常方便。最简单的做法，就是我刚才提到在配置变更的时候，重新初始化一个数据库连接池，然后把新的流量都导到新的连接池，等老的连接池所有的流量都释放干净之后，才把老的连接池给释放掉，这是最简单的一种做法。

场景四：服务注册发现

在阿里，他的服务发现跟配置中心是绑定在一起的。一个团队他会既提供配置中心，又提供服务发现，在组织架构上也是在一起的。因为现在服务注册发现说白了就是配置变更和下发，这件事情只要在我配置中心上面封装一下，就能很简单的做到服务注册发现。比如说像点评服务注册发现，就基于配置中心去实现的。

场景五：通知

在做配置中心的时候有业务同学找我说，因为你的配置中心不是有能实时生效的功能，换句话说就是一个通知的场景了。我就问他，你为什么不用MQ，他就说，MQ太烦琐了，还不如通过配置中心去做这个通知。换个角度讲这是不是我们的MQ做的不够易用，对应用接入成本是不是太高。换句话说配置中心做这个通知的场景也是挺顺的，当时我就在想，在配置中心的API上面封装一层，在界面上封装一层，一个场景用来专门做通知的，用户只需要一个配置和一行代码就能做到通知，不需要一堆一堆流程上面的事情来提升效率。

四 配置中心基本实现原理

大部分配置中心很多是用ZK做的，所以你问你的同事你的配置中心是不是ZK做的，我觉得这是一个误解。大家为什么喜欢用ZK呢？因为ZK天然具有通知功能的。某台应用的机器和ZK的节点有一个长连接，当这个节点发生变更的时候ZK会替它通知，另外一个是ZK选举机制是可以保证节点间的数据是一致的。所以这两个也是作为配置中心需要解决的一些问题。所以很多配置中心都是基于ZK做的。另外一种就基于数据库。数据库其实也很好理解，相比大家可能仔细理解一下配置的场景，配置是典型的更改次数比较少，但是读多写少的场景，所以数据一致性，我通过一些机制很容易保证数据的一致性。而且利用Http Long Polling方式做通知，成本也很低。所以ZK的优势通过这两种技术手段可以去实现。

ZK和数据库相比有什么利弊
- 可靠性
有一次携程内部在做IDC切换的时候，所有流量就导到另外一个IDC。这时候如果这种场景下ZK一下子连接进来很多之后，ZK很可能就垮掉了。像Dubbo的ZK是跟所有的服务都建立一个长连接的，也就是说在连接数很多，并且一下子涌过来的时候ZK是不可靠的。我们公司就踩过无数次这种坑，所以现在都提倡去掉ZK。
- 可维护性
一方面是公司一般很少有专门的专业的ZK的管理员。如果你是数据库的话，肯定是有一套很完善的体系去维护，但ZK的话不一定就有。
- 可扩展性
数据库有很多工具去做，比如说主从同步等等很多的容灾机制。另外数据库提供了一套很完善的CIUD的一些很成熟的通过代码方式去操作数据库的查询和其他的。所以从这个角度讲，数据库的可扩展性也是比ZK高的，所以很多时候如果是基于ZK搭建的配置中心的话，也会整一个数据库，让所有的配置变更都是在数据库上做的。然后在配置发布的时候，将这个配置写到ZK里面去，让ZK推到客户端。这个其实是没有必要的。

最后讲一下市面上一些开源的配置中心。阿里在云栖大会上发布了ACM，基于阿里云的SaaS配置中心云服务。我在做开源的时候也在想，像配置中心这种场景，如果你要搭一套配置中心是很麻烦的，完全是可以做到放到阿里云上通过SAAS这个服务做的，我接入就不需要自己搭建了，然后应用接入也是很方便的。我相信这种SAAS云服务配置中心，肯定是下一代的配置中心。