面经策

Spring Cloud 的优缺点有哪些？ ​

  • 标签：微服务、后端、Spring Cloud

🏛 业务架构师 ​

Spring Cloud 的优缺点我按"它为你做什么、向你收什么"来讲：

优点：

  1. 治理能力开箱即用：注册发现、配置、网关、熔断限流、链路追踪全家桶——自研这些能力是几十人年的投入，中小团队以极低成本获得大厂级治理基础设施；
  2. 生态标准统一：Spring 背书 + 社区庞大，组件可插拔（Nacos/Consul 可换、Sentinel/Resilience4j 可换），避免供应商锁定；
  3. 微服务演进路径平滑：与 Spring Boot 一体，单体渐进拆分时按需引入组件。

缺点：

  1. 复杂度税：组件多（Nacos、Gateway、Sentinel、Seata 每个都要人懂、都要高可用部署）——5 人小团队上全家桶，治理成本可能吃掉 40% 研发力；
  2. 排障链路长：一次调用穿过网关、LB、Feign、线程池，问题定位需要全链路可观测性支撑，没有 APM 的微服务是黑盒地狱；
  3. 版本兼容地狱历史包袱：Spring Cloud 与 Boot 版本矩阵、Netflix 组件退役潮、Alibaba 版本对齐——升级是要排期的真实工程；
  4. 部分职能与 K8s 重叠：服务发现、灰度、流量治理平台层也在提供，重复建设是隐性浪费。

我的结论（架构师立场）：Spring Cloud 是"业务规模到了"的答案而非起点——服务数 <5、团队 <10 人，模块化单体（Spring Modulith）先行；等痛点真实出现（独立发布需求、团队并行受阻）再按组件逐个引入，每引入一个组件都要能说出它替换掉了什么 pain。

🏗 系统架构师 ​

优点：

  • 生态完整：注册、配置、网关、调用、容错、事务、追踪一站式，Spring 团队背书加版本列车治理；
  • 与 Boot 无缝、开发体验好、人才储备充足；
  • Spring Cloud Alibaba（Nacos/Sentinel/Seata）经国内大厂验证，中文生态成熟。

缺点（我如实讲）：

  • 复杂度转嫁：把单体的复杂度换成分布式的复杂度——网络分区、脑裂、雪崩、数据一致性一个不少；
  • 基础设施 sprawl：注册中心、网关、MQ、链路、配置中心各一个集群，小团队的运维成本可能压垮收益；
  • 版本矩阵苛刻（Boot、Cloud、Alibaba 三方对齐），升级是长期工程；
  • JVM 绑定——多语言技术栈下 SDK 模式失效，要 mesh 补位。

我的架构态度：Spring Cloud 解决的是「微服务治理工具从零搭建」的问题，不解决「该不该微服务」。百人以下团队我推荐模块化单体加局部服务化；上 Spring Cloud 的前提是组织规模、发布频率、独立扩展需求真实存在。技术选型对齐组织能力，这是第一原则。

💻 全栈开发专家 ​

优点：

  1. 生态完整、组件可插拔：注册/配置/网关/调用/容错/观测全家桶，每个位置都有备选实现
  2. 与 Spring Boot 无缝：开发者心智连续，注解 + starter 即接即用
  3. 社区活跃、文档齐全
  4. 抽象层统一（spring-cloud-commons 的 DiscoveryClient/LoadBalancer 接口），换 Nacos/Consul/K8s 基本不动业务代码

缺点（都是真实痛）：

  1. 版本匹配地狱：Boot 与 Cloud train 必须按对照表配，错一位就是诡异的 NoSuchMethodError
  2. 链路长排障复杂：一次请求过网关 + LB + Feign + 熔断，每层都可能吞错误信息，新人定位成本高
  3. 运维负担重：Nacos、Sentinel Dashboard、Seata TC、SkyWalking OAP 一堆中间件都要高可用
  4. Netflix 组件退场的包袱：老项目停在 Zuul/Hystrix/Ribbon 上，升级等于换血
  5. 代码侵入：Feign 接口、熔断注解散在业务里，换框架有成本（对比 Service Mesh 的 sidecar 无侵入）

我的立场：中小团队微服务 Spring Cloud 仍是性价比之选；治理诉求重、多语言混合的大厂逐步把治理下沉 Istio/Envoy，Java 侧只留业务。