Apachecon2023 on Apache Dubbo

Apache Dubbo 云原生可观测性的探索与实践

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

摘要：本文整理自平安壹钱包中间件资深工程师、Apache Dubbo committer宋小生在 Community Over Code 2023 大会上的分享。本篇内容主要分为五个部分：

一、可观测性建设
二、多维指标体系
三、链路追踪门面
四、日志管理分析
五、稳定性的实践

一、可观测性建设

首先介绍一下云原生升级的挑战。目前大部分公司里基本上都有CICD、OPS来帮助开发、测试、运维提升开发的效率与质量，也会有容器化来帮助提升产线运维的效率与质量。但在云原生时代，大规模容器的频繁变更会带来很多稳定性的问题。这些稳定性问题，包含了很多我们可以提前规避掉的已知的异常，也包含了很多我们无法避免的异常，比如网络故障、机器宕机等系统无法提前测出来的问题。

如果我们能提前发现这些问题，其实是可以规避掉很多风险的。所以我们通过可观测系统及时的感知到了这些问题，高效的分析异常，快速的恢复系统。因此可以判定，在云原生时代，可观测系统的建设是非常重要的。

Dubbo作为微服务RPG的框架，直接建设一个大而全的可观测性系统或者平台是不现实的，而且它的定位也不是很符合。可观测性系统更强调关联性，通过单维度或者多维度进行系统的观测与问题的诊断。

首先看一下可度量系统的健康状态的指标。Dubbo通过采集系统内部的Dubbo指标的同时，把指标内部的数据暴露给外部的监控系统。这些监控指标中间包含了很多的应用信息、主机信息、Dubbo服务标签信息等等。当我们发现问题的时候，可以通过这些标签信息关联到全链路系统。之后全链路系统可以做到请求级或者应用级的系统性能分析或者系统异常诊断。

Dubbo侧通过适配各大厂商门面的形式，只需进行非常简易的依赖就引入或者配置就可以直接把数据导出到各大全链路平台。无论企业使用哪个流行平台，在后期升级Dubbo后都可以直接把链路导出去。

另外，链路系统还包含全链路的Traceid或者局部的磁盘ID。通过全链路的ID，我们可以在链路系统直接跳转到日志平台。在日志平台里包含非常详细的日志上下文，这些日志上下文可以提供非常精确的异常问题诊断。

Dubbo也提供了非常详细的错误码机制和专家建议的形式，在官网上通过日志的形式可以直接通过错误码的形式直接导航到官网上的帮助文档。

二、多维指标体系

Dubbo在多维度指标体系实践的时候，我们主要从两个维度来看它。

第一个是纵向的维度。Dubbo指标在采集的时候有一个接入导出的流程。Dubbo为用户和开发者提供了简单易用的接入门面。接入后服务在运行过程中通过指标器进行指标的采集。Dubbo中提供了非常多的指标采集器，包括聚合和非聚合的指标采集等等。

然后采集的指标会通过变量值临时存储在内存里，之后会有部分指标（QPS等带有滑动窗口的最小值、最大值的聚合指标）进行聚合计算，最后这些指标会导出到外部系统。我们支持在Dubbo QPS服务质量中进行指标导出，或者把指标导出到Prometheus，或者http直接访问也可以进行指标的查询。

第二个是横向的维度。Dubbo指标采集覆盖了非常容易出现异常的地方。比如Dubbo 3提供了三大中心，包括注册中心、元数据中心、配置中心，存在外部网络交互的地方是非常容易出现问题的。

另外一个比较关键的是RPC电路上的采集，比如请求相应的时间、异常、nity网络、IO的指标等等。此外还有一些关于Dubbo线程池的指标采集。

前面说的是比较大面上的指标采集，具体Dubbo的采集需要哪些指标我们也调研了很多比较流行的方法论。

