从人肉运维到智能运维，京东金融服务监控的进阶之路

为什么要做服务监控?

业务规模不断扩大、微服务化、频繁变更这三方面现实需求，是做服务治理和监控的重要原因。为保证这三方面的正常进行，需要做很多事，重点包括如下几点：

• 如何快速发现问题?采用哪些技术?
• 如何梳理服务依赖?面对京东过万的服务，如何进行梳理，具体实现过程是怎么样的?
• 如何判断依赖合理性?微服务之间相互依赖，采用什么样方式判断依赖是否合理?
• 如何实现实时容量规划?传统的方式是在618前两月进行封网，不允许上线，利用这段时间进行线上压测，得到应用的容量，随后根据现实情况进行扩容。这样的方式耗时耗力，所有研发不让上线，成本很难评估。现在的做法是基于历史数据，机器学习，自动运算，那具体是如何实现的?
• 如何判断故障影响范围?也就是故障定位问题，如何能知道哪个节点发生故障，响应了哪些业务?
• 如何实现业务级监控?京东金融会和很多第三方支付机构打交道，如何去监控和合作伙伴之间交易的服务质量?

综上都是服务监控要完成的使命，下面我们先从服务监控设计原则、自主监控的基本要素、服务依赖关系梳理、调用链分析、容量规划、根源分析等方面来看看服务监控的应用。

服务监控的应用实践

服务监控设计原则

服务监控与治理软件的设计原则主要有五个方面，分别是微内核、乐观策略、零侵入、约定大于配置、动态路由。

• 微内核。设计产品时把内核设计的非常小，称之为微内核。采用Plugin模式，所有功能采用微内核方式，把自己也当做第三方去扩展，这样的产品，不管是开源或商用，别人扩展时也会更加便捷。
• 乐观策略。不能因为监控影响业务，一旦影响业务采用抛弃策略，监控项要全部异步处理。通过SoftReference(软引用)的方式，在内存吃紧的时候优先释放掉监控本身所占用的内存。
• 零侵入。简化研发使用，实现业务、中间件、监控完全独立。
• 约定大于配置。自动发现：部署规范，配置规范默认返回码、描述。
• 动态路由。日志传输节点远程控制，无限扩容。

自主监控三剑客

做自主监控有三个最基本要素，分别是调用量、性能、成功率。后期的一些监控扩展，都是基于这三个指标。如下图，是监控的细节：  

如图中所示，红颜色的线条被称之基线，通过波动可知当前这个服务的响应时间、调用量、成功率等情况。基线计算很复杂，基于以前历史数据，利用异常检测算法，推算当前的量应该是多少。

如下图，是监控分层的细节展示：

如图中所示，每一条线都可以下钻，钻进去就可看到某个应用里有哪些类正在被监控，进一步下钻可以看到方法、IP级别。当出现某一台服务器故障，影响整个响应时间时，从IP级别的图中就可以快速定位，看到是哪个IP出现了问题。

服务依赖关系梳理

分享服务梳理方法之前，先来了解两个概念：依赖强度和依赖频度。

• 依赖强度指服务之间的依赖关系强弱。比如购物必须要交易，交易必须经过支付后才发货，交易对支付就是强依赖，支付系统出故障，交易也不能幸免。
• 依赖频度指对某一个服务的调用次数，调用频繁，就是高频依赖。

基于这两个概念，可以进一步对方法、应用和业务线之间的依赖关系进行分析，如下是某场景依赖关系的全拓扑图：

从图中，可以很清晰的看到整个调用的拓扑，所有应用相互之间的依赖强度，通过连线之间的数字来描述应用之间的依赖频度。

如下，是依赖关系的主流程图:

把弱依赖及依赖频度较小的应用去掉以后，可以看到主流程，主流就是核心系统，如果出现故障，影响会非常大。

调用链分析

如下图，是调用链分析:

这是整个服务监控中相对重要的环节，当触发一次请求，如用户在京东购物，用户付款这个动作要经过哪些IP来处理，IP上有哪些方法进行处理，通过哪些协议去调用，耗时是多少，每一次调用都要跟踪，每天有千亿以上类似的调用。

