SRE02|管中窥豹，微服务可用性监控之道

作者：方勇(gopher)

2021 年 12 月 28 日
本文字数：5638 字
阅读完需：约 18 分钟

溪云初起日沉阁，山雨欲来风满楼

技术重要吗？

在我们身边经常有一些自嘲的声音：作为“新生代农民工”，干的都是体力活，加班严重，认为做技术没有什么前途，好多人都拼命地想转管理或是转行。这是中国技术人员的一个现实问。这个问题耗子叔在 17 年也探讨过。[注 1]

这里不得不引出一个大家比较敏感的话题：是产品决定技术还是技术决定产品？

21 世纪信息化标志着第四次工业革命的开始，中国互联网经历了 20 多年的高速发展，产品迭代也逐渐从野蛮发展过度到了精细化运营阶段，技术可谓撑起了互联网半壁江山。

伴随业务的不断迭代，技术趋向越来越精细化的运作，前后端分离，SOA 微服务，自动化测试，自动化运维，自动化部署等。背后的技术折叠带来了研发能效的提升，同时也带来了技术人员的焦虑。

在微服务的江湖里，开发工程师如何证道，从而跳出“CRD 码农怪圈”呢？今天我们管中规豹，只从监控的角度聊一下如何运营高可用的微服。

运营高可用的微服务就像和邻家女孩谈恋爱，需要细水长流。你会关注她一日三餐吃什么，今天又换个什么发型，为何又发小脾气。如果这时候有个小舅子帮你透风，就能事半功倍。SRE 小组很多时候就是充当“小舅子”这个角色，那 SRE 这个“小舅子”是如何辅助大家证道呢？且听我从三个阶段一一道来。

1、问道：为何微服务可用性运营带来了证道契机？2、寻道：渔网先有纲方有眼，MDD 指导微服务运营从 0 到 1！3、入道：微服务运营分层模型让不同角色各司其职。

向阳而生，孕育工程师修炼法则

康威定律表明，组织架构制约系统设计，影响意识形态。产品、开发、测试、运维往往处在不同的组织架构中，天然存在意识不一致性，产生的沟通成本往往会隐形反馈到微服务运营上，甚至多方博弈后往往忽略了微服务运营。

博弈论中有个经典模型“囚徒困境”和“纳什均衡”。由于产品、开发、测试、运维每个人的认知和关注点各不相同，有时候交流鸡同鸭讲，如果相互推诿很容易形成囚徒困境，如果大家什么都不做，或者各自为政，可能出现纳什均衡。但这些不一定来带收益最大化，那有没共赢方案呢？

前面也提过，一款成熟的产品不再仅仅是功能实现，最终会演化成精细化的运营。接受市场的洗礼，得到社会认可才能成活。有些工程师认为这些都是产品应该考虑的事，随着躺平思想的渗透，还有一种声音，做多错多，不做不错。运营一款好的产品早已不是单独几个人的事了，微服务的可用性易用性都深深影响着产品的生命周期。这需要工程师拓宽认知边界，工程师在提升服务可用性上，不断淬炼，修炼内功，从而和产品实现共赢。

再谈工程师文化

有些“工程师”认为服务开发完就完事了，后期就是运维和产品的事了。如果把自己定位为“CRD 码农”那这种想法无可厚非，一个人只是懂一点工程实现的手段，需要别人告诉他怎么做，那最多算是助理工程师或者技工，不在我们讨论的工程师之列。

前面也说过工程师文化，每一级的能力和贡献大致可以总结如下。

[注 2]

第五等工程师，能够独立设计和实现一项功能的人。这也是工程师最基本的要求。

第四等工程师，需要有点产品头脑，他们会考虑产品的价值，可用性，易用性，稳定性等等。还需要有一定的领导力，能从头到尾负责整个产品的生命周期。这不是学校能培养出来的，需要三到四年的工作积累的锤炼。

第三等工程师，可以做出行业里最好的产品。他们一般工作十年八年，经过多次失败，不断总结，突发在哪一天顿悟。一个年轻人工作了四五年就开始做行政管理工作，基本上就和这个水平无缘了。

第二等工程师，是那些可以给世界带来惊喜的人，比如实现第一台实用化个人电脑的沃兹尼亚克、DSL 之父约翰·查菲、iPhone 和 Google Glass 的总设计师等。他们与第三四五等工程师的差别在于其工作的原创性以及对世界的影响力。

第一等工程师，是开创一个全新行业的人，历史上有爱迪生、特斯拉、福特等。这些工程师不仅在技术和产品等各个方向上与第二等的工程师有了质的差别，而且在经验和管理上也是好手，他们通常也是企业家，并通过自己的产品改变了世界。

每个工程师有不同的追求，心有多大格局就有多大，纵然第一等，第二等可遇不可求，但每个工作 5 年以上的工程师还是可以追求第四等，甚至第三等。

