Java 微服务框架对比:Dubbo 和 Spring Cloud

微服务特点:

微服务(Microservices)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。

  1. 独立部署
  2. 松耦合
  3. 单一职责,每个服务仅关注一件任务

微服务框架

 相关概念:

 

rpc

1、远端过程调用,其调用协议通常包含传输协议和编码协议

2、RPC 可以把 HTTP 作为一种传输协议(比如 gRPC 使用 HTTP 2.0 协议传输),本身还会封装一层 RPC 框架的应用层协议,不同语言之间调用需要依赖 RPC 协议

grpc HTTP 2.0 协议传输
dubbo 自定义报文的 TCP 协议。编码协议包含: 如基于文本编码的 XML Json,也有二进制编码的 ProtoBuf Binpack 等
rest REST 风格直接把 HTTP 作为应用协议(直接和服务打交道),不同语言之间调用比较方便

 

为什么 Dubbo 比 Spring Cloud 性能要高一些?

Dubbo 采用单一长连接和 NIO 异步通讯(保持连接/轮询处理),使用自定义报文的 TCP 协议,并且序列化使用定制 Hessian2 框架,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况,但不适用于传输大数据的服务调用

Spring Cloud 直接使用 HTTP 协议(但也不是强绑定,也可以使用 RPC 库,或者采用 HTTP 2.0 + 长链接方式(Fegin 可以灵活设置))。

Dubbo

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

dubbo

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

Consumer: 调用远程服务的服务消费方
Registry: 服务注册与发现的注册中心
Monitor: 统计服务的调用次调和调用时间的监控中心
Container: 服务运行容器

SpringCloud

基于 Spring Boot,为微服务体系开发中的架构问题,提供了一整套的解决方案——服务注册与发现,服务消费,服务保护与熔断,网关,分布式调用追踪,分布式配置管理等。Spring Boot 是 Spring 的一套快速配置脚手架,使用默认大于配置的理念,用于快速开发单个微服务

Java 微服务框架对比:Dubbo 和 Spring Cloud_第1张图片

核心功能:

  • 分布式/版本化配置
  • 服务注册和发现
  • 路由
  • 服务和服务之间的调用
  • 负载均衡
  • 断路器
  • 分布式消息传递

流程:

  • 请求统一通过 API 网关(Zuul)来访问内部服务。
  • 网关接收到请求后,从注册中心(Eureka)获取可用服务。
  • 由 Ribbon 进行均衡负载后,分发到后端具体实例。
  • 微服务之间通过 Feign 进行通信处理业务。
  • Hystrix 负责处理服务超时熔断。
  • Turbine 监控服务间的调用和熔断相关指标。

对比

dubbo

优点:

Dubbo 支持 RPC 调用,服务之间的调用性能会很好。

支持多种序列化协议,如 Hessian、HTTP、WebService。

Dobbo Admin后台管理功能强大,提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。

在国内影响力比较大,中文社区文档较为全面

阿里最近重启维护

缺点:

1、Registry 严重依赖第三方组件(zookeeper 或者 redis),当这些组件出现问题时,服务调用很快就会中断

2、只支持 RPC 调用。使得服务提供方(抽象接口)与调用方在代码上产生了强依赖

3、Dubbo 只是实现了服务治理,其他微服务框架并未包含,需要结合第三方框架实现(比如分布式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra,但使用相对麻烦些),开发成本较高,且风险较大。

springcloud

优点

1、有强大的 Spring 社区、Netflix 等公司支持

2、标准化的将微服务的成熟产品和框架结合一起,Spring Cloud 提供整套的微服务解决方案,开发成本较低,且风险较小

3、基于 Spring Boot,具有简单配置、快速开发、轻松部署、方便测试的特点

4、支持 REST 服务调用,相比于 RPC,更加轻量化和灵活(服务之间只依赖一纸契约,不存在代码级别的强依赖),有利于跨语言服务的实现,以及服务的发布部署。另外,结合 Swagger,也使得服务的文档一体化

5、提供了 Docker 及 Kubernetes 微服务编排支持

6、企业应用非常多,经受了大公司的应用考验(比如 Netfilx 公司),以及强大的开源社区支持

缺点:

1、REST 服务调用性能会比 RPC 低一些(但也不是强绑定)

2、Spring Cloud 整合了大量组件,相关文档比较复杂,需要针对性的进行阅读

3、支持 REST 服务调用,可能因为接口定义过轻,导致定义文档与实际实现不一致导致服务集成时的问题(可以使用统一文档和版本管理解决,比如 Swagger)。

 

Java 微服务框架对比:Dubbo 和 Spring Cloud_第2张图片

性能比较:

Java 微服务框架对比:Dubbo 和 Spring Cloud_第3张图片

选型出发点

微服务选型要评估以下几点:

  1. 内部是否存在异构系统集成的问题;
  2. 备选框架功能特性是否满足需求;
  3. HTTP 协议的通信对于应用的负载量会否真正成为瓶颈点(Spring Cloud 也并不是和 HTTP + JSON 强制绑定的,如有必要 Thrift、ProtoBuf 等高效的 RPC、序列化协议同样可以作为替代方案);
  4. 社区活跃度、团队技术储备等。作为已经没有团队持续维护的开源项目,选择 Dubbo 框架内部就必须要组建一个维护团队,先不论你要准备要集成多少功能做多少改造,作为一个支撑所有工程正常运转的基础组件,问题的及时响应与解答、重大缺陷的及时修复能力就已足够重要。

选型建议

1、使用 Dubbo 构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;而 Spring Cloud 就像品牌机,在 Spring Source 的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解。

2、Spring Cloud 可以说是一个更完备的微服务解决方案,它从功能性上是 Dubbo 的一个超集对于一些中小型企业 Spring Cloud 可能是一个更好的选择

3、Dubbo 和 Spring Cloud 的主要不同体现在两个方面:服务调用方式不同专注点不同(生态不同)

你可能感兴趣的:(微服务,分布式,java,微服务)