高性能零售IT系统的建设04-APM全链路建设精讲

Posted 2022-10-15 TGITCIC

结论

先上结论：百万行代码的面向零售、金融业务交易系统必须要上APM，不上APM整个团队会面临崩溃、你的业务也势必会受到影响、你的系统可用率将会很低、你的业务和企业的正常运营会受到巨大的口碑以及名誉上的损失。

什么是APM

APM是application performance monitor的简称。在市面上APM有两种分代法：

1. 分成三代，目前我们的市场上的通用产品处在第三代。第一代：侵入式、专注于单个代码块或者是SQL类似于单元测试偏监控类而不带有业务链路概念；第二代：引入了业务链路概念偏程序员使用体验而非一个运维监控工具；第三代：引入了大数据实时计算等核心技术让APM本身的收集信息和判断更快；
2. 分成四代，即：在第三代APM基础上增加了第四代：AI（人工智能）。这种分法是因为APM目前已经进化到了我在上一篇：高性能零售IT系统的建设03-监控体系化的重要不亚于开发的投入中提到的AI OPS即可以做到AI、自动化修数、重启、切换这些动作会由APM发起而不再是人为去发起；

为什么要用APM

从字面来看，application performance monitor，这不是性能监控吗？

来看目前市面上90%（这个数字有点保守，实际更多，很多人连APM都没听说过）的CTO啦、Tech Leader啦、Tech Manager啦的说法：

这不就是一个监控工具吗？喏。。。我们有大厂来的架构师，会JVM DUMP出来看Thread-park, Thread-dead，我们可以在STAGING（准生产环境）环境上重现、我们可以有Monkey Testing、我们可以DEBUG，哦，不对，生产不可以DEBUG反正我们让程序员水平高一点就可以解决这些生产问题。。。等等等。。。

哈哈哈，这边只能说一下为什么会有这种思想：

1. 你的系统还不够复杂到拥有几十个legacy系统；
2. 你的API连接还不够到达上万个不同的API连接；
3. 你的系统面临的流量不可能超过每秒150个并发；
4. 你的数据量单表最最多只有几万条数据（6位数都不到）；
5. 你的系统里的关联表不会超过50个单表；

什么样的环境适合APM：

1. 每秒至少千位数并发（我指下单、支付、搜索）；
2. legacy系统几十个一集成；
3. 集成API就达1万个，除去API还有SFTP、跑批、WebService(WSDL)、Http连接、Socket，加一起差不多5万+条的链路；
4. 业务系统>300张表，每张表1,000万历史数据；
5. 基本会员达到50万+；
6. 每天3,000+单生意来自线上；

我们把上面红色的大都数人认为：生产有问题不就该这么办吗套用到上述我描述的这样的环境里去，然后我们来看当这样的一个复杂的生产环境发生了性能问题、深层次BUG时，你会怎么办？

先来看一张图

 不好意思，又是E文，没办法，我的工作和老外打交道很多，因为我们的策略都是从Global层面即全球总部层面去做的决策。

没有APM时会发生什么

对于上图我们结合着接地气的话来理解，当这么一个复杂的生产环境（我写的已经是简单了，实际我经历的生产环境比我描述的还要复杂系数上乘以2）发生一个深层次的、持续的、不断的影响你系统的BUG时，你会怎么排查？先来看这个问题，其实。。。这个问题就一个描述“9：50分左右APP首页白屏了1小时”：

1. 先从CDN开始查，翻日志，对比，看来看去，不太像有问题；
2. 来看WAF层有没有流量异常，比来比去没有异常；
3. 然后到了WAF回源了，然后在这边有至少两层NG（对外、反向），每一层NG上都有LB，LB还有HA主备或者集群，也是一堆日志，到这一步此时两小时已经过去了；
4. 然后开始看后面的各种服务了，上万个API接口哈，去ELK里翻这段时间有些什么exception日志没？30多个模块一个个看那些exception，几十万条日志。。。看吧。。。啃吧。。。加班吧，看完发觉似乎也没什么问题；
5. 去问一下前端开发吧。喂，我说APP同学你们那能否看一下代码有什么异常点吗？此时已经下午18：00了；

然后第二天，这个问题不发作了，所以IT团队报告也写不出来、原因也分析不出来。就这么过了4天，业务那又来了：今天11：30分，APP又白屏了20分钟！

好家伙。

IT老大一听：今天必须给我找出原因。

于是IT开发团队进入了疯狂模式，DUMP出来这段时间内的JAVA HEAP，由于是生产，你还不能直接“联调和DEBUG”。然后就打了一堆Trouble Shooting补丁即：断点日志。

然后把DUMP出来的东西看来看去，也看不出个虾米，而打的Trouble Shooting补丁进到这种复杂生产环境后产生的日志光看一遍就又快到18：00了。

加班吧。

加啊加，去STAGING去QAS环境想重现这个问题，这东西妖了。。。还重现不了。

于是又是没有报告、没有原因、然后再过几天又来这么一次。

最后这个问题一共来了3次，业务部门跑到CEO那说：这个IT老大不懂电商。APP老是卡！

