RPC 对比 REST

由于 Dubbo 是基础框架，其实现的内容对于我们实施微服务架构是否合理，也需要我们根据自身需求去考虑是否要修改，比如 Dubbo 的服务调用是通过 RPC 实现的，但是如果仔细拜读过 Martin Fowler 的 microservices 一文，其定义的服务间通信是 HTTP 协议的 REST API。那么这两种有何区别呢？

服务提供方与调用方接口依赖方式太强

我们为每个微服务定义了各自的 service 抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并 install 之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而 REST 接口相比 RPC 更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然 REST 接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合 swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST 方式的服务依赖要比 RPC 方式的依赖更为灵活。

服务对平台敏感，难以简单复用

通常我们在提供对外服务时，都会以 REST 的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在 Dubbo 中我们要提供 REST 接口时，不得不实现一层代理，用来将 RPC 接口转换成 REST 接口进行对外发布。若我们每个服务本身就以 REST 接口方式存在，当要对外提供服务时，主要在 API 网关中配置映射关系和权限控制就可实现服务的复用了。

Dubbo 实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。

而 Spring Cloud 依然发扬了 Spring Source 整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了 Spring Boot 简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些。所以，如果选择 Dubbo 请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难。而如果选择 Spring Cloud，相对来说每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。