『互联网架构』调⽤链系统概述(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:这次说了互联网架构调用链系统的概述,这个工具存在的意义,以及有哪些类似的成熟工具,下次咱们一起说说他们的底层实现。

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:『互联网架构』调⽤链系统概述(107)
上一篇: 下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注