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

痛点二：定位性能瓶颈的过程
第二个定位性能的瓶颈，其实也是非常麻烦，过程跟上面的有点像。如果是没有做微服务的，可能一个模块加时间打日志就能够知道。但是微服务的话，它其实调用都是跨机器，跨进程的。我站点的HTTP接口花了三秒钟，这三秒钟花在哪个服务上，这个定位的过程相对比较麻烦。这个服务它又依赖于其他服务，其他的服务又依赖于数据库，依赖于缓存，依赖于其他的服务，要找出我这个HTTP接口具体的性能主要矛盾在哪里的周期也会非常的长。可能大家也有这样的痛点，就是微服务架构之后，想要整体的性能提升，但去寻找主要矛盾很麻烦。
痛点三：不合理调用导致扩缩容的过程
第三个是不合理的调用，以及扩容缩容的过程比较麻烦。举我们曾经的例子，因为微服务调用方写代码太方便和高效了，他像调用本地函数一样去调用一个远端的服务，有时候他调用甚至都不知道自己调用的一个远端的服务。
比如我们曾经线上出现过的个问题，就是由城市ID拿城市的一个具体信息。比如说北京的承载力是一，我要一传进去后返回北京，这里它可能有一个服务，我们叫做城市品类服务。我们专门有一个服务，但是工程师在写这套代码的时候，他可能觉得服务部做个Map ，做个配置就行了，他可能都未必意识到了自己在写下这行代码的时候，调用的时候是调用一个远端的服务，他可能觉得自己直接本地很高效的去实现了这个东西，传一个一进去，传一个北京出来。所以他把这个调用写在了一个For循环的内部，本来执行一次就行，一传过去，北京拿回来，它写在了一个For循环内部，它可能就调用50次，每次都有一拿北京。如果是一个本地的MAP也没什么大问题，但是最后它其实是一个远端的调用，网络上它可能就是几十毫秒级别，但一个For循环100次，它可能几百毫秒甚至秒级别了。
最后如果我们要去找到哪个地方有一个不合理的调用，没有分布式的调用链的追踪体系的话，其实很难，包括在扩容缩容的过程中，整个微服务架构体系我们要扩容缩容哪个节点这个环节。我调了5个微服务，容量好像扛不住了，但是我要扩容我调用了5个的哪一个微服务，以及怎么来扩，这可能都是问题。如果大家用了微服务架构体系，可能也会存在这样的问题。
三、分布式调用链追踪系统的特点
解决方案是分布式调用链追踪系统，它能够解决上述的问题。分布式调用链追踪系统，它是什么？其实在解释它解决问题的过程中，基本上就能够知道它是做什么的。

文章图片
1、全链路
当一个HTTP请求进入到你的站点层，你调了哪一个服务，这个服务是广度调用还是深度调用，以及服务后面调的数据库，也可能调缓存，这整体是一个递归的过程。一个请求花了500毫秒，这500毫秒花在哪里了？这个服务100毫秒，另一个服务80毫秒，服务的递归、调用、深度、广度，它是全链路的一个呈现。
2、跨进程
为什么单节点的好做，因为单节点的上下文所有信息都有，用本地时间就能够描述绝对的时间，是偏序的。但是微服务架构体系，请求是由这台机器上的这个进程去了另外一台机器的另一个进程，另一个数据库，去了机器的缓存节点。它是跨进程的，所以整个分布式的调用链，信息的收集，包括时序和全流量，其实比较难。
3、全流量
微服务不只是描述依赖关系，还要精确到每一个具体的请求。
打日志，它会有多个ID ，有快速的ID 。如果是单节点的话，通过一个日志文件里的RequestID就能够全部串起来，知道调用哪一个函数，调用哪个数据库，调用哪个用了多长时间。但由于微服务它是跨进程、跨机器的，所以它全流量的收集、呈现，其实相对比较困难。
四、分布式调用链追踪系统的难点
1、难点
微服务它的难点也是因为它全流量跨进程，包括全球量化进程、全链路，所以对如何跨进程的去标识它是同一个HTTP请求过来的，跨进程的串联标识，跨进程的时序标识是个问题。上面说的单节点，用本地时间就可以做偏序，但是由于微服务它跨进程，可能另一台机器的本地时间比我这台机器的本地时间要快或者是要慢，如果用本地时间的话，可能就不能够描述全链路的请求的一个持续了。