简介： 做过微服务开发的开发者相信对 Dubbo 都不陌生，Dubbo 是一款能帮助我们快速解决微服务开发、通信以及流量治理的框架。相比于之前只限定在 Java 语言范围内，Dubbo 的多语言版本在这两年呈现了良好的发展势头，其中，Dubbo Go 语言版本在功能、稳定性各个方面都已非常完备，其它几种主流的多语言版本在社区也有提供。

作者 | 陆龟

来源 | 阿里巴巴云原生公众号

本文整理自作者在3月20日云原生中间件 Meetup 上海站的分享。回复关键字“中间件”可以获取视频录播地址和 PPT。

就在今天，Dubbo 社区刚刚发布了 3.0 的首个预览版本 - 3.0.0.preview。

https://github.com/apache/dubbo/releases/tag/3.0.0.preview

本文将和读者一起解读 Dubbo3 的首个 preview 版本：一方面，我们将深入分析 Dubbo3 云原生变革的核心理念；另一方面，我们将逐个解读 preview 版本的核心功能。

做过微服务开发的开发者相信对 Dubbo 都不陌生，Dubbo 是一款能帮助我们快速解决微服务开发、通信以及流量治理的框架。相比于之前只限定在 Java 语言范围内，Dubbo 的多语言版本在这两年呈现了良好的发展势头，其中，Dubbo Go 语言版本在功能、稳定性各个方面都已非常完备，其它几种主流的多语言版本在社区也有提供。

云原生视角的微服务变革

Dubbo 主要解决微服务开发、运行域问题，它和微服务的编程、通信、流量治理等密切关联，因此，在探寻 Dubbo3 的云原生变革之前，我们先尝试从云原生视角观察云原生基础设施带给微服务架构和实践的变革，进而总结出 Dubbo 这样一个和微服务实践密切相关的框架所面临的变革与挑战。

微服务在让业务开发演进更灵活、快捷的同时，也带来了一些它独有的特征和需求：如微服务之后组件数量越来越多，如何解决各个组件的稳定性，如何快速的水平扩容等。

这些诉求，尤其是运维、交付相关诉求，如微服务组件的生命周期、网络、通用服务绑定、服务状态管理等，并不应该是开发人员关注的重点，因为它们已经完全脱离了业务逻辑，开发人员更愿意专注在有业务价值组件上，但这个层次的诉求却是实现微服务交付的关键能力。开发者期望由底层基础设施来提供此类能力支持，而处于不同阶段发展的基础设施却不一定具备这样的能力，因此，在微服务软件架构和底层基础设施之间就出现了一条鸿沟，我们需要有组件能填补这一鸿沟，让微服务组件能更好的接入底层基础设施。

这里从一个更抽象的层面，尝试用两条发展曲线演示了软件架构诉求与底层基础设施能力丰富度之间的关系。总体上，两者之间的发展关系可拆分为两个阶段。

在第一个阶段，软件架构（这条红色的线）从单体应用、到面向服务的软件架构、再到微服务架构，快速演进，从而也提出了上文我们讲到的对基础设施对交付的诉求，这个时候基础设施层还多是以定制化的方式来满足软件架构的诉求，如过往的集中化的 ESB、各个不同的 PaaS 平台等。

第二个阶段，是从容器、Kubernetes 为代表的基础产品的出现开始，蓝线与红线之间的增长速度被快速拉近，以云原生技术为代表的底层基础设施丰富度得到了极大改善，它们不再只是被动的满足微服务开发的诉求，而是开始抽象更多的软件诉求到底层的基础设施，将它们下沉为基础能力，并开始以统一的、标准化的形式向上输出以满足微服务对交付、运维等的诉求，不仅如此，通过更深入的主动创新、持续的向上释放能力，底层基础设施还开始反过来影响微服务的开发、接入方式，如 sidecar、dapr 等模型。

Dubbo3 的云原生变革

通过上文云对原生基础设施演进给传统微服务带来变革的分析，我们得出，以 Dubbo 为代表的微服务开发框架，应重点在以下方向突破与变革。

更多的微服务组件及能力正下沉到以 Kubernetes 为代表的基础设施层。传统微服务开发框架应剔除一些冗余机制，积极的适配到基础设施层以做到能力复用；微服务框架生命周期、服务治理等能力应更好地与 Kubernetes 服务编排机制融合。 以 Service Mesh 为代表微服务架构给微服务开发带来的新的选择，但由于 Mesh 架构本身的复杂性，其距离大规模生产落地还有一段距离。我们相信，基于 ServiceMesh 的体系会逐步从孵化器走向成熟期，会有越来越多的企业采用 Service Mesh技术，但在未来在很长一段时间内，基于服务框架的传统微服务体系还将是主流，长期仍将占据半壁江山。