【51CTO.com原创稿件】随着互联网+时代的到来，京东金融业务规模不断扩大，业务场景也不断创新。但是，业务变化之快超乎想象，相应的 SOA 及微服务架构日趋深入，服务数量不断膨胀，线上环境日益复杂，服务依赖关系每天都在变化。
- 如何实时看清系统的容量水位，为容量评估和系统扩容提供客观依据?
- 当故障发生时，如何精确判断影响范围?
- 如何确定每一次交易过程中，每个系统处理耗时分别是多少?
- 每个系统在处理一笔交易时，分别在数据库、NoSQL、缓存、日志、RPC、业务逻辑上耗时多少?
- 如何快速确定系统的真正瓶颈点?
面对上述难题，本文将从智能容量评估与智能告警切入，为大家分享京东金融的运维实践。
智能容量评
应用的容量评估是一个老大难问题，目前也没有一种简单而有效的方式，主要是通过压测手段直接得到应用单机*** QPS 的相关数据。
线下压测
为了测试数据的相对真实性，在容量评估的线下压测中一般通过 tcpcopy 等工具，将线上的流量直接复制到测试服务器，在测试服务器出现瓶颈时得到应用***的 QPS，再通过线上线下的换算系数推算出线上的应用能承载的容量。
注：本图片转自tcpcopy官网
线上压测
通过线下压测的方式进行容量评估的优点是压测过程对线上的环境几乎没有影响，但是过程比较繁琐，耗时也较长。所以以短平快为主要特色的互联网公司更钟爱通过线上的压测来进行容量评估。
如何进行线上的压测?
一般来说，不管是通过集中的负载设备(如 F5、Radware 等)或是四七层的软负载(LVS、Nginx、HAProxy 等)亦或是开源的服务框架(如 Spring Cloud、DUBBO 等)都支持加权轮询算法(Weighted Round Robin)。简单的说就是在负载轮询的时候，不同的服务器可以指定不同的权重。
线上压测的原理就是逐渐加大某一台服务器的权重，使这台服务器的流量远大于其他服务器，直至该服务器出现性能瓶颈。这个瓶颈可能是 CPU、LOAD、内存、带宽等物理瓶颈，也可能是 RT、失败率、QPS 波动等软瓶颈。
当单机性能出现性能瓶颈时，工程师记下此时的应用 QPS 就是单机容量，然后根据集群服务器数量很容易得到集群的容量。
如下 Nginx 的配置，使得服务器 192.168.0.2 的流量是其他服务器的 5 倍，假设此时服务器 192.168.0.2 出现瓶颈，QPS 为 1000，那么集群容量为 3000。(假设负载没有瓶颈)
- http {
- upstream cluster {
- server 192.168.0.2 weight= 5;
- server 192.168.0.3 weight= 1;
- server 192.168.0.4 weight= 1;
- }
- }
容量计算
不管是线上还是线下的压测，反映的都是压测时的应用容量。在互联网快速发展的今天，程序版本迭代的速度惊人，针对每次版本的迭代、环境的变化都进行一次线上的压测是不现实的，也是不具备可操作性的。
那么换一种思路去思考，我们通过压测去评估应用的容量其实是因为我们无法知道具体的一个方法的耗时到底在哪里?也就是说被压测的对象对我们是一个黑盒子，如果我们想办法打开了这个黑盒子，理论上我们就有办法计算应用的容量，而且可以做到实时的应用容量评估。
因此，迫切需要寻求另外一种解决问题的思路：QPS 的瓶颈到底是什么?如果弄清楚了这个问题，应用的 QPS 就可以通过计算得到。
再结合下图的耗时明细和应用所处的运行环境，我们就可以找到具体的瓶颈点。
举一个简单的例子：
如果一个方法在一定采样时间内，平均 QPS 为 200，平均耗时为 100ms，耗时明细分析发现平均访问数据库 6 次，每次耗时 10ms，也就是数据库总耗时 60ms，其他均为业务逻辑耗时 40ms。如何确定应用的容量呢?
假如数据库连接池的***连接数为 30，执行此方法的线程池***为 50(简单起见暂时不考虑线程的切换成本)，那么理论上数据库的单机*** QPS 为 30*1000/60=500。
同理业务逻辑的单机*** QPS 为 50*1000/40=1250，显然这个方法的瓶颈点在数据库上，也就是这个方法的单机*** QPS 为 500。
然后，针对这个方法进行优化，数据库每次访问的耗时降到了 5ms，平均访问次数变成了 4 次，也就是数据库总耗时为 20ms，业务逻辑耗时依然是 40ms，此时数据库的单机*** QPS 为 30*1000/20=1500。显然此时的瓶颈点在业务逻辑上，也就是这个方法的单机*** QPS 为 1250。
上例为一个方法的单机*** QPS 推断，结合其他方法做同理分析，依据计算出这个方法在整个应用中对资源的占用比例就可以推算出整个应用的单机*** QPS。
进一步分析，业务逻辑耗时也就是总耗时去除了 IO 的耗时(如 RPC 远程调用、访问数据库、读写磁盘耗时等等)，业务逻辑耗时主要分为两大部分：
- 线程运行耗时(RUNNABLE)
- 线程等待耗时(BLOCKED、WAITING、TIMED_WAITING)
通过对业务逻辑耗时的分类得知，真正消耗 CPU 资源的是线程运行耗时，那么问题就变成了我们怎么拿到运行时间与等待时间的耗时比例了。
CPU 使用率(进程、线程)可以通过 proc 虚拟文件系统得到，此处不是本文重点，不展开讨论。不同环境还可以通过不同的特性快速得到这些数据。以 Java 应用为例，我们可以从 JMX 中拿到线程执行的统计情况，大致推算出上述的比例，如下图所示：
继续分析上面的例子，假设我们通过分析线程的运行情况得知，运行时间与等待时间为 1：1，此时进程 CPU 的使用率为 20%，那么 CPU 指标能支撑的单机*** QPS 为 200 * 100% / 20% = 1000，也就是这个方法的单机*** QPS 为 1000。同理可以推断网络带宽等物理资源的瓶颈点。
一般来说，业务逻辑耗时中，对于计算密集型的应用，CPU 计算耗时的比例比较大，而 IO 密集型的应用反之。
通过以上的数据，我们就可以实时评估系统的容量，如下图：
应用实时水位图
智能告警
根源告警分析是基于网络拓扑，结合调用链，通过时间相关性、权重、机器学习等算法，将告警进行分类筛选，快速找到告警根源的一种方式。它能从大量的告警中找到问题的根源，因此大大缩短了故障排查及恢复时间。
告警处理步骤
- 告警过滤(将告警中不重要的告警以及重复告警过滤掉)
- 生成派生告警(根源关联关系生成各类派生告警)
- 告警关联(同一个时间窗内,不同类型派生告警是否存在关联)
- 权重计算(根据预先设置的各类告警的权重，计算成为根源告警的可能性)
- 生成根源告警(将权重***的派生告警标记为根源告警)
- 根源告警合并(若多类告警计算出的根源告警相同，则将其合并)
- 根据历史告警处理知识库，找到类似根源告警的处理方案，智能地给出解决方案。
根源告警原理图
举例来说：
假设多个系统通过 RPC 进行服务调用，调用关系如下：D 系统->C 系统-> B 系统-> A 系统。
当 A 系统查询数据库出现查询超时后，告警会层层往前推进，导致 B、C、D 系统均有 N 个超时告警产生。此时，ROOT 分析可以将告警进行收敛，直接分析出根源告警为 A 系统访问数据库异常，导致 A、B、C、D 多个系统异常。
这样，就避免了处理人员和每个系统开发人员沟通，辅助处理人员快速定位问题根源、提高了平均解决时间(MTTR)。如下图所示：
根源告警调用链关系
根源告警明细表
根源告警分析主要分为强关联分析与机器学习两类。
a.强关联数据分析
强关联指的是已知确定的关联关系。如：
- 应用之间的调用链关系
- 数据库与应用服务器
- 网络设备与网络设备、网络设备与应用服务器
- 宿主机与虚拟机关系等
若在同一个时间窗内，有多个强关联的设备或应用服务器同时告警，则大概率认为告警之间存在关联关系。
在权重算法中，有一个重要的规则，链路上存在连续的告警可能存在关联，越靠后的应用越可能是根源。现在我们根据例子，分别计算各类根源告警。
继续使用上面的例子，D 应用->C 应用->B 应用->A 应用->数据库异常的情况。
- 首先是计算数据库根源告警。根据数据库关联关系，会派生数据库类型的数据库告警、A 应用告警。还会派生一条应用类型的 A 应用数据库异常告警。
根据数据库派生告警以及数据库与应用的关联关系及权重，可以得出数据库异常导致 A 应用查询超时。
- 接下来是计算应用根源告警。根据调用关系，我们先计算出连续多个应用告警的链路。当前 D->C->B->A 四个应用都有派生告警，满足此规则。
- 然后，找到最靠后的告警应用，也就是 A 应用。列举时间窗口内所有 A 应用的派生告警(可能存在多种派生告警，根据权重计算根源)，将权重***的派生告警标记为根源告警。
比如：A 系统内部有 2 种类型派生告警，分别是数据库告警、GC 告警。
根据权重计算规则，数据库告警为 90，GC 告警 10，也就是说数据库异常告警权重***。这时由于数据库根源告警和调用链根源告警一致，会将两种类型的告警合并。***得出结论：数据库异常导致 A、B、C、D 系统告警。
b.机器学习根源分析
强关联数据分析是对已知告警的关联关系，直接进行根源告警分析。但是有些时候，关联关系是未知的。这时就需要通过机器学习算法，找到告警之间的隐含联系，再进行根源告警预测。
目前，主要进行了两类机器学习实践。
1、关联规则算法
关联规则算法主要进行了 Apriori 算法和 FPGrowth 两类算法的实践。这两类功能相似，都可以发现频繁项集。经过实测，FPGrowth 比 Apriori 更高效一些。
我们按一定的时间间隔划分时间窗，计算每个时间窗内，各种告警一起出现的频率，找出各类告警之间的关联。最终可按分析出的关联关系，生成根源告警。
关联规则算法的优点在于理解和实现起来比较简单。缺点是效率比较低，灵活度也不够高。
2、神经网络算法
循环神经网络(简称 RNN)是一个和时间序列有关系的神经网络，对单张图片而言，像素信息是静止的，而对于一段话而言，里面的词的组成是有先后的，而且通常情况下，后续的词和前面的词有顺序关联。
这时候，卷积神经网络通常很难处理这种时序关联信息，而 RNN 却能有效地进行处理。
随着时间间隔的增大，RNN 对于后面时间的节点相比前面时间节点的感知力将下降。解决这个问题需要用到 LongShort Term 网络(简称 LSTM)，它通过刻意的设计来避免长期依赖问题。LSTM 在实践中默认可以记住长期的信息，而不需要付出很大代价。
对于某类故障引起的大量告警之间，存在着时间相关性。将历史派生告警作为输入，将根源告警类型作为输出。通过 LSTM 提取派生告警特征，建立告警相关性分析模型。这样就可以实时将符合特征的派生告警，划分到同一类根源告警中，帮助用户快速定位问题。
需要说明的是金融本身的业务特点决定了对第三方存在依赖性，因此告警本身的随机性较大，客观上导致学习样本的质量不高，需要长期的积累和修正才能达到比较好的效果，因此对于根源告警，如果有条件取到强关联关系，建议使用强关联分析，能达到事半功倍的效果。
结语
智能运维是目前运维领域被炒得最火的词汇之一，但是个人认为没有一个智能运维的产品是放之四海而皆准，智能运维需要在真实的环境中不断的磨合，才能达到我们预期的效果。
随着人工智能在运维领域的不断尝试与探索，未来在运维领域中的异常检测与智能报警及自动化容量规划与分配必将得到快速的发展，从而成为运维的核心竞争力。
沈建林
京东金融集团资深架构师
曾在多家知名第三方支付公司任职系统架构师，致力于基础中间件与支付核心平台的研发，主导过 RPC 服务框架、数据库分库分表、统一日志平台，分布式服务跟踪、流程编排等一系列中间件的设计与研发，参与过多家支付公司支付核心系统的建设。现任京东金融集团资深架构师，负责基础开发部基础中间件的设计和研发工作。擅长基础中间件设计与开发，关注大型分布式系统、JVM 原理及调优、服务治理与监控等领域。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
编辑：王雪燕、陶家龙、孙淑娟
