Spring Cloud从零开始：微服务入门指南
上周五晚上10点半，杭州西溪园区的灯还亮着一片。我正戴着AirPods听着周杰伦的《稻香》，试图在双11压测前把一个诡异的服务注册问题搞定。这时候钉钉突然弹出一条消息：“大佬，Spring Cloud到底咋玩啊？我们项目想上微服务，但连Eureka和Nacos都分不清……”
我苦笑了一下——这场景太熟悉了。去年我刚从网易跳槽到阿里时，也是被“微服务”三个字砸得晕头转向。当时leader扔给我一句：“下周上线，用Spring Cloud重构老系统。” 我内心OS：你礼貌吗？
今天这篇就当是给那位兄弟、也给曾经的自己写的一份实战指南。不讲八股文，只说人话。
为啥非得搞微服务？
先别急着抄代码。咱们得先搞清楚：微服务不是银弹，而是一把双刃剑。
我在阿里带过一个小团队，之前有个单体应用，20万行Java代码，启动要3分钟，改一行就得全量回归。产品经理一提需求，测试兄弟脸都绿了。后来拆成5个微服务，虽然运维复杂度上来了，但迭代速度直接起飞——某个模块崩了，不影响其他服务，双11大促期间我们甚至敢凌晨三点热更新！
但如果你的系统就两个接口、三个表，硬上微服务？那纯属给自己加戏。微服务的核心不是技术，而是组织协作和业务边界划分。这点在阿里的“中台战略”里体现得淋漓尽致。
从“Hello World”到能上线：我的踩坑实录
第一步：选注册中心，别被名词吓住
新手最容易卡在这儿。Eureka、Consul、ZooKeeper、Nacos……到底用哪个？
| 注册中心 | 语言生态 | 阿里系推荐度 | 学习曲线 | 是否支持配置中心 |
|---|---|---|---|---|
| Eureka | Java | ⭐⭐ | 简单 | ❌ |
| Nacos | Java/Go | ⭐⭐⭐⭐⭐ | 中等 | ✅ |
| Consul | 多语言 | ⭐⭐ | 较难 | ✅（需插件） |
结论：如果你在阿里生态，或者未来可能用到云原生（比如ACK），直接上 Nacos。它既是注册中心，又是配置中心，还能对接K8s。我们团队现在所有微服务都跑在Nacos + Spring Cloud Alibaba 上。
安装Nacos贼简单（本地开发）：
# 下载解压后
sh startup.sh -m standalone
然后访问 http://localhost:8848/nacos，账号密码都是 nacos。看到界面那一刻，我差点感动哭——终于不用再配Eureka的peer节点了！
第二步：服务提供者 & 消费者
假设我们要搞一个用户服务（user-service）和订单服务（order-service）。
user-service 的 bootstrap.yml：
spring:
application:
name: user-service
cloud:
nacos:
discovery:
server-addr: localhost:8848
config:
server-addr: localhost:8848
file-extension: yaml
关键点：@EnableDiscoveryClient 注解加上，服务启动时自动注册到Nacos。
消费者怎么调用？别手写RestTemplate拼URL了！用 OpenFeign：
@FeignClient(name = "user-service")
public interface UserClient {
@GetMapping("/users/{id}")
User getUserById(@PathVariable("id") Long id);
}
然后在 order-service 里直接注入 UserClient 调用。网络调用像本地方法一样丝滑——当然，前提是你要处理好超时、熔断、重试。
💡 血泪教训：有一次线上事故，就是没设Feign超时，下游服务慢，导致线程池打满，整个服务雪崩。现在我们默认配置：
feign: client: config: default: connectTimeout: 2000 readTimeout: 5000
第三步：熔断限流，别让一个服务拖垮全家
双11期间，某个营销服务突然QPS暴增10倍，结果把数据库连接池占满了，连支付服务都挂了。这种“级联故障”在微服务里太常见。
我们的解法：Sentinel + 熔断规则。
引入依赖：
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
然后在Nacos里配流控规则（或通过Sentinel Dashboard动态调整）。比如对 /createOrder 接口限流100 QPS，超过就快速失败，而不是让请求堆积。
面试题挑战：
“Sentinel 和 Hystrix 有什么区别？”
答：Hystrix 已停更，Sentinel 是阿里开源、生产验证、支持集群流控、实时监控更友好。在阿里内部，Sentinel 是标配。
数据库设计 & 接口规范：别只顾着拆服务
很多团队以为微服务就是把代码拆开，结果数据库还是一个大库，事务跨服务乱成一锅粥。
我们的实践：
- 每个微服务独享数据库（物理隔离）
- 跨服务数据一致性用 Saga模式 或 可靠消息最终一致性
- 接口返回统一结构：
{ "code": 200, "data": { ... }, "msg": "success" } - 所有服务接入 Arthas，线上问题秒级诊断
举个真实例子：订单创建需要扣减库存。我们不用分布式事务（性能太差），而是：
- order-service 发送“预占库存”消息到RocketMQ
- stock-service 消费消息，扣库存
- 如果失败，发“回滚”消息
最终一致性虽慢，但稳。双11零点那几分钟，宁可让用户看到“处理中”，也不能让系统崩。
运维视角：微服务上线只是开始
在阿里，开发和运维的界限越来越模糊。我们前端工程师（没错，我虽然是前端，但Node.js + Java混搭项目多的是）也得懂K8s。
我们的微服务部署流程：
- 代码提交 → 触发Jenkins构建Docker镜像
- 镜像推送到ACR（阿里云容器镜像服务）
- Helm Chart 部署到 ACK（阿里云K8s集群）
- Nacos 自动发现新Pod，流量切入
关键配置：Pod的 readinessProbe 必须检查 /actuator/health，否则K8s会把流量打到还没启动完的实例上——这坑我踩过，半夜被叫起来查日志。
写在最后：微服务不是终点，而是起点
从被leader“逼”着学Spring Cloud，到现在能带队搞微服务架构，我最大的感悟是：技术永远服务于业务。
微服务拆得好，能让你在双11从容喝咖啡；拆得烂，就是天天救火、背锅、改简历。
如果你正在准备跳槽，或者被安排重构老系统，记住：
- 先画清楚业务边界，再动代码
- 监控、日志、链路追踪（SkyWalking）必须同步上
- 别追求“高大上”，能跑通、能维护、能扛住流量才是王道
对了，那位周五晚上问我问题的兄弟，昨天告诉我他们服务成功上线了。我回他：“恭喜，现在你可以开始踩新的坑了。” 😏
代码人生，不就是一边填坑，一边造轮子，顺便听听歌、喝杯瑞幸，继续搬砖么？
附：高频面试题清单（来自真实阿里P6/P7面经）
- Spring Cloud 和 Dubbo 的核心区别？
- Nacos 如何实现配置的动态刷新？
- 微服务下如何保证接口幂等性？
- 网关（Gateway）如何做灰度发布？
- 为什么Feign默认用HttpURLConnection而不是OkHttp？
这些问题，下次我们边撸串边聊。
评论 0