今天我准备再谈下微服务治理方面的内容，在前面我写过一篇微服务治理框架重构的文章，里面给出了一个完整的覆盖微服务全生命周期管理和后期治理管控的框架体系。今天的重点则是对里面的一些内容进行细化说明。

微服务治理框架

对于微服务治理在前面已经谈到了实际上包括了微服务模块本身和微服务API接口治理两个方面的内容，而不能简单理解为API接口的治理。

因此微服务治理应该进一步融入IT治理和SOA治理两个部分的内容。

如果重新给微服务治理一个定义，应该如下：

微服务治理是针对企业组织和业务目标，制订一套标准的管理，业务，技术，过程规范体系，实现微服务从需求，设计，开发上线，运行，下线的全生命周期管理能力。同时构建一套完整的度量指标体系，通过实时的日志和性能数据采集，持续的监控服务运行监控状态，并执行相应的限流，预警等管控策略，以确保微服务的持续健康，可靠和高效运行。

基于这个，可以理解为整个治理框架应该包括三方面内容：

设计态：如何进行微服务分析和设计，模块拆分，接口设计
运行态：如何构建度量分析体系，实现微服务监控，确保微服务健康运行
规范类：构建一套完整的覆盖管理，业务，技术，过程支撑的规范体系
工具类：基于上面治理要求，选择可行的技术平台或工具进行支撑

以上就是一个微服务治理本书应该包括的全面内容。从这个里面也可以看到微服务治理平台或开发框架实际上仅仅占了微服务治理的一部分内容，而不是全部。

微服务治理概括来说，实际上关键包括两个部分。

• 其一是微服务如何拆分，接口如何设计

• 其二是运行期如何监控，管理，运维

上图给出的围绕微服务全生命周期管理和基于服务度量体系的持续运维监控两个方面展开，对于一些二级的内容在该图暂时无法展开，比如常说的服务版本管理，服务依赖分析也是微服务治理的关键内容，暂时在该图没有体现。

在运行期还有一个关键思维的转变就是不是简单的发生问题故障后的运维治理，而是应该基于监控预警分析下的主动的技术运营和SLA服务等级提升。

如果你要去给别人做微服务治理，实际上是客户在确定了微服务架构后就需要介入，包括选择什么样的开发框架，采用哪些开源技术，这些开源技术如何整合，微服务如何拆分，微服务开发过程如何规范化，如何持续集成和部署，API接口如何设计，微服务间如何集成，运行期微服务如何进行状态和性能监控，如何进行安全，日志，限流等管控。

以上所有内容都应该纳入到微服务治理范畴。那么当前企业实施微服务都会去请技术咨询公司来进行完整的微服务治理规划和咨询吗？

答案显然不是。

对于治理这件事，我最近也在思考。治理不是别人给你一套框架，一套标准规范体系你就能够使用得好的。治理这种事情最佳的方式更多应该是别人给你一个粗粒度的规则，然后你尽快去执行，在执行过程中通过短周期迭代不断的去自我优化和调整。

也就是说一个组织治理过程的完善往往是问题驱动的自我不断完善，这个完善过程来源于实践。只有你自己吃亏了，走弯路或遇到问题了，你才真正理解为何要制定一个规则。

开发框架和开源组件的选择

一接触到微服务，实际上并不是马上谈到标准规范，也不是马上去谈后期的运维监控。更多的都是在谈前期的开发框架和开源组件的选择。

因此你经常会看到究竟是选择SpringCLoud还是Dubbo，类似Eureka，Consul，Nacos这么多的开源注册中心实现究竟应该选择哪个；是选择SpringCLoud框架中的Zuul或CLoud Gateway微服务网关，还是选择类似Kong这种独立的API网关。服务限流是选择Hystrix还是Sentinel；对于后期监控运维，包括ELK方案，Prometheus，还是Skywalking；有无必要选择独立的Apollo来做服务配置中心？当前基于ServiceMesh服务网格的Istio微服务治理是否可以替代传统治理方案等。

所以一个组织要实施微服务的时候，并不是一件容易的事情。

面对如此多的开发框架和开源组件如何选择？

这个问题，我在前面也回答过。就是当你没有足够的实践经验积累的时候，最好的方法就是选择一个大而全的框架体系，然后根据需要来启用里面的一些关键组件和功能。

比如就选择SpringCLoud完整框架。

可以看到这个框架里面类似服务注册和发现，限流熔断，安全，负载均衡，声明式调用，配置中心，微服务网关等都具备，你只要按需要选择使用即可。