对，APP只卡了3次，看似数字才3，但很多业务领导的确喜欢这么说话：老是。。。

CEO才不管这么多呢：是卡吗？是卡。有几次？3次！那么好。。。你无能，解决不了，你别干了！

于是IT团队又陷入了疯狂模式，然后开发开始说：这个是网络抖动造成的。网络部门回击开发：网络流量一切正常，这几次发生卡、白屏时流量是平均水平没有任何爆发点。然后开发和网络部门一起再去飞锅给Infra部门：你的服务器抖动。Infra部门拿着几十页的数据报告再回击开发部门。

当着IT老大的面，IT内部的几个团队吵成一堆，这个情景让我想到了一部电影：虎口脱险中里面的一个场景，那一场德国军官审问油漆工和指挥家时：两个人互相对话不断飞锅甩锅，最后把德国军官搞得血压飙升到了180，差点气到心脏病发作。

片中德军军官面对两个人的扯弹，一边用白手手帕擦着满头的大汉、一边满脸通红的用颤抖的话语问两人：你们俩把我当傻瓜了，把我当傻瓜了！

想想就要发笑。

或许，我用以下这个图来进一步表示这个场景会更贴切。

 有了APM会发生什么

我们先抛开APM，进入一个幻想。我们幻想有这么一种东西：

1. 在你的面前有一个像蜘蛛网一样的图，每一条丝是一个API，每一条丝上还会显示它经过了哪个jar、哪个war、哪个系统、哪个redis、哪个mongo、哪个db。
2. 然后你去点这条“丝”，这条丝线会进一步告诉你里面还会有一些什么样的分叉，这些分叉又包括哪些节点，甚至连哪个SQL都给你显示出来。
3. 在那些>1秒或者是“jvm thread-park”，“jvm dead”，访问频次超过5位数的那些点都给你自动标成红色。
4. 然后这些红色的有异常的节点，你也可以点，点进去甚至可以看到API的进出参、里面的Redis操作、正在执行的SQL。
5. 然后再根据出问题时的时间段筛选一下，这些异常点进一步明确的展示在了你的面前。

为了佐证你拿着看到的这个异常去ELK里对一下日志。。。哦。。。问题原来出在：第三方渠道订单在那个时间正好同步，而在同步时因为是全门店的全品类库存同步，这边有一个for循环，连续6位数以http connection访问ERP系统，导致了这个模块的http连接数被用尽了，而http连接数用尽时这个同步工作依然还在进行，最终这个模块开始级联雪崩，看这边的红色的点，从后往前崩、崩、崩，最终崩到了用户模块。那么我们的首页一进去会去取用户的信息和用户当前的地址去定位我们附近的门店的。这就是崩溃的原因。我只用了5钟定位问题。

