了解为何须要微服务。最初的服务化解决方案是给相同服务提供一个统一的域名,而后服务调用者向这个域发送 HTTP 请求,由 Nginx 负责请求的分发和跳转。
这种架构存在不少问题:Nginx 做为中间层,在配置文件中耦合了服务调用的逻辑,这削弱了微服务的完整性,也使得 Nginx 在必定程度上变成了一个重量级的 ESB。图 1 标识出了 Nginx 的转发信息流走向。spring
图 1 Nginx 转发的信息流安全
服务的信息分散在各个系统,没法统一管理和维护。每一次的服务调用都是一次尝试,服务消费方并不知道有哪些实例在给他们提供服务。这带来了一些问题:架构
为了解决上面的问题,咱们须要一个现成的中心组件对服务进行整合,将每一个服务的信息汇总,包括服务的组件名称、地址、数量等。
服务的调用方在请求某项服务时首先经过中心组件获取提供服务的实例信息(IP、端口等),再经过默认或自定义的策略选择该服务的某一提供方直接进行访问,因此考虑引入 Dubbo。
Dubbo 是阿里开源的一个 SOA 服务治理解决方案,文档丰富,在国内的使用度很是高。图 2 为 Dubbo 的基本架构图,使用 Dubbo 构建的微服务已经能够较好地解决上面提到的问题。负载均衡
图 2 Dubbo 的基本架构图框架
从图 2 中,能够看出如下几点:分布式
可是对于微服务架构而言,Dubbo 并非十全十美的,也有一些缺陷,好比:ide
笔者认为,Dubbo 和 SpringCloud并非彻底的竞争关系,二者所解决的问题域并不同。
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 提出的口号是开发“面向云的应用程序”,它为微服务架构提供了更加全面的技术支持。结合咱们一开始提到的微服务的诉求,参见表 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 对微服务周边环境的支持力度最大。对于中小企业来说,使用门槛较低。