【藏经阁一起读】（77）__《Apache Dubbo3 云原生升级与企业最佳实践》

【藏经阁一起读】（77）

__《Apache Dubbo3 云原生升级与企业最佳实践》

目录

一、Dubbo是什么

二、Dubbo具体提供了哪些核心能力？

三、构建企业级Dubbo微服务

（一）、创建项目模板

（二）、将模板项目导入IDE开发环境

（三）、进入部署环节

（四）、进入流量管控

四、Dubbo特点：

快速上手，让开发者专注业务开发

服务治理，实时监测、管控集群状态

超高性能，面向百万实例集群设计

企业级解决方案，多年企业生产环境检验

五、书中案例

5.1、第一个方案，基于 Dubbo Filter 的单向方案。

5.2、第二个方案，网状点对点方案。

5.3、第三个方案，高速公路

5.3.1、Dubbo 的客观接入方式

5.3.2、高速公路的架构

5.3.3、隧道的机制

5.3.4、未来规划

六、读后思考

---

作者： 华钟明 宋小生 陈有为 江河清 王晓彬 何家欢 季敏

发布时间：2023-11-01

章节数：7

简介：

本书为CoC Asia 2023（原ApacheCon） RPC & Service Mesh 专题分享实录，通过摘取 Community Over Code Asia 2023（原 ApacheCon Asia）的 RPC & Service Mesh专题的精彩内容，我们以 Apache Dubbo 为中心展开，给大家带来开源微服务技术方向发展、云原生微服务选型、企业实践分享的精彩内容！

目录页

启动速度提升 10 倍：Apache Dubbo 静态化方案深入解析.........5
Apache Dubbo 云原生可观测性的探索与实践.............................29
基于 Triple 实现 Web 移动端后端全面打通...............................45
精进云原生 – Dubbo Kubernetes 最佳实践.............................. 58
政采云基于 Dubbo 的混合云数据跨网实践...................................77
OpenSergo & Dubbo 微服务治理最佳实践..................................94
Seata: 微服务架构下的一站式分布式事务解决方案................... 1

一、Dubbo是什么

　　Dubbo3 是一款微服务架构，它帮助解决微服务开发中的通信问题。

　　它不绑定编程语言。

　　目标是为所有主流语言提供对等的微服务开发体验

　　Dubbo从架构图上分为数据面和控制面

　　在数据面，使用Dubbo开发的微服务进程间基于RPC协议通信，由一系列可选的微服务治理组件构成

　　负责Dubbo集群的服务发现、流量管控策略、可视化检测等。

二、Dubbo具体提供了哪些核心能力？

　　首先，Dubbo 作为服务开发框架解决了业务应用中微服务定义、暴露、通信与治理的问题，为业务应用开发定义了一套微服务编程范式。

　　具体来说，Dubbo为业务应用开发提供了微服务开发API、RPC协议、服务治理三大核心能力，让开发者真正的专注业务逻辑开发，

　　Dubbo不是应用框架的替代者，它可以很好的工作在每种语言的主流编程框架之上，以Java为例，Dubbo可以很好的与Spring协作，并在此基础上提供服务定义、微服务编程、服务发现、负载均衡、流量管控等能力

　　在通信方面，Dubbo区别于其他RPC框架的是它不绑定特定协议，你可以选择HTTP/2、Dubbo2、REST、gRPC、REST、Hessian等任何通信协议，同时享受统一的API、以及对等的服务治理能力

　　Dubbo的另外一个优势在于其可扩展性设计，从流量管控、协议编码、诊断调优、再到服务治理，你都可以去扩展，满足企业级微服务开发与运维的所有诉求，

基于扩展能力Dubbo官方提供了丰富的生态适配，涵盖了所有主流的微服务开源组件

　　对于服务网格架构，Dubbo也可以很好的接入原生Istio体系，在数据面支持与Envoy部署的Proxy模式，

　　也支持无Envoy的Proxyless模式，提供更灵活的数据面选择

三、构建企业级Dubbo微服务