整个调用链都处于监控中，如出现故障，告警就会通过短信、邮件的方式把链接推送给运维人员。运维人员点开链接就可知晓故障位置，同时还有一些工具辅助处理问题。

容量规划

容量规划方面，传统的方式是应用上线之前做压测，但很多时候一上线容量就变了，导致之前设置的数据都是没有意义了。如下图，是现在的实时容量规划方式：

如上图左侧所示，在618，双11等大促时，把这些拓扑图实时数据和性能指标都摆放在大屏上，当水位、响应时间等任何一个指标出现异常，运维人员就会及时发现问题，并快速进行问题解决。

如下图，是服务访问慢，出现异常的快速定位案例：

当服务访问慢时，系统会计算到IP上的指标，很多时候是一两台服务器过慢，可通过邮件看到是哪个服务器出问题。点开邮件链接，就可以看到从什么时间开始慢，什么时间结束，平均的响应时间是否偏高。进一步下钻，可看到什么样的问题导致响应时间偏高，这里会引用一些智能故障分析工具。

根源分析

根源分析可基于自动学习的拓扑关系、数据库与应用的关系、应用与IP的关系等确定性因素来做，如下图，是一个非常典型的磁盘IO导致日志打印慢的问题。

这样因一台机器由于打印日志排队造成堵塞，导致后面好多应用出现调用性能下降的简单问题。如果没有根源分析，要靠人为分析去定位根本原因还是非常困难的。

综上所述是服务监控的应用，下面我们从日志采集方案对比、分布式服务跟踪的挑战、整体技术架构等方面来看看技术实现。

服务监控的技术实现

日志采集方案对比

所有的服务监控是基于一条日志，日志采集方案有很多，如下图所示，分为四个阶段：

最原始的阶段，是业务各自监控，自己编写监控逻辑，业务上埋点，输出自己的监控日志。

第二阶段，是业务与监控耦合，提供公共的监控API，通过API的方式自动产生这条日志。

第三阶段，是中间件与监控的耦合，通过中间件埋点方式来产生这条日志。

第四阶段，是业务、中间件、监控无耦合，采用APM或流量镜像分析的方式。流量镜像分析，是从设备上把流量镜像下来，分析服务之间的关系，但存在的问题是，流量分析出来的是一个结果，当应用调整或服务依赖发生变化，结果会受到很大影响。APM是目前主流的方式。

分布式服务跟踪的挑战

在分布式追踪上，我们碰到了一些问题，这里主要分享三方面，分别是跨线程、跨协议、扩展性。

• 跨线程。在设计过程中，服务被访问时，可能会启动新线程去处理，跨线程去追踪会有些难度。以Java语言举例来说，同线程之内，可借助现有ThreadLocal非常方便的去追踪。如某个服务有一部分代码逻辑是放在另一个线程上执行的，就要去修改JDK对线程的一些实现逻辑。
• 跨协议。通常情况下，追踪链都很长，一个正常的交易要由很多应用串起来，提供服务。这时就要跨很多协议如RPC、HTTP、JMS、AMQP等去追踪。
• 扩展性。当新增协议、与其他企业框架不同怎么办?这需要自定义的扩展性描述语言来解决。

服务监控平台的整体技术架构

如下图，是服务监控平台的整体技术架构：

服务监控平台的核心是产生日志的Agent，采用Java Bytecode的方式进行自动增强。由统一的Config Server下发监控指令，Agent在应用启动时或者运行时动态增强需要监控的方法。日志产生后由路和模块决定发送到哪里，可以是本地磁盘、消息队列、Collector等。随后进行流水计算，实时汇聚结果，存入NoSQL，然后由页面进行展示。

由于篇幅原因，很多内容没有一一整理，服务监控应用部分：调用来源分析、耗时分析、JVM监控以及针对业务的一系列监控模型，像分类、比值等。服务监控技术实现部分：Agent采集内容、调用链扩展方式、自动监控扩展以及一些优化小贴士。欲知更详尽的内容，请点击 视频观看。

【讲师简介】