五行合一，微服务运行态建设的“内功心法”

本文主要是介绍五行合一，微服务运行态建设的“内功心法”，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

导读

本篇文章为微服务转型系列第五篇。

微服务化建设需要做很多方面的改造和适应，比如适应微服务开发、适应敏捷运维、打造专门的微服务团队，以及符合云原生指导下的架构设计等。所以微服务化转型，要做好持久战的准备，同时亦不可疏忽每一步的决策。

在上一篇文章中（理念指导实践，厘清微服务建设的主要内容和顺序）我们提到微服务化转型可以先从运行态入手，微服务运行态是微服务化转型中关键的一步，也是最能体现阶段性成果的一步，这篇我们将主要总结一下，微服务运行态支撑平台应该具备哪些能力。

运行态一定具备的能力是管理、观测、运行和变更，再加上微服务自身关注的治理特性，这样我们就可以将微服务运行态支撑平台的基本核心功能整理出来了：

应用服务管理：包括应用服务基本信息、实例状态、业务关系等；
运行观测：主要是监控、拓扑图、日志，当然这都是以应用服务的视角；
故障定位：微服务环境下主要依赖于调用链的追踪，定位真实场景中的问题；
配置管理：无论是服务发布、服务运行、策略生效，无不需要配置的管理和下发；
流量控制：包括限流、熔断、负载，当然最主要的是访问权限的控制。

接下来我们逐条分析一下。

应用服务管理能力

在未搭建微服务运行平台时，微服务的使用者通常都是研发人员，面对注册中心中注册的一堆英文服务名，研发人员至少能区分自己研发的业务服务，对其他的服务也无需关注太多。然而，当微服务的管理者或运维人员查看全注册中心的服务的时候，通常会变得无比痛苦。

举个例子，当我们从注册中心看到“monitor-provider”（SpringCloud框架下的某个服务）这个服务的时候，除了该服务的研发能准确知道其功能外，其他人只能去臆测这是监控相关的提供数据的服务；如果看到的服务名称是“com.jrca.purview.sdk.export.session.MonitorProviderService”（ZooKeeper注册中心的某个服务)，除了经常使用和调用该服务的研发之外，其他人则更加难以了解其作用，更不用说当注册中心的服务列表全是这样的服务名称时，将会给管理和运维带来多大的困扰。

所谓微服务治理，不同的人有不同的理解和认知，但是最基本的“理”应该是能让管理者知道有哪些系统，有哪些服务，每个服务是干什么用的，有个便于认知和交流的名称，这就是管理的能力（很多项目描述为服务目录，也有一些叫做应用管理）。

这种看似很简单，很容易的建设，其实才是微服务运行平台建设中最关键和最核心的，因为实际上所有的开源组件都没有给到我们想要的应用管理能力。我们需要的应用管理能力是这样的：

应用服务的目录：每个应用服务的最直观的管理，包括其名称、功能描述、使用方法，可能还有编号、负责人等信息的管理。
应用服务视角的管理：这个是关键，也是运行支撑平台区别于开源组件最大的特征。开源的组件只提供功能的实现，比如服务寻址、健康检查有注册中心，服务配置管理有配置中心，服务性能监控有APM，服务访问权限有权限中心限制，等等。一个服务的观测，需要同时登录五个平台、打开五个界面、核对五次在各个平台中的ServiceName，最终拿到一个服务的综合数据。因此，应用服务视角的管理，解决的就是数据和功能的整合展示。
应用服务的观测和治理：依赖于应用服务视角的管理，我们能在当前服务下看到服务的性能数据，同时根据该服务的性能统计和资源占用，适当的调配限流、熔断策略。
层级分明的结构：通常应用服务都有上层管理结构，比如从部门视角的行政组织结构，或者以业务划分的业务域结构，总之如果是建设全企业的微服务平台，就更应该贴合真实的使用场景，灵活的支持多种管理结构和模式。

综上所述，应用服务管理平台是集管理、目录、统计、展示、更改、限制于一体的平台，从服务的视角集成监控、配置、日志、策略、告警等功能，又不同于监控中心、告警中心、日志中心这些大而全的平台，应用视角下精准定位要求更高，更便于快速查看。

运行观测能力

观测至少应该具备：监控、拓扑、日志的能力。

微服务层面的监控区别于传统的监控系统，微服务通常重点关注性能监控，这是由于微服务间依赖关系复杂，导致单个服务的性能可能会直接影响到整体的性能。因此微服务的性能监控至关重要，通过观测微服务的性能，适当调整服务的实例数、流控策略，以保障整体的健康和稳定。

另外，服务数量增多，业务细化，将导致服务间依赖关系庞杂，很难梳理清楚。因此通过运行中的拓扑图将真实的调用关系展示出来，便于明确服务的调用关系，也便于做架构的优化调整。

服务的业务日志，通常是服务运行观测中经常使用到的，运行状况、交易状况、问题定位都离不开日志的帮助。

因此，性能的监控、拓扑图的展示、服务日志的展示，都是运行支撑平台的建设范围。

故障定位

通常微服务运行平台中，故障定位是最有价值的功能点。如果带有实时调试bug的功能，将更会受到开发、运维人员的欢迎。但是功能越有价值，代表的建设难度也越大，因而也可以逐步细化功能来建设。

故障定位，需要从粗到细，逐步钻取定位。一笔真实的业务，可能会经过很多个应用服务，每个环节的问题都有可能导致业务失败。那么一条用于记录业务调用的链路，将显得尤为重要，链路会记录整条业务所走过的每一处痕迹，在哪里出的问题将会一目了然。

如果只是链路，对于故障的定位可能还是较为粗糙，通常开源组件也只能做到这一步。而在实际使用中，我们对于故障定位需要更为精准地知道问题出在哪个服务、哪个接口，以及在该接口的调用信息和产生的日志，甚至需要观测具体接口调用中的线程情况，并可以在线调试。而这则需要将链路追踪、性能剖析、在线运维做整合，提供更好的观测和定位功能。