关于阿里云:OpenSergo-CloudWeGo-共同保障微服务运行时流量稳定性

作者：宿何

微服务运行时稳定性的问题

微服务的稳定性始终是开发者十分关注的话题。随着业务从单体架构向分布式架构演进以及部署形式的变动，服务之间的依赖关系变得越来越简单，业务零碎也面临着微小的高可用挑战。大家可能都经验过以下的场景：

• 演唱会抢票霎时洪峰流量导致系统超出最大负载，load 飙高，用户无奈失常下单；
• 在线选课时同一时刻提交选课的申请过多，零碎无奈响应；
• 页面服务中某一块内容拜访很慢，始终加载不进去，导致整个页面都卡住，无奈失常操作 

影响微服务可用性的因素有十分多，而这些不稳固的场景可能会导致严重后果。咱们从微服务流量的视角来看，能够粗略分为两类常见的运行时场景：

• 服务本身流量超过承载能力导致不可用。比方激增流量、批量工作投递导致服务负载飙高，无奈失常解决申请。
• 服务因依赖其余不可用服务，导致本身连环不可用。比方咱们的服务可能依赖好几个第三方服务，假如某个领取服务出现异常，调用十分慢，而调用端又没有无效地进行预防与解决，则调用端的线程池会被占满，影响服务本身失常运行。在分布式系统中，调用关系是网状的、盘根错节的，某个服务呈现故障可能会导致级联反馈，导致整个链路不可用。

在遇到这些微服务运行时稳定性的问题时，咱们应该如何解决呢？针对这些不稳固的场景，MSE 提供全方位的流量防护能力，基于开源流量治理组件 Sentinel 的稳定性防护能力，以流量为切入点，从流量管制、并发管制、熔断降级、热点防护、零碎自适应爱护等多个维度来帮忙保障服务的稳定性，笼罩微服务框架、云原生网关、Service Mesh 等几大场景，反对 Java、Go、C++、Rust 等多种语言的异构微服务架构。

CloudWeGo 原生反对 Sentinel 及 OpenSergo

CloudWeGo 是一套由字节跳动开源的、可疾速构建企业级云原生微服务架构的中间件汇合。CloudWeGo 我的项目独特的特点是高性能、高扩展性、高牢靠，专一于微服务通信与治理。其中 Kitex 是下一代高性能、强可扩大的 Golang RPC 框架，提供整套微服务的能力；Hertz 是高易用性、高性能、高扩展性的 Golang 微服务 HTTP 框架，旨在为开发人员简化构建微服务。

近期 CloudWeGo 社区与 Sentinel 社区单干共建，提供了 CloudWeGo Kitex 及 Hertz 对接 Sentinel Go 的适配模块，只需简略地引入适配模块并引入对应 Middleware，即可疾速将 Kitex 及 Hertz 服务接入 Sentinel Go，享受全面的流量治理与防护能力。同时联合 Sentinel Go 与 OpenSergo 微服务治理规范的对接，CloudWeGo 也将反对 OpenSergo spec 中流控降级与容错的标准配置，将来能够通过对立的 CRD 形式进行流量治理管控。

适配模块文档能够参考：

• Kitex adapter:

https://pkg.go.dev/github.com…

• Hertz adapter:

https://pkg.go.dev/github.com… 

同时，基于 Sentinel 的 Kitex 和 Hertz 适配模块，咱们能够联合 MSE 服务治理 Go SDK 接入形式，来不便地将 Kitex 和 Hertz 服务接入到阿里云 MSE 微服务治理产品中，通过白屏化的观测与治理配置伎俩来保障微服务的运行时流量稳定性。

CloudWeGo + MSE 流量防护最佳实际

MSE 微服务治理提供全方位的流量治理、流量防护及微服务视角的数据库治理能力，其中对于 Go 微服务，开发者能够通过 Go SDK 形式接入 MSE 来享受流控降级与容错相干的治理、白屏化配置与观测能力，保障服务运行时的稳定性。MSE 流量治理反对 CloudWeGo, gRPC, Gin, dubbo-go, go-micro 等罕用 Go 微服务框架的流控降级与容错能力。首先咱们先来看一下流量防护的典型场景。

流量管制保障激增流量下服务的稳定性

流量是十分随机性的、不可预测的。前一秒可能还惊涛骇浪，后一秒可能就呈现流量洪峰了（例如双十一零点的场景）。然而咱们零碎的容量总是无限的，如果忽然而来的流量超过了零碎的承受能力，就可能会导致申请解决不过去，沉积的申请解决迟缓，CPU/Load 飙高，最初导致系统解体。因而，咱们须要针对这种突发的流量来进行限度，在尽可能解决申请的同时来保障服务不被打垮，这就是流量管制。流量管制的场景是十分通用的，像脉冲流量类的场景都是实用的。

