Dubbo和Spring Cloud微服务架构比较

 

Dubbo 出生于阿里系，是阿里巴巴服务化治理的核心框架，并被普遍应用于中国各互联网公司；只须要经过 Spring 配置的方式便可完成服务化，对于应用无入侵，设计的目的仍是服务于自身的业务为主。

微服务架构是互联网很热门的话题，是互联网技术发展的必然结果。它提倡将单一应用程序划分红一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

虽然微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些颇有影响力的开源微服务架构框架提供了微服务的关键思路，例如 Dubbo 和 Spring Cloud。

各大互联网公司也有自研的微服务框架，但其模式都与这两者相差不大。

微服务主要的优点

下降复杂度

将原来耦合在一块儿的复杂业务拆分为单个服务，规避了本来复杂度无止境的积累。

每个微服务专一于单一功能，并经过定义良好的接口清晰表述服务边界；每一个服务开发者只专一服务自己，经过使用缓存、DAL 等各类技术手段来提高系统的性能，而对于消费方来讲彻底透明。

可独立部署

因为微服务具有独立的运行进程，因此每一个微服务能够独立部署。当业务迭代时只须要发布相关服务的迭代便可，下降了测试的工做量同时也下降了服务发布的风险。

容错

在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。好比经过限流、熔断等方式下降错误致使的危害，保障核心业务正常运行。

扩展

单块架构应用也能够实现横向扩展，就是将整个应用完整的复制到不一样的节点。

当应用的不一样组件在扩展需求上存在差别时，微服务架构便体现出其灵活性，由于每一个服务能够根据实际需求独立进行扩展。

本文主要围绕微服务的技术选型、通信协议、服务依赖模式、开始模式、运行模式等几方面来综合比较 Dubbo 和 Spring Cloud 这 2 种开发框架。

架构师能够根据公司的技术实力并结合项目的特色来选择某个合适的微服务架构平台，以此稳妥地实施项目的微服务化改造或开发进程。

核心部件

微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置，基于上述几种必要条件对 Dubbo 和 Spring Cloud 作出对比。

整体架构

Dubbo 核心部件（以下图）:

• Provider：暴露服务的提供方，能够经过 jar 或者容器的方式启动服务。
• Consumer：调用远程服务的服务消费方。
• Registry：服务注册中心和发现中心。
• Monitor：统计服务和调用次数，调用时间监控中心。（Dubbo 的控制台页面中能够显示，目前只有一个简单版本。）
• Container：服务运行的容器。

Dubbo 整体架构

Spring Cloud整体架构（以下图）：

• Service Provider： 暴露服务的提供方。
• Service Consumer：调用远程服务的服务消费方。
• EureKa Server： 服务注册中心和服务发现中心。

Spring Cloud 整体架构

点评：从总体架构上来看，两者模式接近，都须要服务提供方，注册中心，服务消费方。

微服务架构核心要素

Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一个方面。

Dubbo 提供了各类 Filter，对于上述中“无”的要素，能够经过扩展 Filter 来完善。例如：

• 分布式配置：可使用淘宝的 diamond、百度的 disconf 来实现分布式配置管理。
• 服务跟踪：可使用京东开源的 Hydra，或者扩展 Filter 用 Zippin 来作服务跟踪。
• 批量任务：可使用当当开源的 Elastic-Job、tbschedule。

点评：从核心要素来看，Spring Cloud 更胜一筹，在开发过程当中只要整合 Spring Cloud 的子项目就能够顺利的完成各类组件的融合，而 Dubbo 却须要经过实现各类 Filter 来作定制，开发成本以及技术难度略高。

通信协议

基于通信协议层面对 2 种框架支持的协议类型以及运行效率方面进行比较。

支持协议

Dubbo

Dubbo 使用 RPC 通信协议，提供序列化方式以下：

• Dubbo：Dubbo 缺省协议采用单一长链接和 NIO 异步通信，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的状况。
• RMI：RMI 协议采用 JDK 标准的 java.rmi.* 实现，采用阻塞式短链接和 JDK 标准序列化方式。
• Hessian：Hessian 协议用于集成 Hessian 的服务，Hessian 底层采用 HTTP 通信，采用 Servlet 暴露服务，Dubbo 缺省内嵌 Jetty 做为服务器实现。
• HTTP：采用 Spring 的 Http Invoker 实现。
• Webservice：基于 CXF 的 frontend-simple 和 transports-http 实现。

Spring Cloud

Spring Cloud 使用 HTTP 协议的 REST API。

性能比较

使用一个 Pojo 对象包含 10 个属性，请求 10 万次，Dubbo 和 Spring Cloud 在不一样的线程数量下，每次请求耗时（ms）以下：

说明：客户端和服务端配置均采用阿里云的 ECS 服务器，4 核 8G 配置，Dubbo 采用默认的 Dubbo 协议。

点评：Dubbo 支持各类通讯协议，并且消费方和服务方使用长连接方式交互，通讯速度上略胜 Spring Cloud，若是对于系统的响应时间有严格要求，长连接更合适。

服务依赖方式

Dubbo

服务提供方与消费方经过接口的方式依赖，服务调用设计以下：

• Interface 层：服务接口层，定义了服务对外提供的全部接口。
• Molel 层：服务的 DTO 对象层。
• Business层：业务实现层，实现 Interface 接口而且和 DB 交互。

