Ecosystem on Apache Dubbo

OpenSergo & Dubbo 微服务治理最佳实践

Sat, 07 Oct 2023 00:00:00 +0000

摘要：本文整理自阿里云 MSE 研发工程师何家欢的分享。本篇内容主要分为四个部分：

一、Why 微服务治理？
二、OpenSergo：服务治理控制面与标准规范
三、OpenSergo & Dubbo 最佳实践
四、OpenSergo 的未来之路

一、Why 微服务治理？

现代的微服务架构里，我们通过将系统分解成一系列的服务并通过远程过程调用联接在一起，在带来一些优势的同时也为我们带来了一些挑战。

如上图所示，可以看到一个词云，这些都是目前微服务架构在生产上所遇到的挑战。比如，最常见的流量激增的场景，近一年内AIGC突然爆火，相关网站/服务都存在过因为激增流量导致服务不可用的情况，可能会让我们错过一个最佳的增长窗口。

再比如缺乏容错机制，某视频网站的某个服务异常，随调用链扩散，导致全站入口不可用，影响千万用户，产生实质性的经济损失。这些生产故障频频发生，也是在提醒我们稳定性是用好微服务的重大挑战之一。

为了保障微服务的稳定性，我们就需要做一些架构的演进。

我们先看一下左侧的微服务3大件，这个大家已经很熟悉了，通过这三者的配合，我们的应用就能够正常使用了，但是距离生产可用其实还有很大一段距离，各个企业和社区为了消除这其中的gap都有一些探索和实践，比如Dubbo社区在Dubbo3中引入一系列诸如流量管理、高可用性的能力来保障微服务的稳定性，这些措施可以统称为微服务治理。

所以其实大家已经意识到，从把微服务跑起来到真的生产可用，微服务治理是必不可少的一环。但微服务治理要做些什么，如何去做其实都还比较模糊。

从软件生命周期的角度，我们可以把微服务治理分成三个域，开发态与测试态、变更态、运行态。

在这三个域中都面临着很多挑战，对于这些挑战大家也有着一些探索和实践，比如对于发布有损的问题，我们可以通过无损上下线来解决，变更的影响面通过灰度来控制，对于不确定流量使用流控、热点防护，不稳定调用使用熔断与隔离。

可以看到在各个域中都有一些成熟的方案和效果很好的实践。但是不管是阿里还是其他公司，在体系化落地微服务治理时都会遇到很多问题。

二、OpenSergo：服务治理控制面与标准规范

首先我们涉及的组件有很多，在微服务架构中，往往会涉及很多组件，它们需要有Dubbo这样的调用框架，nacos这样注册中心，snetinel、hystrix这样的稳定性中间件等等，因此也没办法进行统一治理，管控成本就非常高。

其次时概念不统一，比如在envoy中的隔离与 sentinel中的隔离完全不是一个意思，envoy的隔离是摘除不健康实例，sentinel的隔离是并发控制，这就会使开发者理解成本很高。

同时各个企业社区都有自己的最佳实践，这也就导致大家能力上是不对齐的，没有统一的标准。

还有配置不统一的问题相信大家都很有体感，比如sentinel、hystrix、istio都有熔断的能力，但是配置却各有差别，需要开发者分别学习，还要注意不混淆，不利于理解，也不利于统一管控。

可以发现由于这些问题，我们在落地体系化微服务治理时会有很大的阻力，我们需要的是一个统一的治理界面来让我们更好地做微服务治理，因此我们提出了OpenSergo这个项目。

而OpenSergo期望提出一套开放通用的、面向云原生架构的微服务治理解决方案及标准规范，来助力保障微服务高可用，上图的四个部分就是OpenSergo社区的愿景。

OpenSergo社区会基于业界微服务治理场景与实践抽象成规范，通过这种方式去解决前面提到的概念、配置、能力不统一的问题，并用统一的管控面去承载，降低使用和维护成本。

同时在纵向上，我们针对链路上的每一环进行抽象，覆盖完整的场景，在横向上，无论是Java生态，Go生态或是其他语言，无论是传统微服务还是Mesh架构，都会纳入到这套统一的体系中。

但是OpenSergo作为一个开放标准，仅凭借阿里是不够的，所以我们联合了多家公司以及社区比如bilibili、中国移动、字节跳动的cloudwego社区等，共同建设这套开放标准，希望能够真正解决微服务稳定性的风险。

