共计 3120 个字符，预计需要花费 8 分钟才能阅读完成。
简介：一个新的里程碑！
一、背景
自从 Apache Dubbo 在 2011 年开源以来，在一众大规模互联网、IT 公司的实际中积攒了大量教训后，Dubbo 凭借对 Java 用户敌对、功能丰富、治理能力强等长处在过来获得了很大的胜利，成为国内外热门支流的 RPC 框架之一。
但随着云原生时代的到来，以 Apache Dubbo、Spring Cloud 等为代表的 Java 微服务治理体系面临了许多新的需要，包含冀望利用能够更快的启动、利用通信的协定穿透性能够更高、可能对多语言的反对更加敌对等。例如 Spring 也在往年推出了其基于 GraalVM 的 Spring Native Beta 解决方案，领有毫秒级启动的能力、更高的解决性能等优化晋升。
这样的背景对下一代 Apache Dubbo 提出了两大要求：一是要保留已有的开箱即用和落地实际背景下积攒的长处，这也是泛滥开发者所冀望的；二是尽可能地遵循云原生思维，能更好的复用底层云原生基础设施并且更贴合云原生的微服务架构。
二、拥抱云原生
在现在的大背景下，Apache Dubbo 3 抉择全面拥抱云原生，将 Dubbo 的架构降级，提出了全新的服务发现模型、下一代 RPC 协定和云原生基础设施适配等优化计划。
1、全新服务发现模型（利用级服务发现）
利用级注册模型
以 Dubbo 原有的设计，存储在注册核心中的数据会在很大水平上存在反复的内容，这其实节约了一部分的存储。而当整个集群的规模足够大的时候，因为服务注册发现是服务维度的，注册核心的数据量就会爆发式地增长。
以后同样是微服务治理工具的 Spring Cloud 和 gRPC 都是基于利用级的服务发现，如果仍应用接口级别的注册形式，Dubbo 就很难和他们进行互通。但如果 Dubbo 也能够像 Spring Cloud 一样以服务级注册，那么在异构体系下将能够很轻松地工作起来。
异构下部署计划
利用级服务发现机制是 Apache Dubbo 面向云原生走出的重要一步，它帮 Apache Dubbo 买通了与其余微服务体系之间在地址发现层面的鸿沟，也成为 Apache Dubbo 适配 Kubernetes Native Service 等基础设施的根底。
基于利用级服务发现，注册核心的数据将被从新组织，注册核心的压力大大加重。同时，因为地址量减少了，利用本身的内存耗费也能够大幅升高。
性能晋升
在个别状况下，利用中存储的地址量能够升高约一半，针对上游利用大规模部署的场景（比方部署了 1000 个节点、提供了 50 个服务）甚至能够达到 95% 以上，这对于外围利用的内存压力环境带来的优化是微小的。
2、下一代 RPC 协定 —— Triple
在云原生时代，Dubbo RPC 协定次要面临两个挑战：
1、生态不互通，Dubbo 协定基于二进制流定制了与 RPC 强绑定的外围语义，包含协定头、标记位、申请 ID 以及申请 / 响应数据等。而对于越来越多的云原生治理设施，要让他们都“读”懂 Dubbo 的二进制“语义”并不容易。
2、因为协定设计的问题，Dubbo 协定的协定头已无奈再承载更多的元数据信息。而对于 Mesh 等网关型组件，如果想要对数据进行治理就须要对残缺的数据包进行解析能力获取到必要的元数据信息（如 RPC 上下文），从性能到易用性方面都会面临挑战。
Dubbo 协定通信形式
在反对已有的性能和解决存在的问题的前提下，Apache Dubbo 3 提出了下一代 RPC 协定——Triple。
基于 Tripe 协定，咱们冀望能够解决这些问题：
1、跨语言互通的问题。传统的多语言多 SDK 模式和 Mesh 化跨语言模式都须要一种更通用易扩大的数据传输格局；
2、提供更欠缺的申请模型。除了 Request/Response 模型，还应该反对 Streaming 和 Bidirectional；
申请模型示意图
3、易扩大、穿透性高。包含但不限于 Tracing / Monitoring 等反对，也应该能被各层设施辨认，网关设施等能够辨认数据报文，对 Service Mesh 部署敌对，升高用户了解难度；
4、反对 Java 用户无感知降级。不须要定义繁琐的 IDL 文件，仅须要简略的批改协定名便能够轻松升级到 Triple 协定。
基于这些冀望，咱们感觉 HTTP/2 作为底层通信协议，应用 protobuf 作为序列化协定的组合是最正当的，这套组合计划也是 gRPC 协定应用的计划。所以对于 Triple 协定来说，咱们能够基于 gRPC 协定进行演变，以满足 Apache Dubbo 已有的优良个性，这同时也保障了在生态系统上新协定和 gRPC 是可能互通和共享的。
Triple 协定通信形式
3、云原生设施接入
针对于 Kubernetes 的场景，Apache Dubbo 3 为此做了两方面的接入：
一是原生反对与 Kubernetes Pod 生命周期对齐，基于 Dubbo QoS 机制，Kubernetes 可能感知到运行在 Pod 容器中的 Dubbo 利用以后是什么状态，而且得益于 Dubbo SPI 机制用户能够自定义探针检测的维度，实现框架和业务的生命周期都达到对立。
第二是 Dubbo 也将反对接入 Kubernetes Native Service 体系，原生反对基于 Kubernetes API Server 和 DNS 的服务发现体系，实现部署架构下的服务概念与 Dubbo 中的服务概念进行对齐。
Kubernetes 架构下部署计划
而对于 Service Mesh 体系，如果利用应用 Apache Dubbo 2 想要部署以 Mesh 形式部署，须要应用 Sidecar 对 Dubbo 流量进行拦挡，而同时因为 Dubbo 自身是具备肯定的治理能力的，从利用来说会多做了很多无用的事件，从集群的角度来说会造成调用的错乱。
基于此，Apache Dubbo 3 提出了两种部署模式，一种是配合 Sidecar 部署的 Thin SDK 模式、另一种是间接接入管制面的 Proxyless Mesh 模式。
Dubbo 3 在 Mesh 场景下部署架构
除了部署架构的接入，在 Apache Dubbo 3 中还定义了一套面向云原生流量治理，反对传统 SDK、Mesh 场景的对立治理规定。
Apache Dubbo 3 冀望应用这一套规定，便能够实现如金丝雀公布、A/ B 测试等丰盛的路由语义，只须要配置一套规定，写入对立的管制面，就能够对立地管制所有集群。这样无论应用 Kubernetes 间接部署、亦或者是 Mesh 场景下应用 Thin SDK 或 Proxyless 混合部署甚至是用户间接手动部署集群均能够被同一套规定所管制，实现定义一次，到处应用的指标。
三、将来瞻望
Apache Dubbo 3.0.0 是捐给 Apache 后的一个里程碑版本，代表着 Apache Dubbo 全面拥抱云原生的一个重要节点。
在 2021 年 11 月咱们会公布 Apache Dubbo 3.1 版本，届时咱们会带来 Apache Dubbo 在 Mesh 场景下部署的实现与实际。
在 2022 年 3 月咱们会公布 Apache Dubbo 3.2 版本，在这个版本中咱们将带来全新的大规模利用部署下智能流量调度机制，进步零碎稳定性与资源利用率。
Apache Dubbo 3 目前曾经和阿里巴巴团体外部的 RPC 框架实现了交融，冀望用它来解决外部落地问题，做到技术栈对立。将来，Apache Dubbo 3 将大规模落地阿里团体，承载 618、双十一等简单业务场景。
社区衷心地心愿欢送大家向社区提交 issue 和 PR，社区的同学会尽快进行 review 和回复。另外，社区会尽可能保障一个较短的发版周期，及时对已有的问题进行修复。
同时在 Apache Dubbo 3 开始，社区也会采纳更凋谢的态度看待生产环境下的定制需要，咱们欢送大家将本人的定制化实现奉献给开源社区，dubbo-spi-extensions 仓库将来会对这些定制化进行反对。
原文链接
本文为阿里云原创内容，未经容许不得转载。
