- 🏠博客主页：小谢同学的小破站
- ✍️本文由小谢同学的小破站原创，首发于 CSDN 💻
- ☕JavaSE专栏：JavaSE
- 📗JavaEE初阶专栏：JavaEE初阶
- 📘JavaEE进阶专栏：JavaEE进阶
- 🧩数据结构专栏：数据结构
- ⚙️算法专栏：算法
- 📚MySQL初阶专栏：MySQL初阶
- 🔐Spring Cloud：Spring Cloud
- 🌐计算机网络专栏：计算机网络
- 💻SpringAI：SpringAI从入门到应用
- 👍欢迎点赞👍 收藏⭐ 留言📝，发现错误欢迎指正！
- ✨脚踏实地，持续深耕，奔赴自己的目标✨
----- 📌分割线 📌-------
Spring Cloud 微服务开发
- 1. 什么是微服务开发?
- 2. 单体架构：一开始真挺好用
- 3. 扛不住了，只有两条路
- 4. 集群和分布式，到底差在哪
- 5. 微服务：拆到不能再拆
- 6. 这笔买卖，赚的和赔的
- 7. Spring Cloud：微服务的大管家
- 8. 版本号为什么是地铁站名
- 9. 两代实现：Netflix 和 Alibaba
- 10. 总结与速查
- 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/1，JSON，好调试），RPC 像打内线电话（getById(1)，二进制，快）。
最后纠个常见误解：分布式和微服务不是程度差别。
分布式：服务拆分，拆了就行。微服务：更细粒度的垂直拆分，通常指不能再拆的服务。分布式侧重压力的分散，微服务侧重能力的分散，更强调专业化和精细分工。
还有句更狠的：微服务架构通常是分布式架构，反之未必成立。所以选择微服务，通常意味着需要解决分布式架构的各种难题。潜台词就是：你选了微服务，等于主动把所有分布式的坑都领了一遍。
这几个观点都是错误的一个观点~
6. 这笔买卖，赚的和赔的
左边四样是你换来的，右边四样是你付出去的。注意右边，一样都不少。
就像一个刚开始创业,经济压力比较大的公司,一个员工什么都会干的时候,由于公司比较小,管理起来就相对于比较简单;但是如果公司的规模越来越大,就必须区分部分,效率是提高了,但是维护的成本也跟着涨价了,人越多,管理就越复杂,服务和人是同一个道理;
所以别被"先进"两个字带着走。团队不到 5 个人、产品还在找方向、日活几千、没有自动化运维，这几种情况就老老实实写单体。判断标准其实特别朴素：当你因为"发个版会牵连别的模块"和"扩容不能按模块来"而真的开始痛苦了，那才是拆的时候。不是因为面试要问。
7. Spring Cloud：微服务的大管家
官方说到: spring cloud提供了一些可以让开发人员快熟构建分布式服务的工具,就好像配置管理,服务发现,熔断,智能路由等等,他们可以在任何分布式环境中很好的工作;
简单来说，Spring Cloud 就是分布式微服务架构的一站式解决方案，是微服务架构落地的多种技术的集合。
用我们现在的话来说就是:微服务那一堆的基础设施的破事,它都替你把成熟方案打包好了,引入依赖,我们只需要写几行配置就能使用.
| 官方能力 | 解决什么麻烦 | 后面学的组件 |
|---|---|---|
| Distributed versioned configuration | 配置散在 12 个服务，改一个改 12 遍 | Nacos / Config |
| Service registration and discovery | 服务在哪台机器？挂了怎么知道 | Eureka / Nacos |
| Routing（智能路由） | 前端不该记住 12 个服务的地址 | Gateway |
| Service-to-service calls | 怎么像调本地方法一样调远程 | OpenFeign |
| Load balancing | 一个服务 5 个实例，这次调哪个 | LoadBalancer |
| Circuit Breakers | 下游挂了，别把我一起拖死 | Resilience4j / Sentinel |
| Distributed 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.x（Ilford）、2021.0.x（Jubilee）、2022.0.x（Kilburn）、2023.0.x（Leyton）。代号没取消，只是退到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 和 Alibaba
Spring 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 了。
这套东西不少公司都在大规模用，停更短期没事，长期肯定不行，所以官方给了替换清单：
| 停更的组件 | 官方推荐替代 | 说明 |
|---|---|---|
| Hystrix | Resilience4j | Hystrix 自己也推荐用它 |
| Hystrix Dashboard / Turbine | Micrometer + Monitoring System | 监控交给更专业的组件 |
| Ribbon | Spring Cloud LoadBalancer | Spring 团队亲自出手 |
| Zuul 1 | Spring Cloud Gateway | 同上，而且异步非阻塞 |
| Archaius 1 | Boot 外部化配置 + Spring Cloud Config | 比 Netflix 实现更好用 |
第二代是 Alibaba。
虽然 Spring Cloud Alibaba 目前并不是 Spring Cloud 官方推荐的默认方案，但它是阿里中间件团队主导的一个新生项目，正处于高速迭代中。甚至在 Alibaba 的开源组件还没有织入 Spring Cloud 生态之前，就已经在各大公司广泛使用了。
它主要靠Nacos（注册中心 + 配置中心，一个顶俩）、Sentinel（流控熔断）、Seata（分布式事务）撑场面，外加 Dubbo（RPC）和 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 Boot | JDK | 状态 |
|---|---|---|---|---|
| 2026.0.x | Paddington | 4.2.x | 17+ | 里程碑阶段，还没 GA |
| 2025.1.x | Oakwood | 4.0.x | 17+ | 当前主线，新项目首选 |
| 2025.0.x | Northfields | 3.5.x | 17+ | 存量项目主力 |
| 2024.0.x | Moorgate | 3.4.x | 17+ | 已过开源支持期 |
| 2023.0.x | Leyton | 3.2.x / 3.3.x | 17+ | 已过开源支持期（课件版本） |
| 2022.0.x | Kilburn | 3.0.x / 3.1.x | 17+ | 官方已停止支持 |
| 2021.0.x | Jubilee | 2.6.x / 2.7.x | 8+ | 官方已停止支持 |
| 2020.0.x | Ilford | 2.4.x / 2.5.x | 8+ | 官方已停止支持 |
| Hoxton | — | 2.2.x / 2.3.x | 8 | 已停止支持 |
| Greenwich | — | 2.1.x | 8 | 已停止支持 |
| Finchley | — | 2.0.x | 8 | 已停止支持 |
| Edgware / Dalston | — | 1.5.x | 8 | 已停止支持 |
| Camden | — | 1.4.x | 8 | 已停止支持 |
| Brixton | — | 1.3.x / 1.4.x | 6 / 8 | 已停止支持 |
| Angel | — | 1.2.x | 6 | 已停止支持 |
📌 上表核对于2026-10-31。这类信息变得快，真要动手选版本时，以spring.io/projects/spring-cloud官方矩阵为准。
10.4 组件速查
| 能力 | 官方 | Netflix | Alibaba | 到底解决什么 |
|---|---|---|---|---|
| 服务注册 / 发现 | Eureka | Eureka | Nacos | 服务在哪台机器，挂了怎么办 |
| 服务调用 | OpenFeign | Feign | Dubbo | 怎么像调本地方法一样调远程 |
| 配置中心 | Spring Cloud Config | Archaius | Nacos | 配置改了不用重新打包 |
| 服务网关 | Gateway | Zuul | Gateway | 前端只认一个入口 |
| 负载均衡 | LoadBalancer | Ribbon | Dubbo（内置） | 5 个实例这次调哪个 |
| 熔断降级 | Resilience4j | Hystrix | Sentinel | 下游挂了别拖死我 |
| 分布式事务 | — | — | Seata | 跨库操作怎么保证一致 |
| 分布式消息 | Spring Cloud Stream | — | RocketMQ | 异步解耦、削峰 |
小技巧：面试问"你们用什么注册中心"，答"Nacos，它同时是配置中心"，比干巴巴答个 Eureka 有信息量得多。
11. 小结
这篇没几行代码，但它是整个系列的地图。看到这儿，你应该能在脑子里画出这条线：
单体扛不住 → 加机器（集群）→ 还是乱 → 拆业务（分布式）→ 还是重复 → 拆细 + 抽公共能力（微服务）→ 拆完没人管 → Spring Cloud 出场。
如果这篇帮你理清了一个概念，点个赞再走；有不同意见评论区见，我基本都会回。我们下期见~
