架构技能（九）：服务治理_服务治理能解决什么问题-优快云博客

本文链接：https://blog.youkuaiyun.com/wang_zong_sheng/article/details/145395678

先说交通治理。

没有交通治理，会是怎样的场景？见下图。

交通没有治理，车流效率会大大降低，尤其是在十字路口这种有资源竞争的路段，交通很容易陷入瘫痪。

如果引入交通治理，会是怎样的场景？见下图。

交通治理，通过使用信号灯或是建造立交桥，在即使有资源冲突的路口段，通行车辆仍然可以大路朝天，各走一边；交通治理，在高车流量下避免了交通瘫痪，提高了车辆的通行效率。

总结一句：交通治理解决了高车流量场景下车流的通行效率问题。

再类比，说服务治理。

如果没有服务治理，会是怎样的场景？

1. 服务 A 集群因为需求迭代和业务升级，需要程序部署和服务重启来上线；为了减少服务上线对用户的影响，我们往往采用灰度发布的方式；例如：服务 A 集群有 5 个节点，先重启第一个节点，让 20% 的流量验证服务的稳定性和可行性（如果能让上游服务减少对新节点的流量调用是最好的，但这无疑增加了上游服务的工作量），在第一个节点稳定运行的情况下，再重复上述工作，继续重启第二个节点、第三个节点，直至灰度完成整个集群；在没有服务治理的情况下，上述的工作需要人工完成，效率极低。

2.服务 A 集群有 3 个节点，因负载偏高，需要将服务 A 集群扩容至 5 个节点，新增加的 2 个节点如何分担对服务 A 集群的调用流量？没有服务治理的情况下，服务 A 的负责人需要首先知道哪些服务调用了服务 A，然后挨个通知这些调用服务的负责人，让他们修改对服务 A 集群节点的调用流量权重；调用服务的负责人会非常抱怨：明明是服务 A 集群进行了扩容，为什么要增加我的工作量！

3.对服务 A 集群进行缩容，场景与上雷同，上游服务的负责人同样抱怨：明明是服务 A 集群进行缩容，为什么让我修改对服务 A 集群节点的调用权重，来增加我的工作量；在企业中，需要增加别人的工作量来完成自己的业务指标，往往效率会非常低。

4.服务 A 被服务 X 和服务 Y 调用，突然某个时刻服务 X 增加了对服务 A 调用的吞吐量，导致服务 A 负载的急剧升高，此时服务 Y 对服务 A 的调用，往往会出现超时，进而引发一系列其他的问题；服务 Y 的负责人会非常委屈：明明是服务 X 不守 “规矩”，突然增大调用量，为什么要影响我的服务？在企业微服务开发中，城门失火殃及池鱼的故事比比皆是。

5.在微服务系统中，雪崩是很容易发生的，尤其当流量达到一定限度；我们知道，微服务系统中，一个服务因为负载、IO、网络等问题会导致接口调用不通，上游调用服务的系统资源得不到及时释放，会逐步向上扩散波及到其他服务，造成大面积的微服务雪崩；所以，在重大运营活动之前，我们需要采用流量控制、服务熔断、服务降级等方式来避免雪崩情况的发生；对相关服务调节流量控制阈值、启动与关闭服务熔断、打开服务降级开关等，在没有服务治理手段的情况下，又会是效率极低和极容易出错的人工操作。

什么是服务治理呢？

服务治理是指对服务从发布到下线全生命周期的管理，这些管理内容包括服务的发布、服务的注册和发现、服务的通信、服务的扩缩容、服务的熔断和降级、服务的限流、服务的下线等，这些对服务的操作本质上是为了提高服务的运维效率和保证服务的稳定运行。

服务治理的内容很多，网络上有大量介绍的资料，这里不再逐个分析来重复累述；我们从大量的服务治理案例中总结出了一个普适性的服务治理模型。见下图。

