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

第一步先将冗余的数据收口，就只能存一份。这一份存在哪里？我们可以存在全局配置文件里，而且这个改造对于原有的架构体系冲击非常的小，只需要运维层面建一些统一的规范，就可以做到。
比如说我是一个公共的服务，很多人依赖了我，那么我就将我的配置会写在一个比如说全局的配置文件中Global.conf ，我是D ， Global.conf了，我的IP1和IP2 ，所有的业务测，它的修改则是原先是从自己的配置文件里去读，现在则统一到配置文件里去读，这个对原有的架构体系的冲击非常的小，对于业务这边代码的影响也非常的小，所以升级上来是非常快的，也非常有效。这样，以后如果我要扩容，比如说我要变IP1和IP2 ，变成加2个节点，那么所有的上游在任何一次服务升级或者重启的过程中，就能够自动的读取最新的节点迁移上来，就不需要我反向的去发群邮件或者是发群消息说谁依赖了我，自己改一下配置，我就统一的改在那个地方配置就行了。
但是依然存在我不知道谁依赖了我的问题，如果我不知道谁依赖了我，那么可能一些服务治理，调用方限流的一些工作可能做不了。同时如果有一个业务它迟迟不重启，迟迟不读取新的配置文件，它其实流量也迁移不过来，但是只要配合上两个小组件，它就可以自动的干这个事情。
一个叫做文件监控组件，一个叫做动态连接词组件。文件监控组件其实就是监控配置文件的变化。如果配置文件有变化，不一样了，实施方式也非常简单。怎么来做？每隔一秒钟去检查一下最近更新实践，或者每隔一秒钟去检查一下配置文件的MD5 ，一旦发生变化则毁掉，非常容易。
实现了文件监控组件之后，动态连接词组件，动态连接词组件是RPC框架中的一个非常基础的组件。你是一个RPC的Server ，通过IPC的Client来调动它， RPC的Client它里面有连接词，你IP1要建连接， IP2要建连接，所谓的动态连接词就是能够动态地增加连接和减少连接。
你的配置文件回调，你发现IP1没了，那么你的动态链接只要销毁与原来IP1节点建立的连接。你的配置文件回调说增加IP3和IP4节点，你的动态链接只要动态的新建IP3和IP四的节点。
如果实现了这2个组件，只要配置文件统一变化，所有的连接全部实施变化了，那么旧的节点就可以下架，新增的节点负载马上就均衡了。这是第二个阶段。配置的管理。这个阶段我刚刚提到对原有架构体系的冲击非常小。如果大家现在还是使用的配置市场阶段，如果还在这个阶段，每个上游和自己的配置文件里去写下游的配置文件，强烈建议快速升级到这个阶段。

文章图片
3）阶段三：配置中心
当然这个方案的缺点就是我还是不知道谁依赖了我。终极解决方案其实还是配置中心，配置中心也是现在行业内聊的非常多的话题，在运维领域，在配置架构领域都有很多的话题。方案就是由配置文件升级成配置中心，当然配置中心本身也是一个非常复杂的架构。

文章图片
如果升级配置中心，那么所有业务要调用下游，会去配置中心，问要调用下游，它的配置是多少，配置中心就告诉他，然后他再给下游，那么如果我的配置会发生变化，我会在配置中心的后台进行操作，说IP1要下调，增加IP3和IP4 ，然后配置中心它记录了依赖关系，它能够反向的通知所有调用了的它的人说增加IP3和IP4减去IP1 ，再配合动态连接词组建。
首先配置中心它本身就是一个注册加反向通知的机制，所有人要依赖于它，你去配置中心注册后，我发生变化的时候要通知你，然后再配合动态连接词，只要我扩容缩容，通过配置中心，一修改则通知所有的，这么做了之后，整个全局的依赖关系图就极其容易了，因为所有人都在配置中心，需要配置时，谁依赖谁，谁调用了谁，谁依赖了数据库，谁调用了缓存，整个全局的依赖关系图就呈现了，但是它是一个全局的关系，它并不能够精确到每一个请求。
配置中心，它对原有的架构体系和架构的冲击比较大，可以慢慢调整往这个方向尝试，但是上述的，全局配置文件则对现有的一个架构体系的冲击应该是比较小。
4、分布式调用链追踪系统的核心难点