配置中心是互联网架构体系中非常重要的一部分，但是为什么要有配置中心，是不是一开始就要有配置中心，解决什么问题，这些都是要讨论的问题今天。随着互联网服务越来越复杂，用户和流量越来越大，“服务分层”是架构演进的必由之路。如上图所示，站点应用会调用服务，上游服务会调用底层服务，依赖关系会变得非常复杂。对于同一个服务：（1）它往往有多个上游调用；（2）为了保证高可用，往往是由若干个节点组成的集群来提供服务；如上图，用户中心服务user-service共有三个节点，ip1/ip2/ip3向上游提供服务，任何一个节点崩溃都不会影响服务的可用性。那么问题来了：调用方如何维护下游服务集群的配置？当服务集群增加或减少节点时，调用方是否有意识？初始阶段：“Configurationprivatestorage”架构“Configurationprivatestorage”是配置的初始阶段，upstream调用Downstream，每个upstream都有一个专用的私有配置文件，里面记录了每个调用downstream的节点的配置信息。如上图：用户中心user-service有三个节点ip1/ip2/ip3；service1调用用户中心，里面有一个专门的配置文件s1.conf，里面和我们配置的集群是ip1/ip2/ip3；service2也调用创建了用户中心，同样有一个配置文件s2.conf，里面记录了us集群是ip1/ip2/ip3；web2也调用用户中心，类似w2.conf，配置us集群为ip1/ip2/ip3；画外音：你熟悉吗？大多数公司在早期都是这样玩的。“配置私有存储”架构的缺点是什么？我们来看一个容量变化的需求：运维检测到ip1节点的硬盘性能下降，通知研发ip1节点后续会下线；由于5月8日有大促运营活动，未来流量会激增，研发计划新增两个节点ip4和ip5；这个时候怎么办？用户中心负责人需要通知所有上游调用者，修改“私有存储”配置，并重启上游，连接新集群。ip1没有流量后，通知运维让ip1节点下线，完成整个缩容和扩容过程。这个解决方案有什么问题？当业务复杂度高、研发人员多、服务依赖复杂时，就不那么简单了。问题一：来电者很痛苦。你是改变能力的人。为什么是我修改配置重启？这是典型的“反向依赖”架构设计，上下游通过配置耦合，不合理。问题二：服务端很痛苦。ta不知道有多少upstream给他打过电话，只能通过以下方式定位upstream：在群里发邮件要求通过连接找ip，通过ip询问运维，找到机器负责人，然后通过机器负责人找到相应的呼叫服务。如何优化呢？中期：“全局配置”架构的升级不是一步到位的。首先，用最低的成本解决上述“修改配置重启”的问题。“全局配置”架构：针对通用服务，建立全局配置文件，杜绝私有配置：在运维层面制定规范，新建全局配置文件，如/opt/global.conf；画外音：如果配置比较多，注意Configuredverticalsplits。对于服务器，如果是通用服务，在global.conf中配置集群信息；对于调用者，调用者禁止配置私有存储，必须从global.conf中读取通用的下游配置；全局配置有什么好处？如果下游容量发生变化时，只需要修改一个配置global.conf，上游不需要修改；下次调用者重启时，会自动迁移到扩容后的集群；修改成本很小，读取配置文件的目录就这样；全局配置有什么问题？如果调用方不重新启动，则无法将流量迁移到新集群。有没有办法实现自动流量迁移？答案是肯定的，只需要引入两个不复杂的组件就可以实现调用方的流量自动迁移：文件监控组件FileMonitor：作用是监控文件的变化，起到定时器的作用很容易监控ModifyTime或者md5定期更新文件，并在文件更改时执行回调。动态连接池组件DynamicConnectionPool：“连接池组件”是RPC-client中的一个子组件，用于维护与多个RPC-server节点的连接。所谓“动态连接池”是指连接池中的连接可以动态增减。画外音：使用锁进行互斥很容易实现。引入这两个组件后：一旦全局配置文件发生变化，文件监控组件实现回调；如果动态连接池组件发现某些节点在配置上减少了，就会动态销毁对应的连接；如果增加了一些节点，会动态建立连接，自动完成下游节点的扩缩容；最终版本：“配置中心”架构“全局配置”架构是一种可以快速实现的解决“修改配置重启”问题的方案，但仍然不能解决问题。提供者“不知道有多少上??游调用了自己”的问题。如果你不知道自己有多少上游调用：“根据调用者限流”和“绘制全局架构依赖图”，你该怎么办？“配置中心”架构可以完美解决“全局配置”与“配置”的对比问题。center》架构图，你会发现配置从静态文件升级为动态服务：整个配置中心子系统由zk、conf-center服务、DB配置存储和conf-web配置后台组成；所有下游服务，通过后台在配置中心设置；所有上游需要拉取配置，需要到配置中心注册，拉取下游服务配置信息（ip1/ip2/ip3）；当下游服务需要扩缩容：conf-web配置后台设置，增加ip4/ip5，减少ip1；conf-center服务将变更后的配置推送给已经注册的调用者关注相关配置；结合动态连接池组件，自动扩缩容完成；“配置中心”架构有什么好处？调用者无需重启；t服务端从配置中心明确知道上游依赖，从而根据调用者进行限流；很容易从配置中心获取全局架构依赖；痛点1和痛点2同时解决。“配置中心”架构的缺点是什么？第一，系统复杂度比较高；二是配置中心的可靠性高，一处链接全局链接。总结一下要解决哪些痛点？上游痛点：下游扩容，上游改配置重启；下游痛：不知道谁依赖我；总之，服务治理难落地。如何解决以上痛点？“配置私有存储”架构；“全局配置文件”架构；“配置中心”架构；知其然，知其所以然。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
