Spring Cloud基础分析

微服务架构及其特点

核心思想：将单体应用拆分为一组独立的小型服务，每个服务运行在独立进程中，通过轻量级通信机制协同工作。

特点：

松耦合：服务间通过接口（如 HTTP/REST、RPC）通信，内部实现透明。

独立部署：每个服务可独立开发、测试、部署和扩展。

技术异构：不同服务可使用不同技术栈（如 Java、Go）。

容错性：通过熔断、降级、限流等机制提升系统健壮性。

高可维护性：模块化设计，便于团队协作与维护。

SOA架构和微服务架构的区别

维度	SOA	微服务
服务粒度	较粗（如企业级服务）	较细（单一业务功能）
通信协议	重量级（如SOAP、ESB）	轻量级（如REST、gRPC）
数据管理	共享数据库	每个服务独立数据库
部署与扩展	整体部署为主	独立部署、按需扩展
技术统一性	强（标准化技术栈）	弱（允许技术异构）

Spring Cloud常用组件及其作用

组件	作用
Nacos	服务注册与发现、配置中心
Ribbon	客户端负载均衡
Feign	声明式的REST服务调用
Sentinel	流量控制、熔断降级、系统保护
Seata	分布式事务解决方案
Gateway	API网关（路由、过滤、限流）
Sleuth/Zipkin	分布式链路追踪

 如何实现服务注册与发现

 核心原理：

1. 服务注册

• 主动注册：服务实例启动时向注册中心（如 Eureka、Consul）提交自身元数据（IP、端口、健康状态等）。

• 被动注册：由第三方组件（如 Kubernetes 的 Service）监控服务实例并自动注册。

2. 服务发现

• 客户端发现：调用方从注册中心拉取服务列表，通过负载均衡策略选择目标实例（如 Ribbon）。

• 服务端发现：请求通过路由层（如 Nginx、Istio）转发，路由层负责从注册中心获取服务实例。

3. 健康检查

• 心跳检测：服务定期向注册中心发送心跳（如 Eureka 的续租机制）。

• 主动探测：注册中心定时调用服务的健康接口（如 HTTP /health）验证存活状态。

服务熔断和服务降级原理

服务熔断

原理

1. 类比电路保险丝：当某个服务因故障（如高延迟、异常）导致调用失败率超过阈值时，熔断机制会暂时切断对该服务的调用，避免请求堆积导致整个系统崩溃。

2. 状态机设计：

   • 关闭（Closed）：正常调用服务，统计失败次数。

   • 开启（Open）：失败次数超过阈值后，拒绝所有请求，返回预设的降级响应（如错误提示或缓存数据）。

   • 半开启（Half-Open）：一段时间后允许少量请求试探服务是否恢复，若成功则切换回关闭状态，否则保持开启。

触发条件

• 错误率阈值（如 50% 错误率）。

• 响应超时阈值（如单次调用超过 1 秒）。

• 连续失败次数（如 10 次调用失败）。

典型实现

• Hystrix：Netflix 开源的熔断框架，通过线程池隔离和信号量控制请求。

• Sentinel：阿里开源的流量控制组件，支持熔断策略配置。

服务降级

原理

1. 主动放弃非核心功能：当系统资源不足（如 CPU、内存、线程池耗尽）或服务压力过大时，主动降低非核心服务的功能或响应质量，优先保障核心业务。

2. 策略类型：

   • 返回默认值：如返回 “服务繁忙，请稍后重试”。

   • 返回降级数据：如返回缓存中的历史数据。

   • 关闭次要功能：如暂时关闭评论、推荐等非核心模块。

触发方式

• 配置触发：预先设置规则（如 QPS 超过 1000 时触发降级）。

• 手动触发：通过管理后台或 API 主动开启降级。

• 动态监控：根据实时指标（如线程池利用率）自动触发。

典型场景

• 电商大促期间，优先保证订单支付，降级商品推荐功能。

• 服务依赖的第三方接口不可用，返回本地模拟数据。

如何实现负载均衡 

客户端负载均衡：请求方在调用前通过本地负载均衡器选择目标实例（如 Ribbon、Feign）。

服务端负载均衡：通过独立代理层（如 Nginx、HAProxy）转发请求。

全局负载均衡：基于 DNS 或 CDN 实现跨地域流量分配。

如何实现服务通信 

1. 同步调用

适用场景：需要立即得到响应的业务（如订单查询、用户认证

实现方式：

• REST API：基于 HTTP 协议，简单易用（如 Spring Cloud Feign）。

• gRPC：基于 HTTP/2 协议，支持流式传输和高性能序列化（如 Kubernetes 服务间通信）

• Thrift：跨语言服务通信框架，支持多种协议（如二进制、HTTP）。

2. 异步消息传递

适用场景：解耦服务、削峰填谷（如订单创建后的库存扣减、日志处理）。

实现方式：

消息队列（MQ）：

• RocketMQ：阿里巴巴开源，支持顺序消息和分布式事务。
• RabbitMQ：支持事务和消息确认，适合可靠消息传递。
• Kafka：高吞吐量，适合日志和实时流处理。

事件驱动架构（EDA）：通过事件总线（如 Spring Cloud Stream）解耦服务。

如何进行流量控制

限流：限制单位时间内通过的请求数

熔断：当服务故障率超过阈值时，暂时切断请求

降级：服务不可用时返回预设的降级响应

队列削峰：将请求放入队列，按系统负载能力逐步处理

分布式事务问题怎么解决

使用 Seata 的 AT 模式（自动补偿事务）：

• 开启全局事务（@GlobalTransactional）
• 各服务执行本地SQL，Seata拦截并记录回滚日志
• 提交阶段各服务自动提交，回滚阶段根据回滚日志逆向执行

RocketMQ事务消息

• 生产者发送半事务消息（Prepared Message）。
• 执行本地事务。
• 根据本地事务结果提交 / 回滚半事务消息。
• 消费者处理消息，若消息未收到则通过 MQ 回查本地事务状态。

TCC模式

• Try阶段：预留资源
• Confirm阶段：提交资源
• Cancel阶段：释放资源