SpringCloud之Ribbon
————————————————————————————————————
推荐文档： https://www.springcloud.cc/spring-cloud-dalston.html#spring-cloud-ribbon
1.什么是Ribbon
Ribbon 是 Spring Cloud 微服务架构中实现客户端负载均衡的核心组件，由 Netflix 开源并集成到 Spring Cloud 生态中。它通过动态分配请求到多个服务实例，提升系统的可用性和性能。
2. 客户端负载均衡
与服务端负载均衡的区别：
Nginx 属于服务端负载均衡（集中式），请求先经 Nginx 转发到后端服务。
Ribbon 将负载均衡逻辑嵌入服务消费者，直接从注册中心（如 Eureka）获取服务列表，在本地选择实例并调用。
优势：减少单点故障，降低网络跳转延迟，适应动态伸缩。
Ribbon与Nginx对比
| 特性 | Ribbon (客户端负载均衡) | Nginx (服务端负载均衡) |
|---|---|---|
| 部署位置 | 集成在服务消费者进程内 | 独立服务器或集群 |
| 服务发现 | 动态从注册中心获取服务列表 | 需手动配置或通过脚本更新 |
| 灵活性 | 支持动态策略调整和深度定制 | 配置相对静态，修改需重启 |
| 性能影响 | 减少网络跳转，延迟更低 | 增加额外网络跃点 |
| 典型用例 | 微服务内部调用 | 南北流量（客户端到网关） |
3. 核心能力
动态服务发现：集成注册中心（如 Eureka），自动更新可用实例列表。
多种负载策略：支持轮询、随机、响应时间加权等算法。
故障容错：超时重试、服务熔断（常与 Hystrix 结合）。
4.工作流程
步骤 1：消费者从注册中心拉取服务实例列表，缓存在本地。
步骤 2：通过 IRule 策略（如轮询，随机，权重等）选择目标实例。
步骤 3：RestTemplate 发起请求（需添加 @LoadBalanced 注解）。
步骤 4：若请求失败，根据配置重试或切换实例。
5.核心组件
ILoadBalancer：负载均衡器，管理实例列表与选择逻辑。
IRule：定义负载策略（如 RandomRule 随机选择）。
ServerList：动态获取服务实例列表（与 Eureka 集成）。
6. IRule策略对比
| 策略名称 | 实现类 | 工作原理 | 适用场景 | 缺点 |
|---|---|---|---|---|
| 轮询策略 | RoundRobinRule | 按服务实例列表顺序依次选择（如 A→B→C→A） | 节点性能均匀的无状态服务（如静态API） | 无法感知节点实时负载 |
| 随机策略 | RandomRule | 完全随机选择实例 | 节点性能相近的简单服务 | 可能将流量引向高负载节点 |
| 权重响应时间策略 | WeightedResponseTimeRule | 根据实例历史响应时间动态分配权重（响应越快权重越高） | 节点性能差异大的集群（如混合部署新旧服务器） | 冷启动阶段可能分配不均 |
| 最小连接数策略 | BestAvailableRule | 选择当前并发请求数最少的实例 | 高并发场景（如秒杀系统） | 需监控并发数，增加系统开销 |
| 可用性过滤策略 | AvailabilityFilteringRule | 过滤故障节点和高并发节点，剩余节点轮询选择 | 高可用要求的服务（如支付系统） | 依赖健康检查机制 |
| 区域感知策略 | ZoneAvoidanceRule | 优先选择同区域实例，避开高延迟或故障区域 | 跨机房/云区域部署（如全球业务） | 单区域部署时退化为轮询 |
| 重试策略 | RetryRule | 在指定时间窗内重试获取可用服务（默认基础策略为轮询） | 网络波动环境或服务临时不可用 | 重试可能增加请求延迟 |
| 自定义策略 | 继承 AbstractLoadBalancerRule | 按业务逻辑定制（如基于 IP 哈希的会话保持） | 会话保持的服务（如用户登录状态） | 需开发成本，扩展性需手动处理 |
7.适用场景
微服务间调用（如通过 RestTemplate 或 Feign）。
需灵活定制负载策略或深度集成 Spring Cloud 的场景。
8.总结：
Ribbon 作为微服务架构的“流量调度器”，通过客户端负载均衡显著提升系统弹性。其核心价值在于：
✅ 轻量集成：无需独立部署，与 Spring Cloud 生态无缝协作。
✅ 灵活扩展：支持策略定制和容错机制。
⚠️ 演进过渡：虽被 Spring Cloud LoadBalancer 取代，但理解其原理仍是掌握微服务治理的关键基础。