共计 3614 个字符，预计需要花费 10 分钟才能阅读完成。
本文将带你疾速理解 Dubbo3 的设计背景、总体架构与外围个性、与典型用户如阿里巴巴 HSF2 的关系等。也能够通过如下局部理解更多：
小白用户，疾速浏览 Dubbo3 外围个性：
- 下一代通信协议 – Triple
- 百万实例集群的机密 – 利用级服务发现
- Dubbo Mesh
Dubbo3 的兼容性与迁徙老本?
- Java – 迁徙指南
- Golang – 迁徙指南
Dubbo3 相干资源：
- 更多材料，如性能指标、高级个性阐明等请参考 多语言 SDK 实现
背景
Dubbo3 的设计与开发有两个大的背景。
首先，如何更好的满足企业实际诉求。 Dubbo 自 2011 由阿里巴巴募捐开源以来，始终是泛滥大型企业微服务实际的首选开源服务框架。在此期间，企业架构经验了从 SOA 架构到微服务架构变迁，Dubbo 社区本身也在一直的更新迭代以更好的满足企业诉求。然而 Dubbo2 架构上的局限逐步在实践中凸显：
- 协定 ，Dubbo2 协定以性能、简洁著称，但却在云原生时代遇到越来越多的通用性、穿透性问题；
- 可伸缩性 ，Dubbo2 在可伸缩性上仍旧远超很多其余框架，但随着微服务带来更多利用与实例咱们不得不思考如何应答更大规模集群的实战；
- 服务治理易用性 ，如更丰盛的流量治理、可观测性、智能负载平衡等。
其次，适配云原生技术栈的倒退。 微服务让业务开发演进更灵便、快捷的同时，也带来了一些它独有的特色和需要：如微服务之后组件数量越来越多，如何解决各个组件的稳定性，如何疾速的程度扩容等，以 Docker、Kubernetes、Service Mesh 为代表的云原生基础设施为解决这些问题带来了一些新的抉择。随着更多的微服务组件及能力正下沉到以 Kubernetes 为代表的基础设施层，传统微服务开发框架应剔除一些冗余机制，踊跃的适配到基础设施层以做到能力复用，微服务框架生命周期、服务治理等能力应更好地与 Kubernetes 服务编排机制交融；以 Service Mesh 为代表微服务架构给微服务开发带来的新的抉择，Sidecar 给多语言、通明降级、流量管控等带来的劣势，但同时也带来运维复杂性、性能损耗等弊病，因而基于服务框架的传统微服务体系还将是支流，长期仍将占据半壁江山，在长时间内将会维持混合部署状态。
总体目标
Dubbo3 仍旧放弃了 2.x 的经典架构，以解决微服务过程间通信为主要职责，通过丰盛的服务治理（如地址发现、流量治理等）能力来更好的管控微服务集群；Dubbo3 对原有框架的降级是全面的，体现在外围 Dubbo 个性的简直每个环节，通过降级实现了稳定性、性能、伸缩性、易用性的全面晋升。
- 通用的通信协议。 全新的 RPC 协定应摒弃公有协定栈，以更通用的 HTTP/2 协定为传输层载体，借助 HTTP 协定的标准化个性，解决流量通用性、穿透性等问题，让协定能更好的应答前后端对接、网关代理等场景；反对 Stream 通信模式，满足不同业务通信模型诉求的同时给集群带来更大的吞吐量。
- 面向百万集群实例，集群高度可伸缩。 随着微服务实际的推广，微服务集群实例的规模也在不停的扩大，这得益于微服务轻量化、易于程度扩容的个性，同时也给整个集群容量带来了累赘，尤其是一些中心化的服务治理组件；Dubbo3 须要解决实例规模扩大带来的种种资源瓶颈问题，实现真正的有限程度扩容。
- 更丰盛的编程模型，更小的业务侵入。 在开发态业务利用面向 Dubbo SDK 编程，在运行态 SDK 与业务利用运行在同一个过程，SDK 的易用性、稳定性与资源耗费将在很大水平上影响业务利用；因而 3.0 应该具备更形象的 API、更敌对的配置模式、更少的强占业务利用资源、具备更高的可用性。
- 更易用、更丰盛的服务治理能力。 微服务的动静个性给治理工作带来了很高的复杂性，而 Dubbo 这方面始终做的不错，是最早的一批治理能力定义者与实践者；3.0 需面向更丰盛的场景化，提供诸如可观测性、安全性、灰度公布、谬误注入、内部化配置、对立的治理规定等能力。
- 全面拥抱云原生。
面向企业生产实践痛点
Dubbo2 仍旧是国内首选开源服务框架，被广泛应用在互联网、金融保险、软件企业、传统企业等简直所有数字化转型企业中，久经规模化生产环境测验。以 Dubbo2 的贡献者和典型用户阿里巴巴为例，阿里巴巴基于 Dubbo2 在外部保护的 HSF2 框架经验了历次双十一峰值考验，每天数十亿次的 RPC 调用，治理着超过千万的服务实例。在长期的优化和实际积攒中，阿里巴巴有了对下一代服务框架的构想与计划，在外部开始了疾速演进，并疾速的被奉献到 Apache 社区，如同阿里巴巴一样，其余用户的实际诉求与痛点也在开源社区疾速的积攒，造成了统一的方向和技术计划，能够说 Dubbo3 的诞生就来自于超大基数的企业用户积攒，为了更好的满足他们的实际诉求。
Dubbo3 交融了阿里巴巴 HSF2 及其他社区企业的大量服务治理教训，以后 Dubbo3 曾经被全面利用到生产实践环境，用户包含阿里巴巴电商、饿了么、钉钉、考拉、阿里云、小米、工商银行、风火递、安全衰弱等。社区与用户的单干造成的良性循环极大的促成了 Dubbo3 的倒退，阿里巴巴曾经以社区版 Dubbo3 齐全取代了外部保护的 HSF2 框架，他们的实践经验一方面推动 Dubbo3 的稳定性，另一方面正够源源不断的将服务治理实践经验输入到开源社区。
面向百万集群实例，横向可扩容
随着微服务实践经验的积攒，微服务被拆分成更细粒度，部署到越来越多的机器实例，以撑持一直增长的业务规模。在泛滥的 Dubbo2 企业用户中，尤其是以金融保险、互联网为代表的规模化企业开始遇到集群容量瓶颈问题（典型的请参照 工商银行实际案例）：
服务发现过程
- 注册核心数据存储规模达到容量瓶颈
- 数据注册 & 推送效率重大降落
Dubbo 过程
- 强占更多机器资源，导致业务资源利用率升高
- 频繁 GC 影响业务稳定性
Dubbo3 在设计上很好的解决了这些问题，通过全新设计实现的服务治理（服务发现）模型，能够实现服务发现链路上的数据传输、数据存储量均匀降落 90% 左右；同时 Dubbo3 本身在业务过程中变得更轻量、更稳固，实现晋升资源利用率 50%。
Dubbo3 一个更大的劣势在于其对整体架构稳定性的晋升，新的服务发现架构使得对于整个集群容量、可伸缩性评估变得更容易、更精确。
如果将利用开发粗略划分为业务开发、运维部署两个档次，其中变动比拟频繁的因素包含服务（接口）、利用、机器实例。在 2.x 时代，所有这三个因素的增长都会影响微服务集群的总体容量，尤其是接口增减带来的稳定，对整体容量评估是十分不通明的。而在 3.0 中集群容量变动仅与利用名、机器实例两个因素相干，而容量评估的对象往往都是利用与实例，因而整个集群变的更稳固通明。
云原生
在云原生时代，底层基础设施的改革正深刻影响利用的部署、运维甚至开发过程，往上也影响了 Dubbo3 微服务技术计划的选型与部署模式。
下一代 RPC 协定
新一代的 Triple 协定基于 HTTP/2 作为传输层，具备更好的网关、代理穿透性，原生反对 Stream 通信语义，兼容 gRPC 协定。
多语言敌对
Dubbo3 从服务定义、RPC 协定、序列化、服务治理等多个方面都曾经将多语言敌对性作为重点考量因素，目前提供了 Java、Golang 稳固的多语言版本，更多语言版本的 3.0 实现如 Rust、Javascript、C/C++、C# 等在开发建设中。
Kubernetes
Dubbo3 开发的利用能够原生部署到 Kubernetes 平台，Dubbo3 在地址、生命周期等已设计可与 Kubernetes 等容器调度平台对齐；对于要进一步复用 Kubernetes 底层基础设施能力的用户来说，Dubbo3 也已对接到了原生的 Kubernetes Service 体系。
Service Mesh
Service Mesh 强调管制面在微服务治理中的作用，在肯定水平上推动了管制面通信协议、职责范畴的扩大与标准化；传统 Mesh 架构下的 Sidecar 模型强调旁路代理对于流量的对立管控，以实现通明降级、多语言无感、无业务侵入等个性。
Dubbo3 提供了基于本身思考的 Dubbo Mesh 解决方案，强调了管制面对微服务集群的对立管控，而在部署架构上，同时反对 sicecar 与无 sidecar 的 proxyless 部署架构，应用 Dubbo Mesh 的用户基于本身的业务特点将有更多的部署架构抉择。
异构体系互通
咱们正看到越来越多的异构微服务体系互通的诉求，典型如 Dubbo、Spring Cloud、gRPC 等。有些是因为技术栈迁徙，有些是组织合并后须要实现业务互调，Dubbo3 借助于新的服务发现模型以及可灵便扩大的 RPC 协定，能够成为 Dubbo3 将来的倒退指标。
原文首于 Dubbo 官网：https://cn.dubbo.apache.org/z…
欢送在 https://github.com/apache/dubbo 给 Dubbo Star。
搜寻关注官网微信公众号：Apache Dubbo，理解更多业界最新动静，把握大厂面试必备 Dubbo 技能
