Dubbo在Java微服务生态中还有多少份额

摘要：## Dubbo在Java微服务生态中还有多少份额？说句大实话 前两天和几个做架构的朋友撸串，聊到微服务选型，有人突然问：“现在还有人用Dubbo吗？感觉身边全是Spring Cloud了。” 这话一出，桌上安静了两秒，然后大家开始七嘴八舌——有意思的是…

Dubbo在Java微服务生态中还有多少份额？说句大实话

前两天和几个做架构的朋友撸串，聊到微服务选型，有人突然问：“现在还有人用Dubbo吗？感觉身边全是Spring Cloud了。” 这话一出，桌上安静了两秒，然后大家开始七嘴八舌——有意思的是，说“用”和“不用”的，差不多各占一半。

这场景你应该不陌生吧？技术圈的风向变得太快，今天还是“当红炸子鸡”，明天可能就成了“时代的眼泪”。那Dubbo到底怎么样了？我翻了翻近两年的开发者调查报告、看了不少开源社区的讨论，甚至问了一圈在一线“打仗”的朋友，今天咱就抛开那些“生态”、“赋能”的黑话，聊点实在的。

先泼盆冷水：份额确实被挤占了，但没“凉”

先说结论：跟它自己最风光的时候比，份额是下降了；但在整个Java微服务的大盘子里，它依然是个不容忽视的玩家，而且活得挺结实。

为啥这么说？咱们看数据（别怕，不堆数字）。最近一份面向国内Java开发者的调研显示，在“主要使用的微服务框架”这个多选题里，Spring Cloud系列（包括Alibaba那套）的占比确实一骑绝尘，超过了60%。而Dubbo呢？大概在20%-25%这个区间徘徊。

——看到这你可能会想，这不就是“others”了吗？

别急。你得看这数据背后的“水分”。首先，Spring Cloud这个名头太响，很多项目哪怕只用了里面一个组件（比如就用了Feign做声明式调用），填问卷时也会勾选它。这就像你去超市买了瓶酱油，别人问你今天买了啥，你说“我去超市了”一样，没错，但不精确。

其次，Dubbo的用户，往往是那些“沉默的大多数”。他们可能是一个庞大的电商系统、一个支付核心、或者一个日活千万的社交应用的后台团队。这些系统稳定跑了五六年甚至更久，架构稳定，性能够用，业务也没逼着他们非得折腾重构。你很少会在各种技术大会上看到他们出来讲“我们如何用Dubbo撑住了双十一”，因为他们没空——系统稳定不出事，就是最好的KPI。

我见过最典型的一个例子，是上海一家互联网金融公司的哥们说的：“我们的交易核心链路，从15年到现在就是Dubbo。你说换Spring Cloud？老板第一个问题就是：花了钱、花了人、冒着线上风险，能带来多少收入增长？答不上来，那就接着用。”

说白了，技术选型很多时候不是技术问题，是生意问题。 Dubbo在它最擅长的领域——高性能RPC通信、服务治理——依然能打，这就够了。

Dubbo的“钉子户”们，到底图个啥？

那么，哪些场景下，大家还会死守着Dubbo不放？从我接触的情况看，主要是这几类：

1. 历史包袱重的“巨无霸”系统：这个前面提了，很多早期（2015-2018年）的互联网公司，技术选型就是Dubbo。整套运维体系、监控告警、人员技能都围绕它构建。推倒重来？成本高到吓人。这类系统，往往是公司的核心赚钱业务，稳定性压倒一切。Dubbo久经考验，他们用着放心。

2. 对性能有“变态级”要求的场景：虽然Spring Cloud性能也不差，但Dubbo在纯RPC通信的性能损耗上，尤其是高并发、低延迟的场景下，依然有它的优势。比如一些量化交易、实时风控的系统，他们对毫秒甚至微秒的延迟都斤斤计较。有个做游戏服务器的朋友跟我吐槽：“我们用Spring Cloud Gateway试过，压测下来比Dubbo+自定义协议，平均延迟多了那么一点点。就这一点点，在我们这儿就是不行。”

