Dubbo 3.0 前瞻系列 | 2020双11，Dubbo3.0 在考拉的超大规模实践 - GrumpyAmber的个人空间 - OSCHINA - 中文开源技术交流社区

安宇雨 - 随手采集
2020-11-30 08:45:19
随手采集
0000-未整理-等待研究

大咖揭秘Java人都栽在了哪？点击免费领取《大厂面试清单》，攻克面试难关~>>>

前言开发者一直以来好奇的是：阿里自己有没有在用Dubbo，会不会用Dubbo？在刚刚结束的双11，我们了解到阿里云今年提出了“三位一体”的理念，即将“自研技术”、“开源项目”、“商业产品”形成统一的技术体系，最大化技术的价值。终于，在2020的双11，阿里巴巴经济体也用上了Dubbo！本文是阿里双十一在考拉大规模落地 Dubbo3.0 的技术分享，系统介绍了 Dubbo3.0 在性能、稳定性上对考拉业务的支撑。

覃柳杰（花名：未宇）Github ID: qinliujie，Apache Dubbo PMC；阿里巴巴微服务框架 HSF 负责人，负责 HSF 研发及 Dubbo 在阿里的落地。

HSF 是阿里内部的分布式的服务框架，作为集团中间件最重要的中间件之一，历经十多届双十一大促，接受万亿级别流量的锤炼，十分的稳定与高效。另外一方面，Dubbo 是由阿里中间件开源出来的另一个服务框架，并且在 2019 年 5 月以顶级项目身份从 Apache 毕业，坐稳国内第一开源服务框架宝座，拥有非常广泛的用户群体。

在集团业务整体上云的大背景下，首要挑战是完成 HSF 与 Dubbo 的融合，以统一的服务框架支持云上业务，同时在此基础上衍生出适应用下一代云原生的服务框架 Dubbo 3.0,最终实现自研、开源、商业三位一体的目标。今年作为 HSF&Dubbo 融合之后的 Dubbo 3.0 在集团双十一落地的第一年，在兼容性、性能、稳定性上面都面临着不少的挑战。可喜的是，在今年双十一在考拉上面大规模使用，表现稳定，为今后在集团大规模上线提供了支撑。

Dubbo 3.0 总体方案

在上面的方案中，可以看出来我们是以 Dubbo 为核心，HSF 作为功能扩展点嵌入到其中，同时保留 HSF 原有的编程 API，以保证兼容性。为什么我们选址以 Dubbo 为核心基础进行融合，主要这两点的考量：

1.Dubbo 在外部拥有非常广泛的群众基础，以 Dubbo 为核心，符合开源、商业化的目标；

2.HSF 也经历过核心升级的情况，我们拥有比较丰富的处理经验，对于 Dubbo 3.0 新核心内部落地也是处于可控的范围之内。

选定这个方案之后，我们开始朝着这个方向努力，由于 Dubbo 开源已久，不像 HSF 这样经历过超大规模集群的考验验证，那么我们是如何去保证它的稳定性呢？

稳定性

为了保证新核心的稳定，我们从各个方面进行巩固，保证万无一失

1.功能测试

HSF3 共有集成用例数百个， 100% 覆盖到了 HSF 的核心功能；HSF3 的单测共有上千个，行覆盖率达到了 51.26%

2.混沌测试

为了面对突发的异常情况，我们也做了相应的演练测试，例如 CS 注册中心地址停推空保护测试、异常注入、断网等情况，以此验证我们的健壮性；例如，我们通过对部份机器进行断网，结果我们发现有比较多的异常抛多。

原因是 Dubbo 对异常服务端剔除不够及时，导致还会调用到异常服务器，出现大量报错。

同时，我们也构建了突发高并发情况下的场景，发现了一些瓶颈，例如：

瞬间大并发消耗掉绝大部分 CPU 。

3.性能优化

Dubbo 核心之前未经历过超大规模集团的考验，性能上面必将面临着巨大的挑战；对于 Dubbo 来说，优化主要从地址推送链路和调用服务链路两个链路来进行。对于地址推送链路，主要是减少内存的分配，优化数据结构，减少静态时地址占用内存对应用的影响，从而减少 ygc/fgc 造成的抖动问题。我们利用测试同学提供的风暴程序，模拟了反复推送海量地址的场景，通过优化，120万个 Dubbo 服务地址常态内存占用从 8.5G 下降到 1.5G，有效降低 GC 频率