微服务应用故障定位系统实现原理剖析 _大数据

当下最流行的设计架构便是微服务架构，越来越多的企业将老的服务拆分成微服务模式、在新的业务中采用微服务架构的设计理念进行技术架构设计。
其中实践的最好的莫过于阿里了，早期淘宝的架构是一个单体式架构，即Linux操作系统+服务器+mysql数据库+PHP开发的程序，所有的功能如用户注册与管理、商品管理、订单管理全都集中在一个程序包里，业务越扩展越大，这个程序包也变得越来越大，最终长成了巨无霸应用，难以承受业务的继续增长，技术团队也难以进行维护。
不过办法总比困难多，在千百个日夜轮回的摸索与实践后，终于找到了合适的解决方案，即进行重构，将原来的巨无霸应用进行业务抽象，拆分成独立的子服务，由不同的团队进行开发与维护。
以淘宝的体量来看，该应用足以拆分上千个子业务，下图是2012年淘宝的整个服务调用拓扑图，如果到2020年，那么业务必定会更加的复杂。

文章插图
不只是淘宝会有这么复杂的微服务链路，任何一个企业，只要采用微服务架构的模式进行技术架构设计，势必都会产生复杂的链路调用，也势必都会面临着着四个问题：
1）定位故障难。当客服向你反馈用户无法进行下单时，很难去排查故障原因。表面上只是一个简单的下单操作，背后却是由几十个微服务所构成的，而且是由不同的业务团队进行开发，出现问题了需要牵扯十几个部门一起排查，定位故障及根本原因太难了。
2）规划容量难。对于服务平台来说，隔三差五的搞个活动、做个促销啥的再正常不过了，一般搞大活动之前都会对业务进行压测，制定本次活动的机器资源安排，然而测试环境与生产环境情况并不完全一样，每个服务的参与程度、重要性都是不一样的，规划合适的容量太难了。
3）梳理链路难。在当下，互联网企业的人员流动是非常正常的事情，往往一个系统的从开发到完成经历了多个人的手，只有从头到尾全参与的人才知道系统的技术架构，核心人员流动后对于系统的架构梳理、性能优化就变得非常难了。一个刚入职的新人往往要花比较久的时间才能梳理清楚业务，才能在业务开发的时候处理得当，不影响上下游业务。
4）浪费资源多。由定位故障难产生的人力成本、规划容量难产生的机器资源成本、梳理链路难产生的人力成本导致了企业资源的浪费。
这些都是实行微服务架构带来的问题，那微服务架构问题这么多？难道是要让我们不用它了吗？
其实不然，有了问题就必然会有解决方案。一套完整的微服务解决方案也必然包含故障定位部分，那么业内是如何来实现微服务的故障定位呢？
目前业内的解决方案一般包含三个模块，即数据采集、数据分析、数据呈现。
数据采集是在应用的每个服务上安装探针，当服务的进程启动时，该探针也会启动，采集服务运行中的数据。
数据分析是通过收集的数据获取链路调用关系、程序执行情况。
数据呈现即在前端页面呈现链路拓扑、服务执行情况。研发人员通过前台就可知道整个服务链路情况、程序运行情况，快速定位故障根因，完美解决了微服务架构的四大问题！
目前用的最多的应用基本是java语言开发的，因此我们以java应用来进行讲解整个监控系统的实现。
第一部分：探针。
我们知道java程序都是在JVM中运行的，实质上是将java代码编译成的class文件，jvm做的第一件事情便是通过java.lang.去加载类（比如A.class），此时探针agent会截取A.class类嵌入监控代码生成A’.class类，之后所有的用户请求都会在A’.class类里执行，而我们的监控代码把这些都完完全全的记录下来了，并且定时发给了后台。