2.4 三位一体：通过度量、管控、管理实现微服务治理闭环

2.4.1 治理指标体系

很多企业在其内部IT发展初期，经常会忽略数据收集问题，更谈不上有意识地构建完整的数据指标体系。没有数据指标体系的支撑，就会导致对线上的实时业务及系统状况一无所知。

在微服务生命周期的各环节中采集必要的指标数据并进行各种度量，就能获得微服务各个环节的健康度状态（开发健康度、设计健康度、测试健康度、线上健康度等），据此可以决定是否对服务进行管控，及采用何种管控举措。

在微服务的生命周期中，每个时期的指标都不一样，要采集的原始指标数量庞杂，汇总和加工后的二次指标也非常多。为了全面客观地描述微服务，对于每个指标都要清楚它是什么、从哪获取、用它干什么，建立一个客观的治理指标体系是大势所趋。

微服务的治理包括线上和线下体系，因此服务治理度量指标的采集也要线上和线下同步进行。

在线上，通过服务注册中心可以获得服务的注册信息及服务的管控指令信息；通过各个微服务主机节点上的主机日志、应用及服务日志、APM监控的调用链日志可以获得相关的性能及异常指标信息。

线下的指标就更多了。通过需求管理系统，可以采集UserStory及各类需求的基本信息；通过项目管理系统可以采集开发人员、开发团队、开发任务的基础信息；通过测试相关的管理系统可以采集测试用例及测试Bug的相关定义信息及过程指标信息；通过源码仓库及软件版本仓库可以采集最终研发产出物的基本信息。

软件研发是一个强调协同的群体行为，产品、开发、测试和运维需要紧密合作。为了更高效地配合，研发团队经常会采用一些协作模式，比如针对开发和测试之间的配合，会采用持续集成（CI）；针对产品、开发、测试的协作，会采用敏捷协作模式。另外，可能还会使用一些DevOps的Pipeline。不管采用何种协作模式，都可以从相关的过程管理系统中抽取出过程指标事件，比如一个任务什么时候完成设计、什么时候开始进入开发、什么时候完成开发等，这也是一大类很重要的治理度量指标。

通过线上环境、线下环境及过程管理体系，可以获得大量的治理度量指标，如图2.28所示。根据这些指标的客观性、可变性及变更频度，可将微服务的治理指标分成3大类，如表2.5所示。可将采集的三大类指标数据统一汇总到数据仓库，以备进一步的深度度量和分析。

2.4.2 治理度量与分析

2.4.2.1 治理度量与分析的整体架构

在上述指标体系下，对采集的度量指标进行深度处理是微服务治理的重要工作。深度处理不同于日志及监控指标的实时处理，实时处理只能对原始指标进行一些简单的基于预定义阈值的告警判断和汇总处理，比如将数据进行分钟级汇总统计。深度处理则可以将不同维度的数据进行聚合和关联，比如将线上故障事件指标数据通过服务名称和从代码库中获取的对应开发人员或团队关联，以评估开发人员或团队的开发质量等。

从微服务全生命周期各环节采集的数据以ODS（操作型数据）汇总到数据仓库中，再根据预先定义的数据模型，抽取出相应的主数据：服务、开发人员、团队、项目、应用等。在此基础上，基于线上的异常、性能、资源、事件等主题和线下的开发、测试、运维等主题来构建多层次的数据集市。有了这个数据集市，就可以进行各个维度的数据聚合和关联，制作出各种报告及报表，包括如下几大类：

1）各维度分钟、小时、日、周、月汇总报表；

2）架构分析、性能分析、容量分析、健康度分析等相关聚合分析报表；

3）故障定界定位指标（调用链）；

4）将指标按时间维度进行比较，可以获得趋势报告；

5）将指标与线下的开发团队和开发个人挂钩，可以获得开发质量及生产效率分析报告。

治理委员会根据这些分析报告进行深度的分析并制定出各类治理决策，或者通过人为或自动化的机制发出各类管控指令。

治理决策和管控指令就是微服务度量及分析体系的最终产出物。