问题找到了，解决方案更简单：我们把那边的逐条循环访问HTTP同步传数据方式改成最多5次循环，每次循环时接口送1万条数据一批这样送过去，送完一批sleep(100）彻底永久解决了这个后患 。

以上是一个幻想！但实际这东西已经有了，它就叫APM！

不要去从字面上认为它只是一个“monitor”。

我们把上面“在没有APM时会发生什么”这一段排查手段“反射”到程序员身上要找到类似的问题，你必须具备一些掌握相关生产debug、分析并且可以得到同样的问题的root cause的人，至少是架构师级别的。

生产刚上线在前期1年左右会处于一个不稳定期，这是互联网应用的流量不确定性导致的“系统性能优化是以螺旋上升方式”伴随着的过程，因此就会一直不断有这种不确定的妖怪问题，而你如果没有APM，你至少需要好几个架构师而且是大厂那种至少P7+起板的。这是什么成本？

因此业界有一句话：一个靠谱的APM=每年省了至少3个P7级别架构师的工资；

因此，为了证明这个幻想非幻想，我在2018年左右拿了APM直接去支持了公司相应的双11大促活动（每天亿级订单流水的电商小程序+APP），然后我们达到了这样的成果：

 对于我们在双11参加大促活动时最关心的：APP、小程序、拣货系统，最长一次排查不超过20分钟，还解决了一个历史达小一年的“各部门间经常甩锅”的问题的根本原因。

 APM好在哪

如上文中提到的，APM它可以展示出各个节点的链路、整个系统的API链路、异常节点、JVM堆栈（JVM排查只是APM功能中的百分之一功能而己）、甚至直接把有异常的API的进出参、慢SQL都给你显示出来。

因此，它天然就有一种先知先觉得的能力。

我们知道，传统的运维监控如我在上一篇“监控体系化建设”中所述，它是一个后知后觉的监控工具。往往监控到了问题、问题也已经发生了。

而由于APM它具有全链路、上帝视角。同时结合在系统发生问题时它会有一个逐步趋于“变坏”的过程，譬如说：Redis节点挂了然后流量打到DB上、DB吃不消了发生了严重的主从延迟、进而开始引起级联雪崩、进而把APP的首页搞死。系统的崩溃一定是有一个逐步的过程。那么我们在这个过程的关键节点如：这一条DB的访问突然是平时的10倍或者说设一个：这个模块通常正常情况下一次HTTP访问的response time在500毫秒，而连续1分钟内它由原先的500毫秒开始变成了600毫秒一次、800毫秒一次、1.2秒一次、2.5秒一次。那么就说明了这个系统会有一个“崩溃”的趋势。

所以APM具有“前置风险预警”功能。业界把它又称为：APM具有业务预警功能。

各位，报警和预警可是有着本质上的区别的。

通过以下例子我们来看一下这个区别：

 挑战者号爆炸了，然后报警邮件发到你手上：挑战者号爆炸了。

你收到邮件后，人家遇难者家属已经在你办公室门口摆花圈了。这事都发生了、已经造成了“灾难性结果”。这就是“监控系统”的作用，发生了告诉你这个“果”。

而APM呢？

飞机在起飞前有各种地勤，这边检、那边验，确保这架飞机全程平安飞行。这就是APM。因为有问题就给你在起飞起通过上万道地面检测的方式给“预防”了。

这就是APM的作用。

同时呢，APM在发现问题时不像一般的监控软件只是告诉你这个地方出问题了，它会把代码级别、SQL、链路节点都展现在你的眼前让你去看。

特别是带AI的APM更强大，它直接可以告诉你这可能属于一个什么问题以及你应该要怎么办。

APM轻易不报警！一报警必有大事，而且报出的问题一目了然，谁也甩不了锅。

我说几个CASE给各位听，我以前所在虽然不是大厂，但也最高峰时也有达200多个开发。但是系统复杂，因此在没有APM前我们解决一个生产上发生的问题平均耗时在：5天。

有了APM后，发现问题的根源最多没有超过20分钟的，一般通常情况在10分钟内即可响应。

5天 VS 10分钟。这是多少巨大的差别？这对IT的生产力是多大的提升？

APM在选型时的考虑

APM无论是怎么分代，它都经过了三代的发展。

在第一代，那时还早了，2013、2014年，那时我们用的是著名的开源APM，它叫pin point。它的好处是开源免费，可以在生产集群搭建。

坏处就是：它的界面是以仪表盘、系统性能指标为“先入为主”的视觉切入面的。它在使用上偏：运维监控类人员而不是偏开发。

我们通过上文所述知道了APM其实更偏开发、它是为生产发生各种妖怪问题时开发甚至研发团队人员快速解决问题根源所使用的。

因此我们来看开发们排查问题的视角：开发熟悉系统的每一条脉络，比如说你告诉开发：订单这边的加车有点问题。开发马上会定位到：order模块里的addBasket.do。倒过来通过addBasket.do开发可以告诉你这是一条什么“业务”；

倒过来如果我们使用运维监控的视角：

你告诉开发系统目前低于99分、CPU有上升、NETWORK IO有异常。。。

开发：。。。。。。come on man, what are you talking about? what can I help you?

对不对，是不是这个道理？

因此，成熟的APM一定是一个这样的使用上的体验：业务接口为入口->业务模块健康值->异常点->异常点周围的拓扑有哪些nosql、db->是否有什么http error还是jvm异常->此时的网络、CPU等硬件情况的表现。

它是一个“和运维监控倒过来看问题”的模式。因为只有这样开发才能“更快、更精准”的判断到问题的root cause。所以在选型APM时一定要注意我上面说的这两个视角的核心区别。

APM的引入其实还可以为你IT省成本

IT团队在没有APM前，监控是逃不掉的。一个零售企业的IT系统何止1个，10个都算少的，20个，30个都是可能的。这家供应商开发几个、那家供应商开发5个。每个都要运维监控系统吧？由于是不同的供应商，因此每个供应商只会为自己的系统给甲方去搭一套监控。我们就拿通用类监控来说好了。

需要监控一个或者多个系统，你最小化的监控系统硬件用量如下：

至少5个服务器。

然后我们说30个系统，分成9个供应商，那么至少45台服务器。

我现在只要一般的服务器，然后上一套APM，把这些系统统统纳入监控中，这些额外的服务器是不是全部可以release掉了？

看：Cost more effective, Cost on demands加上：Efficiency & High Productivity，你觉得谁会去拒绝APM呢？

其实我比较倾向于开源的APM，因为现在APM到了第三代其实也有开源的，一分钱不要而只要花一些适当的硬件的钱我就可以取得这个能力？但实际还是买了商业版的APM，必竟是生产环境这个也无可厚非。

不过APM一点不贵，我选型时把Gartner象限头部那7个APM全部玩了一遍，我说句实在话，有一个APM真的比你雇佣额外3个架构师都要便宜。

结语

有了成熟的监控体系、有了APM，我们已经具备了挑战高性能、高并发场景的准备了。见水化水、逢山开路。

后面开始，会越来越深入到“打流量、打黑产”的核心环节了，在后续的篇章里各位可以领略到技术的魅力、架构的魅力以及TOGAF架构思想是如何运用在各种场景下的更深层次的体验。