作者 | 郭浩（项升） 阿里巴巴经济体 RPC 框架负责人
导读：本文整理自作者于 2020 年云原生微服务大会上的分享《Dubbo3.0 - 开启下一代云原生微服务》，主要介绍了关于思考 rpc 框架层面，功能演进的方向是什么？以及怎么更好地支持云上的多语言开发的新思考。
看到这个题目，大家可能会有几个问题，比如，什么是云原生微服务？Dubbo3.0 是什么？和目前的 Dubbo2.0 有什么区别？用了 Dubbo3.0 会带来哪些业务视角的好处？后面的分享会对这些问题逐一解答。
这次分享分为以下几个环节：
Dubbo 的演进历史
Dubbo 的开源现状
定义 Dubbo3.0
分享 Dubbo 3.0 目前取得的一些成果
考虑到有些同学对 Dubbo 可能不太熟悉，在介绍背景之前，我先简单介绍一下 Dubbo 是什么。简单地说，Dubbo 是基于 Java 的 RPC 框架。一个 RPC 框架至少由数据格式、传输协议和连接管理组成，这三点也是构成核心。Dubbo 能够被广泛应用主要有两个原因：
一方面是较好的插件机制支撑了多种扩展，这些扩展在不同业务场景和基础架构中能分别发挥最大优势；
另一方面不同于普通的 RPC 框架，Dubbo 的服务治理功能让其在易用性方面脱颖而出，比如路由规则能够支持灵活多样的运行时动态路由，可以基于此功能实现灰度、ABTest、流量回放等功能。
Dubbo 发展历程
简单介绍完 Dubbo，现在让我们一起回顾一下 Dubbo 的历史。
在 2008 年，Dubbo 作为阿里巴巴内部 SOA 解决方案横空出世。业务的急速发展带来了强烈的服务化需求，只用了两年的时间 dubbo 就在内部大面积落地，日均调用量超过了 30 亿。经过落地过程中不断的打磨，Dubbo 无论是在性能上还是在扩展性方面，都成为了当时遥遥领先的 RPC 框架。为了更好地回馈开发用户和其他有服务化需求的公司，在 2011 年 Dubbo 选择了开源，并发布了 2.0.7 版本作为开源的第一个正式版本。
开源后 Dubbo 蓬勃发展，社区活跃，获得了开发者的一致好评。2017 年 9 月，阿里巴巴宣布重启 dubbo 的开源维护，重启开源后，解决了积累很久的 pull request 和 Issue ，以及之前一些公司不得不开始自己维护 dubbo 的私有分支也逐步合入了主干。同时，与社区进一步的互动，也会激发 dubbo 团队对产品的灵感。
目前 Dubbo 团队就是阿里巴巴内部负责服务框架的团队，我们在大流量、大规模集群、服务治理领域有着丰富的实践，这些经验已经在有序地回馈给社区。重启开源后发布的 2.7.x 版本带了了很多新的特性，比如 JDK8 支持，完整的异步支持，以及元数据的精简和抽象。在今年，我们启动了另外一个新的历程碑 —— Dubbo3.0，这也会带领 Dubbo 走向下一个阶段，即云原生微服务。
Dubbo 开源现状
简单介绍完 Dubbo 的历史，下一步我们来走进 Dubbo 的开源现状。
Dubbo 目前有 57 位 committer 和 379 位 contributor 。根据 X-lab 开放实验室最新发布的《2020 年微服务领域开源数字化报告》，Dubbo 的开源活跃度全球排名 693，在微服务框架中排名第五。整个社区蓬勃发展，来自外部的代码贡献量已经超过来自阿里员工的贡献量。也正是由于有这么活跃的社区，Dubbo 目前支持 6 种语言和 30 多个生态项目。
数据来源《2020 年微服务领域开源数字化报告》，公众号后台回复关键词“微服务报告”获取报告全文。
作为国内 RPC 框架的领跑者， Dubbo 也在被 Spring Cloud Sleuth、Zipkin、Envoy、Mosn 等标杆项目官方集成。Dubbo-go 子社区是社区演进的另一个探索和优秀实践。Dubbo-go 子社区由官方引导，完全社区化运作和开发，前不久发布的 Dubbo-go 1.5 版本在功能上已经完全对齐 Dubbo-java 2.7 版本，后续的 Dubbo3.0 也会包含 Dubbo-go 3.0 ，让我们拭目以待。
从数据上看， Dubbo 目前有 33k stars 和 21k forks，分别位于 github java 项目前十和前三，用户的认可带来了社区的活跃，而活跃的社区则会以高频率的版本更新带来更多新的、有用的特性来彰显其旺盛的活力。目前已经登记的 Dubbo 企业用户超过了 200 个，其中有 30 多个企业成为了 Dubbo 的生态合作伙伴。
有了这些公司的帮助， Dubbo 在设计、开发、测试、灰度上线的整个流程都有了更强有力的保障。让使用了 Dubbo 的应用跑的更快更稳定一直是 Dubbo 社区不变的追求。
从功能上看，Dubbo 3.0 完成后的功能将涵盖从开发人员直接接触的 API 层到底层传输的完整链路。
API 层将包括基于 IDL 的完整数据交换格式打通，这会带来两方面的好处：
一是统一的 IDL 模型可以生成统一的 client stub 和 server stub，这些 stub 能直接进行非反射调用，会在性能上有很大的提升；
第二点是对异步和 streaming 的原生支持能够给用户更多的选项，根据不同的业务场景选择更方便的用法。
第二层是对于注册中心、元数据中心和配置中心的扩展。注册中心和配置中心基本支持了所有业界主流的实现，元数据中心是 Dubbo 2.7 新抽象出的组件，负责元数据的存取。这里的元数据包括服务的调用配置，如超时时间，序列化方式，协议等，以及对服务方法签名的抽象，方便 Dubbo 实现跨框架和跨语言调用。
集群层是 Dubbo 的一个主要亮点，除了支持各种重试策略外，Dubbo 也提供了各种场景下的负载均衡器，比如随机和权重。值得一提的是，Dubbo3.0 将带来 pull-based 的自适应负载均衡，这将显著提升分布式集群的性能和效率。
再下一层是协议层，协议层是 RPC 框架的内核部分，一般分为应用层协议和传输层协议。应用层协议 Dubbo3.0 支持 GRPC / Redis / REST 等主流协议以及 Dubbo 原生的 Dubbo2.0 协议。传输层支持 HTTP / HTTP2 和一些自定义的协议如 RSOCKET。序列化方面，Dubbo 除了支持 hessian 、Java 外，还支持 protobuf，这对于性能和跨语言都有着巨大的意义。
看完了 Dubbo 3.0-java 的功能图，我们再来看一下 Dubbo-go 的功能图。可以看到，从分层到实现， Dubbo-go 已经基本和 JAVA 对齐，后面的 3.0 版本也会和 JAVA 齐头并进，共同迈向云原生。
Dubbo3.0-下一代云原生微服务
介绍完了 Dubbo 的现状，下面我们进入今天的主题：Dubbo3.0 -下一代云原生微服务。
一个新架构或新技术的出现一定会伴随特定的发展趋势。
目前我们可以看到的几个趋势是 K8s 成为资源调度的事实标准、Mesh 化成为主流以及规模上的急速增长。这些趋势的存在对 Dubbo 提出了更高的要求:
首先，用户如何在 K8s 上更方便的部署和调用 Dubbo 服务是必须要解决的问题，要解决这个问题，统一的协议和数据交换格式是必须前提；
其次，Mesh 化的流行带来了多元化问题，即原生 Dubbo 和 Mesh 化 Dubbo 如何共存，多语言的场景如何支持；
第三点，规模的增长会给整个 Dubbo 架构带来更大的挑战，无论是注册中心等组件，还是客户端，都会有更多的数据和调用量。如何在保持稳定的前提下，提供更高效的服务是 Dubbo 演进的重中之重。
这些云原生时代带来的挑战，促成了 Dubbo 的下一代定义。新协议、K8s 基础架构支持、多语言支持和规模化支持四个子项目共同组成了 Dubbo3.0 。下面我们将走进 Dubbo3.0，看看具体有哪些新特性。
1. 下一代 RPC 协议
首先我们从协议开始。
大家可以看到，这是 Dubbo2.0 的协议。从功能上看， Dubbo2.0 提供了 RPC 的核心语义，包括协议头、标志位、请求 ID 以及请求/响应数据。在云原生时代，2.0 协议主要面临两个挑战：
一是生态不互通，用户很难直接理解二进制的协议；
第二是对 Mesh 等网关型组件不够友好，需要完整的解析协议才能获取到所需要的调用元数据，如一些 RPC 上下文，从性能到易用性方面都会面临挑战。
那么，在支持已有的功能和解决存在的问题的前提下，下一代的协议需要有哪些特性呢？
首先，协议需要解决跨语言互通的问题，传统的多语言多 SDK 模式和 Mesh 化跨语言模式都需要一种更通用易扩展的数据传输格式；
其次，协议应该提供更完善的请求模型，除了 Request/Response 模型，还应该支持 Streaming 和 Bidirectional；
第三点，在性能上，新的协议应该保留 request Id 机制，以避免 HOL 带来的性能损耗；
最后，新协议应该易扩展，包括但不限于 Tracing/ Monitoring 等支持，也应该能被各层设备识别，降低用户理解难度。
基于这些需求，HTTP2/protobuf 的组合是最符合的。提到这两个，大家可能很容易想到 GRPC 协议。那新一代的协议和 GRPC 的关系是什么呢？
首先，Dubbo 新协议是基于 GRPC 扩展的协议，这也保证了在生态系统上新协议和 GRPC 是能够互通和共享的；
其次，在这个基础上，Dubbo 新协议将更原生地支持 Dubbo 的服务治理，提供更大的灵活性；
在序列化方面，由于目前大多数应用方还没有使用 Protobuf ，所以新协议会在序列化方面给予足够的支持，平滑的适配现有序列化，方便迁移到 Protobuf；
在请求模型上，新协议将原生支持 Reactive，这也是 GRPC 协议所不具备的。
2. 应用级注册发现
Dubbo3.0 第二个内容是应用级注册发现。
熟悉 Dubbo 的同学都知道，Dubbo 目前的注册发现都是接口级别的。也就是同一个应用发布的多个服务会在注册中心注册多份数据，这些数据彼此独立，方便进行服务化改造和接口迁移。为什么要提出应用级注册发现呢？
主要有两个原因：
一是现有生态系统的互通，包括 Spring cloud 和 K8s 都是基于实例，也就是应用级别进行的注册发现，Dubbo 要成为连接异构系统最好用的 RPC 框架就需要支持实例粒度；
第二个原因是从规模上看，更大规模的增长会带来元数据的极速膨胀，这会给注册中心和客户端带来更大的内存占用。按照现有数据分析，如果升级到应用级注册发现，以平均发布 50 个服务的应用为例，将减少 60% 的内存占用和注册中心数据。以发布超过 10k 接口的平台型应用为例，这些数据可降低 90%。
可以看到，应用级注册发现带来的优化是十分显著的。由于应用级注册发现目前已经基本开发完毕，下面我们可以简单介绍下它的原理。
首先要解决的一个问题是如何保证平滑迁移，用户基于接口的配置怎么映射到应用上去。
这里我们抽象出了元数据中心来管理接口到应用的映射以及应用级的元数据。在部署态，Dubbo 框架会自动上报这个关系到元数据中心。而运行态用户侧的配置和服务治理则通过这份映射关系重新将应用粒度映射到接口粒度。涉及到最核心的部分——选址也是分为两部分，应用级选址和接口级选址同时存在，方便进行服务治理。
3. K8s 云原生支持
Dubbo3.0 第三个内容是 K8s 云原生支持。
这里主要包括两部分内容：
一是需要对齐 K8s 的生命周期，能够让 Dubbo 服务原生的在 K8s 体系内注册和发现；
第二则是对 Mesh 的支持。上面在协议那里我们已经讲到，新协议通过使用 HTTP2 进行 header / payload 分离解决了网关需要解析完整协议的问题。另外一个问题则是服务注册发现和治理，注册发现需要 Dubbo 能够在 Mesh 的 xDS 体系内作为数据面打通。治理则需要将原有的规则逐步迁移至基于 YAML 的剔除 IP 依赖的规则。最终的形态将是原生的 Dubbo 服务能够和基于 thin SDK 的 Dubbo + Mesh 完美互通和进行服务治理。
4. 柔性增强
Dubbo3.0 最后一部分是柔性增强。
柔性增强要解决的问题有两个：
一是在节点异常的情况下，分布式服务能够保持稳定，不出现雪崩等问题;
二是对于大规模的应用，能够以最佳态运行，提供较高的吞吐量和性能。
从方法上看，Dubbo3.0 的柔性增强会以面向失败设计为理念，提供包括精准容量评估、自适应限流、自适应负载均衡的支持，自底向上的分步构建大规模可靠应用。从单一服务的视角看，服务是压不垮的，稳定的。
从分布式视角看，复杂的拓扑不会带来性能的下降，分布式负载均衡能够以最优的方式动态分配流量，保证异构系统能够根据运行时的准确服务容量合理分配请求，从而达到性能最优。
Dubbo3.0 路线图
介绍完了 Dubbo3.0 的主要内容，下面我们来看一下 roadmap。
在接下来的 9 月份，应用级注册发现会同时在阿里巴巴内部和外部公司同时大规模落地。今年双十一前会交付云原生服务治理规则。到明年的 3 月份，开源侧的新协议支持功能基本完备。明年的 6 月份，云原生 K8s 的支持和 Mesh 支持功能完备，开始试点。柔性增强将在 2022 年的 3 月份全面落地，请拭目以待。
看了 roadmap ，大家可以发现，Dubbo3.0 已经是运行态。
首先，基于 Dubbo3.0 核心的 HSF3.0 在阿里巴巴内部大规模落地，内外统一的路线不仅仅是对 Dubbo 质量的肯定，也是对社区用户的保障和回馈。
后续我们会将内部的大规模高并发经验继续输出到 Dubbo 开源侧，也会以最高的质量来保证 Dubbo 的可靠演进。Dubbo 3.0 的应用级注册发现功能也在内部和开源侧同时灰度试点。在协议侧，新协议已经在阿里巴巴和蚂蚁的互通中得到广泛应用，内部实践的经验将更好的服务开源侧协议演进。
最后，欢迎大家参与 dubbo 的社区，分享你们在实践中的经验，反馈碰到的问题，携手让 Dubbo 发展的更好。
公众号后台回复 818 即可获取直播回看地址和大会 PPT 合集。
本文分享自微信公众号 - K8S中文社区（k8schina）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
来源：oschina
链接：https://my.oschina.net/u/4586894/blog/4537526