图2.29是整个治理数据的分析架构。图中数据源层的数据采集技术在2.2.1中有详细的介绍，这里就不再赘述。下面将重点介绍数据仓库、数据集市、数据应用及展示。

2.4.2.2 构建指标数据仓库

数据仓库这个概念是由数据仓库之父比尔·恩门（Bill Inmon）于1990年提出的。在他的著作Building the Data Warehouse中是这样定义数据仓库的：数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。

这里的数据仓库是泛指的，它由一系列存储服务混合构成。原始日志数据存储在分布式NoSQL数据库中，如Cassandra或笔者团队在使用的HBase，索引信息存储在ElasticSearch中，另外一些轻度汇总过的数据（包括分钟、小时、天、周、月汇总数据）和一些较小的、结构化比较好的原始数据（包括服务基本信息快照、项目信息快照、测试Bug快照、源码解析结果—调用关系）存放在关系型数据库（RDBMS）中，比如MySQL或者Oracle中。以上数据一旦在数据仓库中落盘，基本就不会再被修改，所以数据仓库中的主要操作更多是新增及查询。

数据仓库中有一些基础的相对静态的数据会被全局使用，包括微服务基础信息、开发人员基础信息、团队基础信息、项目基础信息等。这类信息作为治理的基础维度数据，往往被划分到主数据（MDM）范畴。这些数据的数据量相对固定并且可控，一般都在关系型数据库中以独立表的形式存储。

通过NoSQL+RDBMS的混合模式来构建分层的数据仓库有很多好处，主要体现有如下几点。

● 原始日志数据量大，用NoSQL存储可以满足海量存储及快速扩容的需求。汇总后的数据量较小，用关系型数据库存储可以提升查询的灵活性。

● 分工更加明确，满足不同层次的查询需求，大跨度时间范围的查询直接查询汇总表，不仅避免了直接查询原始数据的低效，也降低了构造查询语句的复杂性。

● 可以定期清理原始数据，由于有多层汇总表的存在，不用担心历史数据的缺失。

● 主数据的存在，提高了数据的复用率，减少了重复查询和计算，节省了计算资源。

数据仓库存储模型的设计可以参考业界通用的Kimball和Inmon模型。这两种模型的详细描述不是本书的重点，感兴趣的读者可以自行查阅相关书籍。这里以Kimball提出的维度建模法来演示对微服务度量指标的数据建模，如图2.30所示。以存储线上采集的服务性能指标和异常指标的“服务性能”表和“线上异常”表为事实表，每条性能指标及异常都会关联到特定主机上的某个微服务，同时都有采集的时间点，异常还会关联特定的动态调用链。因此，可以把微服务表、主机列表（可以从CMDB获取）、时间表及存储动态调用链信息表作为维度表，事实表和维度表之间通过外键进行关联。

图2.30是维度建模中非常经典的星型架构，这种建模方式的好处是简单、直观。为了提高检索性能，需要对各个维度做一些预处理，包括预先的统计、分类、排序等。比如根据原始的线上异常事件指标，可以按时间维度从小到大分别汇总出小时异常汇总表、天异常汇总表、周异常汇总表等；还可以将异常事件按服务维度进行汇总或者按主机维度进行汇总。这些不同维度的大大小小的汇总表可以为更复杂、更深入的度量分析提供高效完善的数据查询支持。

2.4.2.3 按数据集市对指标进行汇总

数据集市并不是物理上真实存在的，它的底层存储其实和数据仓库是一样的，甚至共享同样的存储服务，对它的划分更多基于逻辑方面的考量。数据集市更关注领域数据，它以主题来组织数据表，每个主题下都有若干张汇总或者清洗后的数据表。举个例子，比如“异常”这个主题，可以按应用域做二级分类，再在每个应用域下按系统异常和应用（服务）异常来存储三级的异常数据明细。因此，如果把数据仓库比作原料仓库，那么数据集市就是半成品仓库，它为最终的治理分析提供准确、清晰、分门别类的素材。

2.4.2.4 ETL

