前言

随着软件系统的不断迭代，目前越来越多的单体应用已经不再满足当前业务的需求，分布式系统越来越普及（一个应用往往部署到很多台不同的机器上）。为了保证在多机部署环境中，不同机器不同的进程之间 业务操作的安全，分布式锁应运而生。

必备条件

为了保证分布式锁的可用，：

互斥性/排他性：任意时刻，只会有一个”人“能持有锁。

不会发生死锁：在”甲“持有锁的期间系统崩溃导致没有主动释放锁，也能保证后续 ”乙“能获取锁。-设置超时时间

加锁和解锁需得同一个”人“：”甲“不能把”乙“加的锁给释放了，隔离性。

二阶段提交

强一致性设计，引入了”事务协调者“协调管理各个本地事务的提交和回滚。两个阶段分别是 准备 和 提交 。

准备： 将提交事务之前的事情全部执行完成

提交：所有本地参与者都准备完成的话 协调者会向所有参与者发送提交事务的命令，然后等到所有事务都提交成功 才能说事务执行成功。

情况1：准备阶段失败-协调者会告知所有参与者进行回滚 分布式事务执行失败

情况2：第二阶段的提交如果是 ”回滚事务“ 那么需要不断重试 直到成功 不然在第一阶段准备成功的参与者都会一致阻塞。

情况3：第二阶段的提交如果是 ”提交事务“ 那么也是不断重试

介绍

由一台注册中心和很多个微服务构成。当服务启动，会向注册中心注册服务，注册中心也会主动将服务列表反馈给各个微服务。当服务A想要调用服务B，A需要先知道B的调用地址，反向同理

微服务组件之一，提供上述三大功能。特性如下

Nacos特性 服务发现和服务健康监测，动态配置服务，动态 DNS 服务，服务及其元数据管理......

地图：

特性大图：要从功能特性，非功能特性，全面介绍我们要解的问题域的特性诉求

架构大图：通过清晰架构，让您快速进入 Nacos 世界

业务大图：利用当前特性可以支持的业务场景，及其最佳实践

介绍

作为微服务的统一入口，可能还会涉及 认证，监控，负载均衡，限流等功能

依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

介绍

微服务架构：将原本的一个单体应用拆分成多个应用程序，其中每个微服务运行在自己的进程上，并且能通过自动化部署将其独立发布上线。它们之间通过轻量级的通信机制进行交互，通常服务会根据业务模块进行划分，各个服务职责单一。服务可使用不同的编程语言，不同的数据库，不同的技术栈。