Spring Cloud Alibaba 生产实践：一个上海自由开发者的踩坑实录
大家好，我是阿哲，一个在上海浦东和女朋友合租、靠远程办公混饭吃的自由开发者。坐标张江，房租3500（合租次卧），去年十月正式从某二线大厂裸辞，现在接外包+做技术顾问，收入不稳定但自由——上个月刚入账18k，这个月可能就只有9k（笑）。不过能穿着拖鞋写代码、午休顺便给猫铲屎的日子，真的香。
今天想和大家唠点硬核的：Spring Cloud Alibaba 在生产环境的真实使用体验。不是官方文档复读机，也不是“Hello World”式教程，而是我在给一家跨境电商客户做微服务重构时，血泪交织、半夜三点还在改 Nacos 配置的实战心得。
一切始于那个周五晚上的钉钉消息
事情得从去年12月说起。那天是周五，我正和女朋友在盒马买打折牛排（程序员浪漫：满99减20），手机突然震动——是老东家前同事老李发来的私信：
“阿哲，在忙吗？有个急活儿，客户系统快崩了，微服务注册中心用 Eureka，但节点一多就假死，老板急得要砍人……听说你现在搞云原生很溜？”
我内心OS：溜个锤子，我也就是 GitHub 上 star 了几百个仓库、本地 clone 了几十个 demo 而已。但转念一想，这单要是接下来，至少能cover两个月房租+猫粮钱。于是故作镇定回复：“问题不大，下周聊聊？”
结果第二天周六早上九点，我就坐在电脑前，一边喝着瑞幸9.9的拿铁，一边看他们系统的架构图——典型的 Spring Cloud Netflix 套件：Eureka + Ribbon + Hystrix + Zuul。看着那密密麻麻的服务调用线，我头皮发麻。
“这架构，2018年还行，2023年还在用？Hystrix 都停更三年了啊！”我心里嘀咕。
技术选型：为什么最终选了 Spring Cloud Alibaba？
客户明确要求：不能大改业务逻辑，但必须提升稳定性，最好还能降本。老板原话是：“服务器别再动不动就报警，AWS 账单太高了。”
于是我和老李开了个腾讯会议，拉上他们的运维小哥，开始技术选型对比。我们列了张表：
| 组件 | Spring Cloud Netflix | Spring Cloud Alibaba | Go 微服务方案 |
|---|---|---|---|
| 注册中心 | Eureka（需自维护） | Nacos（支持 AP/CP 切换） | etcd / Consul |
| 配置中心 | Config Server + Git | Nacos（配置+注册一体） | Viper + etcd |
| 熔断限流 | Hystrix（已停更） | Sentinel（实时监控+规则热更新） | go-kit / resilience4go |
| 网关 | Zuul（性能一般） | Spring Cloud Gateway + Sentinel | Kong / Traefik |
| 学习成本 | 团队熟悉 | Java 团队平滑迁移 | 需重学 Go 生态 |
| 运维复杂度 | 高（多组件） | 中（Nacos 一栈式） | 中（但需新部署体系） |
关键分歧点来了：要不要趁机切 Go？
老李眼睛一亮：“Go 性能好、内存省，说不定真能降本！”
我沉默了三秒，然后说：“兄弟，你们后端全是 Java 五年经验的老兵，连 lambda 表达式都用不熟，现在让他们两周内上线 Go 服务？怕不是想让老板提前过年。”
其实我心里也动摇过。我自己私下用 Go 写过几个小工具，goroutine 和 channel 确实用着爽，部署也轻量。GitHub 上搜 microservice golang，star 几万的项目一堆。但——技术选型不是比谁酷，而是看团队能不能跑起来。
最后我们拍板：用 Spring Cloud Alibaba 平滑替换 Netflix 套件。理由很现实：
- 团队 Java 技术栈深厚
- Nacos 同时解决注册+配置，减少运维负担
- Sentinel 的控制台比 Hystrix Dashboard 好用十倍
- 阿里云有商业支持（虽然我们没买）
生产踩坑实录：Nacos 不是银弹
方案定了，接下来就是地狱模式。
坑一：Nacos 集群部署翻车
我们一开始用 Docker Compose 搭了个三节点 Nacos 集群，结果服务一多，CPU 直接飙到 90%。查了半天才发现，Nacos 默认用内嵌数据库 Derby，根本不适合生产！
赶紧切到 MySQL + 外部存储。但 MySQL 版本又有坑——Nacos 2.x 要求 MySQL 5.7+，而客户线上还是 5.6。升级数据库？运维直接拒绝：“出问题你背锅？”
最后妥协：先单机 Nacos + 外部 MySQL 5.7（新起一台 RDS，月付 200+），等业务稳定再集群化。技术理想很丰满，现实预算很骨感。
坑二：Sentinel 规则不生效
配置了 QPS=50 的限流规则，结果压测时照样被打爆。查日志发现，Sentinel 的规则默认只在内存中，重启就丢！
赶紧接入 Nacos 动态规则持久化。但文档写得含糊，试了三种方式才成功：
- 控制台推送到 Nacos（手动，不推荐）
- 应用启动时从 Nacos 读取（静态）
- 通过 DataSource 与 Nacos 双向同步（最终方案）
那一刻我真想给阿里开源团队寄锦旗——功能强大，但文档能不能再友好点？GitHub issues 里一堆人问同样问题。
坑三：Gateway + Sentinel 的链路追踪失效
我们用了 Sleuth + Zipkin 做链路追踪，但接入 Gateway 后，traceId 断了。折腾两天才发现，Spring Cloud Gateway 是基于 Reactor 的，而 Sleuth 对 WebFlux 支持需要额外依赖。
加上这段 Maven 才搞定：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-reactor</artifactId>
</dependency>
这种细节，不踩一遍根本不知道。
开发心得：自由职业者的“多面手”生存法则
这次项目让我深刻体会到：作为自由开发者，你不能只会写代码。
- 要懂运维：自己搭 Nacos、调 JVM 参数、看 Grafana 监控
- 要会沟通：和客户解释“为什么不能直接切 Go”，用他们听得懂的话讲技术债
- 要能兜底：凌晨两点收到告警，爬起来查日志是常态
上周五晚上，女朋友问我：“你天天对着屏幕敲，到底在干啥？”
我说：“在给一个叫‘Nacos’的东西擦屁股。”
她翻了个白眼：“不如去送外卖，至少能见太阳。”
我笑了笑，没说话。但心里清楚：这份自由，是用无数个深夜 debug 换来的。
关于 Go 的一点私心话
虽然这次没用 Go，但我依然觉得它是未来。最近我在 GitHub 上 star 了一个叫 go-zero 的框架，国产、高性能、自带熔断限流，文档还特别全。我甚至偷偷用它重写了自己博客的 API 层，QPS 从 200 提升到 3000+，内存占用不到 Java 的 1/5。
但回到现实：技术选型不是个人秀，而是团队协作的产物。如果你的团队还没准备好，强行上 Go，可能换来的是延期、bug 和信任崩塌。
我的建议是：核心系统稳用 Java + Spring Cloud Alibaba，边缘服务试试 Go。比如日志收集、文件处理这类 I/O 密集型任务，Go 真的香。
总结：没有最好的技术，只有最合适的解法
回顾这次 Spring Cloud Alibaba 的生产实践，我最大的感悟是：
架构不是炫技场，而是解决问题的工具箱。
Nacos 好用吗？好用，但要配对数据库。
Sentinel 强大吗？强大，但要配对持久化。
Spring Cloud Alibaba 成熟吗？成熟，但文档和社区仍需努力。
作为一线开发者，我们既要拥抱新工具，也要保持清醒：技术永远服务于业务，而不是反过来。
如果你也在考虑微服务架构选型，我的建议很朴素：
- 先评估团队技术栈，别盲目追新
- 小范围试点，别一上来就全量切换
- 做好监控和回滚预案，别信“一次成功”
- 多看 GitHub issues，少信官方示例
最后：关于自由，和未来
写完这篇文章时，已经是凌晨一点。窗外浦东的灯火依旧明亮，楼下便利店还亮着灯。我看了眼本月收入——16k，勉强够生活。但想到下个月可能接一个用 Go 重构数据管道的项目，又有点小期待。
技术这条路，没有标准答案。有人在大厂卷 P8，有人在小城做全栈，有人像我一样，在出租屋里一边调试 Nacos，一边想着明天早餐吃什么。
但只要代码还能跑，梦想就还没崩。
共勉。
—— 阿哲，于上海浦东，2024年4月
评论 0