随着微服务的推进，业内有种呼声也越来越强烈：“谁开发谁维护，谁污染谁治理”。运维工程师主要负责 IaaS 层，开发工程师需要负责自己的服务层。

首要前提就是工程师意识问题，早年的程序员红利逐渐被消耗殆尽，野蛮开发阶段终将结束，运营服务将成为开发的必备能力。那服务上线后开发工程师需要关注什么呢？

织网--MDD 指导微服务运营

MDD 理念最早是在 2011 年 3 月 12 日 Etsy 公司举办的一次技术交流会“Moving Fast at Scale：a microcon-ference at SXSW”上，由 Etsy 核心平台部负责人 Mike Brittain 提出的。也有说是 Peter Drucker 提出，我们就不讨论具体是谁先提出的了。

以下引用来自 Peter Drucker，如果不去衡量你将无法管理它。

You can't manage what you don't measure.

什么是 MDD 呢？Metrics-Driven Development，这也是一种开发理念，或者叫做开发哲学，即通过实时指标来驱动快速、精确和细粒度的软件迭代。

The use of real-time metrics to drive rapid, precise, and granular software iterations.

躺在代码仓库中的代码，风格再好、注释再详细、算法再精妙，如果没有运行，则对于业务而言依然是没有任何意义的，因此运行中的代码才是有价值的。

量体裁衣

MDD 可以帮助开发，运维，产品人员一起关注业务的相关指标。接下来我们看看微服务运营关注那些指标。

之前介绍过 Google SRE 手册的黄金指标：延迟、流量、错误、饱和度。这里再介绍一下 Weave Cloud 的 RED 方法。

RED 方法是 Weave Cloud 基于 Google 的 4 个黄金指标再结合 Prometheus 及 Kubernetes 容器实践得出的方法论，特别适用于对云原生应用以及微服务架构应用进行监控和度量。在四大黄金指标的原则下，RED 方法可以有效地帮助用户衡量云原生以及微服务应用下的用户体验问题。RED 方法主要关注以下 3 种关键指标。·（Request）Rate：每秒接收的请求数。·（Request）Errors：每秒失败的请求数。·（Request）Duration：每个请求所花费的时间，用时间间隔表示。

大部分业务是产品驱动开发，整体采用微服务架构，我们按不同的角色分层提炼出监控指标。产品关注业务可用性，开发关注服务可用性，运维关注 IaaS 基础支撑可用性。于是我们需要一个抓手，将不同角色关注的指标抓入到一个运营平台里。那如何抓呢，这里采用 Google 四大黄金指标以及“RED”方法”。接下来围绕这个抓手从不同层面产品，开发，运维，探讨如何运营微服务。

分而治之

产品关注业务可用性

每个事业部的业务线都有自己的 OKR，于是各自关注的指标也不尽相同。平台为了满足这样的需求，需要支持业内通用的指标，还需要支持业务线深度定制的指标。

产品一般关注三大点：体验，趋势和转化，比如优化了新页面，监控用户停留时间趋势，基于趋势反馈做出产品的调整，从而提升转化率。

常见的业内通用性指标包括，用户访问 QPS，DAU 日活，订单数量，事件点击率，页面转化率，页面耗时，关键词搜索趋势，舆情监控等等。

本次咱们只探讨一下衡量业务可用性指标。

通用指标

面向用户侧入口流量也就是东西向流量监控指标，我们是从 Kong Log 中提取的。先看一下 Kong Log 的日志字段。

我们从 Nginx 体系迁移到 Kong 体系，日志结构和 Nginx 基本上没太大变化，不过新增了 route_name 字段，用于指导配置熔断、限流、告警的规则。

大体流程基于 Kong 日志分析转换成 Metrics，再在 Grafana 中最终展示趋势，并结合 Prometheus 设置告警规则。那都提取了哪些指标呢？

一般从容量和延迟两个维度分析。

Prometheus 将指标类型分为四大类：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）和 Summary（摘要）。

在设计指标的时候建议按规范来，由于我们采用自研 Exporter 分析 Log 模式，与业务服务分开独立部署，于是大部分指标设计成 Gauge 或类型。为什么这么设计呢？采用 Gauge 类型不需要考虑 Exporter 重启的影响及多实例部署带来的数据同步问题，这样每次 Prometheus 刮擦的结果都是计算过的瞬时向量。当然了后期还是会推动服务内置集成 Prometheus 收集器，暴露 Metrics 接口，这样数据收集延迟会缩短，支持的指标类型也更加的丰富。

业务再持续迭代，有入口的新增或迭代，为了服务的可用性，我们基于 route_name 配置了一些指标，指导入口准入产线策略的设定。

其中一个重要的指标就是看是否拉升了全站的延迟，如设定的 SLO 是期望是 90%route_name 延迟小于 800ms，准上线的入口延迟超过设定值，上线将会受限。

目前 route_name 的耗时分布，82.6%耗时小于 800ms，整体优化任务任重而道远。

