路由、限流、熔断 微服务治理

https://mp.weixin.qq.com/s/62237UuEEJiOP_b3xRrZog

有了这三个锦囊，再也不用担心微服务治理了

百度智能云 2019-09-05

 

微服务作为云原生时代的重要IT理念，正在众多企业中实践应用。随之而来的问题是，采用什么样的微服务治理策略，能够确保微服务架构的可用性、敏捷性？为此，百度智能云从运维者的角度，编写了3个锦囊妙计，确保每一个微服务都能在正确的“位置”高效运行。

 

这三个锦囊分别是：路由、限流和熔断。不过，在讨论微服务治理之前，我们可以先明确一下微服务的定义。

 

用积木来理解微服务治理

 

业界对微服务有很多种定义，其核心思想都大同小异。这里引述一下最早提出微服务定义的James Lewis 和 Martin Fowler关于微服务架构的阐述。

 

定义：“将单个应用程序拆分成多个独立运行的小型服务；服务间基于轻量级机制通信，比如基于Http协议的Restful API；每个服务承担独立的业务功能，并且能够独立部署；服务通过去中心化的方式进行管理；服务可以各自使用不同的编程语言，并使用不同的数据存储技术。”

 

其实我们可以再“翻译”一下，将开发一个微服务架构的应用程序比喻成搭建一个乐高机器人，那么微服务架构如下。

 

• 将一个完整的机器人，拆分成很多个可以独立使用的乐高积木块

• 积木块之间不需要通过胶水黏合，而是使用可以随时插拔的标准接口

• 每个积木块都承担独立的功能，比如说用来组成头部、起到连接作用等

• 任意两块积木都可以直接拼接，不需要一个“集成板”之类的中间组件

• 每块积木只需要提供标准的接口即可，材料、颜色和大小等都可以各不相同

 

这样一来，微服务架构的优势也就一目了然：任何一个服务都是可以替换的，单个服务的损坏不会导致整个系统的崩溃，同时整个系统的可扩展性也得到了大大提升，可以在不破坏系统运行的前提下随时进行服务的增减和升级。

 

当我们系统中的服务数量越来越多，服务之间的组合关系越来越复杂时，如何高效地管理这些服务，以确保每个服务都在正确的“位置”运行，并且随时替换或者升级某些“损坏”的服务呢？

 

这就是百度智能云CNAP（云原生微服务应用平台）为微服务架构的运维者提供了3个锦囊妙计的初衷。

 

锦囊一：用路由控制流量

 

CNAP中的【路由】规则用于管理服务间的通信链路。微服务的管理其实比搭建乐高积木更复杂，因为一块乐高积木最多与和它相邻的几块积木拼接，但是一个系统中的服务却可以与系统中任意一个其它服务产生通信。

 

通过合理配置路由，可以解决微服务架构中的两个问题：

 

1、让服务A访问正确的服务B，就好比积木A用来组成头部，那它就应该与组成身体的积木B拼接，而不应该错误拼接到组成手臂的积木C上。
2、服务间通过正确的实例互相访问。一个服务往往会同时运行在多个实例上（实例即物理资源的单位），就像一块乐高积木上通常会有很多个接口。那么路由规则可以指定当服务A访问服务B时，流量应该具体从服务A的哪些实例出发，流入到服务B的哪些实例中去

 

 

 

 

如上图所示，路由规则主要由【流量来源】和【流量目的】两部分组成。和拼装乐高积木一样，我们通常会拿起一个积木A（流量目的），然后去系统中找另外一个需要拼接到A上面的积木B（流量来源）。

 

流量来源即访问发起的服务，我们通常称之为Consumer（服务消费者）。需要先通过服务名找到所需的Consumer，然后通过一组筛选规则来定位Consumer上产生流量的一组具体实例。

 

流量目的即接受访问的服务，我们通常称之为Provider（服务提供者）。Provider在一条路由规则中是不变的（就是我们先拿到手上的那块积木），只需要通过筛选规则来定位接受流量的一组实例。由于流量最终要被分配到某个具体实例中，所以路由规则中还需要指定流量分配的策略和权重（比如可根据实例负载情况分配流量权重）。

 

有了路由规则，服务间就可以通过正确的方式互相访问，“头部”可以拼接到“身体”，“身体”可以连接到“四肢”，从而在庞大复杂的微服务架构中建立起井然有序的拓扑关系。

 

锦囊二：合理制定限流规则

 

乐高积木的拼接仅仅是物理上的连接，但是微服务之间一旦建立起路由，就意味着会有数据在服务之间流通。由于不同服务可以提供的资源和对数据流量的承载能力不尽相同，为了防止单个Consumer占用Provider过多的资源，或者突发的大流量冲击导致Provider故障。CNAP的【限流】规则用来限定从Consumer到Provider访问流量，起到保护Provider服务的作用。

 

 

 

 

 

 

限流规则分为【流量来源】和【限流对象】两部分。流量来源规定了从哪些服务或者哪些实例产生的流量需要被限制，可以通过多个筛选条件来确认一组实例。限流对象则用来配置所选Provider中接收流量的具体实例和方法（方法在服务中用来对请求进行处理，一个方法往往用来实现一个具体的业务逻辑），并且限定该方法可以接收来自流量来源的请求QPS上限。

 

限流规则就像是城市路网中的交通管制，通过对不同路段不同车道限制单位时间通行车辆数，保障整个交通路网的健康运转。合理地配置限流规则，可以让服务资源能够更加合理地分配给不同的请求者，也预防了流量波动可能引发的服务故障甚至宕机。

 

锦囊三：熔断降级防止“雪崩”

 

在服务治理中，虽然我们可以通过限流规则尽量避免服务承受过高的流量，但是在实际生产中服务故障依然难以完全避免。当整个系统中当某些服务产生故障时，如果不及时采取措施，这种故障就有可能因为服务之间的互相访问而被传播开来，最终导致故障规模的扩大，甚至导致整个系统奔溃，这种现象我们称之为“雪崩”。

 

熔断降级其实不只是服务治理中，在金融行业也有很广泛的应用。比如当股指的波动幅度超过规定的熔断点时，交易所为了控制风险采取的暂停交易措施。CNAP提供了服务熔断降级的能力，用来避免微服务架构中因为少量服务故障而引发的服务“雪崩”。

 

 

 

 

与路由和限流不同，熔断规则是在预先选定了Consumer后，配置该Consumer在不同Provider发生故障时的熔断策略。因此熔断对象（即Consumer）是固定的，需要通过一组筛选条件指定该Consumer中发起请求的实例，然后选择需要熔断的Provider服务以及该服务提供的具体方法。

 

CNAP支持自动熔断和手动熔断，在设置自动熔断的情况下，可以根据指定的熔断条件触发时（如在某个时间窗口内异常返回超过某个比例），自动熔断一段时间内从Consumer到Provider之间的所有流量，从而实现对Consumer的保护。

 

熔断机制是微服务架构中的“交通管制”，一旦高速公路上发生交通事故时立即对某个路段或车道进行封禁，从而避免事故进一步扩大。合理利用熔断规则可以大大提升整个微服务架构的健壮性，降低系统性风险和可能发生的事故规模。

 

结束语：更多功能正在上线

 

路由、限流、熔断，这三个百度智能云所提供的微服务治理锦囊你是否已经查收了呢？其实这还只是CNAP的微服务治理能力中的冰山一角，我们还有微服务的监控与报警、服务拓扑与链路查询、异常请求分析等大量功能可以帮助你搭建更加强大的微服务架构。