配置中心那些事

闲着也是闲着，就看看过往实在没有时间来折腾的一些东西，这不，最近2天看了看配置中心。

比较有代表性的有老牌的Apollo（阿波罗），阿里巴巴出产的新贵 nacos，再就是Pivotal出产的Spring cloud config，网上比较这3者的文章多于牛毛，我就不凑热闹了。这里也不得不提一下，多年以前还有淘宝开源的diamond，以及基于diamond改良的super-diamond，在今天流行的这几种配置中心诞生之前，diamond和super-diamond也被一些公司采用了，在我过往的工作中就主打用的是super-diamond，实现简单，源代码也简单，基于源代码对功能进行增强也很方便，当然还算稳定，10年来没有遇到配置导致的故障。

配置中心需要些什么功能：

1、配置管理（基于配置项或者文件）

2、配置能够共享或者独占

3、配置版本化、回滚、比较

4、支持多环境（dev、test、build、product)

5、支持多集群（Region和AZ）

6、权限（基于环境、应用、账号做权限隔离）

7、配置支持校验、实时下发、灰度下发

8、客户端支持配置项内存缓存、文件缓存

9、客户端支持多语言

10、配置中心服务端支持高可用，有方便的portal可以管理配置；

配置中心的部署方式：

1、按照环境部署独立的配置中心，支持单环境内的权限控制，支持按照环境的Portal。

2、多环境共一套配置中心，支持按环境、应用的权限控制，统一的portal。

3、按照环境部署独立的配置中心，支持按照环境、应用的权限控制，统一的portal。

从安全的角度，肯定是按环境来部署配置中心最好了，但是无可避免的会引入多套不同的Portal，nacos就是这样的。从使用者的便利来看，统一portal入口无疑是方便的，辅以按照环境的配置中心，看起来很美好，Apollo就是这样的。之所以说是看起来美好，就在于配置中心后端很可能会被暴漏出来，隔离并不不彻底。Spring cloud config就不多讲了，不知道有多少人会把它用到自己的产品中去。从开箱即用角度看毫无疑问是nacos最为便利，Apollo最为复杂，Spring Cloud Config由于还要GIT配套，也很实麻烦，要实现高可用也更不容易。

话说Apollo的应该是方方面面考虑的最为全面了，但是架构也确实复杂，这里吐槽一下。

Apollo搞个配置中心，还要拆分为 Config Service 、Admin Service，这也就罢了 ，可以理解为读写分离或者前后端分离，让人受不了的是又引入了 Meta Server 了，说是来给 客户端和Portal简化服务发现的，避免Client和Config Service的长链接过于消耗SLB，这样下来SLB就纯粹是给Meta Server服务的了。中小型企业，多半在1000台服务器和10000个应用实例以下，应该都不会遇到SLB的长链接打爆的问题，再大型一些的企业，也就不用apollo了，人家都会自己造一个。一句话来说，真的在用Apollo的那些公司，很少有人会碰到长链接打爆SLB的问题，能够有资格碰到问题的公司又基本都不会用，当然携程自己用的话，上面的架构应该还是很有必要的。东西是好，麻烦事也多，小厂真不一定要来凑这个热闹。

咋一看，Apollo的Portal还有一个独立的DB，Config Service和Admin Service又有一个ConfigDB，有一些不合道理，但是存在肯定就有合理性，按照Apollo的尿性，多个环境是多套底层的部署，会对应多个【Config Service + Admin Service + Config DB + EUREKA+Meta Server】的组合，但是在通过Portal进行配置管理的时候，可以共用一套Portal，当然Portal对应的DB也是共用的，要不上哪里去保存统一的账号呢。看起来是多此一举，实际上还是有必要的。说到底，这个点也是Apollo的比较优势，一个Portal入口配置多套环境的配置项，用起来还是方便。

讲真，90%以上的公司有个Nacos用就已经足够了，真没必要上Apollo，等到体量再大点，涉及多集群的时候再上Apollo再考虑，毕竟一个Portal用起来也方便啊。只是又有多少公司能够长到那么大呢，这样看来如果真不知道怎么选的话，闭着眼睛用nacos，正确率都在90%以上。