背景
微服务的发展
微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。Hailo有160个不同服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴、腾讯、360、京东、58同城等很多互联网公司都进行了微服务化实践。当前微服务的开发框架也非常多，比较著名的有Dubbo、SpringCloud、thrift 、grpc等。
本节视频议题及讲解顺序

微服务架构介绍

• 微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。
• 系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。
• 每个微服务内聚不同的业务模块。

分布式事务详解

• 本地事务

• 分布式事务-跨库事务

• 分布式事务-微服务

XA/JTA规范
两阶段提交协议(2PC)

开源框架atomikos

• TransactionEssentials：开源的免费产品
• ExtremeTransactions：商业版，需要收费

柔性事务
CAP理论

• 开发大规模的分布式系统时会遇到三个特性：一致性（Consistency）、可用性（Availability）、分区容错（Partition-tolerance），而一个分布式系统最多只能满足其中的两项。
• 分区容错性是分布式系统必然需要面对和解决的问题，因此系统架构师往往需要把精力花在如何根据业务特点在C（一致性）和A（可用性）之间寻求平衡。而前面我们提到的JTA 两阶段提交协议的分布式事务方案，强调的就是一致性；由于可用性较低，实际应用的并不多。

BASE理论
1.基本可用（Basically Available）

• 指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

2.软状态（ Soft State）

• 指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3. 最终一致（ Eventual Consistency）

• 强调的是所有的数据更新操作，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

柔性事务
TCC(Try-Confirm-Cancel)两阶段补偿型方案

TCC(Try-Confirm-Cancel)两阶段补偿型方案

TCC(Try-Confirm-Cancel)框架

TCC与XA/JTA对比

TCC与XA/JTA对比

• XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁
• TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁

TCC的开源框架实现

• Atomikos，tcc-transaction，ByteTcc，支付宝GTS

最大努力通知方案

• 最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等

可靠消息最终一致性方案

• 基于Rocket MQ

可靠消息最终一致性方案

• 基于普通的消息队列中间件

架构师技能集合：

领取的朋友们记得一定要帮我点赞支持一下！谢谢大家！