分布式事务基本概念

分布式架构目标和架构的原则

        分布式系统架构的设计虽然比较复杂，但是也有一些业界遵循的原则，其中一些典型的架构原则主要有以下15项：

• N+1 设计
• 回滚设计
• 禁用设计
• 监控设计
• 设计多活数据中心
• 使用成熟的技术
• 异步设计
• 无状态系统
• 水平拓展而非垂直升级
• 设计时至少要有两步前瞻性
• 非核心则购买
• 使用商业化硬件
• 小构建，小发布和快试错
• 隔离故障
• 自动化

分布式系统架构演进

        系统架构大致经历了单体应用架构--垂直应用架构--分布式架构--SOA架构--微服务架构的演变，很多互联网企业系统架构已经向服务化网格演变

• 单体应用架构：全部功能代码打包成一个服务并且部署在服务器上

优点：

1. 架构简单，项目开发和维护成本低
2. 所有项目模块部署到一起，对于小型项目来说，方便维护

缺点：

1. 所有模块耦合在一起，对于大型项目来说，不易开发和维护
2. 项目各个模块之间过于耦合，一旦有模块出现问题，整个项目将不可用
3. 无法针对某个具体模块来提升性能
4. 无法对项目进行水平拓展

• 垂直应用架构：将原来的项目应用拆分为互不相干的几个应用，以此提升系统的整体性能

优点：

1. 对系统进行拆分，可根据不同系统的访问情况，有针对性的进行优化
2. 能够实现应用的水平拓展
3. 各系统能够分担整体访问流量，解决了并发问题
4. 子系统发生故障，不影响其他子系统的运行情况，提高了整体的容错率

缺点：

1. 拆分后各系统之间相对独立，无法进行互相调用
2. 各系统难免存在重叠的业务，会存在重复开发的业务，后期维护比较困难

• 分布式架构：将系统整体拆分为服务层和表现层，服务层封装了具体的业务逻辑供表现层调用，表现层则负责处理与页面的交互操作

优点：

1. 将重复的业务代码抽象出来，形成公共的访问服务，提高了代码的复用性
2. 可以有针对性地对系统和服务进行性能优化，以提升整体的访问性能

缺点：

1. 系统之间的调用关系变得复杂
2. 系统之间的依赖关系变得复杂
3. 维护成本高

• SOA架构：添加一个统一的调度中心对集群进行实时管理，这就是SOA（面向服务）架构

优点：

1. 通过注册中心解决了各个服务之间服务依赖和调用关系的自动注册与发现问题

缺点：

1. 各服务之间存在依赖关系，如果某个服务出现故障，可能会造成服务器崩溃
2. 服务之间的依赖和调用关系复杂，增加了测试和运维的成本

• 微服务架构：在SOA架构基础上进行了进一步的扩展和拆分，在微服务架构下，一个大的项目拆分成一个个小的可独立部署的微服务，每个微服务都有自己的数据库

优点：

1. 服务彻底拆分，各服务独立打包，独立部署和独立升级
2. 每个微服务负责的业务比较清晰，有利于后期扩展和维护
3. 微服务之间可以采用REST和RPC协议进行通信

缺点：

1. 开发成本高
2. 涉及各服务的容错性问题
3. 涉及数据的一致性问题
4. 涉及分布式事务问题

分布式事务场景

        将一个大的应用系统拆分为多个可以独立部署的应用服务，需要各个服务远程协助才能完成某些事务操作，总的来说，分布式事务会在一下3中场景下产生，分别是夸JVM进程、跨数据库实例、多服务访问单数据库

• 跨JVM进程：各个服务之间通过远程REST或者RPC调用来协同完成业务操作，各个服务部署在不同的JVM进程中，此时会产生因跨JVM进程而导致的分布式事务问题
• 跨数据库实例：单体系统访问多个数据库实例，也就是跨数据源访问时会产生分布式事务，由于数据分布在不同的数据库实例中，需要通过不同的数据库连接会话来操作数据库中的数据，因此产生了分布式事务
• 多服务访问单数据库：多个微服务访问同一个数据库，本质上也是通过不同的数据库会话来操作数据库，此时就会产生分布式事务

数据一致性

总的来说，数据一致性问题包含数据多副本、调用超时、缓存与数据库不一致、多个缓存节点数据不一致等场景

数据一致性解决方案

业界对于数据一致性问题提出了相应的解决方案，目前比较成熟的方案有

1. ACID特性
2. CAP理论
3. Base理论
4. DTP模型
5. 2PC（两阶段提交）模型
6. 3PC（三阶段提交）模型
7. TCC模型
8. 可靠消息最终一致性模型
9. 最大努力通知模型等