是一种架构模式或风格，将单一的应用程序划分成一组小的服务，每个服务其实都是一个SpringBoot应用。每个服务运行在其独立的自己的进程内，服务之间互相协调，互相配置。服务之间采用轻量级的通信机制（HTTP或RPC二进制传输）互相沟通，每个服务都围绕着具体的业务进行构建，并且能够独立部署。
1、六大组件
| 名称 | 说明 |
|---|---|
| 注册中心 | 如Euraka、Zookeeper、Consul、Nacos。实现服务注册与发现。 |
| 配置中心 | 如Config、Nacos。统一管理各个服务的配置文件。 |
| 网关服务 | 如Zuul、Zuul2、Gateway。作为外部访问的统一入口，统一处理请求，将请求分发到相应的服务中。 |
| 负载均衡 | 如Ribbon、LoadBalancer。合理的将请求发送到不同的服务中去，保证高可用。 |
| 熔断器 | 如Hystrix、Sentinel。实现服务熔断、服务降级和服务限流处理，是为了解决集群中因为请求出现的故障点，保证集群的高可用。 |
| 远程调用 | 如feign、openFeign。内置了Ribbon。可以调用服务注册中心的其他服务的Rest接口。 |
2、CAP原则
指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
- 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值（等同于所有节点访问同一份最新的数据副本）。
- 可用性（A）：保证每个请求不管成功或者失败都有响应。
- 分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。
3、分布式事务
3.1、Seata
- 作用：为解决分布式下的事务问题，是作为一个服务运行在我们的分布式项目中的。
- 使用：只需要使用
@GlocalTransactional注解在业务方法上即可。
3.1.1、术语
- TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。
- TM (Transaction Manager) - 事务管理器：定义全局事务的范围，开始全局事务、提交或回滚全局事务；
- RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交互以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
其中TC为单独部署的 Server 服务端，TM和RM为嵌入到应用中的 Client 客户端。TM就是标注了@GlocalTransactional注解的发起者。RM作为参与者，可以理解为数据库。
3.1.2、原理
- TM请求TC开启一个全局事务，TC会生成一个XID作为该全局事务的编号，XID会在微服务的调用链路中传播，保证将多个微服务的子事务关联在一起。
- RM请求TC将本地事务注册为全局事务的分支事务，通过全局事务的XID进行关联。
- TM请求TC告诉XID对应的全局事务是进行提交还是回滚。
- TC驱动RM将XID对应的自己的本地事务进行提交还是回滚。
3.1.3、四种模式
3.1.3.1、AT模式（Seata默认）
AT 模式分为两个阶段：
- 一阶段：执行用户
SQL - 二阶段：
Seata框架自动生成
3.1.3.2、TCC模式
TCC分为三个阶段：
- Try：做业务检查和资源预留
- Confirm：确认提交
- Cancel：业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放
3.1.3.3、Sage模式
Sage 是长事务解决方案。
3.1.3.4、XA模式
是 Seata 将会开源的另一种无侵入的分布式事务解决方案。