微服务Dubbo和SpringCloud架构设计、优劣势比较

本文主要围绕微服务的技术选型、通讯协议、服务依赖模式、开始模式、运行模式等几方面来综合比较Dubbo和Spring Cloud 这2种开发框架。架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台，以此稳妥地实施项目的微服务化改造或开发进程。

微服务架构是互联网很热门的话题，是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。虽然微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如Dubbo和Spring Cloud。各大互联网公司也有自研的微服务框架，但其模式都于这二者相差不大。

现在的JSF构成

⽬前的JSF⼏乎是全部⾃研
RPC框架：轻量级，更佳的性能，兼容旧版本协议；
注册中⼼：基于DB作为数据源，前置Index服务；⽀持⼗倍接⼊量；部分逻辑放在注册中⼼减少客户端负担；
监控中⼼：监控Proxy服务+InfluxDB（2015后改为ElasticSearch）；
管理端：基于DB，功能更强⼤，提供完善的服务治理管理功能；打通京东应⽤管理平台，提供应⽤依赖关系梳理；
HTTP⽹关：基于Netty，⽀持跨语⾔调⽤。
⽬前的JSF是基于DB做的数据最终⼀致，也就是AP系统。注册中⼼主要实现的就是服务列表的注册订阅推送，服务配置的获取下发，服务
状态的实时查看等功能。注册中⼼节点是⽆状态的，可⽔平扩展的。整个注册中⼼集群下的所有注册中⼼⼏点都是等价的。

--------------------------------------------------------

JSF优化与特点

引⼊Index服务概念：该服务就是⼀个最简单HTTP的服务，⽤于找注册中⼼节点（同机房或者压⼒最⼩或者其它特定场景），可以认
为是不会挂的服务，RPC框架会优先连该服务拿注册中⼼地址，这样⼦的好处是注册中⼼地址变化后，RPC框架不⽤修改任何设置；
注册中⼼内存有服务列表全量缓存，连不上数据库也保证可读；
数据库的数据结构更适合各种维度展⽰、过滤、分析等，例如根据分组/IP/应⽤/机房等不同维度；
注册中⼼就是个JSF服务，监控到压⼒⼤即可进⾏动态⽔平扩展，不会出现2015年双⼗⼀那样的事故了；
服务列表推送逻辑改进：例如原来100个Provider，现在加1个节点，之前的SAF是需要下发101个节点，⾃⼰判断加了哪个节点，进
⾏长链接建⽴；现在的改进是：修改为下发⼀个add事件，告知RPC框架加了1个节点，RPC框架进⾏长链接建⽴；这样做⼤⼤减少了
推送的数据量；
注册中⼼与RPC框架可各种交互：注册中⼼和RPC框架是长链接，⽽且JSF是⽀持Callback的，注册中⼼可以调⽤RPC框架进⾏服务
列表变化之外的操作；例如查看状态，查看配置，配置下发等

--------------------------------------------------------

微服务主要的优势如下：

1、降低复杂度

将原来偶合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。每个服务开发者只专注服务本身，通过使用缓存、DAL等各种技术手段来提升系统的性能，而对于消费方来说完全透明。

2、可独立部署

由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。

3、容错

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

4、扩展

单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

一、核心部件

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

1、总体架构

Dubbo 核心部件（如下图）:

微服务Dubbo和SpringCloud架构设计、优劣势比较-mikechen的互联网架构

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

▲Dubbo 总体架构

Spring Cloud总体架构如下图

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

▲Spring Cloud总体架构

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

2、微服务架构核心要素

Dubbo只是实现了服务治理，而Spring Cloud子项目分别覆盖了微服务架构下的众多部件，而服务治理只是其中的一个方面。Dubbo提供了各种Filter，对于上述中“无”的要素，可以通过扩展Filter来完善。

例如

1．分布式配置：可以使用淘宝的diamond、百度的disconf来实现分布式配置管理

2．服务跟踪：可以使用京东开源的Hydra，或者扩展Filter用Zippin来做服务跟踪