所以一开始切入微服务的时候，你不要去谈类似Nacos，Sentinel功能更加强大，Kong网关的性能更好这些。大部分组织刚切入到微服务的时候，很多高级功能你并不需要，一开始你的性能需求也没有到追求极致的程度。

因此类似选择SpringCLoud完整框架体系，减少组件间的集成工作量，快速地搭建完成框架并进入到设计开发阶段才是重点。可以看到前面谈到的其它开源组件基本都是适配SpringCLoud微服务框架的，也就是说你后期再引入这些组件可以做到平滑过渡。

微服务开发框架和微服务治理框架

对于SpingCLoud开源框架，实际上既包括了开发框架，也包括了治理框架，而且两者是耦合或集成在一起的。也就是说微服务在开发阶段，往往就需要考虑为了治理需求增加相应的配置文件，或在类文件或方法上面增加相应的声明式标注。

所以你会看到如果你的限流策略要变化，往往并没有那么容易，涉及到代码或配置文件的修改才能够完成。

而个人一直以来的一个重要观点就是微服务开发框架和微服务治理应该彻底解耦，在开发阶段不应该过多地去考虑治理能力，或者说为了治理能力增加相应的开发工作。包括前面谈到的后续主流的ServiceMesh微服务治理，基本也是基于这个无侵入原则进行。

单个应用层面还是组织层面

第二个经常会遇到的问题即是类似SpringCLoud已经有Config配置中心，为何还需要采用Apollo配置中心，或者说SpingCloud已经有了微服务网关，有无必要还去采用类似Kong这种API网关能力。包括Eureka注册中心和Nacos选择也是同样的问题。

如果你仅仅是从性能，功能层面去思考那么往往就没有彻底理解。而真正你需要考虑的是站在一个大组织层面管理多个微服务应用，还是仅仅一个微服务应用内部开发管控层面。

对于SpingCLoud完整框架方案，其核心定位还是在一个微服务应用开发团队层面，即一个传统单体应用拆分为了10个微服务开发，但是整体来说对外还是一个应用，由一个大的开发团队来开发和交付。这个开发团队本身在进行10个微服务间的集成，交互，安全等问题处理的时候需要一套完整的管控治理框架和方案。

但是如果站在一个企业层面，往往存在多个这样的开发团队，不同的开发团队开发不同的微服务应用，同时采用的微服务开发框架都还可能不同。比如五个独立的应用开发团队，分别开发了SRM，CRM，MES等五个应用。

那么组织层面面对的是这5个大的微服务应用如何进行管控治理。这个已经不再是单个微服务应用内部的事情，而是跨微服务间的事情。

而当上升到跨微服务应用，管理多个微服务应用的时候，类似Nacos，Kong网关，Apollo配置中心才会起到关键的作用。这些管控治理不是由单个微服务应用开发团队来负责，而是应该是组织级的管控治理团队。

微服务拆分和API接口定义

当我们谈到微服务治理的时候，经常已经是面临一个无法解决的问题，比如说微服务拆分得太细，接口集成关系复杂难以管理，持续应用故障的时候难以快速的定位和排查等。

当真正变成问题的时候你采用再好的链路监控工具，管控治理措施都是徒劳，并且已经无法从根本上解决问题。

这个问题就是前期微服务拆分不合理。

在我头条上，实际上我有多篇文章都在谈微服务如何拆分的话题。这些拆分方法基本是可以归结为两类方法。

第一种方法是传统的基于企业架构规划的思路，梳理业务架构和数据架构，并通过业务功能和流程，业务功能和数据对象的多个CRUD分析矩阵来分析功能，数据之间的耦合性，完成最终的拆分工作。其本质还是传统的单体应用里的模块拆分，但是传统模块拆分不会考虑数据库DB层也要拆分，这个是微服务拆分带来的一个新要求。

对于这种方法，我专门整理了一篇文章可供参考：

中台规划中微服务粒度究竟应该如何划分？你可以从以下几点考虑

第二种方法则是基于领域建模分析的思路，去考虑上下文边界，去分析具体的业务功能和数据之间的耦合性完成拆分动作。这个拆分的核心并不是功能模块的拆分，而是功能模块对应的底层数据对象如何拆分。

对于领域分析方法拆分微服务，可参考：

对领域模型和上下文边界分析来划分微服务的再思考

将微服务划分为业务子域来对应数据库拆分