对于数据仓库和数据集市而言，所使用的数据处理手段是一模一样的，无非是数据的抽取、清洗和转换，也就是我们常说的ETL。ETL工具很多，包括开源的Kettle、云上的DTS等。笔者曾经在2013年左右，因一个数据集成项目的需要做过Kettle的设计器Spoon的Web化改造，也就是设计一个Web版本的Spoon设计器，并做Kettle引擎和项目的深度整合，因此对Kettle比较熟悉，这里就以Kettle为例，简单介绍一下ETL工具。

Kettle现在已经改名叫Data Integration。笔者个人更愿意称呼它的原名，这个名称和它的各组件更匹配一些。Kettle的中文名称叫水壶，该项目的主程序员Matt希望把各种数据放到一个“壶”里，然后以一种指定的格式流出。Kettle主要包括三部分，分别为Spoon、Kitchen和Pan。Kettle提供一个图形用户界面设计器Spoon，用来设计数据转换过程（Transaction）及作业（Job）。设计结果本质上是两种XML格式的脚本文件，可以通过定时调度引擎Chief组件来定期调度Job，再通过Job来调用Transaction，Transaction的执行由解析执行引擎Pan负责。整个过程如图2.31所示。

图2.32是Kettle的Spoon设计器的一个界面截图。窗格①是其提供的各种功能部件，包括数据源接入、数据转换、数据连接、数据监测、数据查询等近300个，能够满足绝大部分应用场景，而且还可以通过脚本来扩展其能力。窗格②是一个微服务治理的数据聚合用例：抽取数据仓库中的异常数据指标（存储在Cassandra中），去重并添加索引ID后，将其与主数据（MDM）中的开发人员表（存储在MySQL中）做聚合（利用共同的服务名称作为关联字段）。聚合后的数据集经过必要的校验并增加校验标识后，写入数据集市中的“质量”专题下的某张明细表中。

配置好的ETL规则可以通过定时调度机制定期执行。虽然Kettle这类ETL工具自身会提供Job任务调度的配置能力，但考虑到和数仓系统的集成，一般建议由数仓系统的定时调度任务来托管ETL的任务执行工作。

2.4.2.5 数据质量监控

是否能做到对微服务的准确度量在很大程度上取决于采集的各类治理指标数据的质量。利用ETL相关的校验节点功能可以做一些质量监测及修正，但大规模的数据质量监测，比如监测每天采集的数据量是否达标（是否有暴涨、暴跌的情况）、数据是否符合规范（编码是否符合规范、日期格式是否标准）、数据是否完整（是否有字段缺失）等，则需要在规则引擎的基础上构建综合数据质量监控平台。利用数百甚至上千条预先定义的规则，对数据进行抽样或者全量的检测，一旦检测到异常，就会自动触发自动化数据订正任务或者给管理员发送告警信息。

在企业的数据仓库系统中，一般都集成了针对数据质量进行监控的管理模块，图2.33是针对数据质量监控规则进行配置的一个实例界面。可以看到，可通过多条简单规则的组合来构建复杂检测逻辑，组合逻辑可以采用“与”“或”“非”3种不同策略。

图2.33中的规则配置在保存时会被规则引擎自动解析为SQL语句，如图2.34所示。图里的每条记录都是一条质量过滤（查询）SQL，通过运行这些SQL，可以找出特定质量缺陷的数据记录。

配置出来的质量监控规则单靠人来运行是不现实的，需要系统能够定时调度这些规则并自动执行。可以通过如图2.35所示的定时策略管理模块来配置一系列的定时执行规则，一旦监测到异常数据，立即调用预定义策略进行自动干预，或者通知质量管控人员进行人为评判和修订。

2.4.2.6 数据报表

