直击传统运维痛点，京东金融智能运维初探！

《直击传统运维痛点，京东金融智能运维初探！》要点：
本文介绍了直击传统运维痛点，京东金融智能运维初探！，希望对您有用。如果有疑问，可以联系我们。

随着互联网+时代的到来,京东金融业务规模不断扩大,业务场景也不断创新.但是,业务变化之快超乎想象,相应的 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 资源的是线程运行耗时,那么问题就变成了我们怎么拿到运行时间与等待时间的耗时比例了.

（编辑：ASP站长网）