MSE Sentinel 基于毫秒级滑动窗口准确统计与令牌桶、漏桶、WarmUp 等流量控制算法，提供包含秒级精准流控、集群总量流控、匀速排队等在内的多种维度的流量管制场景。通常在 Web 入口或 RPC 服务提供方（Service Provider）的场景下，咱们须要爱护服务提供方本身不被流量洪峰打垮。这时候通常依据服务提供方的服务能力进行流量管制，或针对特定的服务调用方进行限度。咱们能够联合后期压测评估外围接口的承受能力，配置 QPS 模式的流控规定，当每秒的申请量超过设定的阈值时，会主动回绝多余的申请。

熔断降级与隔离保障服务不被慢依赖调用拖垮

一个服务经常会调用别的模块，可能是另外的一个近程服务、数据库，或者第三方 API 等。例如，领取的时候，可能须要近程调用银联提供的 API；查问某个商品的价格，可能须要进行数据库查问。然而，这个被依赖服务的稳定性是不能保障的。如果依赖的服务呈现了不稳固的状况，申请的响应工夫变长，那么调用服务的办法的响应工夫也会变长，线程会产生沉积，最终可能耗尽业务本身的线程池，服务自身也变得不可用。

古代微服务架构都是分布式的，由十分多的服务组成。不同服务之间互相调用，组成简单的调用链路。以上的问题在链路调用中会产生放大的成果。简单链路上的某一环不稳固，就可能会层层级联，最终导致整个链路都不可用。

MSE Sentinel 提供以下的能力防止慢调用等不稳固因素造成服务不可用:

• 并发管制（隔离规定）：作为一种轻量级隔离的伎俩，管制某些调用的并发数（即正在进行的数目），避免过多的慢调用占满线程池造成整体不可用。并发管制规定可作为一种重要的保底伎俩，避免服务被大量慢调用拖垮。
• 不稳固调用熔断：对不稳固的弱依赖调用进行主动熔断降级，临时切断不稳固调用，防止部分不稳固因素导致整体的雪崩。
• 提前降级：对于一些弱依赖的服务（非关键链路依赖），能够在流动前或资源缓和时进行动静降级，以优先保障重要服务的稳定性。被降级的服务将间接返回给定的 mock 值而不会触发理论调用。

熔断降级个性基于熔断器模式的思维，在服务呈现不稳固因素（如响应工夫变长，错误率回升）的时候临时切断服务的调用，期待一段时间再进行渐进式复原尝试。一方面避免给不稳固服务“雪上加霜”，另一方面爱护服务的调用方不被拖垮。目前反对两种熔断策略：基于响应工夫（慢调用比例）和基于谬误（谬误比例 / 谬误数），能够无效地针对各种不稳固的场景进行防护。

留神熔断器模式个别实用于弱依赖调用，即熔断后不影响业务主流程，而并发管制对于弱依赖和强依赖调用均实用。开发者须要设计好降级后的 fallback 逻辑和返回值。另外须要留神的是，即便服务调用方引入了熔断降级机制，咱们还是须要在 HTTP 或 RPC 客户端配置申请超时工夫，来做一个兜底的防护。

CloudWeGo 接入 MSE 流量防护示例

接下来咱们就以 CloudWeGo Kitex 服务为例，展现如何联合 MSE Sentinel 来保障 CloudWeGo 微服务的运行时稳定性。

首先，咱们先在我的项目中引入 MSE Go SDK，并进行一些简略初始化配置；同时咱们也引入 Kitex Sentinel 适配模块，以便将咱们的 Kitex 服务接入到 MSE：

import (
  sentinel "github.com/alibaba/sentinel-golang/api"
  sentinelPlugin "github.com/alibaba/sentinel-golang/pkg/adapters/kitex"
  api "github.com/cloudwego/kitex-examples/hello/kitex_gen/api/hello"
  mse "github.com/aliyun/aliyun-mse-go-sdk"
)

func main() {
  // 初始化 MSE Sentinel；能够通过环境变量或 sentinel.yml 文件配置利用名
  err := mse.InitMseDefault()
  if err != nil {log.Fatalf("Failed to init MSE: %+v", err)
  }

  // 创立 Kitex server 时增加 Sentinel 适配模块中的 middleware
  svr := api.NewServer(new(HelloImpl), server.WithMiddleware(sentinelPlugin.SentinelServerMiddleware()))

  err = svr.Run()
  if err != nil {log.Println(err.Error())
  }
}

接下来咱们启动服务 provider，即可在 MSE 控制台看到咱们的 Kitex 服务。咱们通过 consumer 触发流量拜访，而后能够在 MSE 控制台的接口详情页面看到咱们 Kitex 服务调用的具体监控信息。