严格意义上的微服务，数据库也完全独立和解耦，这样会导致数据库拆分太细，引入后期大量的分布式事务处理和管理难度。

因此更好的方法是划分业务域，不同业务域对应不同的数据库。可以多个微服务共享一个数据库。在多个微服务共享一个数据库实例的时候，微服务本身没有做到完全解耦，但是也可以实现代码层解耦。

API接口识别和粒度设计

对应API接口识别，实际上微服务在设计阶段第二个重点，即如何保证识别的微服务足够的粗粒度和可复用。

实际我们看到在实践过程中，很多项目团队的管理中心在微服务模块上，而没有在微服务模块暴露的API接口上，导致后续的接口集成混乱。

当我重新思考API接口的时候，实际上的管控应该包括三个层面的内容。

第一个层面是单个微服务存在的后端模块和前端模块之间的接口，这类情况下往往后端暴露大量的API接口给前端调用，很多接口可能还是CRUD级别的细粒度接口。

第二个层面是一个大应用里面，各个微服务模块之间的API接口，比如供应链管理应用中招投标管理微服务和采购微服务两者之间的API接口。这类接口跨微服务，不应该出现重度耦合的情况。

第三个层面是大应用对外暴露的接口，比如供应链整个应用应该对外暴露和注册到外部API网关或能力开放平台，和ERP，和PMS等外部其他应用交互的接口。

对于第一个层面往往是弱管控，类似通过JWT保证基本的安全即可。而对于第二和第三个层面的接口则应该强管控，即应该管控到每一个API接口这个粒度。比如招投标模块的后端暴露了30个API接口给前端用，但是并不是说采购微服务也能够任意访问这30个接口服务。同时接口应该是粗粒度的，可复用的，微服务之间，微服务应用之间不应该出现大量接口交互集成。如果出现，那么就说明两者耦合很紧，没有达到解耦的目的。

基于API驱动的开发过程

如果我来指导微服务架构下的开发过程改进，那么一定会谈到API接口驱动这个核心思路。一个是微服务本身可能划分为了不同的团队在开发，一个是微服务本身又划分了前后端分离分为不同的角色在开发。

如果API接口在前期都没有定义清楚就开始开发工作，那么后续集成一定会出问题。API接口规范或契约是前端开发，后端开发，测试人员共同遵循的一个关键内容。

如上图，大家遵循同样的接口契约，那么后端开发，前端开发和测试人员可以并行开始各自的工作。对于前端优先进行接口开发和实现，前端则通过接口契约产生Mock模拟，通过接口模拟实现来进行前端功能的开发。在前后端开发过程中，测试人员也可以根据接口定义进行测试设计工作，同时进行相关的测试脚本设计或录制工作。

运行态-DevOps和容器云

在微服务架构实施过程中，一般都会谈到容器云和DevOps持续集成和交付。

因此微服务治理过程中的运行态，更多的就是解决微服务如何和容器云资源集成的过程，包括了微服务整个编译，构建，部署和交付过程，如何通过DevOps思想来实现敏捷和自动化的过程。

如果再简单点来说。

即微服务架构实施过程中，我们需要考虑微服务的设计开发和交付，一开始就是支撑全面上云的，能够部署和交付到云原生技术底座上面。

在整个过程中，我们实际的关键点在于。

微服务开发框架和环境，敏捷研发管理和工具，容器云PaaS平台三者之间的融合和集成。而整个融合和集成我们通过DevOps支撑平台来完成。

如果这样的话DevOps平台可以看做是微服务开发和交付过程中重要的一个治理平台。

一个微服务在设计阶段完成后，进入到开发和部署交付阶段，那么这个阶段重点就是进行DevOps过程实践，真正统一敏捷研发和持续集成交付过程。当DevOps完整实施下去后，你可以看到整个微服务开发交付过程自然就理顺了。

对于DevOps和容器云，可以参考我前面输出过的相关文章。

运维管控三核心

对于微服务治理能力，经常会谈到具体的功能点，比如：

• 服务限流，熔断

• 服务安全

• 服务日志审计

• 服务降级

• 服务容错和高可用

那么实际上到了运维监控阶段，服务治理管控核心就三个方面的内容。其一是治理规则中心，其二是监控和度量中心，其三是管控执行中心。

如何理解？

简单来说运维阶段的服务治理重点就是首先制定了服务治理规则，包括了安全规则，限流规则，服务SLA规则等。然后就是进行微服务运行日志，接口服务日志，资源性能日志等的数据采集和度量分析。当分析结果触发了规则后，那么就进行了相关的规则执行。

