Java 微服务框架选型（Dubbo 和 Spring Cloud）

微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

以往我们开发应用程序都是单体型（可以看作是一个怪兽），虽然开发和部署比较方便，但后期随着业务的不断增加，开发迭代和性能瓶颈等问题，将会困扰开发团队，微服务就是解决此问题的有效手段，市面上有很多的微服务框架，比如最著名的两个 Dubbo 和 Spring Cloud，我们该如何选择呢？

公司近期打算向 Java 微服务技术转型，以下是我整理的相关内容，如果你有更好的建议和意见，欢迎探讨～～～

关于 RPC/gRPC/HTTP/REST

因为服务调用方式是 Dubbo 和 Spring Cloud 重要不同点，了解 RPC/gRPC/HTTP/REST 相关概念，有助于对比 Dubbo 和 Spring Cloud。

RPC 是远端过程调用，其调用协议通常包含传输协议和编码协议

TTP 严格来说跟 RPC 不是一个层级的概念，HTTP 本身也可以作为 RPC 的传输层协议。

传输协议包含: 如著名的 gRPC 使用的 HTTP 2.0 协议，也有如 Dubbo 一类的自定义报文的 TCP 协议。编码协议包含: 如基于文本编码的 XML Json，也有二进制编码的 ProtoBuf Binpack 等。

所谓的效率优势是针对 HTTP 1.1 协议来讲的，HTTP 2.0 协议已经优化编码效率问题，像 gRPC 这种 RPC 库使用的就是 HTTP 2.0 协议。

在跨语言调用的时候，REST 风格直接把 HTTP 作为应用协议（直接和服务打交道），不同语言之间调用比较方便。

而 RPC 可以把 HTTP 作为一种传输协议（比如 gRPC 使用 HTTP 2.0 协议传输），本身还会封装一层 RPC 框架的应用层协议，不同语言之间调用需要依赖 RPC 协议（需要跨语言 RPC 库实现，比如 Thrift）。

问题：为什么 Dubbo 比 Spring Cloud 性能要高一些？

回答：因为 Dubbo 采用单一长连接和 NIO 异步通讯（保持连接/轮询处理），使用自定义报文的 TCP 协议，并且序列化使用定制 Hessian2 框架，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况，但不适用于传输大数据的服务调用。而 Spring Cloud 直接使用 HTTP 协议（但也不是强绑定，也可以使用 RPC 库，或者采用 HTTP 2.0 + 长链接方式（Fegin 可以灵活设置））。

另外，Martin Fowler 的 MicroServices 一文，其定义的服务间通信是 HTTP 协议的 REST API。

Dubbo 是什么？

https://github.com/apache/incubator-dubbo

Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，说白了就是个远程服务调用的分布式框架。

Dubbo 框架

模块注解:

• Provider: 暴露服务的服务提供方。

• Consumer: 调用远程服务的服务消费方。

• Registry: 服务注册与发现的注册中心。