3．批量任务：可以使用当当开源的Elastic-Job、tbschedule

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

二、通讯协议

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

（一）、支持协议

1、Dubbo：dubbo使用RPC通讯协议，提供序列化方式如下：

dubbo：Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况

rmi：RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式

Hessian:Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现

http:采用Spring的HttpInvoker实现

Webservice:基于CXF的frontend-simple和transports-http实现

2、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方式交互，为跨平台调用奠定了基础。

四、组件运行流程

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

▲Dubbo组件运行流程

gateWay:前置网关，具体业务操作，gateWay通过dubbo提供的负载均衡机制自动完成
Service：原子服务，只提供该业务相关的原子服务
Zookeeper：原子服务注册到zk上

▲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.6版本，而Spring Cloud更新的非常快。

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

Eureka与Dubbo的分布式服务有哪些不同

    1）一个是PA模式，一个是CP模式
   2）Dubbo是以接口为粒度的。调用那个服务，必须注入他的接口。
        Eureka则是直接调用服务，它使用的是一个RestTelement模板对象。
   3）Dubbo需要单独启动一个注册中心程序，但是Eureka的是一个项目代码。
   4）Dubbo传递的数据使用的是字节流，所以他的实例对象都要进行实现序列化接口。
        Eureka采用的是json数据传输，效率其实没有Dubbo高。

dubbo是RPC微服务框架

1.面向接口的远程方法调用
2.框架自身实现负载均衡

3.服务的注册和发现

所有服务中yml中配置dubbo

添加服务名称

连接注册中心 IP+端口

#spring整合dubbo   
dubbo:
  scan:
    basePackages: com.jt    #开启包扫描
  application:
    name: provider-cart     #必须添加服务名称(其他服务者的名字需要相同)
  registry:                 #链接注册中心
    address: zookeeper://172.16.48.128:2181?backup=172.16.48.128:2182,172.16.48.128:2183
  protocol:
name: dubbo  #注册中心信息存储文件夹的名称 
port: 20881  #每个服务都有自己独立的端口号

RPC是远程过程调用：可以直接调用中立接口

封装了tcp/udp传输协议使用户调用更加简单简化了分布式项目的开发

TCP传输协议：套接字是用（IP地址：端口号）表示的端口

经历三次握手（只有经历3次握手才能保证两端都接收到类数据）但是传输速率相对较慢

SOA是一种面向服务的架构：

将应用程序的不同功能单元（服务）进行拆分用独立的接口连接

OSI网络通信模型：

搭建dubbo框架：

1.创建中立的dubboservice接口

2.dubboserviceImpl实体类中导入的是dubbo的@service注解并且可以定义对象创建时间

3.dubboController中注入的是dubbo的@Reference 引用并且可以定义超时时间和检查是否有提供者

二# zookeeper

zookeeper是分布式应用协调服务器（注册中心）用于注册、调度服务

3台是最小集群可用节点数量 > 总节点数量/2 即保持可用主从集群模式

满足CP：

一致性（防止主机宕机而从机使用错误信息）分区容错性原则

三# eureka

eureka分布式应用协调服务器（注册中心）用于注册、调度服务

对等模式

满足AP：

高可用分区容错性原则

运行原理：

1.服务提供者在启动时，向注册中心注册自己提供的服务地址（servername+端口）

spring:
  application:
    name: item-service
server:
  port: 8001

2.消费者在启动时，向注册中心订阅自己需要的服务（服务列表保存到消费者服务器）

3.当消费者接收到请求之后，查询服务器列表利用负载均衡的机制挑选其中一台发起请求

4.当提供者宕机时，注册中心会通过心跳检测查看服务器是否存活，并且更新服务器列表

5.心跳检测机制：默认每30秒发送一次心跳数据丢失3次会认为服务不可以

6.保护模式：服务不可用eureka会保留地址

7.每30秒更新地址表

posted @ 2022-02-07 11:27 hanease 阅读(181) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

hanease