什么是微服务,为什么需要 Spring Cloud
先说一句大实话:把一个单体应用拆成一堆小服务容易,拆完之后谁来管它们才是难题。服务 A 怎么知道服务 B 的地址?100 个服务改个配置要改 100 个文件?一个服务挂了会不会拖死全家?这些问题,就是 Spring Cloud 这套工具箱要解决的。
论单体 vs 微服务,一张表说清
单体应用:所有功能(用户、订单、商品)塞进一个工程,打一个 jar 包跑起来。代码量小的时候很爽,一个 IDE 窗口全搞定。但代码长到几十万行之后,改个订单模块要重新部署整个应用,团队三五十人挤在一个仓库里互相冲突,一个小 bug 搞崩全站。
微服务:按业务把应用拆成多个小服务,每个服务独立开发、独立部署、独立数据库。用户服务挂了,商品服务还能下单。但代价是——服务之间怎么找彼此?配置怎么统一管?出问题怎么定位?这些"分布式系统的复杂度",单体里根本不存在,拆出来之后全冒出来了。
一句话:微服务不是银弹,它把"代码复杂度"换成了"运维复杂度"。团队小于 10 人、业务还没跑通之前,别为了炫技硬拆微服务,先把单体写好比啥都强。
Spring Cloud 与 Spring Cloud Alibaba 是什么关系
很多人第一次见这俩名字就懵了:不是一个东西吗?还真不是。下面这张表把角色讲清楚。
| 名字 | 大白话定位 |
|---|---|
| Spring Boot | 写单个 Java Web 应用的脚手架,"一个服务怎么跑起来"归它管。 |
| Spring Cloud | Spring 官方出的"微服务治理规范集合"。它本身不生产轮子,而是定义了一堆接口(注册中心长啥样、网关长啥样),让各家轮子都能插进来。Netflix 早期贡献了 Eureka、Hystrix,后来 Netflix 系纷纷停更,生态重心转向 Alibaba。 |
| Spring Cloud Alibaba | 阿里开源的微服务套件,把 Nacos、Sentinel、Seata、RocketMQ 这些国内主流组件,按照 Spring Cloud 的接口规范封装成 starter。国内企业现在基本都用这套,文档中文、社区活跃、踩坑资料多。 |
什么时候该拆微服务,什么时候别拆
别听人说"微服务先进"就上。下面这张表帮你判断:
| 情况 | 建议 | 原因 |
|---|---|---|
| 团队 < 10 人,业务刚起步 | 单体 | 拆微服务的运维成本你养不起。 |
| 单体改一次要发整个应用,团队互相堵 | 可以拆 | 组织痛了才拆,别为技术炫技拆。 |
| 不同模块性能要求差很多(比如报表要扛 10 倍流量) | 拆 | 把热点模块独立出去单独扩容。 |
| 业务还没验证,每天改方向 | 别拆 | 拆完发现业务方向变了,拆分全作废。 |
Spring Cloud、Spring Cloud Alibaba、Spring Boot 三者版本必须严格匹配。Spring Boot 3.2.x 配 Spring Cloud 2023.0.x(代号 Leyton),再配 Spring Cloud Alibaba 2023.0.1.x。你要是拿 Spring Boot 3.3 去配 Spring Cloud 2021.0.x,启动时各种 NoSuchMethodError、ClassNotFoundException,查半天发现是版本号写错了。
正确做法:去 Spring Cloud 官方 Wiki 查"Release Train"对应表,官方列了哪个 Spring Cloud 版本对应哪个 Spring Boot 版本,照着抄。不确定就以官方文档最新稳定版为准。
父工程 pom.xml 里管理版本(只引依赖,不写死版本号)