图中第一张图是谷歌SRE书的四大黄金指标。它是谷歌总结大规模的分布式服务监控总结出来的，它可以进行请求级别的服务质量的衡量，主要包含延迟、流量、错误以及饱和度。
图中第二张图是RED 方法。它更侧重于请求，从外部视角来查看服务的健康状态，主要包含速率、错误与持续时间。
图中第三张图是USE 方法。它更侧重于系统内部的资源使用情况，包含利用率、饱和度与错误。

可以看到，以上三个指标的方法论中都包含的指标是错误，错误也是每个开发者比较关注的。

然后我们进行了指标的系统完善。在Dubbo 3.2版本中，多维度指标体系已经完成，而且也在快速持续的版本迭代中。在这个版本中我们只需要引入一个快速集成的Spring Boot中的Starter包就可以实现指标的自动采集。之后我们通过Dubbo的QPS服务质量端口可以直接访问到。如果是本机可以通过浏览器，如果是服务器可以通过科尔命令访问52端口，后面加一个Metric路径，这样就可以看到非常详细的默认指标的导出。

可以看到这些指标有Dubbo前缀，类型是Dubbo的不同模块，比如消费者提供的请求级别，三大注册中心一起线程。

下面是Dubbo当前指标的行为，比如响应时间最后会加一些单位，这个格式参考的是Prometheus的官方格式。

多维度指标体系有些人可能会直接复用Spring Boot默认的manager管理端口，Dubbo也适配了一下Spring Boot Actuator的扩展。

操作和刚刚一样，只是引入Spring Boot Starter包。后面也无需做任何其他的配置，就可以在Spring端口里看到详细的指标了。包括Spring Boot内置的jvm指标、Dubbo指标等等。

指标体系接入之后，我们如果直接通过命令行访问只能看到一些瞬时的数据，但在监控指标体系我们其实更关注的是多维度的向量数据。如果我们把这些数据看作是一个点其实是比较难看出问题的，所以我们需要把这些数据存储起来，看作是一个实际化的向量数据。

Dubbo默认提供对Prometheus采集的介入。Prometheus作为指标存储与监控一体的监控系统，提供了很多的服务发现模型。比如我们直接把服务部署在K8s上，可以直接基于K8s标签的服务发现机制进行指标采集。如果公司有自建的cmdb系统，可以自己扩展http接口进行指标采集。此外,文件或者静态的服务发现机制只要能发现Dubbo服务的IP和服务接口，也可以进行指标采集。采集到的指标会自动存储在Prometheus的实际数据库里。

上图是我们通过Prometheus的查询框查询出来的响应时间的最新指标。

Prometheus的指标更侧重于存储与报警，如果我们想更直观的体现还需要接入Grafana。Grafana的目标是为企业提供简易接入的监控面板，上图是一个简易的全局大盘。

我们通过应用级别的筛选/机器IP维度的查询/服务接口的维度，查询服务的健康状态。可以看到，这些指标基本上都是基于前面总结的方法论实现的。比如QPS、请求数量、成功率、失败率、请求的时延等等。

此外，还有一些应用信息的指标，比如升级Dubbo 3时，想看到哪些应用已经升级到新的版本，就可以看到新的应用的版本号，也会有应用信息的实例IP分布，还有一些现成资源。

三、链路追踪门面

刚才说的指标比较抽象，它更利于帮助我们发现问题，接下来进行一些简单问题的诊断。微服务系统往往是多个系统之间有关联关系，所以服务之间的诊断更依赖于全链路系统。

全链路系统Dubbo，当时考虑使用Agent的方式，这种方式对于用户接入是非常方便的，在代理层直接注入一些指标采集的方式即可。如果用这种方式在企业里做全链路的覆盖是非常方便的，但如果Dubbo只做Dubbo的指标采集，风险会比较大。因为Agent接入后会进行字节码修改等不兼容的问题，有些时候很难在前期发现。

另外，Dubbo也调研了一些开源的链路追踪门面。Dubbo选择通过原生内置门面的形式，让专业的事情交给专业人做。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保证他们账务体系的数据一致性。

基于 Triple 实现 Web 移动端后端全面打通

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

