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

文章图片
包括深度标识。深度标识有时候是第1个模块调第2个模块，第2个模块调第3个模块，它是深度的，与第1个模块先调第2个模块，然后第1个模块再调第2个模块，你会发现它的日志，时序可能是一样的，但是它的调用深度完全不一样。 A调B ， A再调C ，与A调B ， B调C ，它可能对在日志层面都是A和C分别被调了一次。
深度广度如何来做？包括数据的收集和可视化。我们要精确到任何一个请求，要怎么来收集，怎么样在后端可视化，让大家看到在追踪Bug的过程中所需要掌握的信息。
哪些信息需要要掌握呢？比如参数信息，调用的接口，数据库执行的是哪一个SQL语句，访问缓存的Key是什么？这些信息都可能是大家在追抓、追踪Bug的过程中非常重要的一些信息。能不能在后台统一的展现出来哪一个服务调到哪一个函数，参数是什么，缓存Key是什么，数据库SQL是什么，这些对于我们定位问题都非常有帮助。
最后我还标红了一点，叫做如何低成本的去实现这个事情。首先到家集团、快狗大车，是创业型公司， 14、15年才成立的，到现在，快速打车也就100来人，公司不会给我们一个20人的团队，研发半年的时间，去做出来一个系统。没有这样的资源，没有这样的成本，所以对于创业型公司来说，如何低成本去实现分布式的调用链追踪系统，解决上述难题，也是创业公司非常关注的。
2、我们的实践
来看一下我们是怎么弄的。首先下图是我上文所述的微服务架构的一个请求流程。如果是微服务的架构，端上请求通过反向代理，到了站点业务层，站点应用层如果没有微服务架构的话，直接是在站点应用层会调数据库。但是如果有站点应用层的话，则会调服务，服务对上游提供友好的RPC接口，让上游能够像调本地函数一样去调拿原来的数据，而由服务这一层屏蔽了缓存数据库组成分库、分表、存储引擎各种复杂性。

文章图片
所以我们今天这一套是适用于这个架构体系的，然后是服务，我这边虽然是一个Service节点，但其实服务有很多，服务之间也可能有业务服务，基础服务，也可能有互相调用。所以具体到一个请求，这个图表现的是依赖关系，端上、反向代理、站点应用、服务，服务它去帮助数据库缓存。

文章图片
这是个非常具体的HTTP请求，从这边进来，到这边出去。然后在这个请求，这条时间线，它可能调了第一个服务，微服务有RPCClient调RPCServer ，然后它可能又调了缓存，高调的换车。然后它也可能调到第二个服务，可能又调了缓存，甚至它还可能直接用DAO去调了数据库，所以在这个进程的时间线上，你看到的整个执行过程是这样，但是它是一个递归了，你调了这个服务，这个服务它可能又调了其他的服务，调了数据库。
所以我们会发现对于分布式调用链追踪系统，希望它最后呈现出来一个这样的，希望它呈现出总时间，每一块的分时间，调哪个函数，传的参数。这一块调了，会呈现这个时间，调了它的SQL、Key、每一块的执行时间。就整个一递归的依赖关系，每一块的执行时间、核心参数，如果对数据库还有SQL语句，对于缓存则有Key ，这些信息我希望通过一个界面能够有的。
有了这样一个分布式调用链追踪系统，对于我们定位线上问题，定位性能主要矛盾有帮助，一看就知道是哪个地方花了50%的执行时间，就可以优化这个地方以及其他不合理的调用。如果调了下游的服务但写在了For循环内部，这个图可能会有这个，即呈现出RPCClient调Server可能有50个。
五、分布式调用链追踪系统的最佳实践
接下来是我们的最佳实践。我们现在要做这个事情，我们要怎么来做。假如我们现在要达到的效果就是一个HTTP请求，所有每一块的执行时间，关键参数都要有。而且这是一个请求的，所以它有跨进程的请求ID的串联，还有时序的串联，深度的串联，怎么样解决？怎么样低成本的统一来解决。我们的最佳实践：
1、统一框架
我们会发现在这个过程中我们用了至少两个框架，站点的框架和服务的框架。如果公司的站点的框架是统一的，服务的框架是统一的。我们可以将这些数据和关键参数收集，收口在这两个集中的地方，比如说我在站点的框架的进来和出来两个地方做两个时间差，相关的关键参数收集上来，所有的HTTP请求的总执行时间和关键参数就收下来了。如果我们公司的服务框架是统一的，我们在RPCClient的出口统一发出时间和接收时间，打两个点，以及相关的参数收集上来，服务端接收到请求的时间和返回请求的时间，以及相关的参数收集上来，所有的微服务，所有微服务提供的接口的所有信息就全部收集上来了，所以只需要架构部在这个站点框架和服务框架做简单的改动，所有的业务部门只要使用我们框架的，所有的数据就收集上来了。