关于阿里云:天猫双11背后的流量治理技术与标准实践

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

一年一度的天猫双 11 曾经落下帷幕，大家在疯狂买买买的过程中肯定会有疑难：如何保障微服务在双十一的超级峰值下也能如丝般顺滑稳固？这背地的技术原理是怎么的，有没有一些最佳实际与规范？这篇文章就为大家介绍如何联合 Sentinel 与 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 中，咱们联合 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/Se…
Sentinel Go OpenSergo data-source (work-in-progress):https://github.com/alibaba/se…

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 与治理性能的实现，再到各个微服务生态的整合与落地，都还有大量的演进工作，欢送社区一起参加规范欠缺与代码奉献。

OpenSergo 开源奉献小组正在炽热招募贡献者。如果您有工夫，有激情，有志愿，欢送分割社区退出开源奉献小组，一起独特欠缺 OpenSergo 和 Sentinel，一起主导微服务治理技术与规范演进。Now let’s start hacking!

欢送关注 OpenSergo 社区微信公众号，理解微服务治理社区最新动静。

相干链接：

Sentinel 我的项目官网：https://sentinelguard.io/zh-cn/
OpenSergo 我的项目官网：https://opensergo.io/zh-cn/
MSE Sentinel 流量治理：https://help.aliyun.com/docum…

关于阿里云:天猫双11背后的流量治理技术与标准实践

OpenSergo 是什么？

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

OpenSergo 流量防护与容错规范

Sentinel 原生反对 OpenSergo 流量防护与容错规范

瞻望