摘要:路由、限流和熔断,确保微服务架构的可用性、敏捷性。

微服务作为云原生时代的重要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的微服务治理能力中的冰山一角,我们还有微服务的监控与报警、服务拓扑与链路查询、异常请求分析等大量功能可以帮助你搭建更加强大的微服务架构。