大型互联网应用技术方案

服务注册发现

1. eureka：AP 模型，服务发现时间缓慢，如果使用默认参数，服务发现极限情况需要超过一分钟，集群模式服务信息通过 Http 同步，由于本身集群信息无法分片存储，在大规模集群场景下 eureka 节点间由于心跳续约，服务上下线等变动需要通过广播同步信息，eureka 服务端会承担大量请求，不适合大规模集群场景。

2. zk：CP 模型，保证一致性的同时，在主节点选举过程中整个集群面临不可用的情况，同样不适合于大规模集群场景。

3. nacos：CP 和 AP 都可以支持，集群之间使用 Raft 协议同步数据，通过 namespace，group，clustername 实现服务隔离，方便自定义灰度逻辑

网关（往往集成鉴权，埋点等自定义功能，结合 nginx 使用）

1. Zuul：服务动态路由，阻塞式 IO

2. Gateway：服务动态路由，结合 Webflux 支持异步，内部支持限流，负载均衡

熔断限流

1. hystrix：主要通过线程池的方式实现服务间线程隔离，避免因为调用某个故障服务，夯住己方所有线程，导致服务雪崩，支持信号量隔离

2. sentinel：主要通过信号量的方式进行资源隔离，支持 QPS 限流，热点资源限制，关联资源限制，服务熔断降级等等，相比 hystrix 更加轻量级，限流方式更加丰富。生产环境使用需要修改 sentinel dashbord 源码，结合 nacos 实现限流规则持久化生效，结合 es 实现流量监控数据持久化。

分布式事务

1. 强一致性

2. 传统 TCC：try-confirm-cancel，需要实现自我补偿机制，较为麻烦

3. 重写 jdbc commit 方法，假提交，等待事务管理中心通知，决定最终提交还是放弃，该方案对性能影响较大，不推荐

4. seata：TM 事务发起者，TC 事务协调中心，RM 分支事务。TM 负责向 TC 申请开启全局事务，拿到全局事务 ID XID，记录在 header 中，分支事务执行期间加锁，执行完毕后直接提交，但是会记录下 undo 日志，通过 base64 转码存储于数据库中，如需回滚直接通过 undo 日志回滚，性能较好，无侵入。

5. 最终一致性

6. 通过 MQ 异步通知，如执行失败，通过手动 ack 重试一定次数，直到最终成功。如果重试期间均未成功，则进入死信队列，开发人员手动处理，对性能无影响。