摘要：本文整理自陌陌研发工程师、Apache Dubbo PMC陈有为在 Community Over Code 2023 大会上的分享，本篇内容主要分为四个部分：

一、RPC 协议开发微服务
二、全新升级的 Triple 协议
三、Triple 协议开发微服务
四、Dubbo 为 Triple 协议带来治理能力

一、RPC 协议开发微服务

在我们正常开发微服务的时候，传统RPC服务可能在最底层。上层可能是浏览器、移动端、外界的服务器、自己的测试、curl等等。我们可能会通过Tomcat这种外部服务器去组装我们的RPC层，也就是BFF。或者我们没有BFF，我们的RPC就是对外提供服务。但因为浏览器要访问，所以我们需要有一个网关，比如说Apisix或者ShenYu等HTTP网关。

上图展示的是我们的流程，但是存在一些问题。

如果我们的服务是非常轻的，我们只需要一个转发层，我们是不是很麻烦。无论是配网关还是起一个webserver去转发，肯定都很麻烦。

此外，RPC服务大部分都是基于二进制的，而二进制正常在本地是没法测试的。因此我们的公司内都可能就会开发一种后台或者中间的Process让我们去测试。但这个的前提是你至少得把它部署到测试环境，所以还是没法在本地测试。

总体来说，这两个问题的易用性比较低，且开发成本相对较高，因为要做一些重复劳动。

二、全新升级的 Triple 协议

基于上边的两个问题，我们来介绍一下Triple协议。

先来说一下上一代协议，它产出的原因是什么。我们应该都知道Dubbo原来是Dubbo协议，它是基于tcp的，它有一个包。因为它的包的设计，导致了网关无法做一些特殊规则判断、过滤等操作。但也不是绝对的，如果你愿意牺牲性能把包完全解出来，组装回去再透传还是可以做到的，但一般大家都不太能接受。

所以我们就在想能不能把原数据和真正的包分开。现在我们有现成的HTTP，又有一个业界主流的gRPC，所以我们的目标就是兼容gRPC。因为gRPC目前都是用IDL，而IDL有一个问题，尤其在Java侧。因为大家都是写一些接口，定义一些包去实现，这样就会非常麻烦。Go侧就还好，因为大家已经习惯了这种开发模式。

所以我们开发了Triple协议，首先它兼容了gRPC，所以我们能实现和gRPC的完全互通。其次，我们兼容了自己定义接口的方法。虽然会损失一定的性能，但提升了一些易用性。而且RPC一般不是业务的瓶颈，大多数瓶颈还是在DB。

但还有个问题，虽然我们兼容了gRPC，但gRPC是基于TPC的，所以如果前端或者其他第三方系统只有HTTP，它还是接受不了我们的系统。

基于此，我们想推出一个全新的Triple协议。为了解决上述的所有问题，我们参考了gRPC、gRPC Web、通用HTTP等多种协议，做到浏览器访问，支持Streaming，还支持同时运行在 HTTP/1、HTTP/2 协议上。因为目前HTTP/3还没有大规模推广，未来也会支持HTTP/3。

最终的设计实现是完全基于HTTP的，且对人类、开发调试友好。我们可以通过简单的浏览器访问或者curl访问，尤其是对unary RPC。此外，我们和gRPC是完全互通的，用HTTP的业务不用担心兼容性的问题，也不用担心签协议的问题。为了稳定性，我们只会采用业界流行的网络库，比如Java的netty、Go的基础的net包。

虽然Triple协议和gRPC协议都基于HTTP，但gRPC是基于HTTP/2的，而Triple是基于HTTP/1和HTTP/2的。

我们在进入gRPC的同时，我们为了易用性扩展了一些功能。比如请求里我们支持application Json，curl访问，此外上一版的协议，为了支持传统定义接口的方式，我们有一个二次序列化的过程。我们想在这里通过一个特殊的tag来决定我们的body的结构，解决二次序列化的问题。同时这个东西是可以扩展的，理论上HTTP的所有future我们在Triple协议上都可以实现，也可以拓展。

