作者：宿何&卜比

OpenSergo 是什么

在传统微服务架构中，咱们将服务调用中各人物分为四大块：服务供给者、服务消费者、注册中心、监控。跟着分布式服务架构的不断演进带来诸多杂乱的稳定性与易用性问题，单一的监控已无法满意架构的演进。在现代微服务架构中，咱们需要一些手法来对杂乱的微服务架构进行“办理”。微服务办理便是经过全链路灰度、无损上下线、流控降级、反常流量调度、数据库办理等技术手法来减少乃至避免发布和办理大规模运用过程中遇到的稳定性问题，对微服务范畴中的各个组件进行办理。服务供给者、消费者、注册中心、服务办理，构成现代微服务架构中重要的几环。

OpenSergo 即将发布 v1alpha1，丰富全链路异构架构的服务治理能力

在企业界部，往往存在着不同言语、不同通信协议的微服务，这种异构化的架构会导致办理微服务的过程中，事务开发者、架构师无法用一致的方法来对一切服务进行办理管控，而且这类异构会衍生出更多的痛点：

  • 业界对服务办理的才能和鸿沟没有清晰的认识，每个企业所界说的服务办理概念不一致，造成很高的理解和沟通本钱。

  • 开源微服务结构很多，关于服务办理缺乏一些规范化的约好。例如，Spring Cloud 中界说的微服务接口和 Dubbo 中界说的接口就没有办法互通，经过 Dubbo 和 Istio 办理的微服务也没有办法进行一致办理。开发者无法经过一致的装备方法来对不同结构、不同言语的服务进行一致办理管控。

  • 短少真正面向事务、可以减轻认知担负的笼统和规范。开发者真正想要的可能是简单的、指定服务间的调用关系和装备规矩。但现在关于事务开发者来说，不只需要了解不同微服务结构的布置架构，也要了解不同服务办理方法的概念和才能区别，认知本钱很大。

依据上面这些痛点，阿里巴巴在 2022 年 1 月开始和 bilibili、字节等厂商讨论服务办理怎么规范化和更加遍及，然后一起发起了 OpenSergo 项目。OpenSergo 是一套开放、通用的、面向分布式服务架构、掩盖全链路异构化生态的服务办理规范，依据业界服务办理场景与实践形成服务办理通用规范。

OpenSergo 的最大特点便是以一致的一套装备/DSL/协议界说服务办理规矩，面向多言语异构化架构，做到全链路生态掩盖。 不管微服务的言语是 Java, Go, Node.js 仍是其它言语，不管是规范微服务仍是 Mesh 接入，从网关到微服务，从数据库到缓存，从服务注册发现到装备，开发者都可以经过同一套 OpenSergo CRD 规范装备针对每一层进行一致的办理管控，而无需重视各结构、言语的差异点，下降异构化、全链路服务办理管控的杂乱度。

OpenSergo 即将发布 v1alpha1，丰富全链路异构架构的服务治理能力

OpenSergo 规范依据微服务办理中相关范畴的实践与场景笼统，掩盖了服务元信息、流量办理、服务容错、数据库/缓存办理、服务注册发现、装备办理等十几个关键范畴，掩盖了完好的微服务生命周期（从开发态到测验态，到发布态，再到运转态）。不管咱们是希望针对 Spring Cloud + Dubbo 服务链路装备流量灰度隔离，仍是希望针对一个 Go gRPC 服务进行流量操控，仍是希望针对服务拜访数据库的慢 SQL 调用进行自动熔断，咱们都可以运用 OpenSergo spec 中界说的 CRD 规范来进行一致装备，而无需重视各结构不同的声明式 API 及互不兼容的装备格式。

OpenSergo 即将发布 v1alpha1，丰富全链路异构架构的服务治理能力

OpenSergo 生态由以下几部分组成：

  • OpenSergo spec：一致的服务协议与 CRD 规范界说
  • OpenSergo 多言语 SDK：供给一致的规范 CRD 对接模块，供各个结构组件对接 OpenSergo spec
  • OpenSergo 数据面：即对接 OpenSergo spec 的结构组件，均可经过 OpenSergo 规范方法进行一致办理
  • OpenSergo 操控面：供给一致的操控台来进行服务元信息查询以及流量路由、流量操控等办理规矩装备。

咱们期望与各个社区进行协作共建，将更多的结构与组件对接到 OpenSergo 生态中，每个结构都是 OpenSergo 的数据面，可以经过 OpenSergo CRD 进行一致办理管控。