构建企业级Dubbo微服务你只需要4步，

以Java微服务开发为例

（一）、创建项目模板

使用官方脚手架快速创建项目模板，只需要选择依赖的版本、组件，点击”获取代码“即可

（二）、将模板项目导入IDE开发环境

　　将模板项目导入IDE开发环境，定义Java接口作为Dubbo服务，

　　开发Dubbo服务端，我们接口实现并完成业务逻辑编码，通过一条简单的注解配置即可完成服务发布。

　　开发Dubbo客户端，通过注释声明Dubbo服务，然后就可以发起远程方法调用了。

　　至此，整个开发工作已经完成

（三）、进入部署环节

　　我们选择Kubernetes作为部署环境，首先，通过一条命令安装Dubbo-admin等服务治理组件，安装完成后，我们可以查看部署状态，接下来部署应用，随后查看确认直到应用已经正常运行。

　　然后我们就可以打开Admin控制台查看服务部署与调用情况了解部署情况。

（四）、进入流量管控

　　进入流量管控，当应用已经平稳运行后，进一步控制流量的访问行为，控制台提供了可视化的流量治理规则操作入口，在这里可以直接下发流量规则。

　　以一个线上环境的灰度隔离示例为例，

　　通过Dubbo流量管控机制，我们可以给每个应用的一部分机器打上gray标签，接下来，对于入口为gray的流量，就可以通过控制确保它只在有gray标记的Dubbo实例内流转，实现了全链路的逻辑隔离效果。这对于隔离多套开发环境，线上灰度测试等场景都非常有用。

　　对于同区域优先调用的场景，这里有两个应用做了多区域部署，

　　紫色是杭州区域，蓝色是北京区域，部署在紫色区域的应用会优先调用访问同区域的应用，以此降低访问延迟，蓝色区域部署的服务亦是如此。当应用在同区域部署的实例不可用时，调用会自动跨区域切换到其他可用区，以此来确保整体可用性。

四、Dubbo特点：

快速上手，让开发者专注业务开发

　　多语言 SDK 定义微服务开发范式，通信协议灵活切换，支持 HTTP/2、gRPC、REST、Thrift、TCP 等任一协议。

服务治理，实时监测、管控集群状态

　　内置服务发现、负载均衡、路由等流量管控策略，提供全链路追踪、限流降级、一致性事务、日志、Metrics、服务网格、Admin 可视化控制台等一站式微服务生态。

超高性能，面向百万实例集群设计

　　阿里巴巴每年双十一数百万实例、万亿次调用跑在 Dubbo 之上，从设计之初即将低延迟、高吞吐量、可伸缩性放在第一位。

      

企业级解决方案，多年企业生产环境检验

用户群体遍布各行各业

五、书中案例

书中有7篇文章，我留意了这篇：

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

作者：王晓彬，政采云资深开发工程师

　　政采云的业务是为政府提供的购物网站，类似于淘宝。政府采购会在政采云上做企业采购、 政府采购的业务。

　　云岛中的“云”是指我们的云平台，是公司内部，完全可控的局域网。技术上对应的是一套微服务框架。

　　岛端它可能是局域网或者是私有网络，它可能是完全隔离的一个岛。他们的安全策略和开端口的东西都是他们自己定义的，这就是我们云岛的业务结构。比如安徽或者山西它们都有自己的局域网，如果我们在它们那里也部署一套这个服务框架，就叫“岛”。我们的云平台主要是给浙江省和其他相关的区划用的。

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

混合云岛网络的特点

• 平台的一致性。
• 网络连接与能力复用。
• 统一的平台管理。

政企网络痛点

政企网络有以下几个特点：

网络复杂。

安全要求高。

业务驱动运维。

5.1、第一个方案，基于 Dubbo Filter 的单向方案。

第一个特点，单向传输。

第二个特点，在本地部署业务的 provider 过滤器是运维上的负担。当岛端需要把数据同步 给云端的时候，也就是从岛端的业务 Web 传输到云端的业务 provider。这个时候我必须 在岛端也部署一套业务的 provider 才可以。

