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

原标题：快狗打车CTO沈剑：低成本搞定分布式调用链追踪系统
本文根据沈剑老师在〖2020Gdevops全球敏捷运维峰会〗现场演讲内容整理而成。

文章图片
讲师介绍
沈剑，到家集团技术VP&技术委员会主席，快狗打车CTO ，互联网架构技术专家， “架构师之路”公众号作者。曾任百度高级工程师， 58同城技术委员会主席、高级架构师、技术学院优秀讲师。
大家好，我是沈剑，接下来将会跟大家分享一下到家集团/快狗打车的整个分布式调用链追踪系统的落地。
一、有微服务之前，我们架构是怎样的？
很多公司未必是微服务的架构体系，在微服务之前，大家的架构是什么样的呢？可能有一个站点应用，端上可能是APP或者是H5、PC浏览器，然后你会有一个站点应用层，没有微服务的话，它可能直接连的是缓存，直接连的是数据库，保证高可用的话，它可能是一个集群。
在微服务架构之前，这样的一个架构未必会存在追查调用链的痛点，未必会存在追查Bug困难的痛点，未必会存在寻找新的瓶颈的痛点。因为有这一个节点，所有的后端都是这一个节点来连接的，它直接站点应用连缓存，连数据库。

文章图片
如果要定位线上Bug ，可能加一些日志，在这个模块，在这个站点应用，在里面加一些日志。要定位就加一些日志，然后看你的函数是怎么样调用的，调用在日志里其实能够体现出来，所以追查Bug和查调用链是相对比较容易的，包括性能。
比如要做压测，发现压不上去，一秒钟只能执行几十个。你想要找性能的主要矛盾在哪里？时间花在了哪里？因为你的这一个站点应用也通过加日志的方式的，我就看我的主流程有10个步骤，每个步骤我把时间都打出来，发现其中有一个步骤花的时间是500毫秒，这一个步骤你在递归进去，这一个步骤里面我又调用了哪些？这么递归下去，因为它是单站点应用的一个节点，最多做集群化，但是集群化的每一个节点的本地执行是相同的。通过层层加日志的方式去看每一步的执行时间，其实也相对较容易定位新的瓶颈。
二、微服务架构后，我们的痛点是什么？
如果在微服务之前，可能并不会遇到这样的痛点，但是一旦微服务化之后，一旦微服务化之后，我们的痛点是什么？如果大家也是微服务的体系，有Service内层，不管是Devops的Service还是自源框架的Service ，只要有Service内层，我相信一定会遇到与我们类似的痛点。
痛点一：定位线上故障的过程
比如说定位线上故障，极其麻烦。比如我们用户反馈入不了，我作为登录系统站点的负责人，我这个站点有4个集群，我会SSH去到第1个节点，去公有日志，看Exception ，看Timeout ，发现是Ok的。 SSH到第2个节点， SSH到第3个节点都是ok的， SSH到第4个节点，发现有一个节点，调用下游的某一个地方有超时，下游是我的一个服务。而微服务的整个架构，它调用下游的服务，像调用本地函数一样方便，能够提升研发效率。不用每个节点都关注底层的一些缓存，分库分表，存储引擎，不用关注这些复杂性，像调本地函数一样去拿一个远端的数据，我传一个UID过去，你就给了我一个用户的实体了，像调本地函数一样。
我发现我调用PassCloud的微服务，好像超时了，但是PassCloud微服务，又不是我负责的，我得找相关的同事，于是我给基础架构部的一个同学说我调用PassCloud超时了，用户用不了，你赶快查一查。然后PassCloud的微服务，它可能又调了其他的服务，当然它也可能没有调其他服务，没有调其他服务，路径短的话，对架构部的同事他问题解决比较方便，但他也是一步一步的SSH到线上Passport集群的每一台机器，公有日志看Exception ，看Timeout 。他发现自己直接连数据库，数据库好像不行了，打给DBA说PassCloud调用你的某一个数据库超时了， DBA同学，然后也去看他的数据库集群，发现好像是网络的问题，就打给运维的同学，运维的同学一看，某云厂商挂了，或者是网络出现问题了。
我们会发现定位问题的过程非常的麻烦，可能解决的过程就是把这个节点下掉，网络恢复一下，重启一下就解决了。解决问题的过程可能相对较容易，但是定位问题的过程非常的麻烦。大家如果有用微服务架构的话，公司可能也存在这种现象，它要从站点层到服务一到服务二到数据库，可能还涉及缓存，涉及到网络，时间花在哪里？你可能定位的过程非常的长。