接下来咱们针对 Hello:Echo 这个接口办法配置一条单机 QPS 为 10 的流控规定：

配置实现后，规定会实时失效到服务中。稍等片刻咱们就能够在接口详情页面看到 Hello:Echo 这个接口办法的单机处理量被限度到了 10 次每秒，同时 consumer 端也会接管到相应的流控 error。

联合 OpenSergo 实现标准化的流量治理

联合 OpenSergo 实现标准化的流量治理

业界微服务治理存在概念不对立、配置模式不对立、能力不对立、多框架对立管控较为简单等问题。比方咱们心愿给某个接口配置熔断降级规定，在 Sentinel 中可能须要通过 Sentinel 动静规定的形式进行配置，在 Istio 中可能又是另一套配置形式，在其它组件上可能又是不同的配置。不同框架治理配置形式的不统一使得微服务对立治理管控的复杂度相当高。

基于以上背景，由阿里巴巴、bilibili、CloudWeGo 等企业与社区独特发动的 OpenSergo 我的项目应运而生。OpenSergo 旨在提供一套凋谢通用的、面向云原生服务、笼罩微服务及上下游关联组件的微服务治理规范，并依据规范提供一系列的 API 与 SDK 实现。OpenSergo 的最大特点就是以对立的一套配置 /DSL/ 协定定义服务治理规定，面向多语言异构化架构，笼罩微服务框架及上下游关联组件。无论微服务的语言是 Java, Go, Node.js 还是其它语言，无论是规范微服务还是 Mesh 接入，从网关到微服务框架，从数据库到缓存拜访，从服务注册发现到配置，开发者都能够通过同一套 OpenSergo CRD 标准配置进行对立的治理管控，而无需关注各框架、语言的差别点，升高异构化、全链路微服务治理管控的复杂度。

在 OpenSergo 中，咱们联合 Sentinel 及 MSE 的场景实际对流控降级与容错抽出规范 CRD。一个容错治理规定 (FaultToleranceRule) 由以下三局部组成：

• Target: 针对什么样的申请
• Strategy: 容错或控制策略，如流控、熔断、并发管制、自适应过载爱护、离群实例摘除等
• FallbackAction: 触发后的 fallback 行为，如返回某个谬误或状态码

以下 YAML CR 示例定义的规定针对 Hello:Echo 这个服务办法（用资源名标识）配置了一条流控策略，全局不超过 10 QPS：

apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: RateLimitStrategy
metadata:
  name: rate-limit-foo
spec:
  metricType: RequestAmount
  limitMode: Global
  threshold: 10
  statDuration: "1s"
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: FaultToleranceRule
metadata:
  name: my-fault-tolerance-rule
spec:
  selector:
    app: foo-app # 规定配置失效的服务名
  targets:
    - targetResourceName: 'Hello:Echo'
  strategies: 
    - name: rate-limit-foo
  # 这里还能够独自定义 fallbackAction，比方自定义返回值或谬误；不指定则为默认行为 

Sentinel 2.0 将原生反对 OpenSergo 流量治理相干 CRD 配置及能力，联合 Sentinel 提供的各框架的适配模块，让 Dubbo, Spring Cloud Alibaba, gRPC, CloudWeGo 等 20+ 框架可能无缝接入到 OpenSergo 生态中，用对立的 CRD 来配置流量路由、流控降级、服务容错等治理规定。无论是 Java 还是 Go 还是 Mesh 服务，无论是 HTTP 申请还是 RPC 调用，还是数据库 SQL 拜访，咱们都能够用这对立的容错治理规定 CRD 来给微服务架构中的每一环配置治理，来保障咱们服务链路的稳定性。MSE 作为 OpenSergo 微服务治理规范的企业级产品，也将原生反对 OpenSergo spec。

总结与瞻望

流控降级与容错是微服务流量治理中的重要的一环，同时 MSE 还提供更广范畴、更多场景的微服务治理能力，包含全链路灰度、无损高低线、微服务数据库治理、日志治理等一系列的微服务治理能力。服务治理是微服务革新深刻到肯定阶段之后的必经之路，是将微服务做稳做好的要害。同时咱们也在与 CloudWeGo、Kratos、Spring Cloud Alibaba、Dubbo、ShardingSphere 等社区独特建设 OpenSergo 微服务治理规范，将企业与社区中微服务治理的场景与最佳实际独特提取成标准规范，也欢送更多社区与企业一起参加 OpenSergo 微服务治理规范的共建。欢送大家退出 OpenSergo 社区交换群（钉钉群）进行探讨：34826335

参考链接：

MSE 微服务治理：

https://help.aliyun.com/docum…

Sentinel Go:

https://github.com/alibaba/se…

OpenSergo:

https://opensergo.io/zh-cn

CloudWeGo:

https://www.cloudwego.io