微服务体系治理解决方案

第一章：综述

1.1 业务发展离不开微服务治理的保驾护航

随着微服务技术的发展，微服务(MicroServices) 的概念早已深⼊⼈⼼，也越来越多的公司开始使⽤微服务架构来开发业务应⽤。

微服务架构的最⼤好处是它可以提升开发 效率和系统整体的稳定性：

• 开发和部署相对简单
• 横向扩展简单
• 架构升级灵活
• 更好的容错性

但是微服务在实施过程中，也很容易遇到⼀些难点。如果微服务治理得不恰当，反⽽有可能适得其反，不仅不能享受到微服务架构带来的好处，反⽽会因为微服务带来的系统复杂性，造成开发、运维部署的复杂度增加，进⽽影响开发迭代的速度，甚⾄影响系统的整体稳定性。

一个微服务成功落地的典型案例

业务孵化期

组件技术选型 + 组件落地

业务快速发展期

1.开发测试提效

2.安全发布：无损上下线、全链路灰度

3.屏蔽偶发的异常导致的风险【离群实例摘除】

业务成熟期

1.容灾多活

2.问题快速定位

3.风险预案

1.2 微服务治理在云原生下的挑战

我们进⾏微服务化，本身的使命是让业务的迭代更加⾼效，但当我们的微服务数量逐步增多，链路越来越⻓，如果不进⾏进⼀步的治理，那么引发的效率问题可能会⼤于微服务架构本身带来的架构红利。

1.3 云原生下微服务治理发展的趋势

随着云原⽣技术的不断发展，微服务治理也仍旧在快速的发展和变⾰中。

我们观察到微服务技术的主要 3 个趋势：后端服务 BaaS 化；服务治理逻辑下沉，业务透明化；部署形态混合云化。

后端服务 BaaS 化

BaaS，即 Backend as a service 的简称，微服务架构下，微服务应⽤通常会依赖多个后端服务，典型的如数据库，缓存，消息队列等等，过去我们搭建⼀个微服务体系通常使⽤开源软件⾃⾏搭建这些后端的依赖，但是维护这些后端组件需要⼤量的⼈⼒资源和成本，⼀旦出问题⻛险⾮常⼤。随着业务的云原⽣上云，我们发现越来越多的云厂商通过云服务的形式，提供这些Microservices Governance Technology 17 Microservices Governance Technology 后端依赖的托管服务，免去了业务开发⼈⼯运维这些软件的烦恼。由此使得企业越来越聚焦在⾃⼰的业务应⽤上，⽽更少的去关注底层的中间件依赖。过去我们从数据库开始，再到消息队列，缓存，⼏乎所有的云厂商都提供了托管的服务供选择，然⽽随着微服务化进⼀步深⼊，我们认为微服务的注册中⼼，配置中⼼，微服务⽹关，服务治理中⼼，分布式事务等也逐步由云厂商提供，通过标准服务的形式，企业上云之后可以灵活的选择，并且没有⼚商的锁定。

服务治理下沉，业务透明化

随着 Service Mesh 技术概念的兴起，结合阿⾥巴巴内部架构演进的实践，我们发现，服务治理技术将逐步的和业务解耦，对业务更加的透明，⽆论是以 sidecar 为⾸的 service mesh，还是 Java Agent 为主的新兴治理技术，他们解决的核⼼问题，就是让业务摆脱对服务治理能⼒的依赖，让基础设施的迭代可以脱离业务发展独⽴进⾏。同时，微服务各个语⾔之间通常会有不同的框架，这些跨语⾔的微服务框架将形成统⼀的服务治理控制⾯，进⼀步降低客户选择的成本，⼀个基于开源微服务框架实现的微服务系统，将能够不改⼀⾏代码，能够部署到云上，享受云⼚商提供的 BaaS 服务。

部署形态混合云化

第三个趋势是企业上云部署形态不再会选择单⼀云厂商，⽆论是从避免⼚商锁定，还是从稳定性来讲都会考虑跨多个云⼚商提供服务，因此云厂商提供的服务会趋向于标准化，否则企业很有可能选择开源⾃建来避免⼚商的锁定；同时，企业上云也⾮⼀蹴⽽就，通常⼤量的业务仍部署在⾃建 IDC 的业务，新兴业务逐步上云。如何针对跨多云，跨⾃建机房和云上等多种部署形态，对业务进⾏统⼀的管理，也是摆在企业⾯前的难题。未来的云服务，应该是可以提供跨多个云统⼀纳管，并且⼀致体验的云服务。

1.4 微服务治理的区分

我们基于应⽤开发、测试、运维的不同阶段，对服务治理的概念做⼀个区分，分为开发态、测试态和运行态。其中运⾏态⼜分为发布态、安全态和⾼可⽤。

第二章 微服务治理技术原理介绍

2.1 微服务治理技术概述

值得注意的是，⽆论是 SDK 的形态，还是 Agent 的形态，还是 sidecar 的形态，对于服务治理的控制台来说，都需要统⼀的控制面对多种数据⾯进⾏控制。【目前中小型公司基本还是用sdk模式】