用了Triple协议之后，我们的开发流程也发生了改变。如果你不需要进行组装，或者没有外层的代理，可能你的接入流程就是从外部的请求浏览器、对方的服务器、curl、自己测试等直接到了server。

和其他的gRPC的通信也是没有问题的，流程就相当于少了一层。对于大多数用户，如果你不需要这个场景，其实是有很大的好处。

Triple协议因为最开始兼容gRPC，那个时候只基于HTTP/2，HTTP/2有Streaming的能力，所以它天然支持Streaming。但这里比较特殊的是，我们新版的协议在HTTP/1也支持了Stream，但仅支持了Server Stream。也就是客户端发一个，服务端发好几个回去，这个HTTP/1的Server Push实现的。

Client Stream和Bi Stream就没什么可说的了。但有一个特别的是，在Java侧没有Bi Stream，从编码上就没有，但从实现上是有的。

三、Triple 协议开发微服务

目前Triple协议比较灵活的支持两种定义方式，分别是IDL定义和直接定义。直接定义支持同步、异步、手写。还有比较极端一点的，比如在自己定义接口的时候用IDL生成probuff的类，我们不定义它的service，只用它的接口也是没问题的，它会自动识别接口使用pb还是不使用pb。

Server就是把它的务实现一下。上图是一个例子，我就直接拿了API的组装方式，真正的业务上可能是注解或者XML的方式。

因为我们支持了HTTP这个标准的协议，理论上我们的测试就会变得很简单。

因为我们支持gRPC，所以我们可以用gRPC curl去调用我们的服务。但前提是你得有反射服务，然后手动开启一下，它不是默认开启的。然后它就可以通过反射拿到接口的源数据，通过Json转成pb格式发过去。或者我们直接用Application Json的方式直接调过去。这里有一点比较特别的是在HTTP/1下我们也可以用Sream。

启动速度提升10倍：Apache Dubbo 静态化 GraalVM Native Image 深度解析

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

摘要：本文整理自杭州有赞科技有限公司中间件技术专家、Apache Dubbo PMC华钟明在 Community Over Code 2023 大会上的分享。本篇内容主要分为五个部分：

一、GraalVM 直面Java应用在云时代的挑战
二、Dubbo 享受 AOT 带来的技术红利
三、Dubbo Native Image 的实践和示例
四、Dubbo 集成 Native Image 的原理和思考
五、Dubbo 在 Native Image 技术的未来规划

一、GraalVM 直面Java应用在云时代的挑战

云计算时代比较显著的特点包括：

基于云计算的基础设施，Java应用能够在云计算的基础设施上快速、轻松、高效的做到弹性。
基于容器化技术，系统资源切分的更加细，资源的利用率也更高了。
基于云计算的开发平台，让应用部署的更加容易，更加敏捷。

那么在云计算时代，Java应用存在哪些问题呢？

冷启动速度较慢。
应用预热时间过长，无法立即达到性能峰值。
内存、CPU等系统资源占用高。
Java构建的应用程序繁重，执行还需要具备JDK环境。

在Serverless场景上，Java的问题会尤为突出，因为Serverless不仅能简化开发场景和开发体验，还能做到极致的弹性，甚至是秒级的弹性。

上图是Datalog统计的Fast和AWS两个产品。Java语言虽然更流行，但相较于Python和Node.JS，它的占比还是比较低的。Java本身在Serverless层面，比如在做容器的调度、镜像的下载的时候，启动时间、冷启动的时间、预热时间等等，都会影响Serverless场景下它弹性扩容的时间。

下面介绍一下GraalVM，它是可以把Java应用提前编译到独立的二进制包内，这些二进制包相对于跑在JVM上它可以更小，更快的启动，不需要预热就能够达到极限的峰值，还可以减少内存和CPU的占比。

可以看到它的介绍和Java语言的应用所涉及到的问题都一一对应。GraalVM应该算是JDK的"超集"，除了包含完整的JDK发行版本外，还有GraalVM Compiler、Native image、Truffle等，甚至还涉及到多语言汇编的能力。