在整个微服务系统中，只有一个核心的组件能触达到所有的服务，它就是 “注册中心”；注册中心能与所有的服务节点进行通信，它是整个微服务系统的枢纽，所以注册中心天然具备了服务治理的基础能力；
注册中心通过服务注册与服务发现的能力，解决了服务消费方对服务提供方寻址的问题，确认服务提供方集群节点的地址后，服务消费方对其发起 RPC 远程调用，RPC 解决了服务之间通信的问题；
管理平台是一个泛化的系统，它在实际应用场景中有明确的职责，它可以是发布系统、服务管理系统、服务容错平台、权限管理平台、测试平台等等；
管理平台收集相关服务的状态数据，根据状态值，下发命令到注册中心，然后由注册中心下发指令到相关服务（注册中心能触达到所有服务集群的所有节点），由服务节点执行指令，完成服务治理的内容。

普适性的服务治理模型较为抽象，我们拿服务发布和灰度上线的例子来具体说明。见下图。

服务 X 调用服务 A，服务 A 集群包含 4 个服务节点，如何通过服务治理实现对服务 A 集群的服务发布？

发布平台采集服务 X 调用服务 A 集群节点 1 的权重数据；
发布平台下发权重变更（权重为0）命令到注册中心；
注册中心下发调整权重（权重为0）指令到服务 X，将服务 X 调用服务 A 集群中节点 1 的权重调整为 0，即服务 X 不再发送服务调用请求到节点1；
发布平台采集服务 A 集群的运行状态数据，确认节点 1 没有任何流量进入；
发布平台对节点1 更新程序，并对进程重启；
发布平台下发权重变更（权重为 1%）命令到注册中心；
注册中心下发调整权重（权重为 1%）指令到服务 X，将服务 X 调用服务 A集群节点 1 的权重调整为 1%，即服务 X 将 1% 的调用请求发送到节点1，也就是我们拿 1% 的流量验证节点1更新之后的稳定性；
对线上系统验证没有任何问题后，由发布平台继续下发调整权重（权重为 2%）的指令到注册中心，继续灰度流量，一直到权重调整到 25% 为止，此时完成对节点 1 服务发布和灰度上线的过程；
重复上述流程，分别对节点 2、节点 3 和节点 4进行操作，完成服务发布和灰度上线。

整个服务发布和灰度上线的服务治理过程，尽量减少人工参与，尤其是对上游服务权重的调整，完全避免了上游服务负责人的工作量。

再举一个服务熔断的案例，见下图。

服务 X 作为服务消费方，分别调用服务 A、服务 B、服务 C和服务D。在企业做大促活动时或者为了节省服务资源需要停掉某些边缘业务，来有损提供服务，需要服务 X 对服务 B和服务 D 进行熔断。

由熔断平台下发服务熔断指令到注册中心；
注册中心下发对服务 B 和服务 D 的调用熔断指令到服务 X；
服务 X 接收到熔断指令后，解析执行，完成对下游服务 B 和服务 D 的调用熔断。

普适的服务治理模型中，通过提供和解析注册中心下发的指令，使得服务治理模型有更多的扩展性应用；注册中心是一个中心化的组件，提供了能将各类指令下发给任何服务节点的通道，这为服务治理提供了无限的可能性；我们通过管理平台，可以随时停止任何一个服务节点，也可以随时启动它，可以对服务的流量进行远程限流，也可以远程实现服务的降级应用，所有的操作只需一个指令，这是非常有意思也非常有魅力的一个创新点。

实现该服务治理模型，需要在服务节点与注册中心的连接中提供和打通指令通道，并由服务底层框架实现对指令的解析执行，这里面有非常多的技术难点要攻克解决（在后面文章中会逐步分析）。

服务治理，是在谈什么？谈如何基于统一化的服务治理模型或架构实现服务治理的目的，达到提高服务运维效率和保证服务稳定运行的目的。

最后，总结文中关键：