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

所以需要组建统一框架，只要在这10个地方埋入上文说的数据上报的小SDK就是上报一些时间差及重要参数的日志就行了，所以修改点其实非常的小。最后都是后台的事情，数据集中上报，就看后台是怎么做检索，怎么样做方便查询了，所以上述说的统一框架组件其实非常重要。
6、分布式调用链追踪系统的可视化
最后是可视化，跟大家呈现一下我们的后台，大概是下图这样的。首先进来是一个HTTP ，它的总消耗时间可能是101毫秒，整个过程中它是Passport的外部，它的类型是到家外部Framework ，它是站点层，它是到家ServiceFramework ，这就是DSF的客户端调用方和服务端，调用了什么样的函数，调了服务的什么函数，调用了什么样的函数，传进去什么样的参数，消耗了多少的时间以及这个Service它通过DAO调了哪些，调了多少次数据库，数据库的Server语句是什么，执行时间是什么，整个递归关系，按时序按地位一目了然。

文章图片
对于我来说，如果我要快速定位问题，一看上图哪一块执行的时间最长，这个Service语句怎么执行了600毫秒，我们就去找Service语句在哪个地方出了什么问题。如果看某一台机器挂了，某一个地方，它就是红色的，包括调用。这个地方怎么某一个Service调用了50次，原来是因为写在For循环里了，很快能够帮助我们定位线上问题，找到不合理的调用，找到新的瓶颈来优化。所以最后的系统的产出大概是这样的，这是其中的一个视角。这是另外一个视角。这个视角的话详细信息会比较多，定义到我前面10个节点， Dao节点、Service节点等等，详细信息会比较多。

文章图片
上图是一个依赖关系视图，所以进来的是我们Passport的一个Web ，它的类型是DWF ，我们这边是到家WebFramework ，它调了3个Service ，他通过第1个到家ServiceFramework的Client ，它调了3个Service ，调的都是到家Service ，这是DUSService ，上面是客户端视角，中间是服务端视角。
第一个Service通过DAO调了一次数据库，中间的Service通过DAO调了好多次数据库，最后一个Service通过DAO调了两次数据库，这个图可能是一个用户注册的请求或是用户登录的，通过图我们会发现它其实调了10多次数据库，但是每一次数据库的访问耗时是很短的毫秒级的，绝大部分的时间可能是在CPU处理上，虽然一个请求它访问了10多次数据库，但是其实它的最后总执行时间只有101毫秒。
六、总结
最后一个是总结，根据我的经验，今天讲的内容，明天能够记住的只有5% ，如果只有5% ，我希望是这5% 。

文章图片
1、分布式调用链追踪系统解决什么问题？
1）快速发现线上问题。
2）快速定位性能瓶颈。
【快狗打车CTO沈剑：低成本搞定分布式调用链追踪系统】3）快速找到不合理的调用。
2、我们怎么低成本的来干这个事情？
用我们的最佳实践
1）统一框架，包括站点框架和服务框架。如果不在早期做规划，要统一是很难的，越大的公司统一越难，像BAT他们要统一公司，所有的站点，所有的服务用同一个框架，几乎不可能。但是我能够自信地说，如果到家发展到5年，能够统一战略框架和服务框架，因为我们从一开始就这么规划的。
2）统一组件，前面有很多，比如说数据库的访问，有时候我们只是浅浅的封装了一层，但是浅浅的封装了一层，也非常的重要，能够方便我们统一的来做很多统一的事情。比如说调用链，比如说日志收集，比如说告警，比如说调用Release的组件，我们可能就是使用的Redis ，但是我们在外面包装了一层命名空间，叫到家CacheClient或者叫到家KVClient 。这个到家KVClient 。里面具体是访问的memcache还是访问的Redis ，还是未来我们要切其他的，对于组件的使用方是透明的。未来如果我们要切，要统一切成Release ，可能我们在框架层面统一的做升级，所有调用方只要依赖到我们最新的到家KV的包，到家数据库访问的包，它就能够完成升级。
3）我们统一的在架构部，在组建层面，统一的支持日志的上报，超时的告警，调用链追踪也只需要你们依赖于我们最新的包，就能够统一的支持所有的功能，而不是所有的地方，不知道是哪个请求要记录去埋点。这样的技术体系的推进是很慢的。