总结一下，GraalVM本身涉及两部分，JIT和AOT。

JIT，是在编译后的class文件、字节码文件，它会在运行时把它翻译成机器码。
AOT，它和JIT的区别是，它在编译期就能把字节码直接转化为机器码，无需在运行时再去处理。所以它的CPU和内存会相对更低。

上图左侧是一张Java生命周期的全景图。可以看到，它从JVM的启动，再到Java的main函数的启动，再到Java的应用预热，再到它的稳定期，最后到达效果，这是Java完整的生命周期的呈现。

而AOT的区别在于，它没有红色的VM。另外，JIT相对于AOT而言是没有的，也没有浅绿色的解释器。所以AOT对于JIT来说，只有内加载，GC以及它能够瞬间达到应用的稳定期。

根据右侧的图可以看出：

AOT的启动耗时相对较低，内存损耗和它打出来的二进制包相对较小。
JIT因为有及时编译的效果，所以现在极限的分值比AOT要好，比如它的极限吞吐量比AOT好。

二、Dubbo 享受 AOT 带来的技术红利

多产物形态

我们在编码之后，Soft Code的产物形态新增了。

第一种是我们传统认知上的Jar包形态，比如mvn、clean、package。第二种是Docker Image，它能轻松的帮我们直接打到镜像里面去，不用写dockerfile等文件。第三种是我们集成GraalVM后新产生的一种Native可执行文件的形态。这种形态无需JDK的环境就能启动，它能像GO一样把二进制文件直接启动。

启动耗时大幅降低

手把手教你部署Dubbo应用到Kubernetes – Apache Dubbo Kubernetes 最佳实践

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

精进云原生 – Dubbo Kubernetes 最佳实践

摘要：本文整理自阿里云研发工程师、Apache Dubbo PMC江河清的分享。本篇内容主要分为六个部分：

一、使用 Dubbo Starter 初始化项目
二、开发微服务之协议选型
三、基于 Kubernetes 快速初始化环境
四、快速部署应用到 Kubernetes 集群中
五、云原生微服务可观测最佳实践
六、在 Kubernetes 中管理微服务应用

上图是从 Istio 借鉴的一个demo，它包含了四个组件，分别是Product Page、Reviews、Details、Ratings，它就是一个全链路的串联，实现了整体的微服务架构，它的功能可以实现我们简单的调用。

一、使用 Dubbo Starter 初始化项目

首先介绍一下Starter的功能。对于很多开发来说，在Java体系下创建出新的应用，无外乎就是用IDE创建一个新的项目，或者用maven的artifact，或者基于Spring的Initializer。

上图使我们基于Spring的Initializer建立了我们自己的初始化项目的工程。我们点击最上面的网址就能直接看到这个页面了，你需要输入对应的group和artifact。然后选择你希望用到的组件，比如Nacos、Prometheus的组件等等。

除此之外，我们在IDE里提供了一个Dubbo的插件。这个插件可以通过上图的方式进行安装，或者如果你的仓库里已经用到了Dubbo的配置，它会提示你可以直接安装。安装完成后在右边就会有一个对应的初始化的项目了。

上图是一个示例，它在这里建立了一个Dubbo的项目，然后你需要在这里选中所需要的组件信息，最后点击创建，之后它就会帮你在本地直接创建出一个全新的项目，然后你就可以在这个模版上开发了。

二、开发微服务之协议选型

我们会用到最新的Triple协议，它整体支持兼容gRPC、HTTP/1、HTTP/2。

这里主要想和大家分享的点是，我们基于curl访问的能力，比如POSTMAN、HttpClient都是支持的。

下面来看一下我们的项目，这是刚才建立的一个项目，我现在把应用启动起来，配置一些注册中心的地址，这就是一个标准的Spring的启动的流程。这里定义了一个接口，这个接口返回了一个"hello"的内容信息。然后我用一个简单的命令，就可以直接返回我的hello world的结果了。这样对我们本身的测试来说有很大的帮助，也就是本地启动之后，就可以直接测试接口。

