【.com原稿】人肉阶段的运维，理想与现实大相径庭，无穷无尽埋怨，无尽的坑。运维领域的现状是人工运维、自动运维、智能运维相互重叠。智能运维是大势所趋，但真正落地的并不多。在主办的第十四期“TechNeo”技术沙龙中，资深架构师沈健林分享了京东金融服务监控和服务治理的应用和技术实现。为什么需要服务监控？业务规模不断扩大、微服务化、变更频繁的现实需求是服务治理和监控的重要原因。为了保证这三个方面的正常进行，需要做很多事情。重点包括以下几点：如何快速发现问题？使用了哪些技术？如何梳理服务依赖？面对京东。如何？如何判断依赖的合理性？微服务相互依赖。用什么方法判断依赖是否合理？如何实现实时容量规划？这段时间在线压测获取应用的容量，然后根据实际情况进行扩容。这种方式费时费力，所有的研发都不允许上线，成本难以估计。目前的做法是基于历史数据、机器学习和自动计算。它是如何实现的？如何判断故障影响范围？也就是故障定位的问题。我们如何知道哪个节点发生故障以及响应了哪些服务？如何实现业务层面的监控？京东金融会和很多第三方支付机构打交道。如何监控与合作伙伴交易的服务质量？总结起来就是服务监控的使命。先从服务监控的设计原则和独立监控的基础说起。下面我们从要素、服务依赖排序、调用链分析、容量规划、根因分析等方面来看一下服务监控的应用。服务监控应用实践服务监控设计原则服务监控与治理软件的设计原则主要包括微内核、乐观策略、零入侵、约定优于配置、动态路由五个方面。微内核。在设计产品的时候，内核被设计的很小，称为微内核。采用Plugin模式，所有功能采用微内核方式，作为第三方自行扩展。这样的产品，不管是开源的还是商业的，都会更方便别人去扩展。乐观策略。业务不受监控影响。一旦业务受到影响，就应该采用放弃策略，所有的监控项都要异步处理。通过SoftReference（软引用），当内存吃紧时，先释放monitor自身占用的内存。零入侵。简化研发和使用，实现业务、中间件、监控的完全独立。约定大于配置。自动发现：部署规范、默认返回码和配置规范说明。动态路由。日志传输节点远程控制，无延时扩容。自我监控三剑客自我监控最基本的三个要素，分别是通话量、业绩、成功率。后来的一些监控扩展就是基于这三个指标。下图为监控详情：如图所示，红线称为基线，通过波动可以知道当前服务的响应时间、调用量、成功率。基线计算非常复杂。根据以前的历史数据，使用异常检测算法来估计当前数量应该是多少。下图展示了监控层的细节：如图所示，每一行都可以向下钻取，钻进去可以看到一个应用中有哪些类在被监控，可以看到方法，IP层。当某台服务器出现故障，影响到整个响应时间时，可以从IP级别的图中快速定位，看看是哪个IP出现了问题。服务依赖排序在分享服务排序方法之前，我们先了解两个概念：依赖强度和依赖频率。依赖强度是指服务之间依赖关系的强弱。例如，购物必须进行交易，交易必须先付款再发货。交易强烈依赖于支付。如果支付系统出现故障，交易将无法幸免。依赖频率是指对某个服务的调用次数。频繁调用是高频依赖。基于这两个概念，我们可以进一步分析方法、应用和业务线之间的依赖关系。下面是某个场景下的依赖关系的完整拓扑图：从图中可以清楚的看到整个调用的拓扑结构，所有应用程序的相互依赖强度通过线间的数字来描述依赖的频率应用程序之间。下面是依赖的主要流程图：去除弱依赖和依赖不频繁的应用后，可以看到主流程。主流是核心系统。如果出现故障，影响会非常大。调用链分析如下图，是调用链分析：这是整个服务监控中比较重要的一个环节。当请求被触发时，比如用户在京东购物时，会使用哪些IP来处理用户的支付动作，IP上有哪些方法？处理，用什么协议调用，用了多长时间，每次调用都要跟踪，每天有超过1000亿次类似的调用。整个调用链都在监控中。如果出现故障，告警会将链接通过短信或邮件推送给运维人员。运维人员点击链接就可以知道故障的位置，也有一些工具可以辅助处理问题。容量规划在容量规划方面，传统的做法是在应用上线前做压测，但很多时候一上线容量就变了，让之前设置的数据变得毫无意义。下图展示了目前的实时容量规划方式：如上图左侧所示，在618、双11等大促期间，这些拓扑图的实时数据和性能指标都放在了大屏幕。当水位、响应时间等任何指标出现异常时，运维人员会及时发现问题，迅速解决问题。如下图，是一个服务访问慢的快速定位案例，出现异常：当服务访问慢时，系统会计算IP上的指标。很多时候是一两台服务器太慢了，通过邮件就可以看出是哪台服务器出了问题。点击邮件中的链接，你可以看到它什么时候开始变慢，什么时候结束，平均响应时间是否过高。再往下钻，可以看到是什么问题导致响应时间过长，这里会引用一些智能故障分析工具。根本原因分析可以根据自动学习到的拓扑关系、数据库与应用的关系、应用与IP的关系等确定性因素进行根本原因分析。如下图，是一个非常典型的磁盘IO导致的日志打印慢的问题。这样一来，由于打印日志排队导致一台机器阻塞，导致后续很多应用出现调用性能下降的简单问题。如果没有根因分析，靠人的分析来定位根因还是很困难的。综上所述，以上就是服务监控的应用。下面我们从日志采集方案对比、分布式服务跟踪挑战、整体技术架构等方面来看一下技术实现。服务监控技术实现日志采集方案对比所有服务监控都是基于一条日志。日志采集方案有很多种，如下图，分为四个阶段：最原始的阶段是监控各个业务，自己写监控逻辑。埋头业务，输出自己的监控日志。第二阶段是业务和监控的耦合，提供一个公共的监控API，通过API自动生成这个日志。第三阶段是中间件和监控的耦合，这个日志是通过中间件埋点产生的。第四阶段是业务、中间件、监控之间没有耦合，采用APM或者流量镜像分析。流镜像分析就是对来自设备的流量进行镜像，分析服务之间的关系。但是，问题是流量分析的结果是一个结果。当应用程序调整或服务依赖发生变化时，结果将受到很大影响。APM是目前主流的方式。分布式服务追踪的挑战在分布式追踪中，我们遇到了一些问题。这里主要分享三个方面，即跨线程、跨协议、可扩展性。跨线程。在设计过程中，当访问一个服务时，可能会启动一个新的线程进行处理，跨线程跟踪可能会比较困难。以Java语言为例，在同一个线程内，借助已有的ThreadLocal进行跟踪是非常方便的。如果一个服务的部分代码逻辑是在另一个线程上执行的，那么JDK就需要修改该线程的一些实现逻辑。跨协议。通常，追踪链条很长，一笔正常的交易需要很多应用程序连接起来提供服务。这时候就需要跟踪跨RPC、HTTP、JMS、AMQP等多种协议的可伸缩性。新增协议，和其他企业框架不一样怎么办？这就需要自定义可扩展的描述语言来解决。服务监控平台整体技术架构如下图所示，是服务监控平台的整体技术架构：服务监控平台的核心是产生日志的Agent，由JavaBytecode自动增强。统一的ConfigServer下发监控指令，Agent在应用启动或运行时动态增强需要监控的方法。日志生成后，由路由和模块决定发送到哪里，可以是本地磁盘，消息队列，Collector等。然后进行流水线计算，实时聚合结果，存入NoSQL，然后将它们显示在页面上。由于篇幅原因，很多内容就不一一整理了。服务监控应用部分：调用源分析、耗时分析、JVM监控，以及业务的分类、比例等一系列监控模型服务监控技术实现部分：Agent采集内容、调用链扩展方式、自动监控扩展和一些优化技巧。更多详细内容，请点击视频观看。【讲师简介】曾在多家知名第三方支付公司担任系统架构师，致力于基础中间件和支付核心平台的研发，主导了RPC服务框架，数据库分库分表，统一日志平台、分布式服务跟踪、流程编排等一系列中间件的设计与开发，参与了多家支付公司支付核心系统的建设。现任京东金融集团高级架构师，负责基础开发部基础中间件的设计与开发。擅长基础中间件设计与开发，专注于大型分布式系统、JVM原理与调优、服务治理与监控等领域。【原创稿件，合作网站转载请注明原作者和出处为.com】