2.2 通过java agent方式进行微服务治理

中间件作为提供⽅，苦于业务⽅不能及时升级中间件到最新版。业务⽅作为使⽤⽅，苦于升级成本⽐较⾼。 Java Agent 技术，能够在运⾏时动态修改 Java 字节码，动态的改变 Java 程序的⾏为，能够很好的满⾜这种需求。

将各个中间件的 Java Agent 作为插件(plugin)，组装成⼀个统⼀的 JavaAgent，称为 One Java Agent。

 每个 plugin 可以由启动参数来单独控制是否开启。

 各个 plugin 的启动是并⾏的，将 Java Agent 的启动速度由 O(n+m+...)提升⾄O(n)。

 各个 plugin 的类，都由不同的类加载器加载，最⼤限度隔离了各个 plugin。

 每个 plugin 的状态都可以上报到服务端，可以通过监控来检测各个 plugin 是否有问题。

2.3 通过Service Mesh 来进行微服务治理

2017 年，Google、IBM、Lyft 联⼿发布了 Istio，它与 Linkerd / Envoy 等项⽬相⽐，它⾸次给⼤家增加了控制平⾯的概念，提供了强⼤的流量控制能⼒。经过多年的发展 Istio，已经逐步成为 控制平⾯的事实标准。

Istio的架构

Istiod 作为控制⾯的统⼀组件，负责对接服务注册发现、路由规则管理、证书管理等能⼒，Envoy Proxy 作为数据⾯Sidecar 代理业务流量，Istio 和 Envoy Proxy 之间通过 XDS 接⼝完成服务发现、路由规则等数据的传递，同时 Istio 也提供了 MCP Over XDS 接⼝对接外部注册中⼼，如 Nacos。

Istio 除了⽀持东⻄向的流量代理之外，还⽀持南北流量的代理，通过 Istio Ingress Gateway作为⼊⼝的⽹关，通过 Istio Egress Gateway 作为出⼝⽹关，这样 Istio 将可以对全域流量进⾏治理。

基于 Envoy Filter 的服务治理

Envoy 是 Istio 中的 Sidecar 官⽅标配，是⼀个⾯向服务架构的⾼性能⽹络代理，由 C++ 语⾔实现，拥有强⼤的定制化能⼒。Envoy 是⾯向服务架构设计的 L7 代理和通信总线，核⼼是⼀个 L3/L4 ⽹络代理。可插⼊ filter 链机制允许开发⼈员编写 filter 来执⾏不同的 TCP 代理任务并将其插⼊到主体服务中。Envoy 还⽀持额外的 HTTP L7 filter 层。可以将 HTTP filter 插⼊执⾏不同任务的 HTTP 连接管理⼦系统，可以查看每个 Envoy 的 Config Dump 看到Http filter 配置，Envoy 根据这些配置决定如何执⾏对应的流量处理流程。

第三章 微服务治理在云原生场景下的解决方案

3.1 线上发布稳定性解决方案

绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的 可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代 码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。

无损下线

1.主动通知

一般注册中心都提供了主动注销接口供微服务应用正常关闭时调用，以便下线实例能及时更新其在注册中心上的状态。

2.自适应等待

在并发度不⾼的场景下，主动通知⽅法可以解决绝⼤部分应⽤下线流量有损问题。但对于⾼并发⼤流量应⽤下线场景，如果主动通知完，可能仍然存在⼀些在途请求需要待下线应⽤处理完才能下线否则这些流量就⽆法正常被响应。为解决该类在途请求问题，可通过给待下线应⽤在下线前通过⾃适应等待机制在处理完所有在途请求后，再下线以实现流量⽆损。

如上图 3 所示，⾃适应等待机制是通过待下线应⽤统计应⽤中是否仍然存在未处理完的在途请求，来决定应⽤下线的时机，从⽽让待下线应⽤在下线前处理完所有剩余请求。

无损上线

业界针对上述应⽤⽆损上线场景提出如下包括延迟注册、⼩流量服务预热以及就绪检查等⼀系列解决⽅案，详细完整的⽅案如下图 5 所示：

延迟注册

应用启动成功后，通过延迟一定的时间后再调用注册接口。

小流量预热

在线上发布场景下，很多时候刚启动的冷系统直接处理⼤量请求，可能由于系统内部资源初始化不彻底从⽽出现⼤量请求超时、阻塞、报错甚⾄导致刚发布应⽤宕机等线上发布事故出现。为了避免该类问题业界针对不同框架类型以及应⽤⾃身特点设计了不同的应对举措，⽐如针对类加载慢问题有编写脚本促使 JVM 进⾏预热、阿⾥巴巴集团内部 HSF（High Speed Framework）使⽤的对接⼝分批发布、延迟注册、通过 mock 脚本对应⽤进⾏模拟请求预热以及⼩流量预热等。本节将对其中适⽤范围最⼴的⼩流量预热⽅法进⾏介绍。