三、基于 Kubernetes 快速初始化环境

假设我们已经把前面四个应用的代码全部开发完成了，接下来我要把它部署到K8s环境上。部署之前有一个非常重要的步骤，需要先初始化环境。比如Nacos、ZK、Skywalking、Zipkin、Prometheus等组件，我们都需要将它们安装上去，因为它们是应用前置依赖的各种组件。这些组件的安装流程都很复杂，那么我们如何简化这个流程呢？

Dubbo提供了一个命令，这个命令可以一键帮你在K8s体系下拉起上图左边的所有组件。

这里有一个简单的例子，拉起来之后，它会把所有的组件都会帮你拉起来。这里埋一个点，这里的Prometheus我们后面还会继续使用。整个Nacos的地址，Zookeeper的地址都会直接提供给你。

这也是一个的例子。执行一个简单的命令，然后本地会把kubectl的配置都准备好，它就会自动的帮你把组件都创建起来。也就是我们一键就可以获取到所有service的部署。

四、快速部署应用到 Kubernetes 集群中

部署应用有三个重要的点，分别是应用容器化、无状态部署、生命周期对齐。

首先介绍一下应用容器化。想要将应用容器化，首先需要建一个dockerfile，引入一个jdk的包，把启动命令和启动脚本拉进去。然后还要写一个Java的编译的脚本，把Java编译的jar包结果拉进去。这个过程非常复杂，所以我们可以用一下Jib的插件。这个插件是maven的一个plugin，我只需要把这些配进去，指定成我的Image就足够了。

可以看到，我只需要把我的pom里添加一个对应的配置项依赖，通过一键maven的编译模式，它就可以在maven打包的过程中帮你构建完镜像，然后直接推送到远端仓库。这一切都只需要这一个命令就可以完成，而且一次性配置之后，未来你所有的镜像更新都可以自动化的去做，不需要再去写繁琐的dockerfile。

其次介绍一下无状态部署。刚才我们把镜像打出来了，这只是第一步，紧接着我们要让镜像run起来。我们可以基于K8s的deployment的模式，它是从K8s的官网上直接拉下来的。拉下来之后我们可以指定对应的应用名、镜像信息等等，这是K8s无法绕过去的，相对于说它需要配置这样的一个demo，当然也会有云厂商平台提供一个可视化的界面给你，它的底层配置的就是这样的一个yarml。

这是一个简单的例子，把deployment配置完之后，指定了刚才的镜像。同时我声明了一个service，这个service非常重要，它后面会作为from_end应用入口的配置，但它是一个Ingress网关。可以看到apply镜像之后，我们就可以在K8s体系上把这个环境run起来了。

这里做一个简单的测试，我引入一个curl的容器，同样我们可以用刚才curl的命令访问我新部署好的容器节点，可以看到它返回了hello world的数据信息。

政采云基于Dubbo的混合云数据跨网实践

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

摘要：本文整理自政采云资深开发工程师王晓彬的分享。本篇内容主要分为四个部分：

一、项目背景
二、为什么叫高速公路
三、修路实践
四、未来规划

一、项目背景

我们有一个云岛业务叫政采云，它是政府的购物网站，类似于淘宝。政府采购会在政采云上做企业采购、政府采购的业务。

云岛中的"云"是指我们的云平台，云平台是我们公司自己部署的一套购物网站，它对应的是一套微服务框架。而"岛"是指，比如安徽或者山西它们都有自己的局域网，如果我们在它们那里也部署一套这个框架，就叫"岛"。我们的云主要是给浙江省和相关的区划用的。

我们的云和岛之间存在数据传输的问题，举个例子，比如我现在收到一个政府的公告，而这个公告肯定是全国性的。所以我可能会在云平台的管理平台上去录公告，再把它推送出去，这个时候云和岛之间就存在了一些数据的跨网。

云岛网络

