请写一篇关于【Spring Cloud从零开始：微服务入门指南】的技术文章
去年十月，北京的秋天短得让人心慌。我坐在国贸三期楼下一家连锁咖啡馆里，手边放着一杯已经凉透的美式，笔记本屏幕亮着，正对着一个刚拉下来的 Spring Boot 项目模板发呆。那天是周五，晚上八点半，老婆在微信里发来消息：“今天能早点回吗？孩子发烧了。”
我回了个“马上”，但手指却迟迟没动。因为我知道，所谓的“马上”可能又是凌晨一点。而这样的“马上”，在过去三年里，已经变成了常态。
一、三十多岁的老码农，还在一线写代码
我是典型的“高龄”Java程序员——35岁，头发比五年前少了三分之一，腰椎间盘突出比KPI还稳定。目前在一家中型互联网公司做后端开发，月薪22k，房租3500（合租），每月给老家父母打2000，孩子上私立幼儿园学费4800。说不上富裕，但也算不上拮据。只是每次看到招聘网站上“35岁以下优先”的字样，心里总会咯噔一下。
最近，我和老婆认真聊了一次要不要回老家发展的事。她不是催我躺平，而是看我每天回家都像被掏空一样，连陪孩子搭积木的力气都没有。她说：“你在北京，除了工资高点，还有啥？空气差、节奏快、人情冷。” 我一时语塞。确实，除了“技术成长”，我好像也没剩下什么了。
可问题来了——如果回老家，我能做什么？小城市没有微服务架构，没有高并发场景，甚至很多公司还在用 Struts2。我引以为傲的 Spring Cloud 经验，在老家可能连面试官都听不懂。
二、为什么我要重新学一遍 Spring Cloud？
其实我对 Spring Cloud 并不陌生。早在2018年，我就参与过公司从单体架构向微服务拆分的项目。那时候 Eureka 还是主流注册中心，Zuul 做网关，Hystrix 处理熔断。但这些年技术迭代太快，Nacos 取代了 Eureka，Gateway 替代了 Zuul，Sentinel 也慢慢替代了 Hystrix。更别说 Spring Boot 3.x 对 Jakarta EE 的迁移，让我这个老 Javaer 一度怀疑自己是不是落伍了。
上周五晚上，孩子睡着后，我翻出尘封已久的 GitHub 账号，新建了一个 repo，名字就叫 spring-cloud-from-zero。我对自己说：既然不确定未来在哪，那就先把技术底座打牢。不管是在北京还是回老家，代码能力是我唯一能掌控的东西。
三、从零开始，不是从 Hello World 开始
很多人以为微服务入门就是跑通一个注册中心 + 两个服务调用。但真正的“从零开始”，是要理解背后的问题驱动。
场景还原：我们为什么要拆微服务？
2019年，我在上一家公司做电商后台。当时系统还是单体架构，订单、用户、商品全在一个 WAR 包里。大促时，哪怕只是商品模块有 Bug，整个系统都可能雪崩。有一次因为一个慢 SQL，导致数据库连接池耗尽，所有接口超时。老板在会议室拍桌子：“你们就不能把系统拆开？”
于是我们开始搞微服务。但初期踩了很多坑：
- 服务之间怎么发现彼此？→ 引入 Eureka
- 服务挂了怎么办？→ 加 Hystrix 熔断
- 配置怎么统一管理？→ 上 Spring Cloud Config
- 网关怎么路由？→ Zuul 拦截请求
现在回头看，这些组件不是为了“炫技”，而是为了解决真实业务痛点。
实战第一步：用 Nacos 替代 Eureka
我这次搭建的第一个服务是 user-service，用 Spring Boot 3.2 + Spring Cloud 2022.0.3。
// bootstrap.yml
spring:
application:
name: user-service
cloud:
nacos:
discovery:
server-addr: localhost:8848
注意：Spring Boot 3.x 默认不再加载 bootstrap.yml，需要手动引入 spring-cloud-starter-bootstrap。这点坑了我半天，日志里一直报“Nacos is not enabled”。查文档才发现是版本兼容问题。
启动 Nacos（本地用 Docker）：
docker run --name nacos -e MODE=standalone -p 8848:8848 nacos/nacos-server
然后访问 http://localhost:8848/nacos，用户名密码都是 nacos。看到 user-service 注册上来那一刻，我居然有点小激动——就像当年第一次用 System.out.println("Hello World") 一样。
第二步：服务调用，别再用 RestTemplate 了！
早期我们都用 RestTemplate + @LoadBalanced 做服务调用：
@Autowired
private RestTemplate restTemplate;
public User getUser(Long id) {
return restTemplate.getForObject("http://user-service/user/" + id, User.class);
}
但现在，官方推荐用 OpenFeign，声明式接口更简洁：
@FeignClient(name = "user-service")
public interface UserClient {
@GetMapping("/user/{id}")
User getUser(@PathVariable("id") Long id);
}
加上配置：
feign:
client:
config:
default:
connectTimeout: 5000
readTimeout: 5000
这样调用方只需要注入 UserClient，像调本地方法一样调远程服务。这才是微服务该有的体验。
第三步：熔断降级，别等线上炸了才想起
去年我们有个支付服务，依赖第三方接口。某天第三方响应变慢，我们的线程全卡住，最后 Tomcat 线程池耗尽，整个服务不可用。
现在我会在 Feign Client 上加 Sentinel 注解：
@FeignClient(name = "payment-service", fallback = PaymentClientFallback.class)
public interface PaymentClient {
@PostMapping("/pay")
Result pay(@RequestBody PayRequest request);
}
@Component
public class PaymentClientFallback implements PaymentClient {
@Override
public Result pay(PayRequest request) {
// 降级逻辑：返回“支付繁忙，请稍后再试”
return Result.fail("支付服务暂时不可用");
}
}
配合 Sentinel 控制台，还能动态设置熔断规则。技术不是摆设，是保命符。
四、回到现实：技术再强，也挡不住生活的重压
写到这里，已经是凌晨两点。窗外北京的夜很静，只有偶尔驶过的出租车声。我忽然想到，就算我把 Spring Cloud 吃得再透，回老家可能也用不上。小城市的 IT 公司，可能连 Docker 都没普及，更别说服务网格了。
但转念一想：技术的价值，不在于它能不能直接变现，而在于它塑造的思维方式。
微服务教会我的，不是怎么写代码，而是：
- 如何拆解复杂问题（单一职责）
- 如何设计容错机制（熔断、降级）
- 如何做配置隔离（配置中心）
- 如何监控系统健康（Metrics + Logging）
这些能力，哪怕我在老家开个小店做电商 SaaS，也能用上。技术是工具，更是思维模型。
五、给同样迷茫的同行几点建议
如果你也和我一样，30+，在一线写代码，考虑要不要换个活法，我想说：
- 别把技术当成枷锁。Spring Cloud 不是必须掌握的“神技”，它是解决特定规模问题的方案。小项目用单体完全 OK。
- 保持“可迁移能力”。与其死磕某个框架，不如深入理解分布式系统的核心概念：CAP、一致性、幂等性、最终一致性。
- 技术之外，要有 Plan B。我在 GitHub 上开源了一些脚手架项目，也在知乎写技术分享。万一哪天失业，这些积累或许能变成副业。
- 家庭比 KPI 重要。上周我跟老婆说，如果明年春招能找到老家合适的工作，我就回去。她说：“你开心就好。” 那一刻，我觉得值了。
六、代码人生，不止于代码
写这篇《Spring Cloud 从零开始》的初衷，不是教大家怎么配置 Nacos，而是想说：我们这代 Java 程序员，经历了从 SSH 到 Spring Boot 再到云原生的完整周期。我们不是被淘汰的一代，而是承前启后的一代。
无论你选择留在一线城市卷，还是回老家过慢生活，都别忘了：你的价值，从来不只是你写的那几行代码，而是你解决问题的能力、持续学习的韧性，以及对生活的热爱。
技术会过时，框架会淘汰，但“代码人生”四个字，值得我们用一辈子去书写。
最后的小彩蛋：
我把这次从零搭建的 Spring Cloud 项目开源了，地址在 GitHub 搜 spring-cloud-from-zero。里面有完整的 README 和避坑指南。如果你也在学微服务，欢迎 Star & Fork。说不定哪天，我们在老家的咖啡馆偶遇，还能一起聊聊 Nacos 和孩子的奶粉钱。
共勉。
评论 0