Spring Cloud完全碾压Dubbo？架构师笑而不语丨QCon

编辑 | 关贺宇

微服务是互联网技术飞速变化以及传统架构无法适应多样化需求的背景下诞生的产物。通常情况下，互联网产品具有用户体量大，需求变化多样且个性化的特点。传统的单体服务已经没办法满足开发者的需求，微服务应运而生。

在认识微服务之前，需要先了解一下与微服务对应的单体式架构。在单体式架构中，系统通常采用分层架构模式，按技术维度对系统进行划分，比如持久化层、业务逻辑层、表示层。但是单体式架构存在很多问题，比如系统间以 API 的形式互相访问，耦合紧密导致难以维护；在系统负载增加时，难以进行水平扩展等等。

为了解决这些问题，微服务架构应运而生。微服务提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

Spring Cloud 和 Dubbo 之争

互联网圈对微服务架构选择的争论由来已久，开发者对二者的讨论也一直继续，近些年 Spring Cloud 有碾压 Dubbo 的趋势，你怎么看？

通信方式

Spring Cloud 采用 HTTP 的 REST 方式，而不是 Dubbo 的 RPC 通信方式。这两种通信方式各有优劣。有人说，REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。

这么说，Spring Cloud 更好？

技术发展

从技术发展的角度来讲，Dubbo 最开始的理念非常先进，解决了各大互联网公司服务治理的问题，中小公司也从中受益不少。经过了这么多年的发展，互联网行业不断涌现更多先进的技术和理念，Dubbo 却有点停滞不前。

Spring 推出 Spring Boot/Cloud 也是基于自身的很多原因。Spring 最初推崇的轻量级框架，后来因为集成项目越来越多，配置文件也越来越混乱，原有的理念与现实产生了冲突。于是 Spring Cloud 才产生。

也就是 Spring Cloud 更有前景么？

不足

Dubbo 的不足在于：Registry 严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断。只支持 RPC 调用。使得服务提供方与调用方在代码上产生了强依赖，服务提供者需要不断将包含公共代码的 jar 包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错。Dubbo 现在已经停止维护了，对于技术发展的新需求，需要由开发者自行拓展升级。这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的。

相反 Spring Cloud 自从发展到现在，仍然在不断的高速发展，从 github 上提交代码的频度和发布版本的时间间隔就可以看出，后期 Spring Cloud 的发展会更加完善和稳定。

Dubbo 完全被碾压？