原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
原文链接地址：『互联网架构』调⽤链系统概述（107）

去年参加的阿里一次培训，里面介绍了鹰眼，对调用链产生了兴趣，就开始看相关的技术类文章，包括springcloud的sleuth，鹰眼等等调用链的监控，都是基于Dapper这套理论产生的。⼀个好的调⽤链追踪系统，能为定位和排查故障提供强⼒的⽀持，对于微服务架构，调⽤链追踪是必备的基础设施。Dapper这套google的实践理论，非常实用，如果没有足够正确的理论知识，在错误的方向坚持和努力。
源码：

（一）分布式调⽤链系统概述

• 讲个找BUG的故事

其实在公司天天都在找，完善的系统都是这样不断的发现问题不断的完善。发现问题首先感觉不是自己的锅，别人的锅，赶紧甩出去。

用户打电话给客服说：“某某功能使⽤不了”。
客服告诉运营⼈员。
运营打电话给技术负责⼈。
技术负责⼈通知会员系统开发⼈员。
会员系统开发⼈员查看日志发现没有问题。
会员找到营销系统开发⼈员。
营销系统开发⼈员查看日志发现数据库连不上了。
营销系统开发⼈员找到DBA。
DBA查看数据库的性能发现没有任何的问题。是不是网络链路哪里出了问题。
DBA找到运维⼈员。
运维⼈员联系机房负责⼈。
机房负责⼈暂时不在联系机房值班人员。
机房值班人员进入轰鸣的机房中。
机房值班人员找到⼀只⽼⿏ ，因为就是它把⽹线咬断了。

其实上边这种情况在公司有过类似的问题，只是老鼠这个角色不存在，修路的时候光纤被挂断了。为什么这个问题涉及到这么多人员，基本上公司内部的所有成员都牵扯到了，为什么这么复杂呢？原因：分布式和微服务框架这个结构所带来的问题，并不是系统大了，如果还是单体应用系统还是可以很快找到问题的。

• 分布式|微服务架构所带来的问题

定位⼀个问题怎么会如此复杂？竟然动⽤了公司⼀半以上的职能部⻔。但其实这只是当我系统变成分布式之后，当我们把服务进⾏细粒度的拆份之后的⼀⼩部分问题，更多问题在哪⾥？

1.开发成本会增加。

原来单体系统开发一个action，service，dao。现在是分布式系统开发的话需要涉及到N个团队的协作，涉及到部门之前的沟通，部门之前需要进行数据间的通信，定义接口的规范，沟通的成本。

2.运维成本增加。

原来一个单体系统，运维团队只关于一个war包就可以了，现在涉及到十几个系统的war包管理，负载转发，构建。每个war包涉及到自己的数据库，也就十几个数据库。运维的工作量明显增加了。

3.测试成本增加。

项目变成了几十个时候，测试人员要把整套服务和环境完整的了解起来，发现问题，沟通到指定的项目组说你们的系统存在问题，这就增加了测试的成本。

4.产品迭代周期将变⻓。

涉及到的系统比较多，迭代可否影响其他系统，设计之初考虑长远变化。

• 产⽣这些问题的原因是什么

按说社会化分工越细，，专业化程度越⾼，产能就越⾼，应该做出来的东西越好。

⼀台汽⻋平均将近3万个零部件，来⾃全球各个供应商，真正的厂家其实就是将这些零部件拼装起来，这样就使得汽车制造业的效率非常的高。你可能会说,汽⻋这种⼤物件太复杂了，⼀家公司搞不定，必须协作。那我们就说⼀个⼩的，⼀次性打⽕机不复杂吧，在浙江温州有⼀个打⽕机村，⼀个⼩⼩的打⽕机⽣产，是由20多个⼚家协作完成，有的做打⽕机燃料有的做点⽕器。就连一个打火机就是拆成很细很细。这些都是经过市场的考验了，效率最高。

