本文将带你快速了解Dubbo3的设计背景、整体架构和核心特性，以及与阿里巴巴HSF2等典型用户的关系。您还可以通过以下章节了解更多信息：初学者快速了解Dubbo3的核心特性：下一代通信协议-三重百万实例集群的秘密-应用级服务发现DubboMesh的兼容性和迁移成本Dubbo3？Java-迁移指南Golang-迁移指南Dubbo3相关资源：性能指标、高级特性说明等更多信息，请参考多语言SDK实现背景Dubbo3的设计和开发有两大背景。首先，如何更好地满足企业的实际需求。Dubbo自2011年被阿里巴巴开源以来，一直是众多大型企业微服务实践的首选开源服务框架。在此期间，企业架构经历了从SOA架构到微服务架构的转变，Dubbo社区自身也在不断更新迭代，以更好地满足企业的需求。然而，Dubbo2架构的局限性在实践中逐渐凸显：协议，Dubbo2协议以性能和简洁着称，但在云原生时代遇到越来越多的通用性和渗透性问题；可扩展性仍然远优于其他很多框架，但是随着微服务带来更多的应用和实例，我们不得不思考如何应对更大规模集群的实战；服务治理的易用性，比如更丰富的流量治理、可观察的性能、智能负载均衡等。第二，适应云原生技术栈的发展。微服务在让业务发展演进更加灵活快速的同时，也带来了一些独特的特性和需求：比如微服务之后，组件越来越多，如何解决各个组件的稳定性，如何快速横向扩展以Docker、Kubernetes、ServiceMesh为代表的云原生基础设施为解决这些问题带来了一些新的选择。随着越来越多的微服务组件和能力下沉到以Kubernetes为代表的基础设施层，传统的微服务开发框架应该剔除一些冗余机制，主动适配基础设施层，实现能力复用。微服务框架的生命周期、服务治理等能力应该与Kubernetes服务编排机制更好的融合；以ServiceMesh为代表的微服务架构为微服务开发带来了新的选择，Sidecar带来了多语言、透明升级、流量控制等，但同时也带来了运维复杂、性能损耗等弊端。因此，基于服务框架的传统微服务体系仍将是主流，长期来看仍将占据半壁江山，长期保持混合部署状态。总体目标Dubbo3依然保持2.x的经典架构，主要职责是解决微服务的进程间通信，通过丰富的服务治理（如地址发现、流量管理等）更好的管控微服务集群。);对原有框架的升级是全面的，几乎体现在Dubbo核心特性的方方面面，稳定性、性能、扩展性、易用性都通过升级得到全面提升。通用通信协议。新的RPC协议应该摒弃私有协议栈，使用更通用的HTTP/2协议作为传输层载体，利用HTTP协议的标准化特性来解决流量通用性和穿透性的问题，使协议能够更好地发挥作用。应对前后端Docking、网关代理等场景；支持Stream通信方式，满足不同业务通信模型的需求，为集群带来更大的吞吐量。对于数百万的集群实例，集群是高度可扩展的。随着微服务实践的推进，微服务集群实例的规模也在不断扩大，这得益于微服务轻量级、易于横向扩展的特点，但也给整个集群容量带来了负担，尤其是一些集中式的服务治理组件；Dubbo3需要解决实例规模扩展带来的各种资源瓶颈，实现真正的无限水平扩展。更丰富的编程模型，更少的业务侵入。在开发状态下，业务应用面向DubboSDK编程。在运行状态下，SDK和业务应用运行在同一个进程中。SDK的易用性、稳定性和资源消耗将极大地影响业务应用；因此，3.0应该有更抽象的API，更友好的配置方式，对业务应用资源的侵占更小，可用性更高。更易用和更丰富的服务治理能力。微服务的动态特性给治理工作带来了高度的复杂性，而Dubbo在这方面做得很好，是最早一批治理能力的定义者和实践者；3.0需要面向更丰富的场景，提供诸如可观察性、安全性、灰度发布、错误注入、外部配置、统一治理规则等能力。全面拥抱云原生。面对企业生产实践的痛点，Dubbo2依然是国内首选的开源服务框架。广泛应用于互联网、金融保险、软件企业、传统企业等几乎所有数字化转型企业，并在大规模生产环境中得到检验。以Dubbo2的贡献者和典型用户阿里巴巴为例。阿里巴巴内部维护的基于Dubbo2的HSF2框架经历了历次双十一高峰期的考验。每天进行数十亿次RPC调用，管理超过千万个服务实例。在长期的优化和实践积累中，阿里巴巴对下一代服务框架有了愿景和规划，并开始在内部快速进化，并迅速贡献到Apache社区。就像阿里巴巴一样，其他用户与痛点相关的实际诉求也在开源社区快速积累，形成了一致的方向和技术方案。可以说，Dubbo3的诞生源于庞大的企业用户基数的积累，为了更好地满足他们的实际需求。Dubbo3融合了阿里巴巴HSF2和其他社区企业的大量服务管理经验。目前，Dubbo3已经全面应用于生产实践环境。银行、火币网、平安健康等社区与用户合作形成的良性循环，极大地促进了Dubbo3的发展。阿里巴巴已经将内部维护的HSF2框架完全替换为社区版的Dubbo3。他们的实践经验一方面促进了Dubbo3的稳定性，并且正向开源社区不断输出服务治理的实践经验就足够了。水平扩展百万级集群实例随着微服务实践经验的积累，微服务被拆分成更细的粒度，部署到越来越多的机器实例上，以支持不断增长的业务规模。在众多Dubbo2企业用户中，尤其是以金融、保险、互联网为代表的大型企业，开始遇到集群容量瓶颈（典型案例请参考工商银行实际案例）：数据存储服务发现流程注册中心规模达到容量瓶颈数据注册推送效率严重下降Dubbo流程占用机器资源较多，导致业务资源利用率降低频繁GC影响业务稳定性Dubbo3在设计上很好地解决了这些问题，实现了服务治理（服务发现）通过一种新的设计模型可以平均减少服务发现链路上的数据传输和数据存储约90%；同时，Dubbo3本身在业务流程上变得更轻量、更稳定，实现了50%的资源利用率提升。Dubbo3更大的优势在于其对整体架构稳定性的提升。新的服务发现架构使得评估整个集群的容量和可扩展性变得更加容易和准确。如果将应用开发大致分为业务开发和运维部署两个层次，那么频繁变化的因素包括服务（接口）、应用和机器实例。在2.x时代，这三个因素的增长都会影响到微服务集群的整体容量，尤其是接口增减带来的波动，对整体容量的考核是非常不透明的。在3.0中，集群容量的变化只与应用名称和机器实例这两个因素有关，容量评估的对象往往是应用和实例，因此整个集群变得更加稳定和透明。云原生云原生时代，底层基础设施的变化深刻影响着应用的部署、运维乃至开发过程，也影响着Dubbo3微服务技术方案的选择和部署方式。下一代RPC协议新一代Triple协议以HTTP/2为传输层，具有更好的网关和代理穿透性，原生支持Stream通信语义，兼容gRPC协议。多语言友好性Dubbo3在服务定义、RPC协议、序列化、服务治理等方面都将多语言友好性作为重点考量。目前提供稳定的Java、Golang多语言版本，Rust、Javascript、C/C++、C#等更多语言版本的3.0实现正在开发建设中。KubernetesDubbo3开发的应用可以原生部署在Kubernetes平台上。Dubbo3在地址和生命周期上被设计为与Kubernetes等容器调度平台保持一致；对于想要进一步复用Kubernetes底层基础设施能力的用户，Dubbo3也已经接入了原生的KubernetesService系统。ServiceMeshServiceMesh强调了控制面在微服务治理中的作用，在一定程度上促进了控制面通信协议和职责范围的扩展和标准化；实现透明升级、多语言无意义、无业务入侵等特性。Dubbo3基于自己的思考，提供了DubboMesh的解决方案，强调微服务集群的统一管控。在部署架构方面，既支持sicecar部署架构，也支持无sidecar的proxyless部署架构。用户根据自己的业务特性使用DubboMesh，将会有更多的部署架构选择。异构系统互通我们看到越来越多的异构微服务系统互通需求，比如Dubbo、SpringCloud、gRPC等，有的是因为技术栈的迁移，有的是因为需要实现业务互调后组织的合并。借助新的服务发现模型和灵活可扩展的RPC协议，Dubbo3可以成为Dubbo3未来的发展目标。原文首发于Dubbo官网：https://cn.dubbo.apache.org/z...欢迎在https://github.com/apache/dubbo给DubboStar。搜索并关注官方微信公众号：ApacheDubbo，了解更多行业最新动态，掌握各大厂面试必备的Dubbo技能
