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

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

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

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

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

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

应用服务管理能力

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

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

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

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

应用服务的目录：每个应用服务的最直观的管理，包括其名称、功能描述、使用方法，可能还有编号、负责人等信息的管理。

应用服务视角的管理：这个是关键，也是运行支撑平台区别于开源组件最大的特征。开源的组件只提供功能的实现，比如服务寻址、健康检查有注册中心，服务配置管理有配置中心，服务性能监控有APM，服务访问权限有权限中心限制，等等。一个服务的观测，需要同时登录五个平台、打开五个界面、核对五次在各个平台中的ServiceName，最终拿到一个服务的综合数据。因此，应用服务视角的管理，解决的就是数据和功能的整合展示。

应用服务的观测和治理：依赖于应用服务视角的管理，我们能在当前服务下看到服务的性能数据，同时根据该服务的性能统计和资源占用，适当的调配限流、熔断策略。

层级分明的结构：通常应用服务都有上层管理结构，比如从部门视角的行政组织结构，或者以业务划分的业务域结构，总之如果是建设全企业的微服务平台，就更应该贴合真实的使用场景，灵活的支持多种管理结构和模式。

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

运行观测能力

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

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

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

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

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

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

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

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

目前使用较多的配置中心是携程的 Apollo，配置文件格式、管理功能都较为全面，通常我们建设时也比较推崇使用。

在运行平台中，服务的创建发布、策略下发等工作，都依赖于配置管理，因此平台也需要集成此项功能。当然建设中由于使用习惯的问题，仍然想要使用原生的Apollo，那么微服务平台中的服务与 Apollo 中的项目就有很大的风险不能对应，给使用带来不小的麻烦，这个细节需要注意。

访问、流量的治理

微服务框架主要是解决调用问题，因此负载均衡、限流、熔断、访问权限等很多与访问、流量有关的功能，都是微服务最早提出的治理功能。在对标的时候，限流熔断是微服务的必备，但是生产运行中却很少有开启限流策略的。原因很简单，限流容易导致交易失败，所以宁可增加服务器节点，也尽量不开启限流等策略。

其实限流并不是没有使用场景，只是微服务转型初期有点低迷，相比之下访问的黑白名单控制，就很有用武之地了。接口级别的调用控制，将是未来纷繁杂乱的微服务运行中，使用最多的功能。

总结一下，微服务运行支撑平台其实就是微服务运行中的以服务为视角的管理、观测平台，其主要意义在于打破管理者对微服务纷杂、神秘的固有认识，提供更直观、更透明的微服务管理能力，让使用者真正掌握微服务的运行细节。