“天猫双11”背后的流量治理技术与标准实践-阿里云开发者社区

作者：赵奕豪(宿何)｜Sentinel & OpenSergo 开源项目负责人

一年一度的天猫双11已经落下帷幕，大家在疯狂买买买的过程中一定会有疑问：如何保障微服务在双十一的超级峰值下也能如丝般顺滑稳定？这背后的技术原理是怎样的，有没有一些最佳实践与标准？这篇文章就为大家介绍如何结合 Sentinel 与 OpenSergo 玩转双十一背后的流量治理技术与标准。

OpenSergo 是什么？

业界微服务治理存在概念不统一、配置形式不统一、能力不统一、多框架统一管控较为复杂等问题。比如我们希望对某个接口配置熔断，在 Hystrix 中可能需要使用 HystrixCommand 中的配置项进行配置，在 Sentinel 中可能需要通过 Sentinel 动态规则的方式进行配置，在 Istio 中可能又是另一套配置方式。不同框架治理配置方式的不一致使得微服务统一治理管控的复杂度相当高。

基于以上背景，由阿里云、bilibili、中国移动、SphereEx 等企业及 Kratos、CloudWeGo、ShardingSphere、Database Mesh、Spring Cloud Alibaba、Dubbo 等社区共同发起的 OpenSergo 项目应运而生。OpenSergo 是开放通用的，覆盖微服务及上下游关联组件的微服务治理项目，从微服务的角度出发，涵盖流量治理、服务容错与自愈、服务元信息治理、安全治理等关键治理领域，提供一系列的治理能力与标准、生态适配与最佳实践，支持 Java, Go, Rust 等多语言生态。

OpenSergo 的最大特点就是以统一的一套配置/DSL/协议定义服务治理规则，面向多语言异构化架构，覆盖微服务框架及上下游关联组件。无论微服务的语言是 Java, Go, Node.js 还是其它语言，无论是标准微服务还是 Mesh 接入，从网关到微服务调用，再到微服务对数据库/缓存的访问，开发者都可以通过同一套 OpenSergo CRD 标准配置进行统一的治理管控，而无需关注各框架、语言的差异点，降低异构化、全链路微服务治理管控的复杂度。

OpenSergo 涵盖的微服务治理关键领域：

流量治理与服务容错：流量路由、流量染色、全链路灰度、流量防护与自愈（流量控制、服务熔断、容错防抖）
微服务视角的数据库与缓存治理：端侧连接池治理、读写流量路由、SQL 流控等
服务元信息与服务发现

OpenSergo 提供 Java、Go 等多语言的 SDK，各个框架生态可以非常方便地通过 OpenSergo SDK 来对接 OpenSergo 标准配置，接入到 OpenSergo 生态中，通过 OpenSergo 控制平面 (Control Plane) 统一管理服务治理规则。

为什么需要流量防护与容错？

微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化，服务之间的依赖关系变得越来越复杂，业务系统也面临着巨大的高可用挑战。大家可能都经历过以下的场景：

演唱会抢票瞬间洪峰流量导致系统超出最大负载，load 飙高，用户无法正常下单；
在线选课时同一时刻提交选课的请求过多，系统无法响应；
页面服务中某一块内容访问很慢，一直加载不出来，导致整个页面都卡住，无法正常操作

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

服务自身流量超过承载能力导致不可用。比如激增流量、批量任务投递导致服务负载飙高，无法正常处理请求。
服务因依赖其他不可用服务，导致自身连环不可用。比如我们的服务可能依赖好几个第三方服务，假设某个支付服务出现异常，调用非常慢，而调用端又没有有效地进行预防与处理，则调用端的线程池会被占满，影响服务自身正常运转。在分布式系统中，调用关系是网状的、错综复杂的，某个服务出现故障可能会导致级联反应，导致整个链路不可用。

在遇到这些微服务运行时稳定性的问题时，我们应该如何解决呢？针对这些不稳定的场景，阿里巴巴开源的 Sentinel 提供全方位的流量防护能力，以流量为切入点，从流量控制、并发控制、不稳定服务熔断、热点防护、系统自适应过载保护等多个维度来帮助保障服务的稳定性，覆盖微服务框架、云原生网关、Service Mesh 等几大场景，原生支持 Java、Go、C++、Rust 等多种语言的异构微服务架构。

