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

发布于: 7 小时前

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、模式间的对比

发布于: 7 小时前 阅读数: 3
用户头像

Albert

关注

还未添加个人签名 2018.08.31 加入

还未添加个人简介

评论

发布
暂无评论
微服务架构下分布式事务解决方案