⼩流量预热⽅法通过在服务消费端根据各个服务提供者实例的启动时间计算权重，结合负载均衡算法控制刚启动应⽤流量随启动时间逐渐递增到正常⽔平的这样⼀个过程帮助刚启动运⾏进⾏预热，详细 QPS 随时间变化曲线如图 6 所示：

服务提供端在向注册中⼼注册服务的过程中，将⾃身的预热时⻓ WarmupTime、服务启动时间StartTime 通过元数据的形式注册到注册中⼼中，服务消费端在注册中⼼订阅相关服务实例列表，调⽤过程中根据 WarmupTime、StartTime 计算个实例所分批的调⽤权重。刚启动StartTime 距离调⽤时刻差值较⼩的实例权重下，从⽽实现对刚启动应⽤分配更少流量实现对其进⾏⼩流量预热。 开源 Dubbo 所实现的⼩流量服务预热模型计算如下公式所示：

模型中应用 QPS 对应的 f(x) 随调用时刻 x 线性变化，x 表示调用时刻的时间，startTime 是应用开始时间，warmupTime 是用户配置的应用预热时长，k 是常数，一般表示各实例的默认权重。

通过⼩流量预热⽅法，可以有效解决，⾼并发⼤流量下，资源初始化慢所导致的⼤量请求响应慢、请求阻塞，资源耗尽导致的刚启动应⽤宕机事故。

3.2 微服务可观测增强解决方案

可观测不但可以判断系统是否正常，还可以在系统出现问题之前，主动发现系统风险。

可观测性支撑数据大致分为三大类：Metrics，Tracing 和 Logging。以下是社区中常用的一张图：

Metrics: 是⼀种聚合的度量数值，提供量化的系统内/外部各个维度的指标，⼀般包括Counter、Gauge、Timer、Histogram 等度量指标。

Tracing: 提供了⼀个请求从接收到处理完毕整个⽣命周期的跟踪路径，⾯向的是请求，可以轻松分析出请求中异常点，通常请求都是在分布式的系统中处理。⽐如⼀次请求的范围，也就是从浏览器或者⼿机端发起的任何⼀次调⽤，我们根据轨迹去追踪，经过哪些组件、微服务等，所以也叫做分布式链路追踪。

Logging: 应⽤运⾏过程中产⽣的事件或者程序执⾏过程中产⽣的⼀些⽇志，可以给我们提供⼀些系统运⾏过程中的精细化信息，例如某个关键变量、事件、访问记录等。

微服务可观测增强解决了什么问题?一句话概括就是：全面增强微服务场景下的可观测能力。

这方面，CAT监控是一个综合性比较好的产品。应用本身可以在核心逻辑上报metric到prometheus,然后通过grafana来展示指标数据。

3.3 微服务应用配置解决方案

选择Apollo方案。

3.4 微服务限流降级解决方案

微服务的稳定性⼀直是开发者⾮常关注的话题。随着业务从单体架构向分布式架构演进以及部署⽅式的变化，服务之间的依赖关系变得越来越复杂，业务系统也⾯临着巨⼤的⾼可⽤挑战。

影响微服务可⽤性的因素有⾮常多，⽽这些不稳定的场景可能会导致严重后果。我们从微服务流量的视⻆来看，可以粗略分为两类常⻅的场景：

1. 服务⾃身流量超过承载能⼒导致不可⽤。
2. 服务因依赖其他不可⽤服务，导致⾃身连环不可⽤。

选择Sentinel方案。

3.5 微服务服务发现解决方案

选择Nacos方案。

3.6 线上故障紧急诊断、排查与恢复

在不可避免发⽣故障情况下，希望能够快速修复，减少线上影响，基于此提出了1-5-10 的快恢⽬标，1-5-10 的⽬标是要我们对于线上问题能够做到 1 分钟定位，5 分钟定位，10 分钟修复。

监控：应用运行指标 + 业务指标

告警：给埋点指标配置告警规则，精确告警到人

诊断：通过CAT监控快速看出问题

a、Arthas

b、JVM概览

1-5-10 故障快恢，故障 1 分钟响应、5 分钟定位、10 分钟恢复；只有不断地⾯向失败地设计、基于故障应急⽅式演练，那么在真正遇到线上故障的时候我们才可以更加从容地⾯对故障。

3.7 异构微服务互通解决方案

⼀个企业内部所开发的微服务有可能都是基于同⼀个微服务框架完成的，对于这样的架构，我们称之为是同构微服务体系；当然也有可能⼀个企业内的微服务是基于多种不同的微服务框架建⽴的，这样的架构我们称之为是异构的微服务体系。多种不同类型微服务框架的共存在⼤型企业内还是⽐较普遍的，形成这种现象的原因有很多，⽐如：可能是历史遗留、难以改造的系统；也可能是企业正在做技术栈迁移；⼜或者是企业内不同业务部⻔为了满⾜各⾃的特殊需求⽽做的独⽴选型。这也就意味着异构微服务 体系很有可能需要⻓期共存。解决方案：通过开发一个中间件来打通双方的调用。

参考：阿里的微服务治理白皮书。