微服务和单体架构
单体架构
当项目规模较小时，这种模式上手快，部署、运维也都很方便，因此早期很多小型项目都采用这种模式。
优点：
1.整个项目只有一个工程，结构简单，开发周期短。
2.部署简单。
缺点：
随着项目的规模越来越大，团队开发人员也不断增加，单体架构就呈现出越来越多的问题：
1.团队协作成本高：试想一下，你们团队数十个人同时协作开发同一个Java工程，由于所有模块都在一个工程中，最终要把所有模块代码合并到一个分支，代码冲突率增加，团队协作成本增加。
2.系统发布效率低：任何模块变更都需要发布整个系统，任何一处出现问题都会导致发布失败，往往一次发布需要数十分钟甚至数小时。
3.扩展困难，在单体架构中，所有功能紧密集成，这意味着当某一部分（如订单处理）需要更多资源时，整个系统必须一起扩展。例如，在双十一期间订单量激增，不仅订单接口需要更多支持，支付接口也是如此。但由于采用了单体架构，我们不能单独扩展这些服务，而是需要增加整个系统的资源或者部署更多服务器节点，这可能会导致其他部分资源的浪费。
使用springboot还是springcloud ，一般要看业务，并发量，以及之后的发展。
总结：小而简的系统用单体（快速落地），大而杂的系统用微服务（灵活扩展）；初期用单体验证，后期按需拆分为微服务，是更务实的选择。
nacos心跳机制
- 服务端→客户端（主动检测）：Nacos 服务端会定期（默认 5 秒）向客户端发送健康检查请求，客户端需在 30 秒内响应，否则标记为不健康；
- 客户端→服务端（主动上报）：服务实例启动后，每 5 秒向 Nacos 服务端发送心跳包（包含服务名、实例 IP、端口等），服务端收到后更新实例的最后心跳时间；
- 健康状态判断：服务端若 15 秒内未收到客户端心跳，将实例标记为 “不健康”；30 秒未收到则从服务列表中剔除（默认配置，可通过 nacos.instance.heart.beat.timeout 等参数调整）。
openfeign的原理与优点
OpenFeign 的核心原理是利用 动态代理 和 注解元数据 在运行时构造和发送 HTTP 请求，并通过与 Ribbon/LoadBalancer 集成实现负载均衡，与 Spring 编解码器 集成实现数据转换。
其最大优势在于 声明式编程模型，通过简单的接口定义取代冗长的 HTTP 客户端代码，显著提升开发效率和代码可读性、可维护性。
springcloud的组件
- nacos：服务发现与注册 服务与发现
- Zuul 或 Spring Cloud Gateway：API 网关 [还有很多网关，如：https://konghq.com/]
- Sentinel：断路器
- Ribbon，Spring Cloud LoadBalancer：客户端负载均衡。
- Feign、OpenFeign：声明式服务调用。
你们是怎么做微服务保护的（熔断、降级、限流）？
熔断降级限流的流程，是不是通过sentinel客户端进行设置阈值，然后正常情况下状态机是closed状态，当达到阈值时，熔断开启，所有的请求走降级处理（持续5s）然后会处于half-open状态放一个探测请求，成功则切回closed，反之则回到open状态，对应的降级操作时通过openfeign+fallbackfactory进行实现，限流的操作一般就是设置对应的异常比例阈值，sentinel进行校验判断
说一下AT模式的原理（两阶段、解决脏读的方案）
首先开启全局事务，调用分支，通过 RM注册分支事务，然后执行sql并提交事务，并记录更新前后的数据快照到undo.log文件中，向TC报告事务的状态，tc根据事物的状态进行判断，未失败，直接删除undo.log如果有失败进行回滚，并通过undo.log进行数据的恢复，通过使用全局锁加上双镜像快照进行避免脏写
阶段一RM的工作：
- 注册分支事务
- 记录undo-log（数据快照）是一张数据库表
- 执行业务sql并提交，向TC报告事务的状态
- 报告事务状态
阶段二提交时RM的工作：
- 删除undo-log即可
阶段二回滚时RM的工作：
- 根据undo-log恢复数据到更新前
