用户您好!请先登录!

Spring Cloud的几个组件的一些理解

Spring Cloud的几个组件的一些理解

一、SpringCloud和Dubbo的区别

  1. SpringCloud和Dubbo主要区别

SpringCloud和Dubbo都是现在主流的微服务架构。

SpringCloud是apache旗下的Spring体系下的微服务解决方案,Dubbo是用于治理阿里系的分布式服务框架。

讲道理,我跟喜欢Spring Cloud,Dubbo只治理自身,对于其他服务只能借助于第三方,没有一个完整健康的生态,而Spring Cloud除了自己还有其21个子项目,以后会更多,谁让人家的Spring家族呢!

在技术选型的时候,由于远程调用方式以及注册中心等原因,我们二者只能选其一。

服务远程调用方式:Dubbo使用RPC远程调用,SpringCloud使用RestAPI,后者更符合微服务官方定义

补充:远程调用的方式有2中:RPC和HTTP,Spring为开发者提供了RestTemplapte模板工具类,对http客户端进行了封装,并实现了对象与json的序列化和反序列化。

注册中心:Dubbo使用第三方的zookeeper作为其底层的注册中心,SpringCloud使用自己的Netflix Eureka实现注册中心,也可以使用zookeeper

服务网关等其他服务,Dubbo都需要借助于第三方,虽然它可以对Spring进行无缝连接,但不是亲儿子啊!而SpringCloud有Zuul路由网关,进行请求的分发,支持断路器,与git完美集成分布式配置文件版本控制,事务总线实现配置文件的更新与服务自动装配等一系列的微服务框架要素(近似于:微服务==SpringCloud)

  1. Rest和RPC对比:

微服务提出者马丁福勒的论文中定义的服务间通信机制是Http Rest

RPC最主要的缺陷是服务提供者和调用方法之间的依赖性太强,需要对每一个微服务进行接口的定义,并通过持续继承发布,需要严格的版本控制。

而REST是轻量级的接口,服务的提供和调用不存在代码之间的耦合,通过约定进行规范,如果出现文档和接口不一致的服务集成问题,可以通过swagger工具整合,所以Rest在分布环境下比RPC更加灵活(例如当当网的Dubbo中增加了对Rest的支持)

二、SpringBoot和SpringCloud

SpringBoot是Spring推出用于解决传统框架配置文件冗余,Maven解决装配组件的繁杂,旨在快速搭建单个微服务而SpringCloud专注于解决各个微服务之间的协调与配置,服务之间的通信,熔断,负载均衡等

SpringCloud依赖于SpringBoot,反之不成立,SpringBoot可以与Dubbo组合开发

总而言之:

  • SpringBoot专注于快速方便的开发单个个体的微服务
  • SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,配置管理,服务发现,断路器,路由,事件总线等集成服务
  • SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot,属于依赖关系
  • SpringBoot专注于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架

三、Eureka和Zuulkeeper的共同点和不同点

相同点:都可以作为服务的注册中心,提供服务的注册和发现功能

补充:著名的CAP理论:一个分布式系统不可能同时满足C(一致性)、A(可用性)、P(分区容错性),P是一个分布式系统必须保证的,因此只能在A和C中抉择。

  1. Eureka保证AP(注重服务的高可用),Zookeeper保证的CP(注重数据的一直性)

Zookeeper在选举期间服务瘫痪,虽然选举结束恢复,但是选举期间服务不可用

Eureka各个节点之间的关系是平等的,只要有一台Eureka就可以保证服务可用,但是不保证数据是最新的

  1. ZooKeeper有Leader和Follower角色,Eureka各个节点之间地位平等

  2. Zookeeper采用过半数存货原则,Eureka采用自我保护机制解决分区问题

  3. Eureka本质是一个工程,Zookeeper本质是一个进程

补充:Eureka Server在运行期间会统计心跳失败比例:在15分钟内心跳失败是否低于85%,如果低于85%,Eureka默认会激活自我保护机制,保护那些因长时间没有心跳而过期的服务,等待修复。

我们可以通过关闭Euraka的自我保护机制,确保注册中心的不可用实例可以被及时清除。但是我们不建议这么做,举例说明:2个健康的服务C1,C2把自己注册给Eureka,这是C2由于网络故障没能及时发送心跳,Eureka就直接删除了C2,这是不合理的,C2服务本身没有问题,只是网络不好。

那我们如何保证Eureka的高可用呢?可以通过集群的方式,设置eureka.client.register-with-eureka为true

作为单纯的服务注册中心来说,Eureka更加专业,因为注册中心更加注重可用性,Eureka目前的1.x版本的实现基于servlet的java web应用,性能受限,期待2.x版本吧!

四、微服务之间的通讯方式

  1. RPC:Remote Procedure Invocation,远程过程调用,就是我们通常说的服务的注册与发现,直接通过远程过程调用来访问别的service

优点:简单,快

缺点:只支持 请求/响应 模式,不支持通知、请求/异步响应、发布/订阅、发布/异步响应。要求服务端和客户端在请求过程种必须都是可用的,可用性低

  1. 消息中间件:使用异步消息通信。服务间通过消息管道来交换消息。

优点:客户端和服务端解耦,松耦合,服务间只要通信就无法解决耦合问题,只能如何降低耦合程度。

对于客户端和服务端没有那么高的要求,由消息中间件保存消息,可用性很高。

支持很多通信机制,通知,请求/异步响应、发布/订阅、发布/异步响应。

缺点:消息中间件相较于RPC要复杂的多。

行走的code
行走的code

要发表评论,您必须先登录