要管得到，必须先看得到！
要对微服务进行治理，先要对微服务进行度量。根据微服务的生命周期，可以将服务度量分为服务开发质量度量、服务测试质量度量、服务运维质量度量和服务线上性能度量四大部分。
服务开发质量度量
通过开发过程管理指标来衡量过程效率及质量
在微服务架构下通常会采用小团队、敏捷的开发模式，使用特定的需求和研发过程管理工具对业务需求、研发用例及研发进度进行全程管理。因此，从开发阶段的过程管理和成果管理中，可以获得很多相关度量指标。
目前流行的敏捷过程管理工具很多，Jira便是其中的典型代表。图2.9是笔者所在团队使用Jira进行敏捷迭代管理的一个功能截图。
Jira提供API接口，可以获取非常丰富的研发过程度量指标，包括一个研发团队开发一批业务需求所投入的人力资源和各个环节所耗费的时间等信息。以下是Jira提供的一些典型接口。
1. 获取所有项目信息
通过API接口http://jiraserver:port/rest/api/2/project可以获取Jira中的所有项目的详细信息，包括项目ID、项目key、项目名称、项目负责人和项目类比/类型等信息。
2. 获取单个项目信息
通过API接口http://jiraserver:port/rest/api/2/project/{projectId}可以获取某个项目ID对应项目的详细信息，包括项目组件列表、版本列表及项目相关角色列表等信息。
通过如上Jira提供的针对issue的API查询接口，利用带JQL的查询接口调用，可以查询某个项目下某个迭代周期中的所有UserStory及Task详情。
4. 获取某个issue的详细信息
通过API接口http://jiraserver:port/rest/api/2/issue/{issueId/issueKey}可以获取某个issue（用户故事、任务、需求、Bug）的详细信息，包括创建时间、状态（及变更）、创建人、负责人、子任务等信息。
通过以上接口，定期收集敏捷过程中每个UserStory及对应Task的相关状态信息、变更时间信息、负责人员信息（开发人员、测试人员和验收人员）、对应服务信息（可通过自定义字段维护issue所关联的微服务）。基于时间轴将这些信息进行横向和纵向的组织及比对，再结合精益看板，即可从不同维度对微服务的开发过程进行全方位审核和把控。整个过程如图2.10所示。
3. 获取项目某个敏捷迭代（Sprint）中的所有issue（UserStory、Task、需求、Bug）
但是，这样就够了吗？
不！我们还有一个庞大的“宝库”没有挖掘，那就是研发成果的最终归档物—源代码。
用代码“读懂”代码：衡量开发交付质量
回顾软件开发的流程，从前期的业务需求分析，到产品设计，再到架构设计，通过层层迭代，让所有关于业务及系统的思考、意图和策略最终都通过开发人员的代码表述出来。代码成了这些活动的最终产出物。
可以说，一个系统的源代码就是一本“书”，读懂这本“书”，我们就知道这个系统的“前世今生”。当然，深入（自动化）分析源代码也可以衡量服务的开发和设计质量。
在实际的开发工作中，大都采用面向对象的编程方式。我们把真实世界的业务实体映射成软件中的对象，实体间的关系就演变成了对象间的继承、实现和引用关系。因此通过对源代码的分析，可以知道软件系统的一系列关系逻辑，包括系统的调用入口在哪，以及系统API的实现和继承关系、类方法之间的引用关系等。如图2.11所示，如果将图左边的代码关系用图形化的方式呈现出来，就可以获得图右边的调用链路关系图。这类关系图对我们快速梳理和理解系统的逻辑非常有帮助，在此基础上也可以对微服务的调用质量进行优化。
源码是一个宝库，包含了很多的内容。假如有个“超人”能够记住所有的源码并理解透彻，那么很多治理的难题都能迎刃而解。问题一出来，超人就能快速地定位问题所在。奈何现实中没有超人，全盘读懂源码既是脑力活也是体力活，将成千上万个核心类的调用关系梳理出来并画出关系图，没有核心程序员好几周的辛苦努力是搞不定的。
“人力有穷时”，最好的办法是通过某种自动化手段，自动提取源码中的元素，自动梳理这些元素之间的关系，简言之就是“通过代码去理解代码”。
所幸，现在已经有一些能够对源码进行解析的工具和组件，JDT就是其中的典型代表。JDT的全称是Java Development Tools，是Eclipse的核心组件，主要用于Java程序的组织、编译、调试和运行等。在Java源码解析上，JDT提供了一个AST组件（Abstract Syntax Tree，抽象语法树）来做Java程序分析。通过AST，编译器会把代码转化成一棵抽象“语法树”，树上的每个节点代表一个代码元素（变量、方法、逻辑块等），同时针对节点的类型和属性解析提供完整的能力。