深度定制除了通用的指标模型，有些端点记录的可用性数据会上报，比如 App/小程程崩溃日志等。关于端数据上报理论可以参考阿里的模型。主要有 SPM（超级位置模型）、SCM（超级内容模型）、黄金令牌。[注 2]

业务有时还会添加自定义指标，比如订单数，登录数，停留时长，访问深度，以及设备型号，地理位置，性别，年龄，搜索喜好等用户画像指标，这些需要业务埋点记录，并且支持业务自定义添加分析策略。

由于产品和开发工程师关注的细节不同，又分为了两种格式，产品需求数据记录 BizLog，服务可用性数据记录 LocalLog。

BizLog 记录的细节更多一般业务深度定制，目前这块是大数据分析部门在支持。LocalLog 不记录业务敏感数据，后面会在探讨服务端高可用性指标中再展开。

开发工程师关注服务可用性

服务可用性从整体考量，关注服务间的依赖，边界，接口，链路等可用性。这里说一下，指标不是越多越好，开发工程师不能每时每刻都盯着监控看板，添加过多监控项也不太合适，可能会造成告警爆炸，把握不到重点。下面根据我们的经验列几个关键项。

服务整体可用性分析

目前好大夫微服务之间南北向通信是基于 http 协议，我们规范请求的状态码，基于状态码占比设计相应的 SLO，这样比较灵活同时还有区分度。目前 http 请求 100%采样记录到 TraceLog 中，按分钟聚合 code 码流量和延迟 p99。

先看一下 TraceLog 字段分布。

这里注意几点：

计算延迟的时候，需要把状态码异常的刨除掉，因为 404，429，430 可能很快就返回了，601 超时可能会大于 5s 返回，如果不排除计算 p99 结果可能有偏差。
计算延迟的时候，由于存在网络传输耗时，这块也需要单独打上标签，nconsume(网络传输耗时),rconnsume(程序真实执行耗时),consume(总耗时=nconsume+rconsume)。
设计 metric 的时候打上不同的标签;code，handle，hostname。
为了直观反映服务的当前状态，设计 code 码的时候按类型分段且最好不要出现小于 0 的状态码。
除了基于 RPC 请求的监控，服务需要内置心跳检测，作为最后一道防线。

基于以上特征，我们提炼出来几个关键指标。

关注服务的可用性，有时候不能只看单个服务，因为服务不是孤岛，服务与服务之间是网状结构。我们可以根据服务的拓扑图(DAG)，查看关联的服务相关指标。

服务依赖稳定性φ= 出向依赖 /（出向依赖 + 入向依赖) (φ∈[0,1])，越小越稳定。

在服务优化的时候，可能需要对比同一个服务不同阶段，不同版本或者不同服务间的性能，我们开发了一个 Compare 工具。

在做架构设计的时候，我们需要充分考虑服务的弹力，设计好冗余、容错机制，配置过载防护策略，提升服务的整体可用性。这块实施建议参考极客时间陈皓老师的《左耳听风》专栏。后续有时间我们也会整理一个专题和大家谈谈。

接口方法可用性分析

一个服务对外的接口有时候比较多，更有甚者达到上百个，一般我们关心的只是 topK 的接口。如 QPM-top5，p99-top5，error 接口等。接口的高可用需要关心是否具备幂，是否存在风险点，如慢接口，慢 SQL，循环调用，SQL 不规范等。这块可以参考解构服务风险治理

有时候在分析问题或者重构的时候可能需要关注整体接口的变化趋势。

接口可用性还在持续迭代中，后续会支持查看 topK 接口的相关指标，设置可用性指标。还会开发小工具，如辅助接口重构的接口溯源，直观的看出接口的上下游和入口请求。

链路可用性分析

链路可用性一般反馈在入口流量和延迟上，这在前面 KongLog 根据 request 可添加相应的指标监控。另外我们还打造了基于 TraceLog 的链路可视化工具，辅助分析链路潜在的问题。

后续配合服务间的接口依赖分析，分析链路中服务依赖是否合理。基于性能压力测试评估出链路的瓶颈。触发告警时，开发快速定位异常的工具，这些都还是规划中。

运维工程师关注基础资源可用性

运维工程师更多关注 IaaS 层的资源使用，服务的资源使用率也需要开发工程师关注。

运维工程师比较关心，服务器，交换机，专线，公网 IP 等，如机器上有几块盘，物理机器有多少块网卡，交换机出入口流量，哪些业务需要分配 CPU 密集型主机，哪些业务需要分配内存密集型等等。这块由运维部在负责，主要采用了 Zabbix 体系的监控。

目前好大夫业务还是部署在虚拟机上，相关的资源监控也是运维工程师关注的多。随着容器化的推进，业务越来越自治，资源配比的策略会逐渐下发到开发工程师。所以现在虚拟机监控也纳入 Prometheus 体系中，如 Node-exporter/Jmx-exporter。为了和 k8s 资源监控对标，虚拟机相应的指标监控也在补全中。

资源监控项