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:

pkg.go.dev/github.com/…

• Hertz adapter:

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 微服务管理：

help.aliyun.com/document_de…

Sentinel Go:

github.com/alibaba/sen…

OpenSergo:

opensergo.io/zh-cn

CloudWeGo:

www.cloudwego.io