微服务架构下分布式事务解决方案

1、可扩展性；

2、可用性；

3、成本

2、常见的微服务架构模式

Command 模式

对

Event 模式

抛出一个事件，发布出系统【发生什么】，解耦

2-1、聚合模式

2-2、代理模式

代理只会根据 URL 去选择一个服务链路；

2-3、链式模式

类似

2-4、分支模式

2-5、数据共享模式

把单体应用的服务拆分，但是没有对数据进行拆分，形成【分布式单体】应用；

没有解决数据瓶颈；

3、微服务架构的痛点

3-1、微服务发展的背景

互联网快速发展，需要 7*24 小时提供服务，系统并发升高；

需要提升 稳定性，可用性

3-1、服务鉴权

单体应用是进程间通信

拆分成【微服务】，调用多个服务，需要服务鉴权？

为什么需要鉴权？

无法避免其他系统【不合规】参数调用；

3-2、平滑上下线

需要保证服务链路可用，服务上下线，依赖节点调用失败，数据不一致；

通过【注册中心】

3-3、灰度发布

新开发功能，没有经过生产验证；

怎么做灰度发布？

1、在新的业务逻辑中加开关，加入白名单；

2、在接入层负载均衡，进行分流；Dubbo 重新 LoadBalance，doSelect 方法，SpringCloud 的 AbstractRoute 功能

3-4、全链路追踪

如何快速定位哪个微服务链路的问题？哪个微服务节点出的问题？

痛点：无法全部采样，只能采样部分，没有采样的链路出现问题，traceId 中的 span 全部记录？

(1) 无侵入性

(2) 有侵入性

3-5、限流降级

单体应用，服务部署比例 1:1

微服务下，服务部署【按流量】部署

服务的拆分粒度，共用性

微服务不是银弹

4、微服务为什么需要分布式事务

1、微服务架构下的分布式事务解决方案有哪些？

5、微服务分布式事务 Seata 框架

TM

1、GTM（Global）

2、LTM（Local）

5-1、分布式事务流程

5-2、分布式事务调用链路

5-3、Seata-AT 模式

5-4、Seata-TCC 模式

空回滚和全挂

数据库操作放在同一事务

5-5、Seata-Sega 模式

5-6、Seata 高可用

5-7、模式间的对比