关于springboot:第三篇-跟我学习SpringCloudSpring-Cloud和Dubbo的区别及各自的优缺点

10次阅读

共计 2088 个字符,预计需要花费 6 分钟才能阅读完成。

咱们先从 Nginx 说起,理解为什么须要微服务。最后的服务化解决方案是给雷同服务提供一个对立的域名,而后服务调用者向这个域发送 HTTP 申请,由 Nginx 负责申请的散发和跳转。
这种架构存在很多问题:Nginx 作为中间层,在配置文件中耦合了服务调用的逻辑,这减弱了微服务的完整性,也使得 Nginx 在肯定水平上变成了一个重量级的 ESB。图中标识出了 Nginx 的转发信息流走向。


服务的信息扩散在各个系统,无奈对立治理和保护。每一次的服务调用都是一次尝试,服务生产方并不知道有哪些实例在给他们提供服务。这带来了一些问题:

  • 无奈直观地看到服务提供方和服务生产方以后的运行状况与通信频率;
  • 生产方的失败重发、负载平衡等都没有对立策略,这加大了开发每个服务的难度,不利于疾速演变。

为了解决下面的问题,咱们须要一个现成的核心组件对服务进行整合,将每个服务的信息汇总,包含服务的组件名称、地址、数量等。
服务的调用方在申请某项服务时首先通过核心组件获取提供服务的实例信息(IP、端口等),再通过默认或自定义的策略抉择该服务的某一提供方间接进行拜访,所以思考引入 Dubbo。
Dubbo 是阿里开源的一个 SOA 服务治理解决方案,文档丰盛,在国内的应用度十分高。图 2 为 Dubbo 的根本架构图,应用 Dubbo 构建的微服务曾经能够较好地解决下面提到的问题。


从图 2 中,能够看出以下几点:

  • 调用中间层变成了可选组件,生产方能够间接拜访服务提供方;
  • 服务信息被集中到 Registry 中,造成了服务治理的核心组件;
  • 通过 Monitor 监控零碎,能够直观地展现服务调用的统计信息;
  • 服务消费者能够进行负载平衡、服务降级的抉择。

然而对于微服务架构而言,Dubbo 并不是美中不足的,也有一些缺点,比方:

  • Registry 重大依赖第三方组件(ZooKeeper 或者 Redis),当这些组件呈现问题时,服务调用很快就会中断。
  • Dubbo 只反对 RPC 调用。这使得服务提供方与调用方在代码上产生了强依赖,服务提供方须要一直将蕴含公共代码的 Jar 包打包进去供生产方应用。一旦打包呈现问题,就会导致服务调用出错。

笔者认为,Dubbo 和 Spring Cloud 并不是齐全的竞争关系,两者所解决的问题域并不一样。
Dubbo 的定位始终是一款 RPC 框架,而 Spring Cloud 的指标是微服务架构下的一站式解决方案。如果非要比拟的话,Dubbo 能够类比到 Netflix OSS 技术栈,而 Spring Cloud 集成了 Netflix OSS 作为分布式服务治理解决方案,但除此之外 Spring Cloud 还提供了配置、音讯、平安、调用链跟踪等分布式问题解决方案。
以后因为 RPC 协定、注册核心元数据不匹配等问题,在面临微服务根底框架选型时 Dubbo 与 Spring Cloud 只能二选一,这也是大家总是拿 Dubbo 和 Spring Cloud 做比照的起因之一。
Dubbo 曾经适配到 Spring Cloud 生态,比方作为 Spring Cloud 的二进制通信计划来施展 Dubbo 的性能劣势,Dubbo 通过模块化以及对 HTTP 的反对适配到 Spring Cloud。

Spring Cloud 好在哪里

作为新一代的服务框架,Spring Cloud 提出的口号是开发“面向云的应用程序”,它为微服务架构提供了更加全面的技术支持。联合咱们一开始提到的微服务的诉求,参见表 1,把 Spring Cloud 与 Dubbo 进行一番比照。

表 1 Spring Cloud 与 Dubbo 性能比照

Spring Cloud 摈弃了 Dubbo 的 RPC 通信,采纳的是基于 HTTP 的 REST 形式。严格来说,这两种形式各有优劣。尽管从肯定水平上来说,后者就义了服务调用的性能,但也防止了下面提到的原生 RPC 带来的问题。而且 REST 相比 RPC 更为灵便,服务提供方和调用方,不存在代码级别的强依赖,这在强调疾速演变的微服务环境下显得更加适合。
很显著,Spring Cloud 的性能比 Dubbo 更加弱小,涵盖面更广,而且作为 Spring 的拳头我的项目,它也可能与 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其余 Spring 我的项目完满交融,这些对于微服务而言是至关重要的。
后面提到,微服务背地一个重要的理念就是继续集成、疾速交付,而在服务外部应用一个对立的技术框架,显然比将扩散的技术组合到一起更有效率。
更重要的是,相比于 Dubbo,它是一个正在继续保护的、社区更加炽热的开源我的项目,这就能够保障应用它构建的零碎继续地失去开源力量的反对。
上面列举 Spring Cloud 的几个劣势。

  • Spring Cloud 来源于 Spring,品质、稳定性、持续性都能够失去保障。
  • Spirng Cloud 人造反对 Spring Boot,更加便于业务落地。
  • Spring Cloud 倒退得十分快,从开始接触时的相干组件版本为 1.x,到当初将要公布 2.x 系列。
  • Spring Cloud 是 Java 畛域最适宜做微服务的框架。

相比于其余框架,Spring Cloud 对微服务周边环境的反对力度最大。对于中小企业来讲,应用门槛较低。

举荐布式架构源码

正文完
 0