微服务相关

1.SpringCloud有哪些常用组件？分别是什么作用？

注册中心：nacos

负载均衡：rabbion**/**LoadBalancer

网关：gateway

服务熔断：sential

服务调用：Feign

2.服务注册发现的基本流程是怎样的？

服务注册（Service Registration）

• 服务启动：一个微服务实例启动时，它需要向服务注册中心注册自己的信息。
• 构建注册信息 ：服务实例构建注册信息，通常包括：
  • 服务名称（Service ID）：服务的唯一标识符，例如 "user-service" 或 "product-service"。
  • 服务实例地址（Host & Port）：服务实例的网络地址，包括主机名或 IP 地址和端口号。
  • 元数据（Metadata）：可选的附加信息，例如服务版本、环境信息、健康检查 URL 等。
• 向注册中心发送注册请求：服务实例使用注册中心的 API（通常是 HTTP）将注册信息发送到注册中心。
• 注册中心存储服务信息：注册中心接收到注册请求后，将服务实例的信息存储起来，并将其与服务名称关联。
• 定期心跳：服务实例定期向注册中心发送心跳（heartbeat）信号，表明自己仍然可用。如果注册中心在一段时间内没有收到某个服务实例的心跳信号，则认为该实例已经失效，并将其从注册表中移除。

服务发现（Service Discovery）

• 客户端发起服务发现请求：当一个客户端（通常是另一个微服务）需要调用某个服务时，它首先需要从服务注册中心获取该服务的可用实例列表。
• 向注册中心发送发现请求：客户端使用注册中心的 API，根据服务名称向注册中心发送服务发现请求。
• 注册中心返回服务实例列表：注册中心根据服务名称查找可用的服务实例，并将实例列表返回给客户端。
• 客户端负载均衡：客户端从服务实例列表中选择一个实例进行调用。通常会使用负载均衡算法（如轮询、随机、加权轮询等）来选择实例。
• 发起服务调用：客户端使用选择的实例的地址（Host & Port）发起服务调用。

3. Eureka和Nacos有哪些区别？

功能定位

• Eureka

  • 专注服务发现：Netflix开源的服务发现组件，核心功能是服务注册与发现，不具备配置管理能力。

  • AP系统：遵循CAP理论中的AP（高可用+分区容错），牺牲一致性（C）以保证服务可用性。

• Nacos

  • 服务发现 + 配置管理：阿里巴巴开源，集服务注册发现、动态配置管理、元数据管理于一体。

  • 灵活CAP模式：支持AP（高可用）和CP（强一致性）两种模式，可根据场景切换（如临时实例用AP，持久化实例用CP）。

---

数据一致性

• Eureka

  • 采用最终一致性：节点间通过异步复制数据，可能存在短暂的数据不一致。

  • 自我保护机制：网络分区时保留旧数据，避免服务实例被错误剔除。

• Nacos

  • 支持强一致性（CP）：基于Raft协议实现Leader选举，确保数据一致性（如配置管理场景）。

  • 也支持最终一致性（AP）：服务发现场景默认使用Distro协议（类似Gossip），保证高可用。

---

健康检查

• Eureka

  • 客户端心跳检测：服务实例主动向Eureka Server发送心跳（默认30秒），失败后需90秒剔除。

  • 依赖客户端上报，可能存在延迟。

• Nacos

  • 多模式支持：

    • 客户端心跳（类似Eureka）。

    • 服务端主动探测（如TCP/HTTP/MYSQL检查，更精准）。

  • 快速剔除：支持自定义健康检查间隔，异常实例可秒级下线。

---

配置管理

• Eureka

  • 不支持配置管理，需结合Spring Cloud Config或Apollo等工具。

• Nacos

  • 内置配置中心：支持动态配置推送、版本管理、灰度发布、监听查询等功能。

  • 配置变更实时通知（长轮询机制），适用于需要动态调整参数的场景。

4. Nacos的分级存储模型是什么意思？

Nacos将服务数据分为三个层级，形成树状结构：

1. Namespace（命名空间）

   • 作用 ：最外层的隔离单位，用于区分不同环境（如开发、测试、生产）、租户或业务线。示例：

     • dev：开发环境

     • prod：生产环境

     • 不同团队可通过命名空间实现资源隔离。默认命名空间 ：public（未显式指定时使用）

   • Group（分组）

     • 作用：在命名空间内进一步分组，通常用于区分同一环境中的不同应用或模块。

     • 示例：

       • order-service-group：订单服务组

       • user-service-group：用户服务组

     • 默认分组 ：DEFAULT_GROUP。

2. Service/Data ID（服务或配置ID）

   • 作用 ：最小的管理单元，对应具体的服务实例（如user-service）或配置项（如database.properties）。

   • 配置管理 ：通过Data ID唯一标识一个配置文件。

   • 服务发现 ：通过Service Name标识一组服务实例。

6.Ribbon和SpringCloudLoadBalancer有什么差异

除非有历史遗留代码强依赖 Ribbon，否则建议使用 Spring Cloud LoadBalancer，它是 Spring 官方维护的现代化解决方案，兼容性更好且支持未来生态演进。

5.什么是服务雪崩，常见的解决方案有哪些？

服务雪崩（Service Avalanche） 是指微服务架构中，由于某个服务故障或性能瓶颈，引发依赖它的上游服务级联崩溃，最终导致整个系统不可用的现象。

典型雪崩场景

1. 服务A 依赖 服务B ，服务B 因高并发或代码缺陷响应变慢或宕机。

2. 服务A 调用 服务B 的线程因长时间等待被占满，自身无法处理新请求。

3. 服务A 的故障进一步导致依赖它的 服务C 、服务D 相继崩溃，故障像雪崩一样扩散。

1. 服务熔断（Circuit Breaker）

• 原理 ：当服务失败率达到阈值时，熔断器自动快速失败（直接返回降级结果），避免持续调用已故障的服务。

• 实现工具：

  • Hystrix（Netflix，已停维护）

  • Resilience4j（轻量级替代方案）

  • Sentinel（阿里开源，支持熔断、限流、降级）

2. 服务降级（Fallback）

• 原理：当服务不可用时，返回预设的默认值或简化逻辑，保证核心流程可用。

• 场景：

  • 查询商品详情失败 → 返回缓存中的旧数据或静态页面。

  • 支付服务超时 → 记录日志并提示"稍后重试"。

3. 限流（Rate Limiting）

• 原理：控制服务的请求速率，防止突发流量击垮系统。

• 算法：

  • 计数器算法：简单限制每秒请求数。

  • 令牌桶算法（如 Guava RateLimiter）：允许突发流量。

  • 漏桶算法：平滑输出流量。

• 工具：

  • Sentinel：支持QPS、线程数限流。

  • Nginx：网关层限流。

4. 异步调用与消息队列

• 原理：通过消息队列（如 Kafka、RocketMQ）解耦服务，避免同步阻塞。

• 场景：

  • 订单创建后异步通知库存系统，而非同步调用。

  • 使用 Spring Cloud Stream 或 RabbitMQ 实现事件驱动

5. 资源隔离

• 线程池隔离：为不同服务分配独立线程池，避免一个服务耗尽所有资源。

  • Hystrix 通过线程池隔离不同命令。

  • Servlet 3.0+ 支持异步处理释放容器线程。

• 信号量隔离：限制并发调用数（如 Sentinel）。

6.什么是CAP理论和BASE思想？

CAP理论 是分布式系统设计的核心原则，由计算机科学家 Eric Brewer 提出，指出在分布式系统中，以下三个特性无法同时完全满足，最多只能满足其中两项：

1. 一致性（Consistency）

   • 所有节点在同一时间的数据完全一致（强一致性）。

   • 例如：写入后立即读取，所有节点返回相同结果。

2. 可用性（Availability）

   • 每个请求都能获得响应（不保证数据最新），系统始终可用。

   • 例如：即使部分节点故障，服务仍能响应（可能返回旧数据）。

3. 分区容错性（Partition Tolerance）

   • 系统在网络分区（节点间通信中断）时仍能继续运行。

BASE 是对CAP中AP模式 的扩展，由 eBay 提出，强调通过牺牲强一致性来获得高可用性，其核心是最终一致性。

1. Basically Available（基本可用）

   • 系统在故障时仍能提供核心功能（如降级、限流）。

   • 例如：电商大促时关闭评论功能，保证下单流程可用。

2. Soft State（软状态）

   • 允许系统中的数据存在中间状态（不同节点间短暂不一致）。

   • 例如：订单状态从"支付中"到"支付成功"可能延迟同步。

3. Eventually Consistent（最终一致性）

   • 经过一段时间后，所有节点数据最终一致。

   • 例如：支付宝转账后，对方账户可能稍后才能看到余额更新。

7.AT模式如何解决脏读和脏写问题？

AT（Auto Transaction）模式 是Seata的核心方案，通过全局锁 + 快照机制保证隔离性：

防脏读

• 读隔离：

  • AT模式下，默认的读未提交（Read Uncommitted）可能脏读。

  • 解决方案 ：通过SELECT FOR UPDATE加全局锁，阻塞其他事务修改数据，直到当前事务提交/回滚。

防脏写

• 写隔离：

  1. 前置快照 ：在更新前记录数据快照（before image）。

  2. 全局锁：更新时获取行级全局锁，防止其他事务同时修改同一数据。

  3. 后置快照 ：提交前生成after image，用于回滚时恢复数据。

  4. 冲突检测 ：若before image与当前数据不一致（被其他事务修改），则回滚当前事务。

TCC模式与AT模式对比

对比维度	TCC模式	AT模式
原理	手动实现Try-Confirm-Cancel三阶段	基于数据源代理自动生成反向SQL
一致性	强一致性（业务层控制）	最终一致性（依赖全局锁）
侵入性	高（需业务代码实现三阶段接口）	低（无代码侵入，依赖框架代理）
性能	较高（无全局锁竞争）	较低（全局锁可能阻塞）
适用场景	金融支付、高一致性需求	普通业务（如电商订单、库存管理）
复杂度	高（需处理空回滚、幂等等问题）	低（框架自动处理回滚）
容错能力	强（可自定义补偿逻辑）	依赖框架（如Seata）的可靠性