对我们云平台来说，这个局域网是我们公司内部完全可控的。比如你要开个端口，很快就能开起来。导端它可能是局域网或者是私有网络，比如我们之前做了一个浙商银行的项目，它是完全隔离的一个岛。他们的安全策略和开端口的东西都是他们自己定义的，这就是我们云岛的业务结构。

混合云岛网络

上图是大概的数据链路图。云平台下面有分支机构、分公司，它们会对应一套业务的系统。政务云是我刚才说的省级（安徽省）或者市级（无锡市）对应的区块，隔离的政务云。私有部署是银行、国企、军队、政企等典型的混合云的网络架构。

混合云岛网络的特点

我们混合云网络架构的特点包括：

平台的一致性。我们部署在公有云、云平台、政务云、私有云上的那一套的代码是一样的。我们把一套代码部署在不同的地方就变成了多个平台。
网络连接与能力复用。我们会依赖一些第三方的能力，比如短信，但私有云上它的网络管控比较严，所以和第三方互通端口或者网络的流程就会比较复杂。这个时候我们希望去复用我们云平台的能力，这个时候他们之间又有一些数据的交互。
跨域访问迁移。
统一的平台管理。像我刚才举的例子，如果要发公告，我们希望可以在一个平台上就可以管理起来。而不是浙江发一条，安徽发一条，那样维护的成本也会比较高。

政企网络痛点

很多公司都会和政府打交道，政企网络有以下几个特点：

网络复杂。比如银行的网络，它们的安全性和内部的东西很复杂，流程的开通也比较多，需要你要经常去跑，跑完了之后发现有新的问题，又要去跑。

安全要求高。比如在开通端口的时候，我们需要去传数据，如果里面的那些序列化的协议不符合它们的规范，它们就会拿掉。这个时候给我们的业务其实是超时的，或者是那种通用的异常。而我们并不知道发生了什么，这就会带来未知的风险。

业务驱动运维。我们有了业务才会去部署，才会去做事情。我们就会多次、重复的投入，这就会导致人力、时间成本会比较高，私有部署的时候会更多。

现有方案

基于以上的痛点，我们做了两个方案。

第一个方案，基于Dubbo Filter的单向方案。这个方案的历史比较久一些，它有两个特点。

第一个特点，单向传输。它是从"岛"到"云"只有一个方向，它基于Dubbo Filter的原因是，我们公司内部的微服务都是通过Dubbo来调用的，所以我们是强依赖的来Dubbo的。所以做数据跨网的方案肯定会基于Dubbo的特性来做。

第二个特点，在本地部署业务的provider过滤器是运维上的负担。当导端需要把数据同步给云端的时候，也就是从岛端的业务Web传输到云端的业务provider。这个时候我必须在导端也部署一套业务的provider才可以。部署它的原因是它要拦截这个请求，然后把这个请求转发给部署在云平台的Dubbo网关。

但这个时候就会给我们带来负担。如果导端本来就有数据的入库就还好，因为provider本来就存在，但一些业务只是做跨网用的，没有本地的入库，那么这个时候业务的provider就是多余的了。

第二个方案，网状点对点方案。因为岛和岛之间需要网络互通，所以就会单独开通这个点和你需要传输的点之间的端口。开通之后我们就可以调用了，调用的形式可以用Dubbo。

这个方案有一个很明显的缺陷，线特别多，所以点和点之间开通的复杂度也很高，对后面的扩展可能也非常不利。

以上方案存在的问题包括单向传输、白名单开通成本高、平台维护成本高、公共功能的缺失。

基于以上的问题，我们做了一个新的方案，叫高速公路。

二、为什么叫高速公路

为什么叫告诉公路呢？主要因为我们想要达到的效果是：

只建一次，可复用。比如北京到上海的高速公路，它只要够宽，一条就够了。如果你是从上海到北京或者从杭州到北京，是可以复用的，不用单独再修建一条。

