前言

前面我们已经了解了微服务的服务分层和技术架构分层，接下来我们就要选择一个框架将微服务进行落地。我们都知道，现在在微服务市场比较流行的有 2 大框架，一个是 Ali 的 Dubbo，一个是 SpringCloud。两者孰优孰劣一直是一个比较令人头疼的问题。

1. 技术选型考虑的要素

其实我们可以先不去考虑是采用 Dubbo 还是 SpringCloud，而是回到技术选型本身，先看下技术选型可能存在的指标，然后根据这些指标来考虑到底是选择那个微服务框架。

可以看到，技术选型需要评估的指标还是非常多的，也是要个很需要经验的决策。要进行大量的调研和输入，根据现有的业务情况作出一个符合自身情况的决策。

我们在做技术选型的时候最忌讳的是临时抱佛脚，在网上随意搜索几个对比文章利用这些碎片化信息来做出决策。一定要确保我们的选型是基于当前业务增长的判断，还要弄清楚业务事实背后的假设。

即使这样，也未必能选出一个最优的方案，但是通过这一系列的评判标准绝对可以挑选出满足当下业务的技术栈。

2. Dubbo 还是 SprigCloud

2.1 Dubbo

Dubbo，阿里巴巴公司开源的一个高性能优秀的服务框架，当前 Dubbo 支撑的阿里分布式应用内支撑万级别的应用数，运行在 20 多万的服务器实例上，每天调用量万亿级别，是国内最高的分布式应用集群。目前 Dubbo 已经被阿里赠予 apache 基金会成为顶级项目。

Dubbo 其实也经历过一段坎坷，中间出现一大段无人维护的阶段，可能是让路于阿里云收费项目 HSF。不过目前已经在 apache 顶级项目下重新维护，目前最新版本是 3.0。

2.2 SpringCloud

SpringCloud 是 Spring Source 的产物，Spring 社区的强大背书可以说是 Java 业务界无人能匹敌的组织，SpringBoot 和 SpringCloud 更是无缝的紧密相连，在 SpringCloud 发展得初期，Netfix 为其提供了强大的技术输出，在一开始的阶段 Netfix 开关套件基本上是 SpringCloud 的核心。不过随着 Netfix 的部分组件不更新，SpringCloud 已经在各个方面提供了替代甚至更强的方案。

如果只是拿两者的背景做比较，前者在国内影响力更大，后者在国外和国内新兴企业中影响力更大。但由于背靠 Spring Source 强大的靠山，在背景上，应该是 SpringCloud 略胜一筹。不过不应该作为选型框架主要依据。

2.3 社区活跃度

有人在 2017 年，Dubbo 还未加入 apache 顶级项目时，有人在做了两个框架在 github 上的活跃度对比，可以看出 SpringCloud 是以小时为活跃维度，而 Dubbo 基本上以年为维度。

但在今天，Dubbo 在加入 apache 顶级项目后，在 github 重新对比，可以看出差距正在缩小

当然真正的活跃不是这么简单就做出评判，不过粗略的观察还是可以得出结论，Dubbo 在社区特别是中国区，活跃已经在恢复。当官方没有维护之后，还是有一些公司对 Dubbo 做了进一步的开发和维护，例如当当基于 Dubbo 研发的分布式框架 Dubbox。

2.4 两者的性能

Dubbo 和 SpringCloud 其实只是解决方案的框架，集中性能的差异主要体现在服务调用和传输协议上，Dubbo 使用的是 RPC 通讯协议，提供了 Dubbo 的序列化，Dubbo 缺省协议采用单一长链接和 NIO 异步通讯（保持连接、轮训处理），使用自定义的报文，适合小数量大并发的服务调用场景，
而 SpringCloud 缺省采用的是 HTTP 协议的 REST API。

网上有人特意做了个模拟测试两者的性能，使用一个 Pojo 对象包含 10 个属性，请求 10 万次，Dubbo 和 SpringCloud 在不同线程数量下，每次请求耗时（ms）

以上图片和测试结果均采自网上

不出意外，采用 HTTP 的 SpringCloud 确实比不过采用 RPC 的 Dubbo。但由此产生了：Http + Json 的 Rest 通信，性能上难堪重用，其实也是一种误读。

评估性能更大的程度是判断 Http 协议的通信对于应用的负载是否会成为真正的瓶颈点。

在大部分的公司网络下，网络消耗并不能算上什么太大的问题。如果真的有问题，SpringCloud 也并不是 Http + Json 强制绑定，也可以选用 Thrift，Protobuf 等高性能 RPC，序列化作为替代方案。

2.5 架构完整性

