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

最新推荐文章于 2024-09-21 16:43:53 发布

程序员小玖

最新推荐文章于 2024-09-21 16:43:53 发布

阅读量604

点赞数

文章标签： java 微服务 dubbo

本文链接：https://blog.csdn.net/CHIKA2333/article/details/131978964

版权

本文深入探讨了Java微服务框架的选择，重点比较了Dubbo和Spring Cloud的优缺点。Dubbo以其高性能、集群容错和强大的管理功能著称，适合小数据量大并发场景，而Spring Cloud提供了一整套微服务解决方案，支持REST调用，具有丰富的组件和社区支持。文章分析了两者的服务调用方式、发展历程、社区活跃度和兼容性，指出Dubbo更适合已有Java生态的企业，而Spring Cloud更适合追求完整微服务架构和跨语言支持的组织。

摘要由CSDN通过智能技术生成

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

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

公司近期打算向 Java 微服务技术转型（一步一步实现，会考虑兼容 .NET/.NET Core），以下是我整理的相关内容，如果你有更好的建议和意见，欢迎探讨～～～

关于 RPC/gRPC/HTTP/REST

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

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

HTTP 严格来说跟 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。