Sentinel 底层基于精心设计的高性能毫秒级滑动窗口统计结构来实现百万 QPS 流量的精确统计，结合上层各个流量治理策略模块的组合来实现对不同维度的流量进行治理，同时支持灵活的扩展定制机制。

Sentinel 在阿里巴巴内部承载非常多的服务可用性与容错的场景，保障了近十年天猫双11流量峰值的稳定。在阿里云上，我们也在 MSE 微服务引擎产品中提供全方位的流量防护与治理能力，帮助大量企业保障微服务的稳定性。

OpenSergo 流量防护与容错标准

在 OpenSergo 中，我们结合 Sentinel 等框架的场景实践对流量防护与容错抽出标准 CRD。一个容错治理规则 (FaultToleranceRule) 由以下三部分组成：

Target: 针对什么样的请求。可以通过通用的 resourceKey（Sentinel 中即为资源名的概念）来标识，也可以用细化的规则来标识（如具有某个特定 HTTP header 的请求）；
Strategy: 容错或控制策略，如流控、熔断、并发控制、自适应过载保护、离群实例摘除等；
FallbackAction: 触发后的 fallback 行为，如返回某个错误或状态码。

无论是 Java 还是 Go 还是 Mesh 服务，无论是 HTTP 请求还是 RPC 调用，还是数据库 SQL 访问，我们都可以用这统一的容错治理规则 CRD 来给微服务架构中的每一环配置容错治理，来保障我们服务链路的稳定性。只要微服务框架适配了 OpenSergo，即可通过统一 CRD 的方式来进行流量防护等治理。

以下 YAML CR 示例定义的规则针对 path 为 /foo 的 HTTP 请求（用资源名标识）配置了一条流控策略，全局不超过 10 QPS。当策略触发时，被拒绝的请求将根据配置的 fallback 返回 429 状态码，返回信息为 Blocked by Sentinel，同时返回 header 中增加一个 header，key 为 X-Sentinel-Limit, value 为 foo。

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: HttpRequestFallbackAction
metadata:
  name: fallback-foo
spec:
  behavior: ReturnProvidedResponse
  behaviorDesc:
    # 触发策略控制后，HTTP 请求返回 429 状态码，同时携带指定的内容和 header.
    responseStatusCode: 429
    responseContentBody: "Blocked by Sentinel"
    responseAdditionalHeaders:
      - key: X-Sentinel-Limit
        value: "foo"
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: FaultToleranceRule
metadata:
  name: my-rule
  namespace: prod
  labels:
    app: my-app
spec:
  selector:
    app: foo-app # 规则配置生效的服务名
  targets:
    - targetResourceName: '/foo'
  strategies: 
    - name: rate-limit-foo
  fallbackAction: fallback-foo

Sentinel 原生支持 OpenSergo 流量防护与容错标准

Sentinel 2.0 品牌将升级为流量治理，并作为 OpenSergo 流量治理的标准实现。Sentinel 目前已原生支持 OpenSergo 流量防护与容错 spec（流控、匀速排队、熔断、并发控制等规则），结合 Sentinel 提供的各框架的适配模块，让 Dubbo, Spring Cloud Alibaba, gRPC 等 20+框架能够无缝接入到 OpenSergo 生态中，用统一的 CRD 来配置流控、异常熔断等治理规则。只要微服务框架适配了 Sentinel，即可通过统一 CRD 的方式来进行流量治理。

Sentinel 社区近期已提供 OpenSergo spec 初版适配，欢迎社区一起参与完善：

Sentinel Java OpenSergo data-source:https://github.com/alibaba/Sentinel/tree/master/sentinel-extension/sentinel-datasource-opensergo
Sentinel Go OpenSergo data-source (work-in-progress):https://github.com/alibaba/sentinel-golang/pull/489

Sentinel 利用 OpenSergo 多语言 SDK 来订阅指定应用的流量防护规则，结合 Sentinel 数据源扩展机制，来实现 OpenSergo 流量防护与容错 spec 的整合模块。

下面以 Java 社区为例，我们来演示一下如何在 Sentinel 接入 OpenSergo 数据源并通过 OpenSergo Control Plane 动态配置流控规则。目前 OpenSergo Control Plane 支持部署在 Kubernetes 集群中，通过 OpenSergo CRD 来管理规则。

第一步：首先我们先在 Kubernetes 集群中安装 OpenSergo CRD，并在 Kubernetes 中部署 OpenSergo Control Plane 实例。具体步骤可以参考 OpenSergo Control Plane 项目的文档。