接下来简单介绍一下OpenSergo的架构体系，前面也介绍了OpenSergo社区会基于场景抽象出OpenSergo的Spec，但这只是第一步，为了承载这些标准规范我们就需要一个控制面，社区在一开始的演进中选择从0开始开发一个控制面来做治理规则的管控、监听与下发。

但是随着社区的演进，我们发现基于Istion去扩展，成本更低，也能够复用更多的能力，因此在后续的演进中我们会选择结合Istio扩展控制面与决策中心实现治理规则统一管控、治理策略预计算。

在有了控制面后我们还需要数据面来进行具体治理能力的实现，它可以是像sentinel这样的中间件，也可以是框架本身。控制面与数据面之间的通讯在初始的架构中是基于grpc构建的链路，但在确定了后续演进方向会基于istio扩展后，社区选择拥抱xds，尽可能服用它的链路，对于一些无法承载的我们再使用自身的grpc链路。

前面也提到社区控制面的后续演进是基于Istio扩展的，Istio本身也有一些流量治能力，并有着一定的普及度。但是Istio主要关注流量管理，让流量到达该去的地方而不是微服务治理治理，所以在微服务稳定性的场景下，Istio所提供的这些能力是不足以满足我们的需求的。

因此我们在Istio的基础上，基于微服务稳定性的一些场景，比如前面提到的变更态稳定性、运行时稳定性去抽象、制定了满足需求的规范标准，希望能够更加贴合微服务场景。所以整体上我们在微服务治理领域会是Istio的超集，而不是互斥关系。

接下来我们一起看一下OpenSergo的标准规范是如何解决前面所提到的这些场景。

首先我们聊一下流量路由，它的主要作用是将符合一定特征的流量路由到指定的workload上，一般大家会用这种能力来实现灰度、同AZ路由等方案。

基于 Istio VirtualService/DestinationRule 的格式社区定义了流量路由spec，但我们在调研以及实践的过程中发现，它并不能很好的满足微服务场景下的需求。所以为了更贴近微服务的场景去扩展去做了扩展。比如我们增加了路由失败后的处理逻辑，这在微服务架构中是很常见的需求。

又由于Istio主要关注的是HTTP请求，它的CRD不能够很好地承载像Dubbo这样的RPC调用，所以我们为此增加了更多RPC模型的支持。后续我们也会探索与社区标准结合的方案，使我们的Spec更加通用与标准。

前面所提到的灰度，在阿里集团内部数年的安全生产实践中，与可监控、可回滚一起被定义为安全变更的三板斧，其中灰度是控制变更影响面，保障变更稳定性的必不可少的能力。

为了实现灰度，我们通常有几种方案，第一种是物理隔离，我们通过部署两套一样的环境来实现灰度，但是这种方案的部署和维护成本都很高。

为了提高资源利用率，便产生了第二种方案，流量灰度。我们不部署独立的环境，而是在流量的每一跳进行流量的特征匹配，并且由此决定去往灰度实例还是base实例，这种方案相较与前者更加灵活高效，可以通过前面提到的流量路由能力来实现。但是需要我们在每一跳都配置路由规则，相对比较繁琐。

并且由于有些信息在后续链路是获取不到的，比如uid，导致这个方案的实施有一定的困难。于是便产生了第三种方案，全链路灰度，我们通过在流量入口处进行流量匹配并打上标签，标签会自动沿着调用链路透传，后续链路根据标签来进行路由。通过这种方式，我们就能够更简洁地去定义灰度。Opensergo针对这种场景抽象了对应的CRD。

我们将这个CRD称之为TrafficLane也就是泳道，我觉得还是比较形象的，大家看一下上边的图片，橙色的是正常的流量走向，灰色的是灰度流量的走向，就像是将一个池子分成了多个泳道。

泳道的CRD有三个部分组成，也比较好理解，首先我们需要去匹配灰度流量，所以就要去定义匹配的条件，然后定义为这些流量打上什么标签，最后再定义这个标签以什么方式去透传。

通过这样的CRD我们就定义了一条灰度泳道。但是如果只是定义是不足以实现全路灰度的，我们还需要借助OpenSergo体系全链路全方位框架的一个支持，才能让标签在这些框架中自动的透传，这些框架也能通过标签进行路由。其中流量染色和标签透传会借助标准的trcae体系去实现，比如OT。

