外部开发者一直以来好奇的是：阿里自己有没有在用 Dubbo？会不会用 Dubbo？在刚刚结束的 双11，我们了解到阿里云今年提出了“三位一体”的理念，即将“自研技术”、“开源项目”、“商业产品”形成统一的技术体系，最大化技术的价值。终于，在 2020 的 双11，阿里巴巴经济体也用上了 Dubbo！本文是阿里 双11 在考拉大规模落地 Dubbo3.0 的技术分享，系统介绍了 Dubbo3.0 在性能、稳定性上对考拉业务的支撑。
HSF 是阿里内部的分布式的服务框架，作为集团中间件最重要的中间件之一，历经十多届 双11 大促，接受万亿级别流量的锤炼，十分的稳定与高效。另外一方面，Dubbo 是由阿里中间件开源出来的另一个服务框架，并且在 2019 年 5 月以顶级项目身份从 Apache 毕业，坐稳国内第一开源服务框架宝座，拥有非常广泛的用户群体。
在集团业务整体上云的大背景下，首要挑战是完成 HSF 与 Dubbo 的融合，以统一的服务框架支持云上业务，同时在此基础上衍生出适应用下一代云原生的服务框架 Dubbo 3.0，最终实现自研、开源、商业三位一体的目标。今年作为 HSF&Dubbo 融合之后的 Dubbo 3.0 在集团 双11 落地的第一年，在兼容性、性能、稳定性上面都面临着不少的挑战。可喜的是，在今年 双11 在考拉上面大规模使用，表现稳定，为今后在集团大规模上线提供了支撑。
Dubbo 3.0 总体方案
在上面的方案中，可以看出来我们是以 Dubbo 为核心，HSF 作为功能扩展点嵌入到其中，同时保留 HSF 原有的编程 API，以保证兼容性。为什么我们选择以 Dubbo 为核心基础进行融合，主要基于以下两点的考量：
选定这个方案之后，我们开始朝着这个方向努力，由于 Dubbo 开源已久，不像 HSF 这样经历过超大规模集群的考验验证，那么我们是如何去保证它的稳定性呢？
稳定性
为了保证新核心的稳定，我们从各个方面进行巩固，保证万无一失。
HSF3 共有集成用例数百个，100% 覆盖到了 HSF 的核心功能；HSF3 的单测共有上千个，行覆盖率达到了 51.26%。
为了面对突发的异常情况，我们也做了相应的演练测试，例如 CS 注册中心地址停推空保护测试、异常注入、断网等情况，以此验证我们的健壮性；例如，我们通过对部份机器进行断网，结果我们发现有比较多的异常抛多。
原因是 Dubbo 对异常服务端剔除不够及时，导致还会调用到异常服务器，出现大量报错。
同时，我们也构建了突发高并发情况下的场景，发现了一些瓶颈，例如：
瞬间大并发消耗掉绝大部分 CPU 。我将在下一篇文章中重点解读我们通过混沌测试发现这些问题后是如何解决这些性能瓶颈的。
Dubbo 核心之前未经历过超大规模集团的考验，性能上面必将面临着巨大的挑战；对于 Dubbo 来说，优化主要从地址推送链路和调用服务链路两个链路来进行。对于地址推送链路，主要是减少内存的分配，优化数据结构，减少静态时地址占用内存对应用的影响，从而减少 ygc/fgc 造成的抖动问题。我们利用测试同学提供的风暴程序，模拟了反复推送海量地址的场景，通过优化，120 万个 Dubbo 服务地址常态内存占用从 8.5G 下降到 1.5G，有效降低 GC 频率。
另外一方面，在调用链路上，我们主要对选址过程、LoadBalacer、Filter 等进行优化，总体 CPU 下降达到 20%，RT 也有一个比较明显的下降。
成果
在 双11 考拉零点高峰，某个 Dubbo 接口，总的流量达到了数百万次/每分钟 ,全程稳定顺滑，达到了预定的目标，Dubbo 3.0 是至重启开源以来，首次在这么大规模的场景进行验证，充分证明了 Dubbo 3.0 的稳定性。
结语
在本次 双11 考拉落地 Dubbo 3.0 只是在阿里内部全面落地 Dubbo 3.0 的第一步，现在 Dubbo 3.0 云原生的新特性也在如火如荼的进行开发与验证，如应用级服务发现、新一代云原生通信协议 Triple 等已经开始在集团电商应用开始进行 Beta 试点。
阿里微服务体系完成了通过开源构建生态和标准，通过云产品 MSE、EDAS 等完成产品化和能力输出，通过阿里内部场景锻炼高性能和高可用的核心竞争力。从而完成了三位一体的正向循环，通过标准持续输出阿里巴巴的核心竞争力，让外部企业快速享有阿里微服务能力，加速企业数字化转型！
https://github.com/apache/incubator-dubbo-samples/tree/3.x
覃柳杰（花名：未宇）
Github ID:qinliujie，Apache Dubbo PMC；阿里巴巴微服务框架 HSF 负责人，负责 HSF 研发及 Dubbo 在阿里的落地。
更多企业落地实践内容，可下载云原生架构白皮书了解详情！点击【阅读原文】即可下载！
