Eureka、Ribbon及相关负载均衡技术问题咨询

1. Eureka是否开箱即用提供负载均衡能力？是否需要额外引入其他依赖？ #

Eureka本身是纯服务注册发现组件，不提供开箱即用的负载均衡能力，它的核心能力仅包括服务实例注册、健康状态检测、服务实例列表查询，不涉及任何请求分发逻辑。
要基于Eureka实现负载均衡需要额外引入相关依赖：

• Spring Cloud 2020.0版本之前：引入spring-cloud-starter-netflix-ribbon即可实现客户端负载均衡
• Spring Cloud 2020.0及之后版本：Netflix Ribbon已被官方移除，需要引入spring-cloud-starter-loadbalancer作为替代组件

2. 为什么选择使用Ribbon而非直接通过Eureka实现负载均衡？ #

二者定位完全不同，能力边界没有重叠，属于配合关系而非竞争关系：

• Eureka没有内置任何负载均衡相关能力，既没有轮询、随机、权重等分发策略，也不支持请求重试、故障实例剔除等配套功能，完全不具备独立实现负载均衡的条件
• Ribbon是专门的客户端负载均衡组件，可以直接对接Eureka拉取的服务实例列表，自带多种可自定义的负载均衡策略，还支持请求重试、异常实例降级等能力，刚好填补Eureka的能力空缺，二者配合即可实现完整的服务发现+负载均衡链路

3. 为什么需要通过API网关实现负载均衡？ #

API网关作为集群流量的统一入口，它的负载均衡能力是对客户端负载均衡的补充，核心原因有3个：

• 外部流量无法直接对接内部注册中心：前端、第三方系统等外部调用方没有能力拉取Eureka的服务实例列表，必须通过网关统一暴露访问入口，由网关做入口层负载均衡
• 统一管控成本更低：限流、鉴权、日志采集、灰度发布等通用流量管控逻辑如果在每个微服务客户端分别实现，会产生大量重复开发工作，在网关层统一实现+统一负载均衡，运维和开发成本低很多
• 安全性更高：网关做入口负载均衡可以隐藏内部服务的拓扑结构、实例地址，避免内部服务直接暴露在公网，降低安全风险

4. spring-cloud-starter-loadbalancer的作用是什么？为什么需要引入该依赖？ #

它是Spring Cloud官方推出的轻量级客户端负载均衡组件，定位为停止维护的Netflix Ribbon的官方替代方案。核心作用是对接服务注册中心拉取服务实例列表，按照配置的负载均衡策略（默认轮询，支持自定义）选择目标调用实例，原生适配RestTemplate、OpenFeign等常用调用组件，几乎不需要改造原有代码即可使用。
需要引入的原因：
Spring Cloud 2020.0（代号Ilford）版本已经正式移除了Netflix Ribbon的默认集成，如果使用该版本及之后的Spring Cloud全家桶实现客户端负载均衡，必须引入该依赖才能实现负载均衡逻辑；另外它比Ribbon更轻量，和Spring生态的适配性更好，后续维护迭代也更有保障。

5. 客户端负载均衡与服务端负载均衡各自适用什么场景？二者应如何选型？ #

首先明确二者的核心差异：客户端负载均衡的逻辑运行在服务调用方本地，由调用方自己选择目标实例；服务端负载均衡的逻辑运行在中间代理节点，调用方只需要把请求发给代理节点，由代理完成转发。

适用场景 #

• 客户端负载均衡：适合内部微服务之间的RPC调用场景，内部服务都可以对接注册中心，没有中间代理节点的性能损耗和单点瓶颈，调用链路短、延迟低
• 服务端负载均衡：适合外部流量到内部集群的南北向调用场景，以及需要统一做流量管控的场景，比如公网API入口、跨集群调用入口等

选型建议 #

两者不存在二选一的关系，生产环境通常是搭配使用：外部请求首先经过Nginx、API网关的服务端负载均衡进入集群内部，集群内部微服务之间的互相调用使用客户端负载均衡，各自发挥自身优势即可。

内容的提问来源于stack exchange，提问作者YellowFootMountain