上图右侧是一个CRD的例子，大家可以简单看一下。

接下来我们一起看一下运行态稳定性的场景。

我们主要提两个场景，第一个是流量激增的场景，比如双十一的秒杀活动，一开始流量是稳定的情况下，系统也处于稳态。但是当流量激增的时候，系统就会开始往不稳定的方向发展，异常调用也会激增，最后就会变成不可用的状态。对于这类场景，我们可以用流量控制的能力拒绝超出容量的请求，或是通过流量平滑的能力削峰填谷，让流量处于比较平稳的状态，避免服务的不可用。

第二个是不稳定调用导致服务不可用的场景，比如我们调用一些第三方服务经常会出现不稳定的情况，这里的不稳定主要指异常或是慢调用。以dubbo为例，当服务提供方出现慢调用的时候，会导致服务消费方的线程堆积，影响到其他的正常调用甚至是整个服务的稳定性，并且这种风险会沿着调用链反向传递、扩散最终影响整个系统的稳定性。这时我们可以通过并发控制或是熔断保护来限制慢调用对资源的占用，保障系统的整体稳定性。

针对前面提到的这些场景，OpenSergo也制定了相关的CRD。在业界的实践中sentinel是一个成熟的流量防护方案，在阿里内部积累了大量的流量防护相关的场景和实践，2018年开源依赖在业界进一步丰富了这些积累，我们从这些积累中抽象出了一套流量防护的规范标准。

Seata 微服务架构下的一站式分布式事务解决方案

Sat, 07 Oct 2023 00:00:00 +0000

摘要：本文整理自阿里云分布式事务产品负责人、Seata 开源项目创始人、微服务开源治理负责人季敏的分享。本篇内容主要分为三个部分：

一、微服务架构下数据一致性的挑战
二、分布式事务Seata的架构演进
三、如何基于Seata扩展RPC和数据库

一、微服务架构下数据一致性的挑战

在2019年，我们基于Dubbo Ecosystem Meetup，收集了2000多份关于"在微服务架构，哪些核心问题是开发者最关注的？“的调研问卷。最终分布式事务占比最大，有54%。

但在Seata出现之前，大家都说分布式事务能避就避，因为消息最终一致性去解释了问题。但Seata开源之后，这些问题都迎刃而解。比如无损上下限，到底是说服务的可用性还是其他的。对于我来说，我觉得它最终关注的是数据的问题。因为无论前端的业务怎么去交互，最终都会沉淀到数据。如果业务的数据不一致，前面是什么架构，都意义不太大，所以我认为数据是企业的核心资产。

那么到底哪些场景会遇到分布式事务的问题呢？

第一个场景，在拆分成微服务架构之后，不同的服务可能由不同的团队负责上下游的协调联动。比如C服务发布的时候，并不会通知A服务和B服务，这个时候就会遇到上下线带来的数据一致性的问题。

第二个场景，不可靠、不稳定的基础设施，会导致网络或者个别主机的宕机。

第三个场景，timeup是分布式架构里比较难解的状态，因为一旦出现服务调用的timeup，这个服务的业务逻辑到底是执行了，还是没有执行timeup的服务怎么实现数据的密度，都是比较尖锐的问题。

第四个场景，业务里除了会涉及到数据库，还会涉及第三方的组件。比如缓存、Redis，我们的库存会先经过Redis这样的组件，那么如何实现它的一致性也是个问题。

第五个场景，我们在上下游做业务的时候，你传给我一些参数，但这些参数本身可能是非法的。那么我就需要把你的下服务也回关掉，而不是只有我这一个服务去做拒绝。

所以分布式事务的场景主要包括了跨库、跨服务、资源的多样性。异常上主要包括业务异常、系统异常。

那么分布式事务是不是微服务架构独有的问题呢？其实不是，它在单体应用里也有类似的问题，只不过在微服务架构里它的问题更凸显。

在单体架构下存在哪些分布事务的场景呢？比如一个单体应用要去修改多个数据库或者多模块的，整体而言，单体数据库它完成的是ServerSission下边的一个本地事务。只要跨了这个本地事务，其他的都是分布式事务，即使微服务都去修改同一个数据库。这样其实你的数据库的本身也不是能反序列化传递到另外一个服务的，这些问题都会涉及到分布式事物的问题。