5.2、第二个方案，网状点对点方案。

　　网状点对点方案。因为岛和岛之间需要网络互通，所以就会单独开通这个点 和你需要传输的点之间的端口。开通之后我们就可以调用了，调用的形式可以用 Dubbo， 也可以用其他。 这个方案有一个很明显的缺陷，线特别多，所以点和点之间开通的复杂度也很高，对后面 的扩展可能也非常不利。

以上方案存在的问题包括：

单向传输、

白名单开通成本高、

平台维护成本高、

公共功能的缺失。

5.3、第三个方案，高速公路

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

云原生 Apache Dubbo3 微服务的架构的高速公路是指 Dubbo3 架构中的 Service Mesh，它是一个用于处理微服务间通信的基础设施层。Service Mesh 包含了一个专门的代理（如 Envoy），该代理管理微服务间的所有流量，包括负载均衡、流量控制、故障转移、安全认证等。这样，服务之间的通信可以更加可靠、安全、高效。同时，Service Mesh 还提供了丰富的监控和管理能力，可以帮助开发者更好地管理微服务架构。因此，可以将 Service Mesh 视为 Dubbo3 架构中的“高速公路”，它为 Dubbo3 微服务提供了快速、高效、可靠的通信通道。

想要达到的效果是：

• 只建一次，可复用。
• 隧道机制。
• 考虑传输性能。

5.3.1、Dubbo 的客观接入方式

Dubbo 的客观接入主要有以下三种方式：

第一种，注解方式。

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

第二种，配置中心指定。它完全可以把接入方式替换 掉，parameters 的信息在配置中心配置也可以，只要 SDK 可以支持就好。这种方式其实 代码是完全无侵入的，就是跟跨网之前和跨网之后没有任何区别。

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

5.3.2、高速公路的架构

5.3.3、隧道的机制

　　隧道技术是一种通过使用互联网络的基础设施在网络之间传递数据的方式。使用隧道传递的数据(或负载)可以是不同协议的数据帧或包。

　　高速公路架构中，使用了隧道这个概念。两端（业务层）是 Dubbo 私有协议，跨网传输过程中，则使用了 http 协议，http 协议可以更好的被中间设备、网关识别转发。这个机制的最大便利在于对业务的低侵入性。对于业务集群的应用完全不需要修改。

　　隧道机制的作用是屏蔽网络的复杂性，屏蔽中间的协议转换， 给用户一个统一透明的调用方式

　　这个机制的好处是，基本上 Dubbo 的所有特性都能支持。但也有一些个例，比如 token 和网络相关的机制

5.3.4、未来规划

六、读后思考

　　这篇案例介绍了政采云基于 Dubbo 的跨网方案落地过程中面临的技术挑战、分析对比了几个方案的优缺点。

　　对云岛业务结构的公司来说，云平台属于公司内部、完全可控的局域网，而岛端则是有自己安全网络策略的独立内部网络。需要云岛通信时，会基于需求，按客户要求走流程开通一些端口，这个过程需要一定的成本且不完全可控。业务上，如果这种跨网需求增多，则会逐渐变成痛点。如果可以搭建一个透明的跨网传输网络，配合良好的顶层设计，就可以在业务支撑、安全管控和运维成本中寻求较好的平衡。

　　一个项目，我们通常能选择的跨网方案非常多，但最终我们会去选择一个能解决痛点的，而不是完美的方案。稳定、高效、可靠的基础设施是互联网企业应对业务高峰流量的底层基石。落地方案一般来说都比较保守，这很多时候跟政企业务特殊性有关。但我们对于架构的思考，一定是需要更超前的。随着方案的落地，后期需要从稳定性、功能增强、新技术探索三个方面去做深、做广。

　　在政采云这种政企业务场景中的数据跨网，与业界公有云、自建私有云的公司相比，既有共性又有自己的特点，通过参考别人的案例，我们可以从中得到新的思路和启发。

            推荐阅读：