好，我们在反观软件⾏业， 你⻅过哪家某个系统是由⼗⼏家企业协作完成的么？你觉得淘宝的电商系统可以让⽇本⼈去开发 购物⻋模块、让法国⼈实现评论模块、让印度⼈去实现下单功能、美国⼈实现商品模块，最后在由中国⼈拼装整合，可能嘛？至少现在是不现实的。在国内互联网软件基本不可能，需求多变。我记得在入行之初，只要日语过二级能看懂日本的文档就可以做对日的外包，说日本的文档写很明确，文档里面连一个按钮的名称都定义好了，基本不会变了，按照文档来就可以了。这就是标准化的概念，我记得软件公司有个评级什么cmm。CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控和研究,以使其更加科学化、标准化、使企业能够更好地实现商业目标。

我想⼀下原因 其实就是在于三个字：“标准化”，在刚说的汽⻋3万个零件，每个都有其标准化规格，包括钥匙孔，一个螺丝都有有标准的，所以才能够顺利的拼装成品，但软件你能标准化⾄表格这么细么，我们连开发个接⼝都没有指定标准。接⼝命名、参数、结构等没有指定的标准，最多就是⼀个规范。换句话说，标准化是有的，但是完全按照这个标准化做的真的很少很少，我有个亲戚之前去德国打工，德国那边上班都是有标准化的，如果你请一个德国人给你装修房子，他会在固定的时间喝下午茶，2点59准时喝下午茶，在多的活我也不干了，我需要休息。所以当地人都喜欢用中国人装修房子，因为他们没有标准可言。扯了下闲篇，虽然有软件有标准，但是到了应用层面使用这个标准的很少。

没有标准化，也就不能进行细粒度的分⼯协作，那怎么实现软件的⼤规模⽣产呢？类似电信，银行，电力，阿里，国美，苏宁等等这种大型系统就是要么自己搞，要么找一帮外包人员一起来搞，不可能是分包出去然后做组装起来，至少现在还没这种分包拼装的模式。管理办法升级加⼯具升级，管理办法是类似于敏捿开发、⼯程师⽂化建设、开发形为准则。另外⼀个就是⼯具：像⾃动化构建、⾃动化部署、⾃动化运维、⾃动化扩容等、线上监控等。还有调⽤链追踪都属于⼯具。

• 调⽤链追踪⼯具的作⽤
  1.分析业务实现

例如下单，经历了哪些系统的那些节点，非常有用，优化性能，发现接口调用是无效，那些调用耗时大。针对性的解决。比开发人员自己去找这些问题，还让在优化，可想而知有工具和没工具的区别了。肯定是有工具更高些。工具只会帮助你，不会去害你。

2.分析⽤例的性能瓶颈

那些调用耗时大。针对性的解决。

3.决策⽀持

用事实数据说话，肯定可以正确的引导，为决策提供支持。

4.定位线上问题

都是线上系统，上线系统现在都是RPC的方式，都有注册中心，总不能你本地连接线上系统吧，dubbo直接consumber给消费掉了。

• ⼤⼚的调⽤链系统发展史

调用链这块的成熟系统基本很少，很多公司才刚刚上自己的调用链系统，例如：联通，移动，电信。基本都是买的很少自己开发的，如果学会了了解了，公司恰好需要都舌的花这个钱。

1.Dapper

很久很久以前google公司开发出来Dapper系统，开发出来非常NB。后来出了篇论文：【Dapper，大规模分布式系统的跟踪系统】http://bigbully.github.io/Dapper-translation/，这篇文章出来后，就衍生了鹰眼和hydra。非开源

2.鹰眼

淘宝开发出来的。非开源

3.hydra

京东开发出来的。起的名字有点叼：九头蛇。开源功能不是很强大。

4.cat

大众点评，开源。集成麻烦需要改造应用。

5.zipkin

Twitter 开发的一款zipkin。springcloud的Sleuth有参考。

6.skywalking

名字：天马行空。apache项目。20多个开发人员中，唯一有一个中国人，华为的一个哥们参与的。2015年开发的。

• 底层的技术

javaagent和javassist

PS：这次说了互联网架构调用链系统的概述，这个工具存在的意义，以及有哪些类似的成熟工具，下次咱们一起说说他们的底层实现。