整体看起来，分布式事物涉及到了分布式架构和单体架构中非常广泛的应用。

市面上的分布式事务方案有以下六类：

XA模式，它的问题是吞吐量和性能要差一点，在一致性上是最高水准。
TCC模式和SAGA模式，可以归结为是一个业务层面的分布式事务，因为他不会拦截数据。比如TCC模式可能有cc接口，至于这个接口怎么回滚，怎么正向的，在框架层面完全不用管。这可能是你里边逻辑本身不是对等的，也不是框架已经参与的，所以更多的是把接口暴露给了业务实现。
消息最终一致性，它最大的优点是实现异步化的解耦，结合消息的削峰填补的特点。但它本身存在着一些问题，对消息来说，他更多的是做一个单项的通知。这个通知可能对于一些消息消费来说，即使业务失败了，它也没法去回滚。

比如现金红包的业务，我首先要将红包转到我的账户，然后再从我的账户转到我的银行卡。可能消息消费的时候我这个账户已经注销掉了，那么你的消息消费就会一直处在失败的状态。对于这类问题，不可能再把上游消息的发送给关掉，所以它更多的是单项通知的场景。

定时任务补偿，它的学习成本低，但实践成本高。尤其是微服务的链路有多翘的节点，需要业务逻辑写的非常周全。
AT模式，它综合了一致性性能，主要的特点是简单无侵入，强一致，学习成本低。缺点是需要遵守一定的开发规约，并且它不是对所有的SQL类型都支持，它有一定限制。从业务场景上来说适应的是一个通用的场景，但它并不适应于热点数据类型的高并发场景，比如SKU的库存的部件。因为在这个模式它有一个应用层的分支锁，需要对相同的数据做一个排队的等待。

二、分布式事务Seata的架构演进

Seata在阿里内部的代号叫TXC，在蚂蚁叫DTX。它起源于集团的五彩石项目，五彩石的项目是当初集团内在做去IOE，从单体架构引进到分布式架构。在分布式架构必然会涉及到很多的中间价，TXC承担的主要的角色做服务一致性的保证。

我们和集团内的三大件都做了深度的集成，包括服务调用框架HSF，也就是对外开源的Dubbo；数据库有分库分表的TDDL组件；异步消息的MetaQ组件。在集团内也有广泛的使用，日均百亿级别调用，标准3节点集群吞吐达近10w TPS。

我们的SLA会分为几个SLA，一个是可用性的SLA服务，另外一个是性能的SLA服务。因为对于分配事物来说，除了要保证一致性，也要保证性能的吞吐量。所以我们规定比如每一次的RT额外的开销不能超过XX。目前能达到毫秒级的事务处理，能保证在稳定性上全年无故障。

最开始我们在做分布式事务实现的时候，我们也去考虑我们的分布式事务应该是在哪层面去实现？

从应用架构的视角，分为这么几层，一个是最上层的应用开发框架，可能每一套公司都有自己的开发框架，比如像ddt的开发框架或者club的体系等等。再下一层是服务调用框架，类似于Apache Dubbo主要承担，也在国内使用的非常广泛。再下一层是数据中间件，这层主要包括ORM框架、事务、同步、对账。再下一层是跟数据库连接，这一层类似于JDBC、Java去连数据库。

我们去做了一个简单的对比，到底是在哪层实现分布式事务，是在DB层、数据中间件层还是应用框架层？

在应用框架层，它去实现一致性相对来说比较弱，因为你会掺杂很多复杂的、不可控的因素，会把服务调用的因素给牵扯进去。比如服务调用的超时，这就是为什么我们现在有的像TCC模式它会有一些密等、放悬挂那些问题。都是因为融入了RPC的因素，持续的不确性导致的一些问题。

在数据中间件层，它的一致性比应用框架要好一些，它主要的问题是他不是在DB层实现的，所以我是有办法绕过中间件直接去修改DB的，这时候就会存在事物并发时序的问题。最好的一致性是在DB层去实现数据一致性，但这一层数据一致性主要是数据库的厂商，但是也是参差不齐。比如Msever，他在5.7.7版本才把差异完善起来，在之前的版本它对差异回滚一直是有问题的。

但它只能局限在数据库的scope，如果我要去更大的scope，从应用架构层可能要跨服务，跨服务这一层它就管不了，只能管我自己数据库。所以他最终还是需要有一个第三方的去协调跨服务的数据一致性。最终我们把这一层AT差异模式是把它做到了数据库中间件这层，JDBC server这层我们做到了应用开发框架这层。