上述的几点在这次选型中，最多是参考点之一，真正决定选择的是架构的完整性，他决定了是否满足我们的需求。

其实把 SpringCloud 和 Dubbo 进行在架构完整性对比有点不太公平，Dubbo 只是实现了服务治理，而 SpringCloud 到目前为止在 github 上已经有三十多个项目，已经覆盖了微服务架构下的方方面面。在一定得程度来说，Dubbo 是指 SpringCloud 的一个子集，但在选择框架的问题上，方案完整度却恰恰是一个最需要我们重点关注。

在上面章节中，说到了，微服务虽然带来了模块清晰划分，独立部署，技术多样式的好处，但是由于分布式，也带来了非常多的复杂度，这些复杂度，是需要进行治理和必要的组件进行支撑。

以上列举出来一些常用的核心组件，从表格不难发现为何说 Dubbo 只是 SpringCloud 的一个子集，不过有一点必须声明，Dubbo 里面对比项中的” 无 “并不是代表不能实现，只是默认 Dubbo 框架自身没有提供，而我们在市面上还是可以找到很多与之相匹配的开源组件。

例如：

• 服务网关：可以采用 Nginx+lua 作为基础网关，可以起到鉴权，路由等简单网关的规则；
• 断路器 ：可以采用 ali 的 Sentinel,Sentinel 比 Hystrix 功能还要强大，并有控制台；
• 分布式配置 ： 可以采用百度的 Disconf 或者携程的 Apollo 作为分布式配置管理，对比起，SpringCloud 的 Config，Config 是存储和配置在 git 上，使用默认配置不够直观，而 Disconf 和 Apollo 都提供了优秀的控制台，有灰度发布，权限隔离功能更加强大；
• 链路跟踪 ： 可以使用 SkyWalking，目前 SkyWalking 也已经纳入 apache 的顶级项目，这 2 年发展迅速，相比 Zipkin，Cat 更加强大，更不用说 Sleuth；
• 消息总线 ： 可以使用 RabbitMq，采用 AMQP 协议的 RabbitMq 也可以实现消息代理将分布式系统节点串联，达到广播状态；
• 批量任务 ： 可以使用 xxl-job。

你可以认为 Dubbo 是组装电脑，SpringCloud 是品牌电脑。下面给出我们组装完的 Dubbo 和 SpringCloud 的对比，其中选择组装的组件大部分来自国产：

Dubbo 在各个环节我们的选择自由度很高，也可以说，只能外部去选装。但毕竟是外部的选装，例如我们为一台组装电脑选择了一条内存或一块硬盘存在问题导致整台电脑都奔溃。如果你是 DIY 的高手，这些都不是问题，但如果你是一名小白，或对各个组件不是太熟悉，那可能品牌机会更适合你。

SpringCloud 像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有较高的稳定性，但 SpringCloud 的默认组件中也有一些不太好用的组件。

除了以上我们讲的组件的区别，还有一些小的细节，例如

笔者在早年使用 Dubbo 为了实现隐式传参，就对 Dubbo 的源码进行了改动，（因为早点 dubbo 停止了维护，所以进行了局部二次开发），在使用 SpringCloud，发现直接实现 RequestInterceptor 就可以实现，可能 SpingCloud 是后发，所以在一些细节上更加考虑周到，更适合小白的使用。

2.6 学习，招聘成本

应该说，学习成本是 SpringCloud 相比较 Dubbo 是更低的，各种组件基本都是开箱即用，并且依托于 SpringSource 大树，兼容性和可靠性是有保障的，相信写 Java 代码的人无人不熟 Spring。在编码上，依托 SpringBoot，各种组件配置即可使用，很大的降低的学习和入门成本。

3. 小结

关于 Dubbo 和 SpringCloud 的相关概念和对比，上面已经叙述清楚了，至于选型是 选择 Dubbo 还是 SpringCloud，这里得根据自身的情况需求出发，这里不做推荐选择。

笔者之前用的一直都是 Dubbo，但后面去了一家新公司新的团队，选择了是 ali 版本的 SpringCloud，考虑的原因是：新团队这方面相关经验还是比较欠缺，SpringCloud 提供了完整的组件支持，SpringCloud 不失为比较稳妥的选择。

作为后起之秀，SpringCloud 使用简单方便，并且 SpringCloud 也有强大的社区支持，文档方面也是非常完善，新团队没有必要在此投入过多的时间去阅读分散的文档和研究各种开源组件，可以分出精力和时间在业务上。

而且公司还存在其他技术栈的团队，存在接口互调的需求。Dubbo 默认使用的 RPC 并不能很好的实现跨语言，而 SpringCloud 默认 Http REST 本身就是支持跨语言实现。