作者：Jiahuan He，阿里云MSE研发工程师。
在现代微服务架构中，我们将系统分解为一系列服务，并通过远程过程调用将它们连接在一起，从而带来了一些优势和挑战。
如上图所示，词云展示了当前微服务架构在生产中遇到的挑战。 例如，在流量激增最常见的场景中，AIGC在过去一年中突然爆发，相关服务因流量激增而无法使用，这可能会导致我们错过最佳增长窗口。
再比如缺乏容错机制，某***的某项服务异常会随着调用链的传播而蔓延，导致全站入口不可用，影响数千万用户，产生重大经济损失。 这些生产故障的频繁发生，也提醒着我们稳定性是善用微服务的主要挑战之一。
为了保证微服务的稳定性，我们需要做一些架构演进。
我们来看一下左边的3大微服务，我们已经很熟悉了，通过这三者的配合，我们的应用可以正常使用，但是在生产可用之前还有很长的路要走，各个企业和社区为了消除距离，有一些探索和实践， 比如 Dubbo 社区在 Dubbo3 中引入了流量管理和高可用等一系列能力来保证微服务的稳定性，这些措施可以统称为微服务治理。
所以其实大家都已经意识到，微服务治理是从微服务运行到实际生产微服务不可或缺的一环。 然而，微服务治理应该做什么以及如何去做，还比较模糊。
从软件生命周期的角度来看，我们可以将微服务治理分为三个领域开发状态、测试状态、更改状态和操作状态。
例如，我们可以通过上线和下线来解决有损释放问题，通过灰度控制变化的影响面，对不确定的流量使用流量控制和热点保护，对不稳定的调用使用熔断和隔离。
您可以看到，有一些成熟的方案和实践在每个领域都运行良好。 但是，无论是阿里巴巴还是其他公司，在系统地实施微服务治理时，都会存在很多问题。
首先，我们涉及到的组件很多，在微服务架构中，我们需要有像 Dubbo 这样的调用框架，像 Nacos 这样的注册中心，像 Sentinel、Hystrix 这样的稳定性中间件，这些组件无法统一治理，控制成本会变得非常高。
二是概念不统一，比如 Envoy 中的隔离和 Sentinel 中的隔离不一样，Envoy 的隔离是为了去除不健康的实例，而 Sentinel 的隔离是并发控制，这会让开发者理解起来非常昂贵。
同时，每个商业社区都有自己的最佳实践，这导致了能力的错位和没有统一的标准。
例如，Sentinel、Hystrix、Istio 都有融合的能力，但配置不同，开发者需要单独学习习，也要注意不要混淆，不利于理解和统一把控。
可以发现，由于这些问题，我们在实现系统化的微服务治理时会遇到很大的阻力我们需要的是一个统一的治理接口，以便我们更好地管理微服务，因此我们提出了 opensergo 项目。
OpenSergo 期望提出一套开放通用的、面向云原生架构的微服务治理解决方案和标准，以帮助保障微服务的高可用性，上图的四个部分是 OpenSergo 社区的愿景。
OpenSergo 社区会基于业界的微服务治理场景和实践，抽象成规范，以解决上述概念、配置、能力不一致的问题，并使用统一的控制面进行承载，降低使用和维护成本。
同时，纵向上，我们抽象出链路上的每一个环节，覆盖整个场景，横向上，无论是J**a生态、GO生态还是其他语言，无论是传统的微服务还是网格架构，都会被纳入到这个统一的体系中。
但是，作为一个开放标准，OpenSergo还不足以单靠阿里，所以我们联合哔哩哔哩、中国移动等多家公司和社区，共同构建了这套开放标准，希望能真正解决微服务稳定性的风险。
接下来，我们简单介绍一下 OpenSergo 的架构如前所述，OpenSergo 社区会基于场景对 OpenSergo 规范进行抽象，但这只是第一步，为了承载这些标准规范，我们需要一个控制平面，社区选择从 0 开始开发一个控制平面来做初始演进中治理规则的控制、监控和交付。
但是，随着社区的演进，我们发现基于 Istio 的扩容成本更低，可以复用更多的能力，因此在后续的演进中，我们会选择将 Istio 扩展控制面和决策中心相结合，实现对治理规则的统一控制和治理策略的预计算。
有了控制面之后，我们还需要数据面来实现特定的治理能力，可以是 Sentinel 等中间件，也可以是框架本身。 在最初的架构中，控制面和数据面之间的通信是基于 grpc 构建的链接，但在确定未来的演进方向将基于 Istio 扩展后，社区选择拥抱 XDS 并尽可能地为其链接提供服务，然后使用我们自己的 grpc 链接来承载一些无法承载的链接。
如前所述，社区控制面的后续演进是基于 Istio 的扩展，Istio 本身也具备一定的流量治理能力，具有一定的普及度。 但是，Istio 主要关注的是流量管理，将流量获取到需要去的地方，而不是微服务治理，因此在微服务稳定性的场景下，Istio 提供的这些能力并不足以满足我们的需求。
因此，在 Istio 的基础上，基于微服务稳定性的一些场景，比如上面提到的变更状态稳定性和运行时稳定性，我们制定了满足要求的规范和标准，希望更适合微服务场景。 因此，作为一个整体，我们将在微服务治理领域成为 Istio 的超集，而不是互斥锁。
让我们看一下 OpenSergo 标准规范如何解决上述场景。
首先，我们来谈谈流量路由，它的主要作用是将满足某些特征的流量路由到指定的工作负载，一般大家都会利用这种能力来实现灰度、同区路由等方案。
基于 Istio VirtualService DestinationRule 的格式社区定义了流量路由规范，但在研究和实践的过程中，我们发现它并不能很好地满足微服务场景的需求。 因此，为了更贴近微服务场景，我们做了扩展。 例如，我们添加了处理路由失败的逻辑，这是微服务架构中的常见要求。
由于 Istio 的主要关注点是 HTTP 请求，因此它的 CRD 不能像 Dubbo 那样很好地处理 RPC 调用，因此我们为此添加了更多的 RPC 模型支持。 未来，我们还将探索与社区标准集成的解决方案，使我们的规范更加通用和标准。
在阿里巴巴集团内部多年的安全生产实践中，灰度被定义为安全变革的三板轴，与监控和回滚并列，其中灰度是控制变革影响、保证变革稳定性不可或缺的能力。
为了实现灰度，我们通常有几种解决方案，第一种是物理隔离，我们部署两套相同的环境来实现灰度，但是这种解决方案的部署和维护成本很高。
为了提高资源利用率，应运而生第二种解决方案是流量灰度。 我们没有单独部署环境，而是在每一跳流量时匹配流量特征，并决定是去灰度实例还是基础实例，这比前者更灵活、更高效，可以通过上面提到的流量路由能力来实现。 但是，我们需要在每跳配置路由规则，比较繁琐。
而且由于后续环节中无法获取到某些信息，比如uid，所以这个方案的实现有一定的难度。 事情就是这样第三种方案是全链路灰度通过在流量入口处匹配流量并标记标签，标签将沿着呼叫链路自动透明传输，后续链路将根据标签进行路由。 通过这种方式，我们能够更简洁地定义灰度。 OpenSergo 为此场景抽象了相应的 CRD。
我们把这个叫做crd车道，也就是泳道，我觉得比较生动，你看上面的**，橙色是正常的交通方向，灰色是灰色的交通方向，就像把一个游泳池分成多个泳道一样。
泳道的CRD由三部分组成，也很容易理解，首先我们需要匹配灰度流量，所以我们需要定义匹配条件，然后定义这些流量用什么标签来标记，最后定义这个标签是如何透明传输的。
有了这个 crd，我们定义了一个灰度泳道。 但是，如果单靠清晰度还不足以实现全通道灰度，我们还需要利用OpenSergo系统的全链路全方位框架的支持，使标签在这些框架中自动透明传输，这些框架也可以通过标签进行路由。 其中，流量染色和标签透传将借助OpenTelemetry等标准TRCAE系统实现。
上图右侧是 CRD 的示例，您可以简要了解一下。
接下来，我们来看一下运行时稳定性的场景。
我们主要提到两种情况第一种是流量激增的场景例如，在双11限时抢购活动中，系统在开始时流量稳定时也处于稳定状态。 但是，当流量激增时，系统会开始向不稳定的方向发展，异常呼叫也会激增，最终变得不可用。 对于此类场景，我们可以利用流量控制能力拒绝超出容量的请求，或者利用流量平滑能力来剔除波峰波谷，使流量保持在相对稳定的状态，避免业务不可用。
第二种情况是不稳定的调用导致服务不可用例如，我们在调用一些第三方服务时，经常会出现不稳定的情况，这里的不稳定主要是指异常或调用缓慢。 以 dubbo 为例，当服务提供者进行慢速调用时，会导致线程在服务消费者身上堆积，从而影响其他正常调用乃至整个服务的稳定性，而这种风险会沿着调用链传递和扩散，最终影响整个系统的稳定性。 在这种情况下，我们可以使用并发控制或熔断保护来限制慢调用对资源的占用，保证系统的整体稳定性。
针对前面提到的这些场景，OpenSergo 也制定了相关的 CRD。 在行业实践中，圣天诺是一个成熟的流量防护解决方案，在阿里巴巴内部积累了大量与流量防护相关的场景和实践，并在2024年开源后进一步丰富了这些行业积累，我们从这些积累中抽象出一套流量防护规范和标准。
因此，您可以简要考虑一量保护规则应包含哪些内容。
我们首先需要确定的是要定位什么样的流量，我们可以按接口划分，也可以根据请求中的特征进行划分。 一旦我们制定了目标，我们就需要定义我们想要采用什么样的治理策略。 这里的策略包括上面提到的策略，以及高阶策略，如自过载保护。
最后，因为限速本身是有损的，但是我们不希望这种有损的传递给用户端，我们需要针对不同的规则配置不同的行为，这样对用户端的性能更加友好，比如最基本的限速对于抢购场景，我们可以返回一个队列， 请稍后提示。
上图右侧是 CRD 示例，其中流量目标为接口名称为 foo 的请求，策略为阈值为 10 的全局限制，回退为特定的返回正文。
通过这个 CRD 配置，无论是 Dubbo 框架还是其他框架，我们都可以轻松使用流量保护能力。
对于框架开发者来说，其实有两种方法可以集成到 OpenSergo 系统中：
一种是通过对接OpenSergo系统的数据面进行接入，框架开发者只需要实现对接模块与Sentinel对接即可完成对接工作。 对于有特殊要求或更接近特定场景的框架，也可以对接 OpenSergo 标准接入 OpenSergo 系统。
对于用户来说，不管是哪种方式，只需要简单地引入一些依赖，就可以在不知不觉中获取OpenSergo定义的微服务治理能力，就可以在统一的控制面上控制这些框架的微服务治理能力，大大提升了使用微服务治理的体验和效率。 说完访问方法，我们再来看看实现的效果。
第一种做法是全链路灰度控制，以消除状态稳定性变化的风险。 这是一个简单的 demo，我们只需要部署这样一个 crd，定义一个 dubbo 请求，当它的参数出现 name=xiaoming 时，我们会将其定向到灰度环境，对于不符合要求的流量，我们还是会去基线环境，我们可以看到当前的请求方向符合我们的预期。
但是，我们的生产环境将比演示复杂得多，并且会涉及各种框架，例如 Rokcetmq 和 Spring Cloud Alibabab。 但是，只要这些框架连接到OpenSergo系统，就可以利用这个CRD来实现全链路和全框架灰度。
第二种做法是流量保护和容错，保证运行时的稳定性——不稳定的调用场景。 这里使用一个简单的 demo，其中应用程序 A 通过 dubbo 调用应用程序 B。 右侧是正常和慢速调用接口的流量图，紫色流量为总流量，黄色为拒绝流量，橙色为异常流量。 刚开始时，没有发生慢呼叫，系统处于稳定状态，没有出现异常流量。
在第一个时间点，我手动调整了慢调用接口的 RT，出现慢调用，出现了异常流量，同时，由于慢调用占用了 dubbo 的大量线程资源，正常调用的资源被挤占，也出现了大量的异常流量， 并且 Dubbo 端的线程池已经耗尽。
你可以想一想，在这个场景下我们应该配置什么规则来解决这个问题，其实这个时候，很多人都会想做流量控制来限制流量，希望能解决这个问题，我们来看看它的其中一个效果。
第二次配置了限速规则，可以看到虽然情况有所缓解，但还是有大量的错误，因为在慢调用场景下，请求已经堆积起来了，只有通过QPS限流还是会造成请求的进一步积累。
所以我们真正需要的是并发控制，在第三个时间点我配置并发控制规则来限制慢调用接口的并发数，也就是正在处理的请求数。 可以看出，通过这个限制，即使慢调用仍然存在，但其能占用的线程资源是有限的，正常接口可以正常调用，从而避免了稳定性风险的扩大，保证了应用的稳定性。
第三种做法是流量保护和容错，以保证运行的稳定性——自适应过载保护。 可以看出，在我们 Demo 的持续高负载下，异常流量开始逐渐上升，系统的稳态被破坏，因此我们可以通过配置自适应过载保护规则来调整限流行为，以排除异常请求，帮助系统恢复到稳态。
我们已经在开源中支持 BBR，并在内部实践中使用 PID。 这里我就不赘述这些策略了，但如果你有兴趣，可以到我们的开源社区参与讨论。
从这三个例子可以看出，Dubbo 通过与 Sentinel 对接 OpenSergo 系统后，具备了 OpenSergo 定义的通用治理能力，可以通过统一的控制面进行控制。
其他框架也是如此，试想一下，如果我们生产中涉及的所有框架都接入了 OpenSergo 系统，那么我们可以在一个控制平面上控制所有服务，所有框架的微服务治理能力可以更好的保证系统的稳定性。
这是多语言服务治理生态系统的大图景。 在生态方面，我们希望 OpenSergo 是一个全链路的多语言异构，我们将主要关注 J**A Go + Gateway + Mesh 生态，并持续覆盖生态中的更多框架。
在能力上，我们将继续抽象和实现更通用的微服务治理能力。 这包括流量保护、自我修复、容错和业务认证。
目前，我们已经与许多社区建立了联系与合作，如Dubbo、Shenyu、APISIX、Higress、RocketMQ、Mosn等，其中许多社区已经取得了一些实质性的进展。
让我们分享一下我们在不久的将来的计划。
在控制面方面，我们将逐步将 control plane 推向生产，并在明年 3 月发布 GA 版本，让大家在生产中验证微服务治理系统。 规格方面，我们将支持微服务安全治理、异常值实例删除以及与社区标准的持续集成。 治理能力的演变我们将重点介绍哨兵 20 升级流量治理，向安全适配方向探索。 在社区合作方面，我们将持续推进与社区的交流与合作，推动各微服务治理领域的生态落地，统一控制面，共同构建SPEC。
虽然阿里巴巴在集团和云上积累了大量的经验和场景，但稳定性问题复杂，场景多样，仅靠一方不足以覆盖所有稳定场景，也不足以成为标准，因此微服务治理技术、生态化、标准化的演进也需要各企业和社区的共同参与。
您可以通过三种方式参与社区活动。
在微服务治理的规范中，每个社区和企业都是各自领域的领跑者，大家可以根据自己的场景和最佳实践，共同制定和完善标准和规范。 作为一个控制平面，它实际上处于决策者的位置，在一定程度上具有整个系统的视角，在当前AI技术的热潮中有着广阔的前景。 你可以参与到服务治理能力的演进中来，也可以为各个社区和 OpenSergo 系统之间的连接贡献力量。 最后，我想说的是，微服务治理其实是一个非常广阔的平台，通过参与其中，你可以接触到各个领域的技术和场景，而不是局限于单一技术点的范围。 欢迎企业和社区同学加入开源贡献小组，引领下一代微服务技术体系演进