规则执行则是最终具体的管控手段。规则执行将直线导致微服务运行状态的变化，微服务SLA等级的变化，资源层的变化等。

当然监控和度量分析中心也可能没有直接触发规则的执行，而是我们根据度量分析的结果，发现了我们前期没有做好的地方，对已有的管控规范进行修改和调整，对服务管控规则进行新增等。

服务运行监控和整个治理框架中的其它核心模块之间的一些集成关系。通过集成关系的梳理，可以更方便理解服务运行监控分析在整个治理框架中的重要作用。

对于整体集成关系如下图：

无论是哪种你都可以看到。服务运行持续改进迭代（规则制定-》监控和独立分析-》规则执行），这个是一个不断优化，持续改进的过程。

这个过程让微服务治理逐步进入到一个最佳的状态。这个过程核心是规则驱动的，但是监控和度量分析又是关键手段，而最终的类似限流，服务降级仅仅是最终的执行措施或结果。

因此一定不要简单地将微服务治理理解为设置了一个限流熔断策略就是微服务治理，或者上了一些限流熔断，服务链路监控工具就是微服务治理。

就远行科技自己多年微服务治理方面的实践来说，其核心都是基于服务运行日志，服务链，性能，异常等监控不断的进行分析和梳理，不断的优化相应的管控治理规则，逐步落地实施的过程。

运维变更和影响分析

在微服务架构实践过程中，由于很多接口是采用Http API接口方式进行调用，很多接口修改实际并不会引起编译构建期的错误。因此导致某个微服务接口修改后导致其它微服务模块功能出现异常的情况。当出现问题后，我们才在事后进行修复。

对于服务链监控和链路跟踪是一个事后的行为，重点是发现性能问题而不是帮你去分析服务之间的依赖关系。

因此提前梳理清楚微服务间的接口交互和依赖关系是必须的，如上图。

通过上图的接口交互矩阵，可以很清楚的看到当某个接口出现变化的时候，究竟地对哪些微服务模块，哪些功能造成影响会那这些影响点就必须考虑配套的变更或者说在提交测试的时候，这些影响到的微服务模块或功能也需要进行测试。

微服务治理框架趋势-ServiceMesh

当前主流的微服务架构，本身就是一种去中心化的架构模式，因此微服务治理本身也是去中心化的。而对于服务注册发现中心，本身可以作为服务治理的一部分，但是无法完成所有的服务治理工作。也因此看到服务限流熔断，服务安全，负载均衡等往往还需要其它组件的配合，共同来完成微服务治理过程。

能否以一个框架完成所有治理工作？

能不能用一个框架来完成所有的服务治理工作，同时这个框架本身又是去中心化的架构。这个即前面谈到过的ServiceMesh服务网格，包括Istio开源实现。

简单来说当前的ServiceMesh服务网格的思路就是通过下放Sidecar边车到各个微服务中的方式来实现管控流和数据流的分离，并彻底的去中心化。

随着云原生，特别是容器云和DevOps的发展，这个问题得到了很好的解决，即我们可以在自动化的服务部署和交付过程中，自动的下放这个代理包，同时在边车模块有更新的时候我们也可以实现自动化的重新部署或灰度发布。

ServiceMesh是下一代微服务

对于ServiceMesh经常有人提到是下一代的微服务，或者说通过ServiceMesh来替代类似SpringCloud等主流的微服务框架。

对于SpringCloud架构体系我们需要理解为开发态和运行治理态两个方面的内容，其一个是为开发态提供的开发框架，环境和组件；其次是在运行态提供的各种微服务治理能力，比如服务注册发现，限流熔断，安全等。

那么ServiceMesh实际上是希望将SpringCloud框架在运行态提供的各种服务治理管控能力全部替代掉，而仅仅保留开发态的能力。即使你在开发态仍然可以使用Spingboot来进行微服务开发，来通过声明式的方式发布Rest API接口服务。

即这个时候的重心仅仅在于你采用一个技术来开发一个微服务组件，同时这个组件能够暴露外部可以访问的Rest API接口。同时这个组件足够轻量化，可以很容易部署到容器中。

包括你还可以用go语言来开发你的微服务，并接入到ServiceMesh，在这种情况下仅仅是ServiceMesh为Go语言定制一个特殊的Sidecar边车组件。

开发和管控治理彻底分离

对于这点，实际上我已经强调过很多次了。

