3.1 线上微服务度量核心指标及分析手段

指标的定义及汇总要尽量保持简单，过于复杂可能会掩盖某种系统性能的变化，也更难以理解。针对线上微服务治理行为，最基础的度量指标共三个：调用量、调用延时和异常。

3.1.1 点：单次请求指标采集

图3.1-①是微服务架构下的典型请求调用，request首先调用前置的A服务，再通过A服务调用实际负责业务逻辑处理的B服务，B服务先后调用了业务数据持久化的C服务和D服务，C服务的业务逻辑涉及数据库的读写操作，D服务的业务逻辑涉及消息队列和缓存的读写操作。

利用2.2.4.2节介绍的应用系统监控技术及2.2.4.3节介绍的调用链跟踪技术，可以获得此次跨网络请求的完整监控指标集合，如图3.1-②所示。这个集合包含如下几项分段（原子）请求：

● A服务调用B服务的请求耗时及状态；

● B服务调用C服务的请求耗时及状态；

● B服务调用D服务的请求耗时及状态；

● C服务进行数据库操作（update）的耗时及状态，如果失败了则同步记录失败信息；

● D服务进行MQ操作（send，发送消息）的耗时及状态；

● D服务进行分布式缓存操作（get、put）的耗时及状态。

以上每一个步骤都可以描述为：调用者是谁，被调用者是谁，在什么时间，调用动作是什么，结果如何。调用者和被调用者涉及请求主体；时间包括时间戳与时间跨度两个重要信息，时间戳表示请求的发生点，时间跨度标识了请求的持续时间；调用动作决定了请求的分类，对于治理的度量至关重要；结果涉及请求的稳定性和质量方面的分析。微服务和微服务之间只有一个动作，就是远程调用（标识为remoteCall），所以在图上我们不需要标注动作。微服务对资源的调用操作有很多种，比如对数据库可能会有select、insert、update、delete等操作，所以必须显式地把它标注出来。

通过图3.1-②，可以对一个跨越网络多个服务节点的请求的完整生命周期有直观的认识。

3.1.2 线：单服务一分钟指标叠加统计

单纯一次网络调用的指标记录可以用于调用链跟踪及故障定界定位的详细分析，但对于衡量服务的总体健康状态意义不大，因为可能存在波动。为了消除波动的影响，可以将一段时间内对服务的所有请求进行汇总，做统计分析。这个时间维度多大合适呢？一秒？一分钟？还是一小时？首先这个时间维度不能太短，一次跨网络、涉及多个网络节点的请求，在各个节点上的请求时间极有可能落在不同的“秒段”上，统计时间维度太短会导致不准确。因此，可以排除一秒钟作为时间维度的可能性。一个小时的时间维度又太长，根据业界的经验，最适宜的指标统计时间维度为一分钟，这也是目前绝大部分团队进行指标汇总时采用的单位时间标准。

将一分钟内所有请求对每个服务和资源的调用进行专项合计，分别计算出总耗时、总调用次数、成功调用次数、失败调用次数等统计指标，如图3.2所示。

有了基础汇总数据后，将总耗时（总耗时是对成功请求的耗时进行累加所得的，针对失败请求计算耗时没有意义）除以成功调用次数，即可得到这一分钟内的算术平均耗时。但算术平均耗时很难准确描述一分钟内的所有请求的分布状况，因此，还可以基于汇总数据计算95分位耗时和99分位耗时。95分位和99分位是正态（高斯）分布中的常用说法，可以简单地认为比95%和99%的请求调用延时大的两个耗时值，它们体现了正态的全面性，可以更加客观地描述调用耗时的分布情况。具体汇总数据展示如表3.1所示。

计算一分钟汇总数据时有个技巧，由于服务都以集群的形式存在，每个服务都有多个节点，可以以服务节点（单IP）为最小统计单元，通过汇总所有服务节点的分钟统计数据获得整个服务集群的分钟统计数据。当然，为了将单个服务节点的统计数据再次汇总出全集群统计数据，在单条分钟汇总数据记录中要额外存储一些中间计算数据，因此汇总记录中的字段数要比表3.1中的字段多。

对监控指标数据进行分钟级统计具有重要的意义。就单个服务而言，冷门服务也许一分钟内没有一个调用请求，而热门服务一分钟内可能会有上百万次请求，这种不确定性经常迫使我们采用NoSQL数据库来存储原始指标数据。如果没有分钟级汇总数据，纯粹基于原始指标数据做实时大时间跨度的平均值或95/99分位值的计算会极其消耗系统计算资源，效率非常低。有了分钟级的汇总统计，一个服务实例一分钟只有一条统计数据，一天最多有60×24=1440条。相对于原始数据，数据总量大幅下降且可预估。这种确定性对运维有很大的好处，可以提前规划统计分析平台的数据库容量。数据总量的减少让我们可以放心地将统计数据存储在关系型数据库中，以充分发挥关系型数据库在数据关联、排序、统计方面的综合优势，这是NoSQL数据库无法比拟的。有了分钟级汇总数据后，还可以定期清理历史原始数据（例如，可以只保留最近3个月的原始请求指标数据），因为历史指标更多用于同比和环比，分钟级汇总数据就完全能满足需求。

3.1.3 面：单服务时间维度汇总统计

在分钟级统计记录的基础上，可以做更长时间周期的汇总统计报表。举个例子，如果要做一年内系统负载及性能指标（调用耗时）的月度环比统计图表，分钟级的统计记录还是过于细小。因此需要在分钟级统计记录的基础上，再汇总小时统计记录、天统计记录、月度统计记录。根据笔者的经验，汇总到月度一级的报表粒度已经差不多了，可以在效率和灵活性上达到较好的平衡。需要注意的是，这些多级汇总记录还是以单节点、单服务为维度的。

以上讨论的分钟、小时、天、月度汇总统计数据就是2.4.2.3节中讨论的数据集市中数据分层存储的典型例子。在此基础上，可以做更多的数据分析，包括典型的“同比”和“环比”的聚合操作，如图3.3所示。

3.1.4 体：服务及资源指标聚合分析

在请求的整个生命周期中，不仅有服务间的调用，还有服务对资源的调用，这类调用也可以被记录并汇总统计，可以参考服务调用请求的做法。将图3.2中针对数据库、消息队列、分布式缓存的调用汇总数据进一步整理，可以得到关于资源的指标汇总表，表3.2和表3.3分别为数据库和分布式缓存调用日志的分钟级汇总统计表格，两者之间有些小的差异，根据资源类型不同，数据库的汇总统计增加了DAO方法及对所操作表名称的记录。

有了服务与资源之间的调用指标，就可以站在服务应用的角度来看待资源服务的线上性能及质量了。基于此角度获得的资源评估和资源自身的评估是不同的，不仅涵盖资源服务自身的性能质量评估，还涵盖对资源服务所处网络环境的性能质量的一体化度量，更广义、更客观！

服务、服务与服务、资源的线上指标相结合，构成了线上服务治理的完整指标体系。在此基础上，可以在指标度量的数据模型中添加更细粒度的时间维度、节点维度、服务维度、应用维度、异常维度和业务维度等（具体体现在数据集市上），最终构建出服务治理的指标数据立方体（Cube）。通过该立方体各个维度的数据钻取，实现对线上服务质量的全面综合度量。下面将分节对微服务不同维度的度量方法和体系展开介绍。