Spring Cloud Alibaba

原创已于 2024-10-24 11:21:44 修改 · 907 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#java #开发语言 #1024程序员节

于 2024-10-22 17:39:55 首次发布

框架原理专栏收录该内容

9 篇文章

订阅专栏

拆分成微服务架构的优点：

如果某一个服务出了问题，最终宕机的是当前问题服务，而对于单体架构，然后一出出来error如OOM，可能整个工程都崩溃了。

对于大型项目，拆成多个服务后，可以更细致的管理，达到敏捷开发，如果是很多人共同去维护一个项目，在提交代码的时候可能还会频繁出现合并冲突。

注册中心的引入：早些年，在微服务架构引进之前，我们如果把一个工程拆成多个子系统，更多的是通过给不同的子系统分配一个二级域名，然后交给nginx来负载均衡。引进微服务架构，如现在流行的Alibaba，它提供了注册中心nacos，用处是：每当一个服务注册进服务中心的时候，将服务信息配置进注册中心，然后其他服务去调用的时候，根据我需要的接口所在的服务名称，去注册中心拿并缓存到本地，这样我们可以在客户端做到负载均衡，而不是等到请求打到服务端上再做。

Ribbon

Ribbon怎么根据服务名称解析成指定IP：端口号的？

在restTemplate的Bean上添加@Ribbon注解，将来在调用http接口的时候，底层会被拦截器LoadBalanceInterceptor.intercept给拦截，在拦截器里面被拦截。根据服务名称去nacos注册中心把服务名对应的服务全部拿过来，缓存到本地。同时（默认轮询）有一个负载均衡策略去帮我们负载均衡。

Nacos

Nacos两大版本：分为1.4.x和2.x两个版本。

前者还是基于http协议，心跳检查任务依靠nacos提供的，即每隔几秒去检测一下当前实例是否健康。后者基于grpc协议，有一个长连接，当有一方不健康了，就能立马感知。同时性能上，后者比前者提高了2~3倍。

OpenFeign

直接通过restTemplate去发http请求，需要去拼接一个长字符串，可读性不太好，维护麻烦。引入OpenFeign组件，它在我们发起请求的时候，会生成一个代理，去帮我们在底层完成字符串拼接，同时帮我们Ribbon，根据Ribbon的负载均衡策略。

Sentinel

服务降级

对于大型项目中，核心链路中的一些非核心业务，比如说交易服务去调用积分服务以及发货服务，如果此时积分服务出现问题崩溃了。用户来交易，它不会说是直接回滚，而是通过日志记录的形式，去记录一下，然后后期通过定时器去查看并补偿。这就是服务的降级处理，正常的走不通，我就改成补偿服务。

调用积分服务，如果调用失败，通过fallback回调，去调用对应的方法。

原理：在调用积分服务的时候，sentinel会帮我们try-catch包住，如果发生了异常，则进入catch代码块，即进入fallback方法逻辑...

服务限流

假设我们当前项目可以容纳的并发量是1w/s ，但是在某一时刻来了10w/s的并发量，这个时候通过服务限流，只让其中1w条请求访问成功，另外9w条返回失败【当然，我们可以给予友好提示，如请重试等】

我们也可以通过其他中间件，在java层代码实现限流，如通过redis的increment方法，原子性的自增，当加到一定数后，进行限流。

服务熔断

场景一般是三个服务以上，A服务先调用B服务，拿到B服务的返回值后，去调用C服务。BC服务有先后顺序的。此时B服务崩溃了，A服务调用B服务失败，接着降级策略，调用B服务的fallback方法，然后A拿到B的fallback方法返回值去调用C服务。相比之下，不用去等B服务正常，而是选择跳过B服务。

Seata

TC - Transaction Coordinator（事务协调器）：
TC 是分布式事务的协调者，负责维护分布式事务的状态和决定全局事务的提交或回滚。

TM - Transaction Manager（事务管理器）：
TM 是全局事务的发起方，它会向 TC 注册全局事务，并请求开始一个新的全局事务。TM 断定全局事务的边界，负责开启、提交或回滚一个全局事务。

RM - Resource Manager（资源管理器）：
RM 负责管理分布式事务内的单个资源（如数据库、消息服务等），这些资源局部地参与全局事务。它向 TC 注册自己管理的资源，报告资源的可用性并响应 TC 的指令，执行具体的分支事务的提交和回滚操作。

这三者的协同工作使得 Seata 能够有效地处理分布式事务，保证事务的ACID。TM 开始一个全局事务，然后多个 RM 加入到这个事务中，实际执行资源的本地事务，最后由 TM 根据各 RM 的执行结果请求 TC 来提交或回滚全局事务。TC 在这个过程中负责统一调度和决策，确保事务的最终一致性。

AT模式

自动补偿事务，其核心是全局事务和分支事务概念。
全局事务：由 TM开始并最终提交或回滚。全局事务包含多个分支事务。
分支事务：由 RM 控制，它连接到资源（如数据库）并管理本地事务的生命周期。
第一阶段：当一个全局事务开始时，Seata 会在其事务存储中创建一条全局事务记录来管理分支事务。
分支事务在本地数据源上执行的每次修改都会被 Seata 记录下来，包括修改前的数据和修改后的数据，生成行锁。基于数据库的undolog 回滚日志。
第二阶段：在全局提交时，如果所有分支事务都成功，则全局事务将被提交。如果任意分支事务失败，则 Seata 会根据undo log来补偿之前的数据修改，即执行回滚。

这个模式适用于不要求强一致性的场景，它支持最终一致性。

XA模式

XA 模式基于 XA 模型和 X/Open DTP（Distributed Transaction Processing）标准，通过两阶段提交保证分布式事务的一致性。在第一阶段，协调者询问所有参与者是否准备好提交，如果所有参与者都答复准备好，则进入第二阶段，协调者命令所有参与者进行提交。如果有任何参与者无法提交，协调者命令所有参与者回滚。
Seata XA 模式支持集成那些已经支持 XA 协议的资源。

这个模式适用于强一致性的场景，同时资源管理器支持XA协议。