还是拿Springcloud框架来举例，可以看到当你在开发的过程中，为了满足后续的治理管控要求，你会增加相应的配置文件编写，增加注解说明，或者还需要增加相应的Java类文件和代码。而这些并不是为业务功能和逻辑实现服务。

这些额外的工作仅仅是为了后续微服务管理和治理。

那么在这种方式下，如果微服务管控治理的规则发生了变化，对于一些无法通过配置中心动态下发的内容，势必还涉及到代码级的修改并重新打包部署。也就是治理管控需求反而影响到微服务组件本身的稳定性。

而我们真正需要的是管控治理和开发的分离。

其一就是在开发状态和开发过程中，不需要为了后续的管控治理来增加任何开发工作量和开发代码，开发配置等。也就是说对于开发人员来说，开发只关系业务功能和业务规则逻辑的实现，在开发阶段不用去考虑任何涉及到微服务治理管控的技术内容。这样才能够让开发更加专注于业务功能的实现。

其二就是管控治理功能和微服务业务功能彻底分离。这个分离在ServiceMesh里面可以看到通过Kurbernetes将微服务部署到Pod里面的时候，会单独再为Sidecar创建一个容器，微服务容器和Sidecar容器在一个Pod里面，几方面接口协同，又实现了相互之间的解耦和隔离。

即使Sidecar本身出现变更或功能增加，也不会影响到微服务本身。

DevOps加速推进ServiceMesh

在前面谈ServiceMesh相关文章里面提到，对于ServiceMesh的Sidecar是做为一个独立的代理组件下发到微服务端的，而且对已有的微服务本身无任何侵入。

如果这个代理包的下发和部署都需要人工去完成，那么整个工作量巨大，同时也不方便后续的管控和升级。因此在整个ServiceMesh的推广实施中一定就涉及到该部分工作的自动化。

如何自动化？

对于云原生本身就在做CI/CD的持续集成和持续部署的实践，我们通过编排可视化的流水线来完成编译，构建，打包，部署整个过程的自动化。也正是有了这个基础，我们也很容易想到可以在自动部署的时候将Sidecar代理模块自动部署下去，在整个过程中不需要人工干预去处理，这个过程完全自动化。

也就是说对于微服务治理能力的实现，从边车的下发，后续的治理管控等对于微服务开发本身都是无感知的，无侵入的，而且整个过程通过DevOps实践来实现了完整的自动化。

开发人员只需要开发微服务，但是开发的微服务通过DevOps+容器云，天然具备了后续的微服务管控治理能力，不会担心后续的微服务无法管控，无法监控等。

云原生-彻底的从资源到服务

云原生的文章我写了很多，其中始终都在强调的一个观点就是从资源到服务，整个云计算演进的过程就是不断地向上抽象的过程。

基于这个思路我们再回来看下微服务和云原生，容器云的融合。

也就是当我们采用类似Springcloud框架体系的时候，这个框架体系既包括了开发态的内容，也包括了运行态的微服务治理内容。也就是说当你将开发完成的微服务部署到测试环境或生产环境的时候，你必须要提前部署类似注册中心，微服务网关这些组件。

那么如何部署这些组件？

常规的容器云PaaS平台并不会提供这些能力，那么在这个时候你就需要去订购虚拟机，自己在虚拟机上面安装这些组件服务，而这部分内容实际是无法通过DevOps和容器云自己进行的，这些动作全部是在DevOps，容器云，PaaS平台服务体外循环。

也就是说本来需要完全面对服务，但是又接触到了资源层的虚拟机资源。

在这种场景下，我们开发完成的微服务的部署，交付过程并没有想象的那么简单，为了微服务管控治理需求，而增加了部署，交付的复杂度。同时又面对了底层资源。

而我们希望的是你的整个应用开发，交付都完全能够通过DevOps+容器云PaaS平台进行，彻底从资源层抽象到服务层。在这个云原生整体推进的大目标下，可以看到通过ServiceMesh来代替传统的微服务治理就势在必行，也是大趋势。

包括我们自己做DevOps支撑平台和容器云平台，也需要在整个产品和最佳实践中完整地融入ServiceMesh的能力。在我前年谈的时候实际类似Istio等开源实现并不是很成熟，而最近1到2年却已经得到更大面积的采用和实践。

特别是在DevOps推进过程中本身也加速了ServiceMesh的落地。

人月聊IT

企业架构和IT咨询规划，SOA和云计算，日常随感

78篇原创内容

Official Account