所以须要为每一个微服务定义各自的 Interface 接口，并经过持续集成发布到私有仓库中。调用方应用对微服务提供的抽象接口存在强依赖关系，开发、测试、集成环境都须要严格的管理版本依赖。

经过 maven 的 install & deploy 命令把 Interface 和 Model 层发布到仓库中，服务调用方只须要依赖 Interface 和 Model 层便可。

在开发调试阶段只发布 Snapshot 版本，等到服务调试完成再发布 Release 版本，经过版本号来区分每次迭代的版本。经过 xml 配置方式便可接入 Dubbo，对程序无入侵。

Dubbo 接口依赖方式

Spring Cloud

服务提供方和服务消费方经过 Json 方式交互，所以只须要定义好相关 Json 字段便可，消费方和提供方无接口依赖。经过注解方式来实现服务配置，对于程序有必定入侵。

点评：Dubbo 服务依赖略重，须要有完善的版本管理机制，可是程序入侵少。

而 Spring Cloud 经过 Json 交互，省略了版本管理的问题，可是具体字段含义须要统一管理，自身 Rest API 方式交互，为跨平台调用奠基了基础。

组件运行流程

Dubbo

下图中的每一个组件都是须要部署在单独的服务器上，Gateway 用来接受前端请求、聚合服务，并批量调用后台原子服务。每一个 Service 层和单独的 DB 交互。

Dubbo 组件运行流程

Dubbo 组件运行：

• Gateway：前置网关，具体业务操做，Gateway 经过 Dubbo 提供的负载均衡机制自动完成。
• Service：原子服务，只提供该业务相关的原子服务。
• Zookeeper：原子服务注册到 ZK 上。

Spring Cloud 组件运行

Spring Cloud

Spring Cloud组件运行：

• 全部请求都统一经过 API 网关（Zuul）来访问内部服务。
• 网关接收到请求后，从注册中心（Eureka）获取可用服务。
• 由 Ribbon 进行均衡负载后，分发到后端的具体实例。
• 微服务之间经过 Feign 进行通讯处理业务。

点评：业务部署方式相同，都须要前置一个网关来隔绝外部直接调用原子服务的风险。

Dubbo 须要本身开发一套 API 网关，而 Spring Cloud 则能够经过 Zuul 配置便可完成网关定制。使用方式上 Spring Cloud 略胜一筹。

微服务架构组成以及注意事项

到底使用是 Dubbo 仍是 Spring Cloud 并不重要，重点在于如何合理的利用微服务。

下面是一张互联网通用的架构图，其中每一个环节都是微服务的核心部分。

架构分解：

• 网关集群：数据的聚合、实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等。
• 业务集群：通常状况下移动端访问和浏览器访问的网关须要隔离，防止业务耦合。
• Local Cache：因为客户端访问业务可能须要调用多个服务聚合，因此本地缓存有效的下降了服务调用的频次，同时也提示了访问速度。本地缓存通常使用自动过时方式，业务场景中容许有必定的数据延时。
• 服务层：原子服务层，实现基础的增删改查功能，若是须要依赖其余服务须要在 Service 层主动调用。
• Remote Cache：访问 DB 前置一层分布式缓存，减小 DB 交互次数，提高系统的TPS。
• DAL：数据访问层，若是单表数据量过大则须要经过 DAL 层作数据的分库分表处理。
• MQ：消息队列用来解耦服务之间的依赖，异步调用能够经过 MQ 的方式来执行。
• 数据库主从：服务化过程当中必经的阶段，用来提高系统的 TPS。

注意事项：

• 服务启动方式建议使用jar方式启动，启动速度快，更容易监控。
• 缓存、缓存、缓存，系统中能使用缓存的地方尽可能使用缓存，经过合理的使用缓存能够有效的提升系统的TPS。
• 服务拆分要合理，尽可能避免因服务拆分而致使的服务循环依赖。
• 合理的设置线程池，避免设置过大或者太小致使系统异常。

总结

Dubbo 出生于阿里系，是阿里巴巴服务化治理的核心框架，并被普遍应用于中国各互联网公司；只须要经过 Spring 配置的方式便可完成服务化，对于应用无入侵，设计的目的仍是服务于自身的业务为主。

虽然阿里内部缘由 Dubbo 曾经一度暂停维护版本，可是框架自己的成熟度以及文档的完善程度，彻底能知足各大互联网公司的业务需求。

若是咱们使用配置中心、分布式跟踪这些内容都须要本身去集成，这样无形中增长了使用 Dubbo 的难度。

Spring Cloud 是大名鼎鼎的 Spring 家族的产品， 专一于企业级开源框架的研发。

Spring Cloud 自从发布到如今，仍然在不断的高速发展，几乎考虑了服务治理的方方面面，开发起来很是的便利和简单。

Dubbo 于 2017 年开始又重启维护，发布了更新后的 2.5.7 版本，而 Spring Cloud 更新的很是快，目前已经更新到 Finchley.M2。

所以，企业须要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题，不论是 Dubbo 仍是 Spring Cloud 都是实现微服务有效的工具。

参考： 到底孰优孰劣？Dubbo和Spring Cloud微服务架构终极对决！