【温故知新】-分布式微服务相关知识点梳理

最新推荐文章于 2022-07-20 16:25:35 发布

老汉健身

最新推荐文章于 2022-07-20 16:25:35 发布

阅读量540

点赞数

分类专栏：【温故知新】【分布式专题】文章标签：分布式微服务 dubbo spring cloud mq

本文链接：https://blog.csdn.net/lovexiaotaozi/article/details/112800730

版权

【温故知新】同时被 2 个专栏收录

10 篇文章 0 订阅

订阅专栏

【分布式专题】

7 篇文章 0 订阅

订阅专栏

关于分布式,微服务相关的一些知识点梳理,总结.

1.概念

1.1 什么是分布式,微服务,他们之间有什么区别?

2.框架

2.1 常见的分布式微服务治理框架有哪些?

2.3.1 spring-cloud的常用组件有哪些

2.3.2eureka和zookeeper作为注册中心有哪些区别?

3.常用中间件

3.1Zookeeper

3.1.1zookeeper的节点为什么必须是2n+1

3.1.2 zookeeper的四种节点类型

3.2.2MQ消息的幂等性(重复消费)如何解决?

3.3.3如何保证MQ消息的可靠性?

3.3.4如何保证MQ消息的有序消费?

3.3.5延迟队列如何实现?

1.概念

1.1 什么是分布式,微服务,他们之间有什么区别?

分布式即把一个系统拆分为多个子系统,并部署在不同的物理节点上,由多个节点互相配合完成整个系统的功能,微服务是特殊的分布式,其它概念与分布式类似,但相对分布式系统,微服务拆分的粒度更细,所能承载的并发量一般也会更高.

2.框架

2.1 常见的分布式微服务治理框架有哪些?

常见的分布式微服务治理框架主要有dubbo和spring-cloud,两者各有优劣和适用场景,具体不在这里多讨论.

2.2 dubbo

2.2.1 dubbo的通讯协议有哪些?

dubbo支持dubbo,rmi,hessian,thrift,http,redis,memcached,其中默认的通讯协议为dubbo

2.2.2 dubbo的SPI机制

先说一下jdk提供的spi机制,spi全称:service provider interface,直译:服务提供接口,这种机制在java框架中非常常见,比如jdbc. 实现spi需要在META-INF/service目录下创建xxx.properities文件,然后在文件中指定key,value(类全路径),然后可以通过java.util.ServiceLoade来获取该类. 这样做的好处显而易见,可以强制约定某个接口的实现类,然后由业务对接方自己去实现. 比如jdbc,由于底层数据库多种多样,通过spi拓展机制,可以把具体实现交给各数据库产商去实现,这边只需要提供一个规范即可. dubbo也用了spi的思想,自己实现了一套,方便用户拓展dubbo提供的接口.

2.2.3

2.3spring-cloud

2.3.1 spring-cloud的常用组件有哪些

Eureka:服务注册中心,服务的注册与发现

Feigin:服务调用

Ribbon:负载均衡器,支持轮训,随机等多种策略

Hystirx:断路器,当有节点服务挂了,可以通过服务降级,保护整个链路,避免连锁反应.

Zuul:网关,一系列filter,非常核心的组件,作为入口可以做一些登录,权限等验证

Config:配置中心,动态拉取配置文件.

Bus:消息总线,对消息API友好的封装

Seluth:链路追踪器,常与zpkin集成,可以看到整个服务的调用链路.

2.3.2eureka和zookeeper作为注册中心有哪些区别?

eureka作为服务注册中心,当它挂了之后不会像zk那样选出一个新的主节点,而是直接切换到其它eureka节点; eureka有心跳机制,默认会将失去心跳的节点踢出服务列表,但可以通过配置自我保护,防止将因为网络分区不同导致的健康服务被踢出服务列表,这点相比zk就很友好. 从CAP(Consisitency-avaliable-partition tolerance 一致性,可用性,分区容错性)理论出发,eureka是基于AP设计的,但ZK是基于CP设计的,zk如果主节点宕机重选,会使部分请求失败,需要重新发起,这在一些2C业务场景,是不适合的,会影响用户体验.

3.常用中间件

3.1Zookeeper

3.1.1zookeeper的节点为什么必须是2n+1

先解释一下脑裂:脑裂是指集群由于网络或分区原因导致集群分裂为不同的小集群. zk的节点必须为2n+1主要就是为了防止集群均等脑裂后,有可能产生多个主节点,一旦脑裂恢复正常,集群将无法正常工作,基数个节点的话,则可以重新选主.

3.1.2 zookeeper的四种节点类型

PESISITENT:永久节点

EPHEMERAL:临时节点

PESISTENT_SEQUENTIAL:永久有序节点

EPHEMERAL_SEQUENTAIL:临时有序节点

3.1.3zookeeper的zab协议

zab协议是针对zk设计的一致性协议.zab协议分为崩溃恢复模式和广播模式,当主节点宕机或超过一半follower失去联系,zk就会进入崩溃恢复阶段,期间会通过选举产生新的主,然后将集群内节点信息同步至主节点,完成恢复. 广播模式即主节向其它节点同步数据,此过程只要主节点的提议被一半以上的副节点确认,即会执行同步.