那么 OpenSergo 规范到底是什么姿态的呢？咱们可以运用 OpenSergo 规范来做哪些事情呢？下面咱们来结合几个例子来进行介绍。

OpenSergo 规范介绍

OpenSergo 项目涵盖服务元信息、服务注册发现、流量办理、服务容错、数据库办理、缓存办理等范畴。在咱们的首个版别 v1alpha1 版别中，咱们供给了 服务契约（元数据）、流量路由、流控降级 这几个范畴的 CRD 规范。下面咱们来介绍一下流量路由与流控降级这两个范畴的示例。

流量路由

流量路由，望文生义便是将具有某些属性特征的流量，路由到指定的方针。流量路由是流量办理中重要的一环，咱们可以依据流量路由规范来完成各种场景，如全链路灰度、金丝雀发布、容灾路由等。

流量路由规矩(v1alpha1) 主要分为三部分：

  • Workload 标签规矩 (WorkloadLabelRule)：将某一组 workload（如 Kubernetes Deployment, Statefulset 或者一组 pod，或某个 JVM 进程，乃至是一组 DB 实例）打上对应的标签
  • 流量标签规矩 (TrafficLabelRule)：将具有某些属性特征的流量，打上对应的标签
  • 依照 Workload 标签和流量标签来做匹配路由，将带有指定标签的流量路由到匹配的 workload 中

咱们以广泛运用的全链路灰度场景为例。全链路灰度经过一系列的流量路由规矩，将链路上的多个服务的相同版别划分到同一个泳道中，然后束缚流量只在指定泳道中流通，完成全链路的流量隔离的意图。

整个流程可以用下图归纳，咱们经过通用的 Workload 标签规矩与流量标签规矩，来以一致的规范方法对完好的服务链路完成灰度的才能。

OpenSergo 即将发布 v1alpha1，丰富全链路异构架构的服务治理能力

给 Workload 打标签：

咱们对新版别进行灰度时，一般会有单独的环境，单独的布置集。咱们将单独的布置集打上 gray 标签（标签值可自界说），标签会参加到详细的流量路由中。

咱们可以经过直接在 Kubernetes workload 上打 label 的方法进行标签绑定，如在 Deployment 上打上 traffic.opensergo.io/label: gray标签代表灰度。关于一些杂乱的 workload 打标场景（如数据库实例、缓存实例标签），咱们可以运用 WorkloadLabelRule CRD 进行打标。示例：

apiVersion: traffic.opensergo.io/v1alpha1
kind: WorkloadLabelRule
metadata:
  name: gray-sts-label-rule
spec:
  workloadLabels: ['gray']
  selector:
    app: my-app-gray
    database: 'foo_db'

给流量打标：

假设现在需要将内部测验用户灰度到新版主页，测验用户 uid=12345，UID 坐落 X-User-Id header 中，那么只需要装备如下 CRD 即可：

apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficLabelRule
metadata:
  name: my-traffic-label-rule
  labels:
    app: my-app
spec:
  selector:
    app: my-app
  trafficLabel: gray
  match:
  - condition: "=="    # 匹配表达式
    type: header       # 匹配属性类型
    key: 'X-User-Id'   # 参数名
    value: 12345       # 参数值
  - condition: "=="
    value: "/index"
    type: path

经过上述装备，咱们可以将 path 为 /index，且 uid header 为 12345 的 HTTP 流量，打上 gray 标，代表这个流量为灰度流量。

依照标签来路由：

在详细的路由过程中，接入了 OpenSergo 的微服务结构、Service Mesh 的 proxy 中，只需完成了 OpenSergo 规范并进行上述规矩装备，那么就能识别流量的标签和 workload 的标签。带 gray 标签的流量就会流通到 gray 标签的实例分组中；如果集群中没有 gray 实例分组（即没有 workload 带有这个标签），则默认 fallback 到没有标签的实例上。后续版别规范将供给未匹配流量的兜底装备方法。

社区还在不断完善流量路由相关的规范，并与各个社区协作共建，让更多的结构组件支撑 OpenSergo 规范，然后支撑一致的流量路由管控。

流控降级与容错

