应用部署在K8s时，何时使用Eureka、Ribbon等Spring Cloud组件？

优先选择 Spring Cloud 相关组件的场景 #

• 存量服务全是 Java/Spring 技术栈，且团队已有成熟的 Spring Cloud 使用经验：原有业务系统已经基于 Eureka、Ribbon 等组件跑通了完整的微服务逻辑，没有架构重构需求的前提下，强行切换为 K8s 原生能力反而会带来不必要的改造和测试成本，维持原有技术栈性价比更高
• 需要细粒度流量治理能力：比如要实现基于请求参数的灰度路由、同机房/同可用区优先调用、方法级别的熔断降级、自定义负载均衡转发规则，Spring Cloud 生态组件可以直接和业务代码集成，灵活度远高于 K8s 原生的 Service、Ingress 能力
• 存在异构部署/跨集群调用需求：比如部分服务跑在虚拟机、部分跑在 K8s，或者有多云多集群的部署架构，Spring Cloud 的注册中心可以跨环境同步实例信息，不需要搭建复杂的跨集群 Service 网格就能实现跨环境的服务发现调用
• 追求开发侧效率：开发人员本地调试时不需要搭建 K8s 模拟环境，直接用本地启动的 Eureka 就能完成服务发现调试，不需要感知底层基础设施的部署形态，开发流程更轻量

优先选择 K8s 原生能力的场景 #

• 微服务集群是多语言技术栈：Spring Cloud 组件基本只适配 Java 生态，假如集群里存在 Go、Python、Node.js 等其他语言开发的服务，用 K8s 原生的 CoreDNS + Service 实现服务发现、负载均衡，对所有语言都无侵入兼容，不需要每个语言单独做适配开发
• 不想让治理能力和业务代码绑定：K8s 的服务治理能力是基础设施层提供的，业务代码不需要引入任何额外依赖、不需要修改任何代码就能享受到服务发现、负载均衡能力，调整治理规则时也不需要重启业务服务
• 基础设施需要统一标准化管控：如果公司层面统一用 K8s 做容器编排，要求所有服务的治理规则由运维侧统一管控，用 K8s 原生的 Service、Ingress、NetworkPolicy 等配置，不需要每个业务团队单独维护注册中心集群、单独配置负载均衡规则，整体运维成本更低
• 超大规模集群的性能要求：Spring Cloud 单 Eureka 集群支撑的实例数通常有几千的上限，而 K8s 的服务发现能力基于 etcd + CoreDNS 实现，已经过万级实例规模的生产验证，同时不需要额外维护一套独立的注册中心中间件，减少了故障点

很多生产环境会选择两者混用，比如用 K8s 做底层容器编排和基础设施层的流量治理，上层基于 Spring Cloud 实现业务侧的细粒度流量控制，兼顾运维标准化和业务灵活度。

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