第二步：假定我们是一个 Spring Boot Web 项目，已接入 Sentinel。我们在项目中引入 sentinel-datasource-opensergo 数据源模块：

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-opensergo</artifactId>
    <!-- 对应 Sentinel 1.8.6 版本 -->
    <version>0.1.0-beta</version>
</dependency>

第三步：在项目合适的位置（如 Spring 初始化 hook 或 Sentinel InitFunc 中）中创建并注册 Sentinel OpenSergo 数据源：

// 传入 OpenSergo Control Plane 的 endpoint，以及希望监听的应用名.
// 在我们的例子中，假定应用名为 foo-app
OpenSergoDataSourceGroup openSergo = new OpenSergoDataSourceGroup("localhost", 10246, "default", "foo-app");
// 初始化 OpenSergo 数据源.
openSergo.start();
// 订阅 OpenSergo 流控规则，并注册数据源到 Sentinel 流控规则数据源中.
FlowRuleManager.register2Property(openSergo.subscribeFlowRules());

第四步：启动应用，访问项目中的 Web 接口，在没有配置规则的情况下应该一直返回正常结果。接下来我们按 OpenSergo CRD 的方式针对 /foo 这个 Web 接口配置一个 QPS=2 的流控规则：

apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: RateLimitStrategy
metadata:
  name: rate-limit-foo
  labels:
    app: foo-app
spec:
  metricType: RequestAmount
  limitMode: Local
  threshold: 2
  statDurationSeconds: 1
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: FaultToleranceRule
metadata:
  name: my-opensergo-rule-1
  labels:
    app: foo-app
spec:
  targets:
    # 这里对应 Sentinel 的资源名，根据实际情况填写
    - targetResourceName: '/foo'
  strategies:
    - name: rate-limit-foo
      kind: RateLimitStrategy

我们将这个配置保存为 YAML 文件，然后通过 kubectl apply 到集群中。我们查看 Sentinel 日志目录（默认目录为 ~/logs/csp）下的 sentinel-record.log，可以看到规则已经成功下发到 Sentinel 侧。

2022-10-26 14:26:59.390 INFO Subscribing OpenSergo base fault-tolerance rules for target <default, foo-app>
2022-10-26 14:26:59.391 INFO Subscribing OpenSergo config for target: SubscribeKey{namespace='default', app='foo-app', kind=RATE_LIMIT_STRATEGY}
2022-10-26 14:27:59.552 INFO [FlowRuleManager] Flow rules received: {/foo=[FlowRule{resource=/foo, limitApp=default, grade=1, count=2.0, strategy=0, refResource=null, controlBehavior=0, warmUpPeriodSec=10, maxQueueingTimeMs=500, clusterMode=false, clusterConfig=null, controller=com.alibaba.csp.sentinel.slots.block.flow.controller.DefaultController@4bbadef7}]}

同时我们再去连续触发 /foo 这个 Web 接口，可以看到，同一秒前两次请求是正常通过的，后面的请求会被拒绝，拒绝效果为默认的 429 返回。

后续 Sentinel 2.0 也会支持通过 OpenSergo FallbackAction CRD 来动态配置 fallback 行为，比如指定返回值与返回状态码等，无需代码编写逻辑。

展望

流量防护与容错是微服务流量治理中的重要的一环，同时 OpenSergo 还提供更广范围、更多场景的微服务治理标准与最佳实践，包括流量路由、流量染色、微服务视角的数据库治理、日志治理等一系列的微服务治理能力与场景。服务治理是微服务改造深入到一定阶段之后的必经之路，是将微服务做稳做好的关键。

同时我们也在与 CloudWeGo、Kratos、Spring Cloud Alibaba、Dubbo、ShardingSphere、Database Mesh 等社区共同建设 OpenSergo 微服务治理标准，将企业与社区中微服务治理的场景与最佳实践共同提取成标准规范，也欢迎更多社区与企业一起参与 OpenSergo 微服务治理标准的共建。

OpenSergo 社区现在处于高速发展阶段，从微服务治理标准定义，到 Control Plane 的实现，再到 Java/Go/C++/Rust 等多语言 SDK 与治理功能的实现，再到各个微服务生态的整合与落地，都还有大量的演进工作，欢迎社区一起参与标准完善与代码贡献。