微服务的分布式事务，微服务分布式框架有哪些类型

本文目录导读：

1. 微服务分布式框架的类型
2. 微服务分布式事务

《微服务分布式框架类型与分布式事务探究》

图片来源于网络，如有侵权联系删除

微服务分布式框架的类型

（一）Spring Cloud

1、服务治理

- Spring Cloud Netflix中的Eureka是一个服务注册与发现组件，它允许微服务实例在启动时将自己注册到Eureka服务器上，并且能够定期发送心跳以表明自己的存活状态，其他微服务可以从Eureka服务器查询到所需服务的实例列表，从而实现服务间的调用。

- Ribbon是一个客户端负载均衡器，它可以与Eureka集成，当一个微服务需要调用另一个微服务时，Ribbon会从Eureka获取服务实例列表，并根据负载均衡算法（如轮询、随机等）选择一个实例进行调用，提高了系统的可用性和性能。

2、配置管理

- Spring Cloud Config提供了分布式系统中的外部化配置支持，它允许将配置文件存储在远程的Git仓库或其他存储介质中，微服务在启动时可以从配置中心获取配置信息，这样在需要修改配置时，无需重新部署每个微服务实例，只需要更新配置中心的配置即可，大大提高了配置管理的效率。

（二）Dubbo

1、高性能服务调用

- Dubbo是一个高性能的Java RPC框架，专注于提供高效的服务调用，它采用了长连接的方式，减少了每次服务调用建立连接的开销，在微服务架构中，Dubbo能够快速地在不同的服务之间进行通信，并且支持多种序列化方式，如Hessian、Java序列化等，可以根据实际需求进行选择，以提高序列化和反序列化的效率。

2、服务治理能力

- 具有服务注册与发现功能，Dubbo的注册中心可以是Zookeeper等，服务提供者将自己的服务信息注册到注册中心，服务消费者从注册中心获取服务提供者的信息并进行调用，Dubbo还提供了服务的路由、负载均衡等功能，能够根据不同的规则将请求分发到合适的服务实例上。

图片来源于网络，如有侵权联系删除

（三）Kubernetes（K8s）

1、容器编排与管理

- Kubernetes是一个开源的容器编排平台，在微服务架构中扮演着重要的角色，它可以对微服务进行容器化部署，将每个微服务封装到一个或多个容器中，Kubernetes能够管理这些容器的生命周期，包括创建、启动、停止和销毁等操作，通过Pod概念将相关的容器组合在一起，方便管理和资源分配。

2、服务发现与网络管理

- 在Kubernetes中，通过Service资源实现服务发现，它为一组Pod提供了一个统一的访问入口，并且可以实现负载均衡，Kubernetes还构建了自己的网络模型，确保不同的Pod之间、不同的服务之间能够进行通信，支持多种网络插件来满足不同的网络需求。

微服务分布式事务

（一）分布式事务的挑战

1、数据一致性

- 在微服务架构中，一个业务操作可能涉及多个微服务的数据更新，在一个电商系统中，订单微服务创建订单后，库存微服务需要减少库存，用户微服务可能需要更新用户的订单历史，如果其中一个微服务操作成功，而另一个失败，就会导致数据不一致，传统的单机事务（如数据库的ACID事务）无法直接应用于这种跨微服务的场景。

2、网络通信的不确定性

- 微服务之间通过网络进行通信，网络可能会出现延迟、丢包甚至故障等情况，当一个微服务发送事务请求到另一个微服务时，由于网络问题可能导致请求丢失或者响应延迟，这种网络通信的不确定性增加了分布式事务管理的难度。

（二）分布式事务的解决方案

图片来源于网络，如有侵权联系删除

1、两阶段提交（2PC）

- 原理：2PC协议将分布式事务的提交过程分为两个阶段，即准备阶段和提交阶段，在准备阶段，事务协调者向所有参与者发送准备请求，参与者执行本地事务操作并将执行结果（是准备好提交还是回滚）反馈给协调者，如果所有参与者都反馈准备好提交，那么在提交阶段，协调者向所有参与者发送提交请求，参与者正式提交本地事务；如果有任何一个参与者反馈回滚，协调者则向所有参与者发送回滚请求。

- 缺点：存在单点故障问题，事务协调者一旦出现故障，整个分布式事务可能会被阻塞，而且在准备阶段，参与者需要一直持有资源（如数据库锁），直到收到提交或回滚指令，这可能会导致资源长时间被占用，降低系统的并发性能。

2、补偿事务（TCC - Try - Confirm - Cancel）

- 原理：TCC是一种基于业务层面的分布式事务解决方案，Try阶段是对业务资源的检查和预留，例如在库存微服务中，Try阶段会检查库存是否足够并进行预留操作，Confirm阶段是对Try阶段预留资源的确认提交，如果Try阶段成功，Confirm阶段将正式更新业务数据，如将库存减少，Cancel阶段是在业务执行失败或者需要回滚时，对Try阶段预留资源的取消操作，例如将预留的库存释放。

- 优点：相比2PC，TCC的性能较好，因为它不需要长时间持有资源锁，而且它是基于业务逻辑的，更加灵活，可以根据不同的业务场景进行定制，缺点是对业务的侵入性较大，需要开发人员在业务代码中编写Try、Confirm和Cancel逻辑。

3、基于消息队列的最终一致性

- 原理：在这种方案中，一个微服务在执行本地事务后，会发送一个消息到消息队列，其他相关的微服务通过订阅消息队列中的消息来执行相应的操作，订单微服务创建订单后，发送一个消息到消息队列，库存微服务订阅该消息并减少库存，由于消息可能存在延迟到达等情况，系统在一段时间内可能处于不一致状态，但最终会达到一致，所以称为最终一致性。

- 优点：这种方案解耦了微服务之间的直接依赖关系，提高了系统的可扩展性和容错性，而且消息队列可以起到缓冲的作用，应对高并发场景，缺点是实现复杂，需要处理消息的重复消费、消息丢失等问题。

微服务分布式框架类型多样，每种都有其特点和适用场景，而在微服务架构下的分布式事务管理是一个复杂的问题，需要根据具体的业务需求和系统架构选择合适的解决方案，以确保数据的一致性和系统的正常运行。

标签： #微服务 #分布式事务 #分布式框架 #类型