“天猫双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:github.com/alibaba/Sen…
Sentinel Go OpenSergo data-source (work-in-progress):github.com/alibaba/sen…

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 社区微信公众号，了解微服务办理社区最新动态。

“天猫双11”背后的流量治理技术与标准实践

OpenSergo 是什么？

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

OpenSergo 流量防护与容错规范

Sentinel 原生支撑 OpenSergo 流量防护与容错规范

展望

相关文章

Compose Desktop实战网易云桌面应用

阿里云 Serverless 异步任务处理系统在数据分析领域的应用

Moshi 真正意义上的完美解决Gson在kotlin中默认值空的问题

盘点｜2021最受开发者欢迎和最具行业影响力的文章

作者信息