微服务相关

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将服务数据分为三个层级，形成树状结构：

Namespace（命名空间）
- 作用：最外层的隔离单位，用于区分不同环境（如开发、测试、生产）、租户或业务线。示例：
  - dev：开发环境
  - prod：生产环境
  - 不同团队可通过命名空间实现资源隔离。默认命名空间：public（未显式指定时使用）
- Group（分组）
  - 作用：在命名空间内进一步分组，通常用于区分同一环境中的不同应用或模块。
  - 示例：
    - order-service-group：订单服务组
    - user-service-group：用户服务组
  - 默认分组：DEFAULT_GROUP。
Service/Data ID（服务或配置ID）
- 作用：最小的管理单元，对应具体的服务实例（如user-service）或配置项（如database.properties）。
- 配置管理：通过Data ID唯一标识一个配置文件。
- 服务发现：通过Service Name标识一组服务实例。

6.Ribbon和SpringCloudLoadBalancer有什么差异

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

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

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

典型雪崩场景

服务A 依赖 服务B，服务B 因高并发或代码缺陷响应变慢或宕机。
服务A 调用 服务B 的线程因长时间等待被占满，自身无法处理新请求。
服务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 提出，指出在分布式系统中，以下三个特性无法同时完全满足，最多只能满足其中两项：

一致性（Consistency）
- 所有节点在同一时间的数据完全一致（强一致性）。
- 例如：写入后立即读取，所有节点返回相同结果。
可用性（Availability）
- 每个请求都能获得响应（不保证数据最新），系统始终可用。
- 例如：即使部分节点故障，服务仍能响应（可能返回旧数据）。
分区容错性（Partition Tolerance）
- 系统在网络分区（节点间通信中断）时仍能继续运行。

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

Basically Available（基本可用）
- 系统在故障时仍能提供核心功能（如降级、限流）。
- 例如：电商大促时关闭评论功能，保证下单流程可用。
Soft State（软状态）
- 允许系统中的数据存在中间状态（不同节点间短暂不一致）。
- 例如：订单状态从“支付中”到“支付成功”可能延迟同步。
Eventually Consistent（最终一致性）
- 经过一段时间后，所有节点数据最终一致。
- 例如：支付宝转账后，对方账户可能稍后才能看到余额更新。