流控降级与容错同样是服务流量办理中关键的一环，以流量为切入点，经过流控、熔断降级、流量平滑、自适应过载维护等手法来保证服务的稳定性。在 OpenSergo 中，咱们结合 Sentinel 等结构的场景实践对流控降级与容错抽出规范 CRD。一个容错办理规矩 (FaultToleranceRule) 由以下三部分组成：

  • Target: 针对什么样的恳求
  • Strategy: 容错或操控战略，如流控、熔断、并发操控、自适应过载维护、离群实例去除等
  • FallbackAction: 触发后的 fallback 行为，如返回某个错误或状况码

OpenSergo 即将发布 v1alpha1，丰富全链路异构架构的服务治理能力

不管是 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:
  targets:
    - targetResourceName: '/foo'
  strategies: 
    - name: rate-limit-foo
  fallbackAction: fallback-foo

在中间件开发者峰会中，咱们宣告了 Sentinel 2.0 流量办理的全面升级。Sentinel 2.0 将原生支撑流量办理相关 CRD 装备，结合 Sentinel 供给的各结构的适配模块，让 Dubbo, Spring Cloud Alibaba, gRPC 等20+结构可以无缝接入到 OpenSergo 生态中，用一致的 CRD 来装备流量路由、流控降级、服务容错等办理规矩。

社区规划

让异构微服务可以用一致的服务协议与装备方法进行办理、让更多微服务可以互联互通，塑造更加云原生的微服务，是 OpenSergo 建立之初就树立的长期开展方针。

在规范化建造上，OpenSergo 社区会联合更多开源社区与企业，在数据库办理、缓存办理、服务注册发现、装备办理等更多范畴层面上规范化微服务办理才能，让企业可以用一套通用言语来描绘和办理自己的微服务架构，让开发者专注于事务核心价值，让微服务结构也可以被客户轻松选用。

在社区生态建造上，OpenSergo 社区将逐步掩盖从网关、RPC、数据库、缓存到服务发现、服务装备等分布式服务链路中的每一环生态，经过与各社区协作，让各主流结构均可以借助一致的 OpenSergo spec 来界说与完成服务办理的才能，开发者无需重视各结构、协议的概念与完成差异，下降开发者跨言语、跨结构、跨协议层面服务办理的管控本钱。OpenSergo 社区将继续与 Kratos、CloudWeGo Kitex、Spring Cloud Alibaba、Dubbo 等社区进行协作，一起也会推进与 Apache APISIX、Envoy/Istio、gRPC、Druid、ShardingSphere 等更多社区的协作，将规范落地到各个结构中。咱们也非常欢迎更多开源社区与企业一起参加 OpenSergo 的规范与生态共建。

在操控面建造上，OpenSergo 目前正在联合社区打造 OpenSergo Dashboard 作为一致的服务办理操控面，经过中立、通用的 OpenSergo 规范协议，让一切的微服务结构、一切的通信协议都可以被同一套微服务门户来办理。

OpenSergo 即将发布 v1alpha1，丰富全链路异构架构的服务治理能力

欢迎参加

OpenSergo 自创建便是社区项目，经过 Apache License 2.0 协议开源。OpenSergo 正在与 Apache Dubbo, CloudWeGo Kitex (字节), Kratos (bilibili), Spring Cloud Alibaba, Apache APISIX 等社区进行协作，一起完善服务办理规范规划与完成，一起将 OpenSergo spec 推进和落地到更多微服务生态中。后续在 OpenSergo 服务办理规范的拟定、开展上，也会经过公开、透明、民主的方法来拟定规范、推进施行。社区也经过 GitHub issue、Gitter、邮件列表、社区双周会等机制，保证经过社区协作的方法来共建规范与完成。欢迎咱们经过这些形式一起来讨论、共建。

也欢迎咱们钉钉扫码参加 OpenSergo 社区钉钉群，一起来界说微服务办理的未来：

OpenSergo 即将发布 v1alpha1，丰富全链路异构架构的服务治理能力

一起咱们在阿里云也供给 OpenSergo 微服务规范的企业级产品 MSE，供给服务办理、流控降级、注册装备中心、云原生网关、分布式事务等核心才能，欢迎咱们体验。

相关链接：

OpenSergo 项目官网：

opensergo.io/

OpenSergo spec:

github.com/opensergo/o…

阿里云微服务引擎 MSE，OpenSergo 的企业级完成：

www.aliyun.com/product/ali…

MSE 注册装备中心专业版首购享 9 折优惠，MSE 云原生网关预付费全规格享 9 折优惠。

点击此处，即享优惠~