Spring Cloud微服务入门：从简历焦虑到深夜撸码实战
凌晨两点，窗外只有路灯和我家猫在盯着我敲键盘。最近远程办公久了，生物钟彻底乱套——但奇怪的是，效率反而比坐班高多了。可能是因为没人突然拍肩膀问“这个需求今天能上线吗？”，也没有产品经理半夜发微信：“我们能不能加个小功能？”（你管这叫小功能？）
说起来，我开始认真搞Spring Cloud，还真跟“简历”有点关系。
去年秋招那会儿，我在某招聘平台更新简历，顺手点了几个大厂的投递按钮。结果HR回复千篇一律：“有Spring Cloud或Service Mesh经验优先”。我当时用的还是单体Spring Boot应用，虽然跑得稳如老狗，但简历上写“精通微服务”总觉得心虚。于是咬咬牙：学！反正晚上睡不着，不如把时间花在刀刃上。
为啥非得上微服务？
我们团队之前维护一个电商业务系统，典型的Spring Boot单体架构。代码量不大，但模块耦合严重——订单模块调库存，库存又依赖用户中心，改个字段要全组人开会。最崩溃的是去年双11压测，数据库连接池直接爆了，运维大哥在群里@全体成员：“谁写的N+1查询？出来挨打！”
领导一拍桌子：“拆！必须微服务化！”
于是，我和两个同事被“委以重任”——其实是背锅侠。
但说实话，微服务不是银弹。如果你的业务还没到百万级DAU，别急着拆。我见过太多团队为了“技术先进性”硬上微服务，结果连日志都没对齐，排查问题靠grep + 祈祷。
不过既然要搞，就得搞明白。
从零搭建：别被“全家桶”吓到
很多人一提Spring Cloud就想到Eureka、Ribbon、Feign、Hystrix、Zuul……一堆组件堆上来，直接劝退。其实现在官方推荐的是 Spring Cloud Alibaba 或 Spring Cloud Netflix OSS（已停更）替代方案，更轻量、国产友好。
我选了 Nacos + OpenFeign + Gateway + Sentinel 这套组合，理由很简单：文档全、社区活跃、阿里背书（简历加分项懂的都懂）。
第一步：注册中心用Nacos，真香
以前用Eureka，配置复杂不说，界面还丑。Nacos不仅支持服务注册发现，还能做配置中心，UI清爽得像Vue3写的。
# bootstrap.yml
spring:
application:
name: order-service
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848
config:
server-addr: 127.0.0.1:8848
file-extension: yaml
启动后，打开 http://localhost:8848/nacos，账号密码都是 nacos，就能看到服务列表。比Eureka那个蓝白界面舒服太多了。
小坑提醒：本地开发时记得关掉Nacos的鉴权（默认开启），不然你会卡在403错误半小时，怀疑人生。
第二步：服务间调用，OpenFeign比RestTemplate优雅
以前写：
ResponseEntity<Order> response = restTemplate.getForEntity("http://user-service/users/123", Order.class);
现在：
@FeignClient(name = "user-service")
public interface UserClient {
@GetMapping("/users/{id}")
User getUserById(@PathVariable("id") Long id);
}
直接注入UserClient，像调本地方法一样调远程服务。配合Spring Retry还能自动重试，再也不用手写try-catch+sleep轮询。
但要注意：Feign默认不支持GET传复杂对象！如果你写了@GetMapping("/search") User search(UserQuery query)，会报错。解决方案要么改POST，要么手动拼URL参数——这种坑我踩过三次，每次都想砸键盘。
第三步：API网关，Gateway比Zuul快得多
Zuul是阻塞IO，性能拉胯。Spring Cloud Gateway基于Netty，非阻塞，吞吐量直接翻倍。而且路由配置超简单：
spring:
cloud:
gateway:
routes:
- id: order_route
uri: lb://order-service
predicates:
- Path=/api/order/**
lb:// 表示走负载均衡，自动从Nacos拉实例列表。配合JWT鉴权、限流、日志打印，一套下来前端只需要对接网关，后端服务完全解耦。
生产环境那些“血泪教训”
你以为本地跑通就完事了？Too young.
1. 分布式事务怎么办？
订单创建要扣库存、发消息、记日志。如果库存服务挂了，订单不能回滚——因为跨服务了！我们最后上了 Seata AT模式，但配置复杂到想哭。后来妥协：关键链路用消息队列+补偿机制，非核心操作异步处理。
建议：除非强一致性要求，否则别一上来就搞分布式事务。先用最终一致性，省心。
2. 日志追踪靠Sleuth + Zipkin
没链路追踪的微服务就像盲人摸象。一次线上慢查询，查了两天才发现是某个Feign调用没设超时，线程全堵住了。
加上Sleuth后，每个请求自动带 traceId，配合ELK或SkyWalking，秒级定位瓶颈：
# application.yml
spring:
sleuth:
sampler:
probability: 1.0 # 采样率100%，生产建议0.1
3. 配置中心别只放配置
Nacos配置中心不仅能存数据库地址、Redis密码，还能动态开关功能！比如：
feature.new-checkout.enabled=true
配合 @RefreshScope，改配置不用重启服务。上周五晚上产品经理突然说“大促前先关掉新支付流程”，我5分钟搞定，他惊了：“你是不是偷偷练了魔法？”
性能与监控：别等线上炸了才看
微服务拆完，接口变多，链路变长，性能反而可能下降。我们做了几件事：
| 优化项 | 工具/方案 | 效果 |
|---|---|---|
| 接口响应 | JMeter压测 + Arthas火焰图 | 找出Feign序列化瓶颈 |
| 数据库 | ShardingSphere分库分表 | QPS提升3倍 |
| 缓存 | Redis + Caffeine二级缓存 | 减少80% DB查询 |
| 熔断降级 | Sentinel规则配置 | 避免雪崩 |
特别提一句Sentinel：比Hystrix好用太多。可以在控制台动态设置QPS阈值、熔断策略，甚至模拟异常。测试同学再也不用求我们“手动制造故障”了。
给想入坑的朋友几点建议
- 别为了微服务而微服务：先问业务是否真的需要。我见过一个内部管理系统也拆成6个服务，结果部署成本比收益高十倍。
- Spring Boot是基础：如果你连Starter、AutoConfiguration、Actuator都不熟，先回去补课。微服务只是Spring Boot的延伸。
- 自动化运维跟上：CI/CD、容器化（Docker + K8s）、健康检查（/actuator/health）缺一不可。否则上线=开盲盒。
- 简历可以写，但要真懂：面试官问“Feign底层怎么实现的？”你答“就是个注解”就完了。至少知道它基于动态代理+Ribbon负载均衡。
现在回头看，折腾Spring Cloud确实值。不仅项目稳了，跳槽时简历上那句“主导微服务架构迁移”也帮我拿下了心仪offer。虽然过程中熬了无数夜，改了无数Bug，甚至和测试妹子吵过架（她说我接口返回500是故意的），但当系统在大促期间扛住流量洪峰时，那种成就感，比喝十杯美式都提神。
所以啊，别怕从零开始。今晚我就打算再重构一个服务，顺便把Sentinel规则配得更精细点——反正猫都陪我到三点了，不写点代码对不起它。
共勉，打工人。
评论 0