| Nacos | Eureka | Consul | CoreDNS | Zookeeper | |
|---|---|---|---|---|---|
| 一致性协议 | CP+AP | AP | CP | — | CP |
| 健康检查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | — | Keep Alive |
| 负载均衡策略 | 权重/ metadata/Selector | Ribbon | Fabio | RoundRobin | — |
| 雪崩保护 | 有 | 有 | 无 | 无 | 无 |
| 自动注销实例 | 支持 | 支持 | 不支持 | 不支持 | 支持 |
| 访问协议 | HTTP/DNS | HTTP | HTTP/DNS | DNS | TCP |
| 监听支持 | 支持 | 支持 | 支持 | 不支持 | 支持 |
| 多数据中心 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 跨注册中心同步 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
| SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 | 支持 |
| Dubbo集成 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
| K8S集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
-
服务注册原理：在
nacos的服务端，有一个用来管理微服务实例的容器，注册中心将微服务的实例交由ServiceHolder处理，ServiceHolder为微服务提供空间并将它的所有实例挂在该空间下。服务注册完成后提供者将于注册中心维护心跳机制，心跳机制可以保证注册中心可以及时的剔除失效的实例。 -
**服务发现原理：**服务完成注册之后，消费者可以向注册中心订阅某个服务，并提交一个监视器，当注册中心的服务发生变更时监听器会收到通知，然后消费者可以更新本地的服务实例列表，以保证所有的服务均可用。
-
nacos的负载均衡：
Nacos的客户端在获取到服务的完整实例列表后，会在客户端进行负载均衡算法来获取一个可用的实例，模式使用的是随机获取的方式。
0、服务容器负责启动，加载，运行服务提供者。 1、服务提供者在启动时，向注册中心注册自己提供的服务。 2、服务消费者在启动时，向注册中心订阅自己所需的服务。 3、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 4、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
是指事务的参与方位于不同的分布式系统的节点上。
-
CAP理论：是设计分布式系统的基础理论依据。强一致性、可用性、分区容错性。
BASE理论，是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩展。
- 基本可用：
- 软状态：相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
- 最终一致性：
两阶段提交协议2PC：
两阶段提交协议中，存在一个节点作为协调者，其他参与事务的节点作为参与者。
第一阶段（准备阶段）：
- 协调者询问所有参与者是否可以执行提交操作，并等待参与者节点的响应。
- 参与者执行各自的本地事务操作，并将操作写入undo 日志。
- 若参与者事务执行成功，返回给协调者同意信号，否则返回终止信息。
第二阶段（提交阶段）：
当协调者节点从所有参与者节点获得的相应消息都为"同意"时
- 协调者向所有参与者发出commit请求。
- 参与者节点完成事务提交操作并释放整个事务期间占用的资源。
- 参与者向协调者返回完成信息。协调者接收到所有参与者返回的完成信息后完成事务。
若任一参与者节点在第一阶段返回的响应消息为"中止"。
- 协调者节点向所有参与者节点发出"回滚操作(rollback)"的请求。
- 参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
- 参与者节点向协调者节点发送"回滚完成"消息。
- 协调者节点受到所有参与者节点反馈的"回滚完成"消息后，取消事务。
三阶段提交协议3PC：
与两阶段提交不同的是，三阶段提交有两个改动点。
- 引入超时机制。同时在协调者和参与者中都引入超时机制。
- 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
**1. XA：**该协议采用两阶段提交（2PC），即整个事务控制过程经历了两个阶段。
- 第一阶段：所有分支的操作都准备好了，由TM告知每个分支准备提交，此时，作为全局事物中的每个RM记录着在稳定存储中的动作（也就是说记录着准备好的这个动作）。
- 第二阶段：TM会告诉RM是提交或回滚，如果所有分支表明准备好能够提交时，RM会被告知提交，如果任何一个RM表明没有准备好或者不能提交，则进行全部回滚。
2. TCC（try-confirm-cancel）：
try阶段：尝试执行，完成所有的业务检查，预留完成业务所必须的资源。
confirm阶段：当TCC事务管理器决定commit全局事务时，就会逐个执行Try操作指定的Confirm操作，将Try未完成的事项最终完成。不作任何业务检查，只使用Try阶段预留的业务资源。
cancel阶段：Cancel 是对Try操作的一个回撤。当TCC事务管理器决定rollback全局事务时，就会逐个执行Try操作指定的Cancel操作，将Try操作已完成的事项全部撤回。
3. MQ事务：
- 在系统A处理任务A前，首先向消息中间件发送一条消息
- 消息中间件收到后将该条消息持久化，但并不投递。此时下游系统B仍然不知道该条消息的存在。
- 消息中间件持久化成功后，便向系统A返回一个确认应答；
- 系统A收到确认应答后，则可以开始处理任务A；
- 任务A处理完成后，向消息中间件发送Commit请求。该请求发送完成后，对系统A而言，该事务的处理过程就结束了，此时它可以处理别的任务了。 但commit消息可能会在传输途中丢失，从而消息中间件并不会向系统B投递这条消息，从而系统就会出现不一致性。这个问题由消息中间件的事务回查机制完成。
- 消息中间件收到Commit指令后，便向系统B投递该消息，从而触发任务B的执行；
- 当任务B执行完成后，系统B向消息中间件返回一个确认应答，告诉消息中间件该消息已经成功消费，此时，这个分布式事务完成。
Seata提供一站式的分布式事务解决方案。可以提供AT（默认使用，基于2PC两阶段模式）、 TCC、 SAGA 、XA事务模式。
Seata的3 + 1个概念：
- TC：事务协调器，负责维护分布式事务的运行状态。负责协调并驱动全局事务的提交或者回滚。
- TM： 事务管理器，是一个分布式的发起者和终结者。最终发起全局提交或回滚决议。
- RM：资源管理器，负责本地事务的运行。负责分支注册，状态汇报，接收事务协调器的指令，驱动本地事务的提交和回滚。
- Transaction ID：全局事务的唯一ID ， XID。
TM是一个分布式事务的发起者和终结者，TC负责维护分布式事务的运行状态，而RM则负责本地事务的运行。
- TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID
- XID在微服务的调用链路中传播
- RM向TC注册分支事务，将其纳入XID对应的全局事务管辖
- TM向TC发起针对XID的全局提交或者回滚决议
- TC调度XID下管辖的全部分支事务完成提交或者回滚请求
-
对于每个微服务对应的数据库都需要添加一张回滚日志表。用于自动的回滚一些数据。
-
下载
seata-server软件包，github.com/seata/seata/releases -
导入依赖
spring-cloud-starter-alibaba-seata -
启动
seata-server -
所有想要使用到分布式事务的微服务使用
seata DatasourceProxy代理自己的数据源 -
@GlobaTransactional开启全局事务。（只需要给分布式事务入口标上该注解即可），对于远程调用的方法不需要标。 -
启动各个微服务即可。
由于Netflix的hystrix停止更新，所以改用spring cloud Alibaba的sentinel组件实现系统的限流、熔断、降级。
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的轻量级高可用流量控制产品，由阿里中间件团队开源。主要以流量为切入点，从**流量限制、服务熔断降级、**系统负载保护等多个维度来帮助您保护服务的稳定性。
sentinel项目分为7个主要部分，其中最主要的 就是sentinel-core模块。限流、熔断、降级、系统保护等都在这里实现。
流量控制在网络传输中是一个常用的概念，它用于调整网络包的发送数据。然而，从系统稳定性角度考虑，在处理请求的速度上，也有非常多的讲究。任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。Sentinel 作为一个调配器，可以根据需要把随机的请求调整成合适的形状。
**限流：**对于打入集群的请求流量在入口处进行控制，使服务能够承担不超过自己能力的流量压 力。
**熔断：**A服务调用B服务，由于各种各样的原因导致请求时间过长。这样的情况次数过多就应该考虑将B服务直接断路。凡是调用B服务直接返回错误数据。
**降级：**由于服务器的压力较大而对一些服务进行有针对的降级，从而保证核心业务的正常运行。
| 对比内容 | Sentinel | Hystrix |
|---|---|---|
| 隔离策略 | 信号量隔离 | 线程池隔离/信号量隔离 |
| 熔断降级策略 | 基于响应时间或失败比率 | 基于失败比率 |
| 实时指标实现 | 滑动窗口 | 滑动窗口（基于 RxJava） |
| 规则配置 | 支持多种数据源 | 支持多种数据源 |
| 扩展性 | 多个扩展点 | 插件的形式 |
| 基于注解的支持 | 支持 | 支持 |
| 限流 | 基于 QPS，支持基于调用关系的限流 | 不支持 |
| 流量整形 | 支持慢启动、匀速器模式 | 不支持 |
| 系统负载保护 | 支持 | 不支持 |
| 控制台 | 开箱即用，可配置规则、查看秒级监控、机器发现等 | 不完善 |
| 常见框架的适配 | Servlet、Spring Cloud、Dubbo、gRPC 等 | Servlet、Spring Cloud Netflix |