3. 与阿里云生态深度绑定的用户：Dubbo现在是Apache顶级项目，但它的“亲爹”毕竟是阿里。如果你公司大部分业务都跑在阿里云上，用了EDAS（企业级分布式应用服务）这类产品，那么用Dubbo几乎是最顺理成章、运维最省心的选择。云厂商的“全家桶”诱惑力，懂的都懂。

4. 就喜欢“轻量”和“直接”的团队：Spring Cloud好，但它也确实重。一套完整的体系下来，组件一大堆。有些团队就觉得，我就要个服务注册发现和RPC调用，整那么复杂干嘛？Dubbo核心功能明确，架构清晰，学习曲线相对平缓，对于中小型项目或者团队技术栈比较单一的，反而更友好。

（插句私货：我见过有些团队为了“技术先进”硬上Spring Cloud全家桶，结果光配置各种组件就掉坑里爬不出来，最后项目延期。这真不如一开始就用更熟悉的工具。）

Spring Cloud就那么“香”？Dubbo的翻身仗在哪？

当然，我们必须承认，Spring Cloud能成为主流，不是没有道理的。它那种“约定大于配置”的哲学，丰富的组件（虽然你可能用不全），以及和Spring Boot无缝集成的体验，对于快速启动新项目、统一技术栈来说，诱惑太大了。特别是对于从零开始的团队，选Spring Cloud几乎是“政治正确”。

那Dubbo就坐以待毙？也不是。

最近两年，Dubbo 3.x版本的推进，能看出它很想打一场翻身仗。最大的变化，就是拥抱了应用级服务发现和云原生。以前Dubbo主要搞接口级服务发现，这在超大规模下有点吃力。现在向主流看齐，支持了和Spring Cloud、Kubernetes Service更好的集成。意思很明确：“哥们儿也能玩云原生，别老把我当旧时代的产物。”

另外，Dubbo 3在通信协议上也做了大升级，默认的Triple协议基于gRPC，更好地支持跨语言、网关穿透。这算是补上了一块曾经的短板。

不过，这些新特性要真正转化为市场份额，需要时间。它面临的最大挑战，不是技术不先进，而是“认知惯性”。很多新一代的开发者，入门微服务就是Spring Cloud，他们对Dubbo的印象可能还停留在“古老的RPC框架”上。改变这种印象，比发十个新版本都难。

所以，到底该怎么选？给你点不成熟的小建议

行了，分析了一堆，如果你正在做技术选型，到底该咋办？我斗胆给几个建议，不一定对，供你拍砖：

• 如果是全新项目：团队对Spring生态熟悉，追求快速开发、生态丰富，就选Spring Cloud（或Spring Cloud Alibaba）。这是最稳妥、招人最容易的路。
• 如果是遗留系统改造或特定领域：系统本来就是Dubbo的，别瞎折腾，继续用，深入优化。如果是金融、交易等对性能极其敏感的场景，可以认真评估Dubbo 3。
• 别太纠结“份额”：份额是市场的事，稳定和合适才是你的事。一个用了多年、稳如老狗的Dubbo系统，远比一个为了追新而漏洞百出的“时髦”架构有价值。
• 亲自试试：别光听人说。用你最熟悉的业务场景，分别搭个Demo压一压，看看监控数据，感受一下开发体验。你的真实感受，比任何调研报告都准。

最后说句大实话：技术栈的“流行度”就像时尚圈的风潮，来回变。 今天Spring Cloud是顶流，明天可能又有新玩意出来。作为工程师，比追逐潮流更重要的，是理解每个工具背后的设计思想，搞清楚你业务真正的痛点是什么。

Dubbo的份额或许不再是第一，但只要那些追求极致性能、手握历史遗产、崇尚简单直接的团队还在，它的位置就依然牢固。它可能不再是聚光灯下的主角，但绝对是幕后不可或缺的实力派。

这事儿，你怎么看？你们公司用的是啥？评论区唠唠。