博客主页小谢同学的小破站✍️本文由小谢同学的小破站原创首发于 CSDN ☕JavaSE专栏JavaSEJavaEE初阶专栏JavaEE初阶JavaEE进阶专栏JavaEE进阶数据结构专栏数据结构⚙️算法专栏算法MySQL初阶专栏MySQL初阶Spring CloudSpring Cloud计算机网络专栏计算机网络SpringAISpringAI从入门到应用欢迎点赞 收藏⭐ 留言发现错误欢迎指正✨脚踏实地持续深耕奔赴自己的目标✨----- 分割线 -------Spring Cloud 微服务开发1. 什么是微服务开发?2. 单体架构一开始真挺好用3. 扛不住了只有两条路4. 集群和分布式到底差在哪5. 微服务拆到不能再拆6. 这笔买卖赚的和赔的7. Spring Cloud微服务的大管家8. 版本号为什么是地铁站名9. 两代实现Netflix 和 Alibaba10. 总结与速查10.1 三句话10.2 概念速查10.3 版本速查10.4 组件速查11. 小结前言这里是 小谢同学 的微服务学习记录微服务系列第一篇。这篇代码不多全在讲概念。但它挺关键——这一篇糊过去后面学 Eureka、Nacos、Gateway 就全是背配置学完也不知道自己在配啥。本文使用一家宠物医院的四年来帮助讲解微服务。1. 什么是微服务开发先给一个不那么教科书的答案:微服务开发,就是将一个大的系统拆分成一堆能各自独立运行的小服务,每一个只管理一件事情,再想办法让它们互相找得到、调得通、扛得住。这句话里其实藏着三个问题为什么要拆拆到什么程度拆完到底谁来收拾摊子整篇就顺着这三个问题走。我们先来看看结论:微服务是用一堆独立服务换来灵活同时欠下一笔运维和治理的债Spring Cloud 就是帮你还这笔债的工具箱。主角叫毛孩子动物医院2021 年从小区门口的小诊所起步。下面这五段是我编的教学设定并不是真实的数据但踩的坑基本是中小项目的通用剧本时间技术状态遇到的事2021一个 Spring Boot 项目1 台服务器够用改完就上线2022同一台机器加配置周末排队中午打不开2023同一套系统复制 3 份集群扛住了但改一次发三次版2024按科室拆 4 个子系统分布式拆开了重复代码翻倍2025十几个微服务 公共基础服务灵活了运维快疯了运维快疯了不是吐槽这也恰恰是 Spring Cloud 存在的理由。 返回目录2. 单体架构一开始真挺好用在2021 年老板找了外包做个 Spring Boot 项目。预约、接诊、化验、开药、收银、会员卡、发短信……全都塞进一个工程打成一个 jar 包扔在一台服务器上跑。这就是单体架构单体架构:将一个应用中的所有功能实现,全部都打包在一个jar包或者war包中,统一部署,统一运行;说白了就是一家只有一个屋子的小诊所挂号在前台那张桌子拿药在身后柜子收钱还是那张桌子一个人从前包到后。开药,看病,以及收银都是在一个位置来进行;现在一提单体好多人一脸嫌弃这不太公平。在它该待的规模里是真香开发一个工程clone下来就能跑部署一行java -jar没什么启动顺序的讲究调用就是本地方法调用纳秒级基本上不可能超时事务一个Transactional全包了数据库替你保证要么全成要么全败。这四条记一下。因为往后你会发现微服务牺牲的正好就是这四条。2022 年事儿来了。周六上午 CPU 打满请求排队超时整站打不开改个药房打印小票的文案也要整个项目重新打包发布全院停三分钟化验单模块内存泄漏把 JVM 撑爆结果不是化验单打不开而是挂号、收银、开药全部 502——它们本来就住在一个进程里。于是只剩一个朴素的问题这台机器、这坨代码怎么扛住下一年答案就两条路。 返回目录3. 扛不住了只有两条路第一条路: 横向,加机器: 代码中的逻辑一个字都不改,直接去买3台服务器,每一台服务器都跑一模一样的jar包,前面的Nginx分流, 这个就叫做集群;集群是把一个系统完整部署到多台服务器上每台都能提供系统的全部服务通过负载均衡调度共同完成任务。集群里的每一台机器叫做一个节点node。用医院来举例子: 一间问诊室忙不过来,就在隔壁再开两间问诊室,请两个一模一样的医生,什么病都能够看,病人来了先去问诊台,去问哪一间空着就往哪送。这里有个细节第一次都想不到集群必须有个分诊台。病人首先得知道去哪排队医生之间也得知道隔壁今天请假没有。这个分诊台 排班表落到技术上就是负载均衡 服务注册发现。但集群只治了扛不住没治太乱——三台机器跑的还是同一坨代码。第二条纵向拆业务。把一个大系统按业务切成几个独立小系统各自部署。课件里管这叫垂直架构以单体规模的项目为单位进行垂直划分把大项目拆成一个个单体结构的小项目项目之间相对独立接口多为数据同步功能。放到医院就是把一个人干所有事改成流水线前台只管挂号分诊门诊只管接诊开单检验只管化验出报告药房只管配药发药收银只管结算开票。药房半夜升级挂号照样接客, 各自管理好各自的功能。清爽了。但新麻烦立刻跟上一次就诊就要跨五个系统以前一个事务搞定的事现在得操心挂号成功、收银失败怎么回滚服务之间怎么找对方换机器了配置改不改调用失败了又怎么办跨网络了检验慢三秒门诊是干等、报错还是重试发现问题没有——这三件事全都不是写业务代码能解决的它们是基础设施问题。而这正是 Spring Cloud 要卖的货。 返回目录4. 集群和分布式到底差在哪分布式和集群到底有什么区别?到底差哪里了?从概念上分集群是多个机器做同样的事分布式是多个机器做不同的事。一句话就完了——三个都看全科病的医生是集群前台、检验、药房、收银各管一摊是分布式。从功能上分集群每个节点功能相同、能互相替代医生 A 请假去 B 那儿照样能看分布式每个节点业务不同一个节点出问题这块业务就直接不可访问——药房关门了你不可能跑去检验科拿药。所以高可用的做法也不同集群挂一个请求自动转走分布式挂一个只能靠给它也做集群或者做降级兜底。从关系上看课件这段总结得挺准我直接写下来:分布式和集群在实践中很多时候是互相配合使用的。比如分布式的某一个节点可能由一个集群来代替。分布式架构大多是建立在集群上的。所以实际的分布式架构设计中并不会把分布式和集群单独区分而是统称分布式架构。翻译一下这俩不是二选一是套娃。所以你说我们项目是分布式架构其实更专业因为这句话默认包含了每个服务都是多实例。对比维度集群 Cluster分布式 Distributed干的事多个节点做同样的事多个节点做不同的事拆分方式复制不改代码拆分按业务切节点可否替代可以随时互换不可以各管一摊单点故障业务不受影响该业务直接不可用主要解决扛不住压力分散太乱职责分离配套需求负载均衡注册发现、远程调用、网关面试问到无非两种问法。问你们项目是集群还是分布式答架构上是分布式的按业务拆成 N 个服务每个服务又部署多实例所以也含集群两者配合用。问我多买两台服务器算分布式吗答不算那只是从单机变集群代码没变、职责没分。 返回目录5. 微服务拆到不能再拆2024 年拆成五个系统舒服了半年。然后发现一件更烦的事每个系统里都写了一遍会员积分。挂号加积分、开药加积分、收银加积分、上门服务也加积分。四份代码逻辑还不完全一样。运营说改成消费 1 元积 2 分开发一看改四个项目、发四次版、协调四个上线窗口。按照业务进行拆分后会有一些重复的功能开发比如订单系统电商平台和支付系统都会涉及。在分布式架构下当部署的服务越来越多重复的代码就会越来越多服务的调用关系也会越来越复杂。解法也比较简单:把通用、会被多个上层服务调用的共享业务抽成独立的基础服务。把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务组成一个个微小的服务。这就是微服务。于是就有了会员积分服务、消息通知服务、在线支付服务——它们不属于任何一个科室但所有科室都要用。上面一层是业务下面一层是能力。上面怎么变下面都能接着复用。但是微服务这个名字挺误导人重点不是小而是独立。很小的服务小到一个服务只对应一个单一的功能只做一件事这个服务可以单独部署运行。三条标准比多少行代码靠谱多了标准什么意思反例只做一件事职责单一一个服务对应一个能力综合业务服务塞了挂号、药房、收银能单独部署有自己的启动类和端口只能跟着主工程一起打包独立进程挂了不影响别人能单独重启扩容和别的模块跑在同一个 JVM所以“拆成 6 个服务≠微服务”。要是这 6 个还共用一个库、必须一起启动那只是逻辑上分了包它骨子里还是单体。另外服务之间用REST 或 RPC通信理解成接口的约定就行区别只在怎么喊REST 像寄快递填单子GET /pets/1JSON好调试RPC 像打内线电话getById(1)二进制快。最后纠个常见误解分布式和微服务不是程度差别。分布式服务拆分拆了就行。微服务更细粒度的垂直拆分通常指不能再拆的服务。分布式侧重压力的分散微服务侧重能力的分散更强调专业化和精细分工。还有句更狠的微服务架构通常是分布式架构反之未必成立。所以选择微服务通常意味着需要解决分布式架构的各种难题。潜台词就是你选了微服务等于主动把所有分布式的坑都领了一遍。这几个观点都是错误的一个观点~ 返回目录6. 这笔买卖赚的和赔的左边四样是你换来的右边四样是你付出去的。注意右边一样都不少。就像一个刚开始创业,经济压力比较大的公司,一个员工什么都会干的时候,由于公司比较小,管理起来就相对于比较简单;但是如果公司的规模越来越大,就必须区分部分,效率是提高了,但是维护的成本也跟着涨价了,人越多,管理就越复杂,服务和人是同一个道理;所以别被先进两个字带着走。团队不到 5 个人、产品还在找方向、日活几千、没有自动化运维这几种情况就老老实实写单体。判断标准其实特别朴素当你因为发个版会牵连别的模块和扩容不能按模块来而真的开始痛苦了那才是拆的时候。不是因为面试要问。 返回目录7. Spring Cloud微服务的大管家官方说到: spring cloud提供了一些可以让开发人员快熟构建分布式服务的工具,就好像配置管理,服务发现,熔断,智能路由等等,他们可以在任何分布式环境中很好的工作;简单来说Spring Cloud 就是分布式微服务架构的一站式解决方案是微服务架构落地的多种技术的集合。用我们现在的话来说就是:微服务那一堆的基础设施的破事,它都替你把成熟方案打包好了,引入依赖,我们只需要写几行配置就能使用.官方能力解决什么麻烦后面学的组件Distributed versioned configuration配置散在 12 个服务改一个改 12 遍Nacos / ConfigService registration and discovery服务在哪台机器挂了怎么知道Eureka / NacosRouting智能路由前端不该记住 12 个服务的地址GatewayService-to-service calls怎么像调本地方法一样调远程OpenFeignLoad balancing一个服务 5 个实例这次调哪个LoadBalancerCircuit Breakers下游挂了别把我一起拖死Resilience4j / SentinelDistributed messaging异步解耦下单后发通知不用干等RabbitMQ链路追踪补充一个请求跨 8 个服务卡在哪环Micrometer / SkyWalking看懂这张表就明白了后面几讲的内容全在里面。这也是为啥这篇必须先讲——不然学 Eureka 时你压根不知道它在整个体系里站哪。Spring Cloud 并不是 Spring 团队研发的框架它只是把一些比较优秀的开源框架基于 Spring Cloud 规范进行了整合并基于 Spring Boot 的风格对这些组件进行了封装屏蔽掉了复杂的配置和实现原理为开发者提供了开箱即用的微服务开发体验。这些开源技术的框架是由各个公司来维护的。Spring Cloud 就是这些微服务的大管家。拆开是三层组件不是 Spring 写的Eureka 是 Netflix 的Nacos 是阿里的它干的是选品、定规范、做适配它定了一套规范所以注册中心从 Eureka 换 Nacos业务代码几乎不用动它用 Spring Boot 风格封装本来配 Eureka 要写一坨 XML现在一行eureka.client.service-url.defaultZone...搞定。所以别问Spring Cloud 和 Spring Boot 啥关系了Boot 是盖房子的脚手架Spring Cloud 是往房里装家电的。家电不是它造的但它保证插头能插上。 返回目录8. 版本号为什么是地铁站名Java 生态版本号一般长1.2.3这样Spring Cloud 偏要用伦敦地铁站名。课件原话Spring Cloud 是一个由很多子项目组成的庞大项目这些子项目由各个公司来维护所以发布阶段也是不同的。为了管理主项目和子项目的依赖关系以及避免和子项目版本的冲突主项目版本命名并没有采用和子项目一样的数字版本化形式而是采用了英文名称。说人话子项目各走各的主项目没法拿数字排序干脆另起一套拿地铁站名按 A 到 Z 往下排Angel → Brixton → Camden → Dalston → Edgware → Finchley → Greenwich → Hoxton正好 A 到 H。用了八年问题也来了字母会背混。面试官问用哪个版本你说C 开头的那个——谁知道是 Camden 还是 Greenwich所以 Hoxton 之后改成了日期版本号格式年份.第几个版本.补丁号2020.0.xIlford、2021.0.xJubilee、2022.0.xKilburn、2023.0.xLeyton。代号没取消只是退到aka后面了——官方写2023.0.x aka Leyton意思是这一班列车花名还叫 Leyton。下面这段请务必看完,可以帮助你节省不少的时间:Spring Cloud 中的所有子项目都依赖 Spring Boot所以两者版本之间存在一定的对应关系。比如 Spring Boot 3.2.X 对应的 Spring Cloud 版本是 2023.0.X。对不上会怎样轻则启动报类找不到重则半死不活地跑着查半天查不出来。原因就三个BOM 锁死了spring-cloud-dependencies里写死了它期望的 Boot 范围Maven 不拦你运行时才翻脸自动配置类是照着版本写的换个大的就加载不了还有javax到jakarta那次大迁移Boot 3 起包名全变拿 2.x 的组件去配 3.x 基本必挂。所以我们需要记住一句Spring Cloud 的版本必须和 Spring Boot 对上。写法上就是引spring-cloud-dependencies这个 BOM自己只声明spring-cloud.version具体组件一律不写版本号。完整对照表放在10.3 节了这里只给结论新项目上2025.1.x Boot4.0.x存量 Boot 3.5 项目守住2025.0.x别为了新硬升 4.0跟着课件练用哪套都行但 BOM 和 Boot 一定要对齐。 顺手教个查版本的技巧浏览器打开https://start.spring.io/actuator/info搜spring-cloud每个发布列车对应哪个 Boot 版本比翻文档快。 返回目录9. 两代实现Netflix 和 AlibabaSpring Cloud 定的是规范规范得有实现。最有名的俩Spring Cloud Netflix和Spring Cloud Alibaba。第一代 Netflix全家桶是 Eureka注册发现、Zuul网关、Ribbon负载均衡、Feign服务调用、Hystrix断路器、Hystrix Dashboard监控面板、Turbine聚合监控、Archaius配置管理。很长一段时间里Spring Cloud这三个字就是Spring Cloud Netflix的代称。然后 2018 年前后Netflix 宣布Hystrix、Ribbon、Zuul 这些核心组件进入维护状态Spring Cloud 只能把对应模块移出主线。 提一句spring-cloud-netflix并没被完全删掉只是从 2020.0 版本起它只管 Eureka 了。所以今天用最新版还能写 Eureka 客户端只是里面没有 Hystrix 了。这套东西不少公司都在大规模用停更短期没事长期肯定不行所以官方给了替换清单停更的组件官方推荐替代说明HystrixResilience4jHystrix 自己也推荐用它Hystrix Dashboard / TurbineMicrometer Monitoring System监控交给更专业的组件RibbonSpring Cloud LoadBalancerSpring 团队亲自出手Zuul 1Spring Cloud Gateway同上而且异步非阻塞Archaius 1Boot 外部化配置 Spring Cloud Config比 Netflix 实现更好用第二代是 Alibaba。虽然 Spring Cloud Alibaba 目前并不是 Spring Cloud 官方推荐的默认方案但它是阿里中间件团队主导的一个新生项目正处于高速迭代中。甚至在 Alibaba 的开源组件还没有织入 Spring Cloud 生态之前就已经在各大公司广泛使用了。它主要靠Nacos注册中心 配置中心一个顶俩、Sentinel流控熔断、Seata分布式事务撑场面外加 DubboRPC和 RocketMQ消息。课件的判断是Alibaba 吸收了 Netflix 的核心架构思想并做了高性能改进自 Netflix 停更后逐渐代替它成了主流。这事儿在国内尤其明显。你翻招聘 JD 就懂了“熟悉 Spring Cloud Alibaba / Nacos出现的频率远高于Eureka”。原因也简单——Nacos 一个组件同时干注册中心和配置中心两件事部署一套就够对小团队太友好。 返回目录10. 总结与速查10.1 三句话① 单体的问题不是小是绑在一起——绑在一起扩容、绑在一起发布、绑在一起故障。所以优化只有两条路横向加机器纵向拆业务。② 集群和分布式不是二选一是套娃——集群是同样的事多个人干分布式是不同的事分给人干。实际项目里分布式架构的每个节点通常自己又是一个集群所以统称分布式架构。③ 微服务 分布式 更细拆分 公共能力下沉换来灵活欠下治理的债Spring Cloud 是还债的工具箱它不造轮子只负责整合、封装、开箱即用。 返回目录10.2 概念速查名词一句话定义关键词单体架构所有功能打成一个包统一部署运行一个 jar一起生一起死集群同一系统完整复制到多台机器靠负载均衡调度同功能可替代分布式一个系统拆成多个子系统部署在多台机器协同不同功能缺一不可垂直架构按业务把大项目切成多个单体小项目纵向拆分接口多为数据同步微服务只做一件事、可单独部署运行的最小服务单元单一职责独立进程服务治理服务多了之后的一整套管理问题依赖、运维、监控、限流Spring Cloud微服务架构的一站式解决方案整合 封装不造轮子 返回目录10.3 版本速查**截图存相册吧这张最实用。后面的按 2026 年 10 月的情况补齐Spring Cloud代号适配 Spring BootJDK状态2026.0.xPaddington4.2.x17里程碑阶段还没 GA2025.1.xOakwood4.0.x17当前主线新项目首选2025.0.xNorthfields3.5.x17存量项目主力2024.0.xMoorgate3.4.x17已过开源支持期2023.0.xLeyton3.2.x / 3.3.x17已过开源支持期课件版本2022.0.xKilburn3.0.x / 3.1.x17官方已停止支持2021.0.xJubilee2.6.x / 2.7.x8官方已停止支持2020.0.xIlford2.4.x / 2.5.x8官方已停止支持Hoxton—2.2.x / 2.3.x8已停止支持Greenwich—2.1.x8已停止支持Finchley—2.0.x8已停止支持Edgware / Dalston—1.5.x8已停止支持Camden—1.4.x8已停止支持Brixton—1.3.x / 1.4.x6 / 8已停止支持Angel—1.2.x6已停止支持 上表核对于2026-10-31。这类信息变得快真要动手选版本时以spring.io/projects/spring-cloud官方矩阵为准。 返回目录10.4 组件速查能力官方NetflixAlibaba到底解决什么服务注册 / 发现EurekaEurekaNacos服务在哪台机器挂了怎么办服务调用OpenFeignFeignDubbo怎么像调本地方法一样调远程配置中心Spring Cloud ConfigArchaiusNacos配置改了不用重新打包服务网关GatewayZuulGateway前端只认一个入口负载均衡LoadBalancerRibbonDubbo内置5 个实例这次调哪个熔断降级Resilience4jHystrixSentinel下游挂了别拖死我分布式事务——Seata跨库操作怎么保证一致分布式消息Spring Cloud Stream—RocketMQ异步解耦、削峰小技巧面试问你们用什么注册中心答Nacos它同时是配置中心比干巴巴答个 Eureka 有信息量得多。 返回目录11. 小结这篇没几行代码但它是整个系列的地图。看到这儿你应该能在脑子里画出这条线单体扛不住 → 加机器集群→ 还是乱 → 拆业务分布式→ 还是重复 → 拆细 抽公共能力微服务→ 拆完没人管 → Spring Cloud 出场。如果这篇帮你理清了一个概念点个赞再走有不同意见评论区见我基本都会回。我们下期见~ 返回目录 
长河君 · 2026/11/6 5:16:57 · 阅读 1.2k Spring Cloud 到底解决了什么？单体、集群、分布式、微服务一次讲透
博客主页小谢同学的小破站✍️本文由小谢同学的小破站原创首发于 CSDN ☕JavaSE专栏JavaSEJavaEE初阶专栏JavaEE初阶JavaEE进阶专栏JavaEE进阶数据结构专栏数据结构⚙️算法专栏算法MySQL初阶专栏MySQL初阶Spring CloudSpring Cloud计算机网络专栏计算机网络SpringAISpringAI从入门到应用欢迎点赞 收藏⭐ 留言发现错误欢迎指正✨脚踏实地持续深耕奔赴自己的目标✨----- 分割线 -------Spring Cloud 微服务开发1. 什么是微服务开发?2. 单体架构一开始真挺好用3. 扛不住了只有两条路4. 集群和分布式到底差在哪5. 微服务拆到不能再拆6. 这笔买卖赚的和赔的7. Spring Cloud微服务的大管家8. 版本号为什么是地铁站名9. 两代实现Netflix 和 Alibaba10. 总结与速查10.1 三句话10.2 概念速查10.3 版本速查10.4 组件速查11. 小结前言这里是 小谢同学 的微服务学习记录微服务系列第一篇。这篇代码不多全在讲概念。但它挺关键——这一篇糊过去后面学 Eureka、Nacos、Gateway 就全是背配置学完也不知道自己在配啥。本文使用一家宠物医院的四年来帮助讲解微服务。1. 什么是微服务开发先给一个不那么教科书的答案:微服务开发,就是将一个大的系统拆分成一堆能各自独立运行的小服务,每一个只管理一件事情,再想办法让它们互相找得到、调得通、扛得住。这句话里其实藏着三个问题为什么要拆拆到什么程度拆完到底谁来收拾摊子整篇就顺着这三个问题走。我们先来看看结论:微服务是用一堆独立服务换来灵活同时欠下一笔运维和治理的债Spring Cloud 就是帮你还这笔债的工具箱。主角叫毛孩子动物医院2021 年从小区门口的小诊所起步。下面这五段是我编的教学设定并不是真实的数据但踩的坑基本是中小项目的通用剧本时间技术状态遇到的事2021一个 Spring Boot 项目1 台服务器够用改完就上线2022同一台机器加配置周末排队中午打不开2023同一套系统复制 3 份集群扛住了但改一次发三次版2024按科室拆 4 个子系统分布式拆开了重复代码翻倍2025十几个微服务 公共基础服务灵活了运维快疯了运维快疯了不是吐槽这也恰恰是 Spring Cloud 存在的理由。 返回目录2. 单体架构一开始真挺好用在2021 年老板找了外包做个 Spring Boot 项目。预约、接诊、化验、开药、收银、会员卡、发短信……全都塞进一个工程打成一个 jar 包扔在一台服务器上跑。这就是单体架构单体架构:将一个应用中的所有功能实现,全部都打包在一个jar包或者war包中,统一部署,统一运行;说白了就是一家只有一个屋子的小诊所挂号在前台那张桌子拿药在身后柜子收钱还是那张桌子一个人从前包到后。开药,看病,以及收银都是在一个位置来进行;现在一提单体好多人一脸嫌弃这不太公平。在它该待的规模里是真香开发一个工程clone下来就能跑部署一行java -jar没什么启动顺序的讲究调用就是本地方法调用纳秒级基本上不可能超时事务一个Transactional全包了数据库替你保证要么全成要么全败。这四条记一下。因为往后你会发现微服务牺牲的正好就是这四条。2022 年事儿来了。周六上午 CPU 打满请求排队超时整站打不开改个药房打印小票的文案也要整个项目重新打包发布全院停三分钟化验单模块内存泄漏把 JVM 撑爆结果不是化验单打不开而是挂号、收银、开药全部 502——它们本来就住在一个进程里。于是只剩一个朴素的问题这台机器、这坨代码怎么扛住下一年答案就两条路。 返回目录3. 扛不住了只有两条路第一条路: 横向,加机器: 代码中的逻辑一个字都不改,直接去买3台服务器,每一台服务器都跑一模一样的jar包,前面的Nginx分流, 这个就叫做集群;集群是把一个系统完整部署到多台服务器上每台都能提供系统的全部服务通过负载均衡调度共同完成任务。集群里的每一台机器叫做一个节点node。用医院来举例子: 一间问诊室忙不过来,就在隔壁再开两间问诊室,请两个一模一样的医生,什么病都能够看,病人来了先去问诊台,去问哪一间空着就往哪送。这里有个细节第一次都想不到集群必须有个分诊台。病人首先得知道去哪排队医生之间也得知道隔壁今天请假没有。这个分诊台 排班表落到技术上就是负载均衡 服务注册发现。但集群只治了扛不住没治太乱——三台机器跑的还是同一坨代码。第二条纵向拆业务。把一个大系统按业务切成几个独立小系统各自部署。课件里管这叫垂直架构以单体规模的项目为单位进行垂直划分把大项目拆成一个个单体结构的小项目项目之间相对独立接口多为数据同步功能。放到医院就是把一个人干所有事改成流水线前台只管挂号分诊门诊只管接诊开单检验只管化验出报告药房只管配药发药收银只管结算开票。药房半夜升级挂号照样接客, 各自管理好各自的功能。清爽了。但新麻烦立刻跟上一次就诊就要跨五个系统以前一个事务搞定的事现在得操心挂号成功、收银失败怎么回滚服务之间怎么找对方换机器了配置改不改调用失败了又怎么办跨网络了检验慢三秒门诊是干等、报错还是重试发现问题没有——这三件事全都不是写业务代码能解决的它们是基础设施问题。而这正是 Spring Cloud 要卖的货。 返回目录4. 集群和分布式到底差在哪分布式和集群到底有什么区别?到底差哪里了?从概念上分集群是多个机器做同样的事分布式是多个机器做不同的事。一句话就完了——三个都看全科病的医生是集群前台、检验、药房、收银各管一摊是分布式。从功能上分集群每个节点功能相同、能互相替代医生 A 请假去 B 那儿照样能看分布式每个节点业务不同一个节点出问题这块业务就直接不可访问——药房关门了你不可能跑去检验科拿药。所以高可用的做法也不同集群挂一个请求自动转走分布式挂一个只能靠给它也做集群或者做降级兜底。从关系上看课件这段总结得挺准我直接写下来:分布式和集群在实践中很多时候是互相配合使用的。比如分布式的某一个节点可能由一个集群来代替。分布式架构大多是建立在集群上的。所以实际的分布式架构设计中并不会把分布式和集群单独区分而是统称分布式架构。翻译一下这俩不是二选一是套娃。所以你说我们项目是分布式架构其实更专业因为这句话默认包含了每个服务都是多实例。对比维度集群 Cluster分布式 Distributed干的事多个节点做同样的事多个节点做不同的事拆分方式复制不改代码拆分按业务切节点可否替代可以随时互换不可以各管一摊单点故障业务不受影响该业务直接不可用主要解决扛不住压力分散太乱职责分离配套需求负载均衡注册发现、远程调用、网关面试问到无非两种问法。问你们项目是集群还是分布式答架构上是分布式的按业务拆成 N 个服务每个服务又部署多实例所以也含集群两者配合用。问我多买两台服务器算分布式吗答不算那只是从单机变集群代码没变、职责没分。 返回目录5. 微服务拆到不能再拆2024 年拆成五个系统舒服了半年。然后发现一件更烦的事每个系统里都写了一遍会员积分。挂号加积分、开药加积分、收银加积分、上门服务也加积分。四份代码逻辑还不完全一样。运营说改成消费 1 元积 2 分开发一看改四个项目、发四次版、协调四个上线窗口。按照业务进行拆分后会有一些重复的功能开发比如订单系统电商平台和支付系统都会涉及。在分布式架构下当部署的服务越来越多重复的代码就会越来越多服务的调用关系也会越来越复杂。解法也比较简单:把通用、会被多个上层服务调用的共享业务抽成独立的基础服务。把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务组成一个个微小的服务。这就是微服务。于是就有了会员积分服务、消息通知服务、在线支付服务——它们不属于任何一个科室但所有科室都要用。上面一层是业务下面一层是能力。上面怎么变下面都能接着复用。但是微服务这个名字挺误导人重点不是小而是独立。很小的服务小到一个服务只对应一个单一的功能只做一件事这个服务可以单独部署运行。三条标准比多少行代码靠谱多了标准什么意思反例只做一件事职责单一一个服务对应一个能力综合业务服务塞了挂号、药房、收银能单独部署有自己的启动类和端口只能跟着主工程一起打包独立进程挂了不影响别人能单独重启扩容和别的模块跑在同一个 JVM所以“拆成 6 个服务≠微服务”。要是这 6 个还共用一个库、必须一起启动那只是逻辑上分了包它骨子里还是单体。另外服务之间用REST 或 RPC通信理解成接口的约定就行区别只在怎么喊REST 像寄快递填单子GET /pets/1JSON好调试RPC 像打内线电话getById(1)二进制快。最后纠个常见误解分布式和微服务不是程度差别。分布式服务拆分拆了就行。微服务更细粒度的垂直拆分通常指不能再拆的服务。分布式侧重压力的分散微服务侧重能力的分散更强调专业化和精细分工。还有句更狠的微服务架构通常是分布式架构反之未必成立。所以选择微服务通常意味着需要解决分布式架构的各种难题。潜台词就是你选了微服务等于主动把所有分布式的坑都领了一遍。这几个观点都是错误的一个观点~ 返回目录6. 这笔买卖赚的和赔的左边四样是你换来的右边四样是你付出去的。注意右边一样都不少。就像一个刚开始创业,经济压力比较大的公司,一个员工什么都会干的时候,由于公司比较小,管理起来就相对于比较简单;但是如果公司的规模越来越大,就必须区分部分,效率是提高了,但是维护的成本也跟着涨价了,人越多,管理就越复杂,服务和人是同一个道理;所以别被先进两个字带着走。团队不到 5 个人、产品还在找方向、日活几千、没有自动化运维这几种情况就老老实实写单体。判断标准其实特别朴素当你因为发个版会牵连别的模块和扩容不能按模块来而真的开始痛苦了那才是拆的时候。不是因为面试要问。 返回目录7. Spring Cloud微服务的大管家官方说到: spring cloud提供了一些可以让开发人员快熟构建分布式服务的工具,就好像配置管理,服务发现,熔断,智能路由等等,他们可以在任何分布式环境中很好的工作;简单来说Spring Cloud 就是分布式微服务架构的一站式解决方案是微服务架构落地的多种技术的集合。用我们现在的话来说就是:微服务那一堆的基础设施的破事,它都替你把成熟方案打包好了,引入依赖,我们只需要写几行配置就能使用.官方能力解决什么麻烦后面学的组件Distributed versioned configuration配置散在 12 个服务改一个改 12 遍Nacos / ConfigService registration and discovery服务在哪台机器挂了怎么知道Eureka / NacosRouting智能路由前端不该记住 12 个服务的地址GatewayService-to-service calls怎么像调本地方法一样调远程OpenFeignLoad balancing一个服务 5 个实例这次调哪个LoadBalancerCircuit Breakers下游挂了别把我一起拖死Resilience4j / SentinelDistributed messaging异步解耦下单后发通知不用干等RabbitMQ链路追踪补充一个请求跨 8 个服务卡在哪环Micrometer / SkyWalking看懂这张表就明白了后面几讲的内容全在里面。这也是为啥这篇必须先讲——不然学 Eureka 时你压根不知道它在整个体系里站哪。Spring Cloud 并不是 Spring 团队研发的框架它只是把一些比较优秀的开源框架基于 Spring Cloud 规范进行了整合并基于 Spring Boot 的风格对这些组件进行了封装屏蔽掉了复杂的配置和实现原理为开发者提供了开箱即用的微服务开发体验。这些开源技术的框架是由各个公司来维护的。Spring Cloud 就是这些微服务的大管家。拆开是三层组件不是 Spring 写的Eureka 是 Netflix 的Nacos 是阿里的它干的是选品、定规范、做适配它定了一套规范所以注册中心从 Eureka 换 Nacos业务代码几乎不用动它用 Spring Boot 风格封装本来配 Eureka 要写一坨 XML现在一行eureka.client.service-url.defaultZone...搞定。所以别问Spring Cloud 和 Spring Boot 啥关系了Boot 是盖房子的脚手架Spring Cloud 是往房里装家电的。家电不是它造的但它保证插头能插上。 返回目录8. 版本号为什么是地铁站名Java 生态版本号一般长1.2.3这样Spring Cloud 偏要用伦敦地铁站名。课件原话Spring Cloud 是一个由很多子项目组成的庞大项目这些子项目由各个公司来维护所以发布阶段也是不同的。为了管理主项目和子项目的依赖关系以及避免和子项目版本的冲突主项目版本命名并没有采用和子项目一样的数字版本化形式而是采用了英文名称。说人话子项目各走各的主项目没法拿数字排序干脆另起一套拿地铁站名按 A 到 Z 往下排Angel → Brixton → Camden → Dalston → Edgware → Finchley → Greenwich → Hoxton正好 A 到 H。用了八年问题也来了字母会背混。面试官问用哪个版本你说C 开头的那个——谁知道是 Camden 还是 Greenwich所以 Hoxton 之后改成了日期版本号格式年份.第几个版本.补丁号2020.0.xIlford、2021.0.xJubilee、2022.0.xKilburn、2023.0.xLeyton。代号没取消只是退到aka后面了——官方写2023.0.x aka Leyton意思是这一班列车花名还叫 Leyton。下面这段请务必看完,可以帮助你节省不少的时间:Spring Cloud 中的所有子项目都依赖 Spring Boot所以两者版本之间存在一定的对应关系。比如 Spring Boot 3.2.X 对应的 Spring Cloud 版本是 2023.0.X。对不上会怎样轻则启动报类找不到重则半死不活地跑着查半天查不出来。原因就三个BOM 锁死了spring-cloud-dependencies里写死了它期望的 Boot 范围Maven 不拦你运行时才翻脸自动配置类是照着版本写的换个大的就加载不了还有javax到jakarta那次大迁移Boot 3 起包名全变拿 2.x 的组件去配 3.x 基本必挂。所以我们需要记住一句Spring Cloud 的版本必须和 Spring Boot 对上。写法上就是引spring-cloud-dependencies这个 BOM自己只声明spring-cloud.version具体组件一律不写版本号。完整对照表放在10.3 节了这里只给结论新项目上2025.1.x Boot4.0.x存量 Boot 3.5 项目守住2025.0.x别为了新硬升 4.0跟着课件练用哪套都行但 BOM 和 Boot 一定要对齐。 顺手教个查版本的技巧浏览器打开https://start.spring.io/actuator/info搜spring-cloud每个发布列车对应哪个 Boot 版本比翻文档快。 返回目录9. 两代实现Netflix 和 AlibabaSpring Cloud 定的是规范规范得有实现。最有名的俩Spring Cloud Netflix和Spring Cloud Alibaba。第一代 Netflix全家桶是 Eureka注册发现、Zuul网关、Ribbon负载均衡、Feign服务调用、Hystrix断路器、Hystrix Dashboard监控面板、Turbine聚合监控、Archaius配置管理。很长一段时间里Spring Cloud这三个字就是Spring Cloud Netflix的代称。然后 2018 年前后Netflix 宣布Hystrix、Ribbon、Zuul 这些核心组件进入维护状态Spring Cloud 只能把对应模块移出主线。 提一句spring-cloud-netflix并没被完全删掉只是从 2020.0 版本起它只管 Eureka 了。所以今天用最新版还能写 Eureka 客户端只是里面没有 Hystrix 了。这套东西不少公司都在大规模用停更短期没事长期肯定不行所以官方给了替换清单停更的组件官方推荐替代说明HystrixResilience4jHystrix 自己也推荐用它Hystrix Dashboard / TurbineMicrometer Monitoring System监控交给更专业的组件RibbonSpring Cloud LoadBalancerSpring 团队亲自出手Zuul 1Spring Cloud Gateway同上而且异步非阻塞Archaius 1Boot 外部化配置 Spring Cloud Config比 Netflix 实现更好用第二代是 Alibaba。虽然 Spring Cloud Alibaba 目前并不是 Spring Cloud 官方推荐的默认方案但它是阿里中间件团队主导的一个新生项目正处于高速迭代中。甚至在 Alibaba 的开源组件还没有织入 Spring Cloud 生态之前就已经在各大公司广泛使用了。它主要靠Nacos注册中心 配置中心一个顶俩、Sentinel流控熔断、Seata分布式事务撑场面外加 DubboRPC和 RocketMQ消息。课件的判断是Alibaba 吸收了 Netflix 的核心架构思想并做了高性能改进自 Netflix 停更后逐渐代替它成了主流。这事儿在国内尤其明显。你翻招聘 JD 就懂了“熟悉 Spring Cloud Alibaba / Nacos出现的频率远高于Eureka”。原因也简单——Nacos 一个组件同时干注册中心和配置中心两件事部署一套就够对小团队太友好。 返回目录10. 总结与速查10.1 三句话① 单体的问题不是小是绑在一起——绑在一起扩容、绑在一起发布、绑在一起故障。所以优化只有两条路横向加机器纵向拆业务。② 集群和分布式不是二选一是套娃——集群是同样的事多个人干分布式是不同的事分给人干。实际项目里分布式架构的每个节点通常自己又是一个集群所以统称分布式架构。③ 微服务 分布式 更细拆分 公共能力下沉换来灵活欠下治理的债Spring Cloud 是还债的工具箱它不造轮子只负责整合、封装、开箱即用。 返回目录10.2 概念速查名词一句话定义关键词单体架构所有功能打成一个包统一部署运行一个 jar一起生一起死集群同一系统完整复制到多台机器靠负载均衡调度同功能可替代分布式一个系统拆成多个子系统部署在多台机器协同不同功能缺一不可垂直架构按业务把大项目切成多个单体小项目纵向拆分接口多为数据同步微服务只做一件事、可单独部署运行的最小服务单元单一职责独立进程服务治理服务多了之后的一整套管理问题依赖、运维、监控、限流Spring Cloud微服务架构的一站式解决方案整合 封装不造轮子 返回目录10.3 版本速查**截图存相册吧这张最实用。后面的按 2026 年 10 月的情况补齐Spring Cloud代号适配 Spring BootJDK状态2026.0.xPaddington4.2.x17里程碑阶段还没 GA2025.1.xOakwood4.0.x17当前主线新项目首选2025.0.xNorthfields3.5.x17存量项目主力2024.0.xMoorgate3.4.x17已过开源支持期2023.0.xLeyton3.2.x / 3.3.x17已过开源支持期课件版本2022.0.xKilburn3.0.x / 3.1.x17官方已停止支持2021.0.xJubilee2.6.x / 2.7.x8官方已停止支持2020.0.xIlford2.4.x / 2.5.x8官方已停止支持Hoxton—2.2.x / 2.3.x8已停止支持Greenwich—2.1.x8已停止支持Finchley—2.0.x8已停止支持Edgware / Dalston—1.5.x8已停止支持Camden—1.4.x8已停止支持Brixton—1.3.x / 1.4.x6 / 8已停止支持Angel—1.2.x6已停止支持 上表核对于2026-10-31。这类信息变得快真要动手选版本时以spring.io/projects/spring-cloud官方矩阵为准。 返回目录10.4 组件速查能力官方NetflixAlibaba到底解决什么服务注册 / 发现EurekaEurekaNacos服务在哪台机器挂了怎么办服务调用OpenFeignFeignDubbo怎么像调本地方法一样调远程配置中心Spring Cloud ConfigArchaiusNacos配置改了不用重新打包服务网关GatewayZuulGateway前端只认一个入口负载均衡LoadBalancerRibbonDubbo内置5 个实例这次调哪个熔断降级Resilience4jHystrixSentinel下游挂了别拖死我分布式事务——Seata跨库操作怎么保证一致分布式消息Spring Cloud Stream—RocketMQ异步解耦、削峰小技巧面试问你们用什么注册中心答Nacos它同时是配置中心比干巴巴答个 Eureka 有信息量得多。 返回目录11. 小结这篇没几行代码但它是整个系列的地图。看到这儿你应该能在脑子里画出这条线单体扛不住 → 加机器集群→ 还是乱 → 拆业务分布式→ 还是重复 → 拆细 抽公共能力微服务→ 拆完没人管 → Spring Cloud 出场。如果这篇帮你理清了一个概念点个赞再走有不同意见评论区见我基本都会回。我们下期见~ 返回目录