在服务治理工作中，治理指标的分析最终要以各类报表或者图表的形式呈现。如果数据仓库和数据集市的模型构建得好，最终报表大都基于数据集市和主数据中的数据来生成，这两类数据都是经过层层清洗和汇总的，数据量基本可控，绝大部分都存储在关系型数据库中。如果利用Hadoop或Spark这类大数据分析工具处理这些数据并生成报表，不仅不灵活，模型设计难度也高，难免有“杀鸡用牛刀”的感觉。传统的报表工具，诸如JasperReport、BIRT、Tableau等，在此时往往有更出色的表现，更能充分发挥关系型数据库查询的灵活性，还可以通过较低的成本来构建主从报表、分组报表、交叉报表等多维度的复杂报表，以提供更好的分析体验。

2.4.2.7 治理呈现

基于治理指标的数据集市所构建的各类数据分析报表将为服务治理提供翔实的决策支持。除此以外，还需要有承载概括性治理信息的大盘呈现，能够通过可视化的方式让人们对服务治理所涉及的整个服务集群及关联资源的健康度和当前运行状况有直观上的感受。图2.36就是针对单个服务线上运行状况的监控大盘。通过这个监控大盘，可以总体把握此服务所在的服务器性能、服务性能、服务调用、异常、健康趋势等。

除了这种综合性的监控大盘，还有一些针对某一类特定指标的监控大盘。这些大盘需要通过专门的系统开发来实现，开发语言不一而论。前端的大盘展示图表控件的选择也很多，流行的HighCharts、eCharts等都是不错的。

2.4.3 通过管理将治理举措落地

治理和管理属于两个不同的行为范畴，COMBIT 5.0对两者的差异做了清晰的阐述。

1.治理

治理（Governance）是指评估利益相关者的需求、条件和选择以达成平衡一致的企业目标，通过优先排序和决策机制来设定方向，然后根据方向和目标来监督绩效和合规。基于此定义，治理包含评估、指导和监督三个关键活动，并确保输出结果与设定的方向和预期目标一致。

2.管理

管理（Management）是指按照治理机构设定的方向开展计划、建设、运营和监控活动，以实现企业目标。根据定义，管理包含计划、建设、运营和监控四个关键活动，并确保活动符合治理机构所设定的方向和目标。

根据定义，治理和管理具有不同的责任主体、不同的活动和流程，治理指导管理的方向，管理确保治理的落实。服务治理和服务管理的关系与治理和管理的关系基本类似。服务治理的责任主体是治理委员会，它包含技术专家（架构师）及研发、测试（QA）、运维等各团队的负责人；服务管理的责任主体是团队的执行管理层。服务的线下治理对服务开发管理和过程管理等线下活动进行评估、指导和监督，服务管理根据服务治理所做的治理决策来具体计划、建设和运营，保证服务治理决策的落地。

综上所述，服务治理对服务管理具有指导职能。它专注于通过何种机制才能确保做出正确的决策。换句话说，它负责找出当前组织架构及研发、测试（QA）、运维等团队组织结构和组织协同中存在哪些问题并给出改进建议，但不涉及具体的管理活动。而服务管理负责采取恰当的管理行为来实现这些改进举措。微服务治理与微服务管理的关系可以用图2.37来表示。

2.4.4 微服务治理整体架构

综合前面的介绍，我们在本章的最后一节给出微服务治理的整体架构图，如图2.38所示。

微服务的治理既有线上治理，也有线下治理，将线上和线下采集的治理指标存储到数据仓库中，进行综合的汇总、聚合、分析，最终形成包含多种主题的数据集市，完成对微服务各维度的客观度量。

在这些度量指标中，有相当一部分线上的性能及异常指标会被转化为运维事件，一旦触发我们预先设置的阈值，就会更进一步转化成“管控指令”，并通过调度中心下发，进行服务的弹性伸缩、扩容缩容等资源调度操作，或者进行服务的限流、降级、容错、路由调整等管控操作。

另外一部分度量指标，包括架构、开发、测试、运维、过程协作效率等，会通过治理委员会（泛指治理成员的集合）进行人为的深入分析，并制定出治理决策。这些治理决策会通过相关的过程优化管理措施进行落地。

这样，通过服务的度量、管控、管理三大举措，构建起一个三位一体、围绕服务治理的闭环体系。后续章节，我们将围绕这个整体架构，对微服务治理的度量和管控策略展开详细的讨论。