1.起源随着互联网业务越来越复杂，用户量和流量越来越大，“服务分层”是演进架构的必由之路。如上图所示：站点应用会调用服务，上游服务会调用底层服务，依赖关系会变得非常复杂。它对同一服务有多个上游调用。为了保证高可用性，一个底层服务往往由多个节点组成一个集群来提供。如上图所示：用户中心服务user-service有3个节点，ip1/ip2/ip3向上游提供服务。如果任何一个节点宕机，都不会影响服务的可用性。那么问题来了，服务集群增删节点时，是否存在“反向依赖”，是否存在“耦合”，上游调用方是否需要修改配置重启，上游能否做到无意识，那也就是说，“配置架构的变化”，是今天需要讨论的问题。2.配置私有存储“配置私有存储”是配置文件架构的初始阶段。上游调用下游，每个上游都有一个专属的私有配置文件，记录了每个被调用下游节点的配置信息。如上图：1）用户中心user-service有ip1/ip2/ip3三个节点2）service1调用用户中心，它有专门的配置文件s1.conf，和我们配置的集群是ip1/ip2/ip33）service2同样是调用用户中心，同样有一个配置文件s2.conf，里面记录us集群是ip1/ip2/ip34)web2也是调用用户中心，同样是w2.conf，配置us集群是ip1/ip2/你熟悉ip3吗？没错，早期大部分公司都是这么玩的。1、配置私有存储架构有什么缺点？我们来看一个容量变化的需求：1）运维检测到ip1节点硬盘性能下降，通知研发ip1节点后续会下线。2）由于运营活动的推进，未来流量会激增，研发计划增加两个节点ip4和ip52。这个时候怎么办？用户中心负责人需要通知所有upstream调用者，修改“私有存储”的配置，并重启Upstream，连接新集群。ip1没有流量后，通知运维让ip1节点下线，完成整个缩容和扩容过程。每个人都在这样做吗？当业务复杂度高、研发人员多、服务依赖复杂时，就不那么简单了。问题一：来电者很痛苦。你是改变能力的人。为什么是我修改配置重启？这是典型的“反向依赖”架构设计。上下游通过配置耦合，值得优化（尤其是上层服务，当ta依赖的服务较多时，每周可能会有类似的合作重启需求）。问题二：服务端很痛苦。Ta不知道有多少上??游调用过他（尤其是底层的基础服务，比如用户中心，有很多上游调用过ta）。往往只能通过以下方式定位上游：在群里发邮件要求通过连接找ip，通过ip找运维，找机器负责人，再找通过本机负责人调用相应的服务（熟悉的请转发=_=）无论哪种方式，都极有可能错过，导致ip1的流量一直难以下线，ip4/ip5的流量很难均匀迁移。如何优化呢？3.全局配置架构的升级不是一步到位的。让我们以最低的成本解决上述“修改配置重启”的问题1。“全局配置”方式：对于通用服务，建立全局配置文件，杜绝私有配置：在运维层面制定规范，新建全局配置文件，如/opt/globalconf/global.conf。如果配置较多，请注意。配置的垂直拆分是针对服务器的。如果是普通服务，在global.conf中配置集群信息。对于调用者，禁止隐藏配置，一般下游配置必须从global.conf中读取。这样做的好处：如果下游容量发生变化，只需要修改一个配置global.conf，而不是每个上游都修改。调用者下次重启时，会自动迁移到扩容后的集群。修改成本很小，读取配置文件的目录变了。Insufficient：如果调用者没有重启，没有办法将流量迁移到新的集群。有没有办法实现自动流量迁移？答案是肯定的，只需要实现两个并不复杂的组件就可以实现调用方流量的自动迁移：1）文件监控组件FileMonitor的作用是监控文件的变化。通过设置一个定时器，定时监控文件的ModifyTime或者md5，就可以轻松实现。当文件更改时，将执行回调。2）动态连接池组件DynamicConnectionPool“连接池组件”是RPC-client中的一个子组件，用于维护与多个RPC-server节点的连接。所谓“动态连接池”是指连接池中的连接可以动态增减（使用互斥锁或线程安全的数据结构很容易实现）。这两个组件完成后：1）一旦全局配置文件发生变化，文件监控组件实现回调2）如果动态连接池组件发现配置中有节点减少，会动态销毁对应的连接。如果增加了一些节点，它会动态建立连接，自动完成下游节点的扩容和缩容。4、配置中心的全局配置文件是解决“修改配置重启”问题可以快速落地的方案，但仍然不能解决服务商“不知道上游调用了多少”的问题本身”。如果不知道有多少上??游调用你，就很难实现“根据调用者限流”、“绘制全局架构依赖图”等需求。怎么办，可以用“配置中心”来解决。对比“全局配置”和“配置中心”的架构图，会发现配置已经从静态文件升级为动态服务：1）整个配置中心子系统由zk和conf-center服务，DB配置存储和conf-web配置后台组成2）所有下游服务的配置通过后台设置在配置中心3）所有上游需要拉取配置，需要去配置中心注册，拉取下游服务配置information(ip1/ip2/ip3)当下游服务需要扩缩容时：4）conf-web配置后台设置，增加ip4/ip5，减少ip15）conf-center服务会将更改后的配置推送给已注册的调用者要注意相关配置6）结合动态连接池组件，完成自动扩容和shri的好处配置中心的nkage：调用者不需要重启服务器就可以清楚的知道来自配置中心的上游依赖，从而很容易通过根据实现限流来获取来自配置中心的全局架构依赖的痛点给调用者1，同时解决了痛点2。缺点：系统的复杂度比较高，对配置中心的可靠性要求比较高，一个地方链接全局链接。五、小结1、它解决了什么问题？配置导致系统耦合，架构反向依赖。2、痛点是什么？上游痛苦：扩容是下游，配置重启是上游下游痛苦：不知道谁依赖我3、配置架构如何演进？1.配置私有存储2.全局配置文件3.配置中心本文为专栏作者“58神剑”原创稿件，转载请联系原作者】点此查看本作者更多好文
