Java面试（6）之微服务篇

注册中心选型对比

选型	CAP模型	一致性协议	安全	SpringCloud集成	版本	语言
Eureka	AP	去中心、不保证一致性	无	支持	2.0(停止维护) 2021年	java
Consul	CP	Raft	acl/https	支持	社区较活跃(天)	go
Zookeeper	CP	zab	acl	支持	社区更新缓慢(月)	java
Etcd	CP	Raft	https(弱)	支持	社区较活跃(天)	go
Nacos	CP(配置中心) AP(注册中心)	Raft	acl	支持	社区较活跃(天)	Java

实现原理:

Zookeeper:

1, zab协议 通过选举机制产生leader,选举时间30~120s,期间服务不可用

2, 通过定时心跳检测发现服务是否可用并注册到注册中心,第一次会从注册中心拉取服务列表存到本地缓存,服务下线或者上线时更新本地缓存文件

3, leader与flowller通过watch机制+版本号来进行数据同步.

watch机制(推拉模式,注册中心服务列表变更通知给消费端,消费端主动拉取最新服务列表)

Eureka:

1, 去中心化架构(没有选举一说),集群之间通过replica方式进行同步(版本号)

2, eureka client每隔30s eureka server发送一次心跳请求,若90s内未接收到则认为客户端挂了并下线服务;当存在大量的客户端挂的时候开启保护机制(服务不下线),也可以设置保护机制

3, 客户端第一次拉取数据后会存本地缓存,注册中心变更会更新本地缓存

4, 支持指定分区部署eureka server 集群

Nacos:

1, 支持基于DNS和RPC的服务发现

2, 提供对服务的实时的健康检查,阻止向不健康的主机或服务发送请求.支持两种健康检查模式: agent上报、服务端主动监测.

Consul:

1, producer服务启动后会向consul发送post请求,告知其IP和端口.

2, consul每隔10s向producer发送请求,监测其服务是否健康

3, consumer向consul发送get请求获取服务列表后会存放到临时表,后面通过临时表获取服务列表,临时表每隔10s进行数据更新

Etcd:

参照:

注册中心对比和选型：Zookeeper、Eureka、Nacos、Consul和ETCD - 掘金

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

paxos、raft、zab一致性协议对比

一致性协议	角色	选举	心跳检测	数据同步
paxos	Proposer(提案,多个) Acceptor(决策者,多个) Learn(最终提案记录者)	Basic Paxos没有选举 Multi Paxos及Fast Pzxos在Acceptor中存在选举	无
raft	Leader(主节点) Follower(从节点) Cadidate(候选者)	Follower-> Cadidate Cadidate->Leader (全票或半数票)	Election timeout: 选举时间,即follower在这段时间如果没有收到leader信息则会变成Candidate; heartbeat timeout: 心跳时间,在选举完后,leader每隔一段时间向flollower发送心跳消息	接收请求封装成log entry,将log副本发给flollower (term)
zab	Leader(主节点) Follower(从节点) Cadidate(候选者)	Follower-> Cadidate Cadidate->Leader (全票或半数票)	Election timeout: 选举时间,即follower在这段时间如果没有收到leader信息则会变成Candidate heartbeat timeout: 心跳时间,在选举完后,follower每隔一段时间向leader发送心跳检测	接收请求封装成log entry,将log副本发给flollower (epoch)

数据同步: 定时心跳+版本号

参照: 分布式一致性（共识）算法(Paxos,raft,ZAB)的一些总结_zab是共识算法-CSDN博客

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

分布式事务一致性解决方案

一, 事务4个基本要素(ACID)

原子性(Automicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)

二, 分布式CAP定理

一致性（Consistency）: 集群多节点在同一时刻数据是否一样.

可用性（Availability）: 集群中某个节点挂了,不影响整体对客户端的读写操作

分区容忍性（Partition tolerance）: 对一致性及可用性的平衡补充,在可接受的时限内达到数据最终一致性的结果,允许暂时不一致或不可用的方式.

三, 分布式事务一致性问题解决方案

方案	过程	优/缺点
二阶段提交(2PC) (协调者（Cooradinator）、参与者（Participant）)	1, 协调者向各参与者提交事务请求并将 undo 和 redo 信息记入事务日志中（但不提交事务）(准备阶段) 2, commit提交事务	1, 同步阻塞协议，参与者对事物处理后不提交，如果协调者不可用，那么资源就无法被释放 2, 单点故障，协调者一挂整个服务都会不可用 3, commit时如果参与者与协调者挂了,会导致数据不一致问题
三阶段提交(3PC) (协调者（Cooradinator）、参与者（Participant）)	1, 协调者仅向参与者提交事务请求(canCommit) 2, 协调者根据阶段1反馈结果执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）(preCommit) 3, commit提交事务(doCommit)	1, 相对于二阶段提交,缩短了阻塞的范围 2, 当参与者进行到doCommit时,如果此时协调者发送了中断事务操作,但参与者不会中断事务还是会执行事务,导致最终数据不一致
补偿事务(TCC)(Try、Confirm、Cancel)	1, try阶段业务操作check及资源预留 2, try执行完后执行confirm、释放资源 3, try执行失败执行cancel回滚、释放资源	1, 仅对操作的业务部分加锁,性能较高 2, 保证了数据的最终一致性 3, 开发成本较高,业务耦合度较高
本地消息表	1, 建一个全局的业务消息表,记录操作的消息及状态 2, 每个业务消息开始时先查看消息表的状态是否成功 4, 定时处理失败的消息进行相应的补偿	1, 需要补偿逻辑、业务要考虑幂等复杂问题
消息事务模型	1, 发送方向Broker发送半消息,等到本地事务执行完毕后提交or回滚 2, 订阅方执行本地事务,执行完毕后消费消息	1, 服务之间解耦,rocketmq支持事务 2, 需要重试及补偿机制

2PC: XA 或 Seata(AT模式); XA模式存在资源锁一直被占用的情况,性能较差,Seata通过本地分支事务协调驱动全局事务来解决2PC的问题,性能较好.

Seata: 在主事物分支开启@GlobalTransactional, 子事务开启@Transactional

JAVA 强一致性 2PC两阶段提交介绍以及Seata AT模式实现_2pc提交-CSDN博客

3PC:

TCC: Seata(TCC模式)

本地消息表: RocketMQ(发送半消息,即发完消息但没有马上提交,而是等到本地事务执行完毕后提交消息进行commit或rollbacl)

消息事务模型:

 

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

SpringCloud与Dubbo的比较 
 

一、整体比较

1、dubbo由于是二进制的传输，占用带宽会更少

2、springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大

3、dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决

4、springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级

5、dubbo的注册中心可以选择zk,redis等，springcloud的注册中心用eureka或者Consul

二, 两者分别介绍

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

SpringCloud是一系列框架的有序集合。它基于SpringBoot的便利性融合了一整套实现微服务的框架并提供了服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等组件。

参照: SpringCloud与Dubbo的比较 - 知乎

实战系列:

1, dubbo中如何集成网关?

可集成Springcloud getway,但需要注意的是,getway需要有注册中心支持,而dubbo仅支持zookepeer、nacos,而getway对于这两种都支持;另外,dubbo的传输协议除了tcp,目前支持了超过10多种传输协议

参照: https://www.cnblogs.com/zlt2000/p/13201326.html