微服务作为云原生时代的重要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的微服务治理能力中的冰山一角，我们还有微服务的监控与报警、服务拓扑与链路查询、异常请求分析等大量功能可以帮助你搭建更加强大的微服务架构。
免责声明：此文内容为第三方自媒体作者发布的观察或评论性文章，所有文字和图片版权归作者所有，且仅代表作者个人观点，与 无关。文章仅供读者参考，并请自行核实相关内容。投诉邮箱：editor@fromgeek.com。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
