快狗打车CTO沈剑：低成本搞定分布式调用链追踪系统( 四 ) ：快狗打车CTO沈剑：低成本搞

最怕是什么？最怕是每个部门需要自己的接口埋点。这个部门你要看这10个接口，我要看这10个接口，你把我的客户端埋到你的这10个接口里面去，这种基础组件、基础能力、基础平台是推广不下去的，需要所有的业务部门配合修改升级是很难的。
所以如果是统一的框架，只需要架构部在两个框架的少数几个地方做升级修改，收集时间数据、参数数据，就可以完成这个事情。
2、统一组件
除了统一框架，还要统一组件，我们要用到哪些组件，就对应到这个里面，在上图其实你会发现三个组件，我们在里面调了数据库，我们是通过DB的Client去调的。缓存的访问，我们公司统一技术栈必须收口在Redis和memcache 。我们memcache有个客户端调用， Redis有个客户端调用，我们整个统一收口的是这三个组件，如果这三个组件是统一的，我们会发现在这三个的客户端调用处稍加升级，就可以收集所有的数据库访问和所有缓存访问的执行时间以及关键参数，数据库收集SQL语句，缓存收集Key的信息，但前提是组件是统一的。
3、统一配置管理（设计服务发现，自动扩容）
统一配置管理，包括上下游的依赖关系。这个集群依赖于多少个集群，配置管理必须要统一的维护，这样依赖关系和调用链关系就比较容易拿到。这是前期需要做一些规划的，不能A部门用它的技术栈， B部门用它的技术栈，这样做全公司的统一调用链就可能非常难。所以我们也会发现早期技术规划的架构师或者是技术负责人，他的一些统一的规划，其实对于后续做一些技术体系的建设是比较有帮助的。
对于配置管理，大家应该也会有类似的痛点，潜在的痛点可能有这三个。这个也是我们曾经有的。
1）阶段一：配置私藏
比如我是某一个服务的负责人，比如Passport ，有很多人调用了我，但我不知道谁调用了我。这是我的痛点，不知道谁依赖于我。如果扩容缩容，我有两个节点，我发现扛不住了，要扩容第三个节点，我不知道谁依赖我，就不知道谁要配合我升级或者要配合我修改配置，系统的依赖关系不清楚。

文章图片
最早的时候是怎么做的？最早的时候，我这个集群的两个IP以及端口的配置，是配置在我上游的配置文件里的。这个可能大家早期都这么做的。
业务A调了ServiceD ，那么ServiceD它的集群有两个节点， IP1和IP2是写在A的conf里的，业务A的conf ，这个conf里配置了，我依赖于D ， D的IP 。业务B调了它， B的conf里也配置了，我依赖了D ， C也同理。如果是这样的话，第一我是不知道谁依赖我。第二，我在做扩容的时候，我要反向通知我的上游，并且要求他们去修改配置。比如说我要扩容，我要由1、2变成3 ，或者是说我的1要下调，我还要扩容三个节点变成2、3、4、5 。
那么第一，我得找到ABC ，因为调用我，不需要经过我的同意，只要拿到我的RPCClient ，以及拿到我的IP1和IP2 ，就可以调用我，我是不知道谁调用了我。于是在我们公司，为解决这个问题，原先是建了一个大群，叫做到家集团技术Order ，里面有300人，现在我是ServiceD的负责人，我在外面丢一个消息说我D要升级了， IP要改了，所以谁依赖我，我换一下配置升级一下。
这个群，它每天弹消息。在做研发的时候，什么是最影响我们研发效率的？根据我的经验，就是群消息和邮件。每天有一个在那儿弹，有一个在那儿闪，这个消息我们得看，万一是跟自己相关的。万一我是业务A的人，他D升级，这个消息就跟我相关，但是大概率消息跟自己没关系，因为公司有200个服务，我只依赖了5个，消息大概率是195个人发的，但是又不得不看消息，很影响研发效率。同时还有邮件，后面升级了，升级为发群邮件，但是道理是一样的，技术Order邮件组来邮件，说有一个服务升级扩容了，谁依赖它的，就需要看一下，检查一下。如果有一个人没有检查到，而我把原来的断了，他服务就影响了。包括每个上游的升级步骤和升级节奏也是不同的，我们会发现自己扩容了几个节点，旧节点的压力大，新节点的流量迟迟不能够迁移过来，这是我们曾经的痛点。
2）阶段二：全局配置文件
对于这种配置管理的方式，我们叫配置市场。所有下游的这些配置是市场在上游的自己的配置文件中，而且还做了配置的这种冗余，数据冗余会引发一致性问题。那要怎么升级？如果大家也存在刚刚我们曾经遇到的痛点可以看下。