分布式事务(1)-理论基础
分布式事务(3)---强一致性分布式事务Atomikos实战
分布式事务(4)---最终一致性方案之TCC
一、服务架构演进
1.单体应用：
最初的所有业务全部融合在一起，我们最初接触到的一个java应用开发完成之后打成一个war包进行部署。
优点：
1）架构简单，所有项目模块部署在一起，对于小型项目来说方便维护
缺点：
1）所有模块耦合在一起，对于大型项目来说不易与开发和维护
2）耦合度过高，一旦一个模块出现问题，会导致整个项目不可用
3）无法针对某个具体的模块来提升性能
4）无法进行水平扩展
2.垂直应用：
为满足业务需求，将单体应用部署多份到不同服务器上。但是无法根据某个模块来进行优化和性能提升，比如有些模块属于CPU密集型的，有些属于IO密集型的。无法进行针对性的优化。垂直应用架构就是将单体应用拆分未及格互不相干的应用，来提升整个系统的性能。比如针对C端的部署成一个应用，管理后台部署成一个服务，C端一般流量大，这个时候只需要把C端的服务多部署几个节点，而管理后台访问量则不需要。
优点：
1）可以根据不同系统的访问情况进行针对性优化
2）能够实现水平扩展
3）各系统分担流量，解决并发量问题
4）子系统故障，不影响其他子系统运行，提高整体的容错率
缺点：
1）拆分后各系统相对独立，无法进行相互调用
2）难免存在重叠的业务，重复开发，增加维护成本
3.分布式应用
垂直应用越来越多，重复的的代码也会越来越多，这个时候就讲重复的业务抽离出来形成单独的服务，提供给其他业务某块调用。这个时候一般拆分成表现层和服务层，服务层负责处理业务逻辑，提供给表现层调用，表现层负责和前端进行交互。
优点：
1）重复代码抽离，提高代码复用
2）可以针对性的进行优化
缺点：
1）系统之间调用关系，依赖关系变得复杂
2）系统维护成本变高
4.SOA（面向服务）架构
分布式架构下，当服务部署越来越多的时候，服务之间的关系，调用越来越复杂，这个时候我们需要增加统一的调度中心，对所有服务进行管理。增加注册中心，解决各个服务之间的依赖和调用关系，使其自动注册与发现。这个时候服务的粒度任然比较粗。
缺点：
1）某个服务出现问题，可能造成服务不可用
2）增加测试、运维成本
5.微服务架构
微服务架构是在SOA基础上进一步的扩展和拆分。将一个大项目拆分成一个个小的可独立部署的微服务，每个服务有自己的数据库。
优点：
1）服务彻底拆分，各个服务独立打包部署，独立升级维护
2）每个服务复杂的业务清晰，利于后期扩展升级、维护
3）服务之间采用REST或者RPC协议通信
缺点：
1）开发成本高（对开发人员要求更高）
2）成本更高，每个服务都需要机器来部署
3）涉及各个服务的容错性问题
4）涉及数据一致性问题
5）涉及分布式事务问题
二、分布式事务场景
1.跨JVM进程
因为服务拆分之后，要完成一个完整业务流程就可能涉及到多个服务之间调用。
2.跨数据库实例
分库导致或者本身业务就是操作不同的库
3.多个服务访问单数据库
三、数据一致性解决方案
ACID特性：利用数据库事务的ACID（原子性、一致性、隔离性、持久性）特性。有些分布式事务解决方案其实最终也是要依赖数据库的此特性。比如阿里seata中的AT模式。还有DTP模型、2PC模型（两阶段提交）、3PC（三阶段提交）、TCC模型、可靠消息最终一致性模型、最大努力通知模型
四、分布式事务基本理论
分布式事务的两大基本理论：CAP理论和Base理论
CAP（consistency一致性、可用性availability、分区容错性partition tolerance）
要满足一致性那么我们在各个节点之间同步数据的时候，需要对资源进行锁定等所有节点都同步完成之后再返回数据。防止在同步过程中应用程序从从节点读取到不一致的数据。
可用性所有请求都会被响应，不会存在响应超时或错误的情况。
分区容错，如果将系统部署在一个节点，那么当节点出现故障时，整个系统将不可用。
因此需要多个节点部署，一个节点挂掉，其他节点也能对外提供服务。分区容错时一个分布式系统必须具备的基础能力。
AP：放弃一致性，但是一般都会考虑最终一致性。允许多个节点在一定时间内数据存在差异，一定时间之后达到一致。比如eureka，节点之间同步数据是一个定时任务从其他节点去同步数据的，定时任务没有触发的这个时间内，节点之间的数据是不一致的。
CP：放弃可用性。当系统对一致性要求比较高的时候使用。比如ZK，写入数据时需要保证过半的节点写入之后，leader才会提交结果并返回。以此来保证数据的一致性。
CA：放弃分区容错性，此时系统不会进行分区，也不用考虑网络不通，节点挂掉等情况，严格来说此时的系统已经不是一个分布式系统了。
Base理论是对AP的一个扩展，它牺牲了强一致性来获得可用性。Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）的缩写。
软状态比如订单中可以设计“支付中”，“退款中”这种中间状态，过一段时间之后变成“支付成功”“退款成功”。
后续：
强一致性分布式事务解决方案、最终一致性分布式事务解决方案