隧道机制。因为高速公路修建的地方不一定都在平原，可能会在河、海、山等等附近。如果我们在高速公路下面搭建一条隧道，这个时候对于司机来说就是无感的。我们的目的是一样的，如果你觉得政企网络很复杂，那么我们就帮你把它屏蔽掉，这样你也是无感的了。

考虑传输性能。如果每个业务部门都自己搭建一套传输链路，那么传输性能只要能承载自己的业务就够了，因为不一定要给别人用，或者给别人用了也是小范围的。但如果搭建的是一条可复用的链路，就必须考虑传输的性能了。

三、修路实践

接下来介绍一下我们在修建高速公路的时候遇到的一些问题以及具体的做法。我们在客户端接入上遇到了以下问题：

第一个问题，强依赖Dubbo。

第二个问题，透明传输，不改变使用Dubbo的方式。也就是我不需要自己写一些注解代替Dubbo，或者写一些API调用Dubbo。因为写了之后，一些新人可能并不能理解或者不能习惯，也不知道里面有什么坑。所以我们用原始的Dubbo来做可能会对用户更加无感。

第三个问题，接入灵活，支持多种形态。虽然我们强依赖Dubbo必须支持Dubbo，但我们也需要支持其他的形式，比如HTTP。但在接入之前，我们需要考虑接入灵活性的问题。

下面我们先介绍一下Dubbo的方式。Dubbo的客观接入主要有以下三种方式：

第一种，注解方式。使用@DubboReference提供的通用parameters参数，设置路由目标，可以达到方法粒度的路由。路由信息写在中间parameters那里，parameters是Dubbo给我们提供的通用参数的传递。

如果是正常的，我写了这个信息，Dubbo是不做任何处理的，因为这个东西对它来说没有含义。但因为你引入了高速公路的SDK，所以在你写了这个东西之后，我们就会去解析，拦截Dubbo的请求，把parameters里的参数抓起来做一些路由处理，这种形式其实没有改变Dubbo的使用方式。

第二种，配置中心指定。比如我们用的是阿波罗的配置中心，它完全可以把接入方式替换掉，parameters的信息在配置中心配置也可以，只要SDK可以支持就好。这种方式其实代码是完全侵入的，就是跟跨网之前和跨网之后没有任何区别。但最后发现我们的业务并不喜欢这种方式，首先因为阿波罗大家不喜欢用，其次不好理解。如果是一个新人看这个代码，他就会认为是在调本地的接口。

第三种，线程指定。当你在线程里指定了路由信息，下面再去调用的时候，这次调用就会走你的路由。如果再调用一次，它就会调回本地。因为基于线程的形式，在Dubbo的扩展里，它会在调用完成之后把线程信息清理掉。所以需要注意一下，如果你想多次调用，就需要写多次。如果不想写多次，你可以用上面这种方式，你只要在当前的been里，都是路由到上海。

接下来介绍一下高速公路的架构，刚才介绍点对点的方式，它的缺点是开通白名单比较复杂。现在我们的高速公路架构是一个新型的架构，所以它开通白名单的复杂度会低一点。

如上图所示，比如最左边的节点是上海，最上边的节点是安徽，我想从安徽到上海，这个时候中心网关就需要开通一个白名单。开完之后，这条链路就可以直接过去了。可以看到一共就六条线，所以它的复杂度也就下来了。

18:30上图是高速公路里最核心的架构图。

比如山西集群的APP1调APP2的时候，我想去调上海APP2，如果你什么都不做，它默认调的就是山西集群的APP2。如果你在APP调用的时候加了一些路由信息，放在山西集群APP1里的SDK就会把它的流量切走，切到山西集群的Dubbo网关。

之后Dubbo网关会通过HTTP的协议走统一网关，再通过HTTP的协议到上海集群的Dubbo网关。在这里会把路由信息拿到，包括调用的Service、方法、版本号、参数等等。然后通过泛化的形式调上海集群的APP1，最后返回，完成这次跨网的调用。

那么为什么要有Dubbo Proxy这个角色呢？为什么不直接从APP1切到统一网关？少一个步骤不好么？涉及到的原因有以下三点：