所以它不仅实现了一整套的集团生产体系，还包括了我们对分布式事务编程模型的定义，运维安全。因为要涉及到数据，会有数据的敏感以及性能和观测高可用等等。

在理论模型上我们当时还是比较匮乏的，我们做了一些对差异以及Spring事物模型的延展。我们延展了已有的模型，而不是新造一条。这于开发者来说，学习成本会更低。

此外，我们还做了一些定义，包括怎么定义一致性，是定义多节点的一致性，还是业务应用架构数据的一致性，以及这套架构里的角色模型设计的事物动作和隔离。

什么是分布式事务的模型定义？举个例子，我去做银行转账的时候，我给你转100块钱，恰好这个时候出现了网络超时，那么这100块钱到底有没有扣。如果不确定就可能出现资损的问题，甚至可能影响企业的商誉。

我们都在谈分布式架构，但从整个应用的视角，并不是所有东西都是分布式的。比如我们从一个应用的架构的层面去看数据库，包括今天称之为分布数据库。从整个应用层面，它我们看它是一个集成式的数据的存储。它的内部实现可能是分布式的，包括分布式的链路数据。

因为在分布式的应用架构里，每个业务的节点都只掌握了部分的信息。如果做一些问题的排查，必然需要一个集成式的东西。对于分布式事务它的核心工作是做分布式协调，所以他要掌握全局的信息。

这就是为什么我们有了Transaction Coordinator。对他来说，他要有一个上帝视角，充当第三方的协调器。而真正做事的是Resource Manager，你可以认为它是数据库的灵魂，我们需要把它作为Pro。

真正随着业务应用去做事务的动作是Transaction Manager，它会随着业务的执行链路进行，到底直接事务的边界是怎么样的，以及分布式事务的动作是怎么样的。

2019年1月Seata开始开源了，我们主打的特点特色是AT 模式，因为是组装，我们从0.1版本就把AT模式给开源出去了。0.4版本我们纳入了TCC的模式，因为AT模式它需要适配不同的数据库。而在现有阶段我们不能满足对所有数据库的支持以及缓存资源，这就需要应用TCC模式去做补充。你可以用TCC模式做一些我们没实现的数据库以及缓存的结构。

在0.9版本，我们纳入Saga的事务模式，它主要解决长事务方解决方案。比如一个事务非常长，且还有微服务的编排工作。在1.1版本，我们纳入了XA的事务模式，因为有的客户已经应用了Seata的AT模式，但他还有一些老的特别事务。他希望应用Seata统一的一套解决方案，解决不同业务常用的分支事务，所以我们把XA的事务模式也纳入进来了。

最终从整个架构上来说，我们是打造了一站式的分布式事务的解决方案。针对不同的业务场景，Seata都能做事务。如上图所示，目前市面上没有一只分布事务的模式，能解决不同业务场景的问题。主要强调几个问题，分布式事务可能有同步的分布式事物，有异步的分布式事务，以及对分布式事务的一致性的要求也不高。有强一致性，最终一致性，弱一致性。

另外，对于事物执行时间的长短也有要求。比如有长事务、短事务以及性能吞吐量等等。所以我们纳入了现在的四种事务模式，它们从改造成本、性能隔离性上各有所长，这里就不展开介绍了。

三、如何基于Seata扩展RPC和数据库

首先看一下Seata开源社区这几年的发展。目前Seata已经具备了AT、TCC、Saga、XA四种事务模式，而且对于市面上主流的关系数据库，RPC框架做了广泛的支持，同时被许多第三方社区做了主动和被动集成。已经和三十多个社区做了集成，这些集成都放在我们的扩展机制里边。

目前多语言体系也做起来了，除了最开始的Java，Go语言支持的也非常成熟，欢迎大家去使用我们的Go版本，给我们提更多宝贵的建议。另外，我们还建建设了多语言版本，包括PHP、Python等等。

目前 Seata 开源产品已被上千家企业在业务系统中应用，金融企业纷纷试点。我们都知道金融类的业务对分布式事务是强需求，而且它的业务场景非常严苛。像中信银行、光大银行、农行我们也做了一些社区上的合作，改造一些他们的核心账务系统，用Seata保证他们账务体系的数据一致性。