Spring Cloud Alibaba 生产实践：裸辞半年后，我靠它重回战场
去年10月，我从某一线大厂“优雅”裸辞。
原因？连续三个季度OKR被砍一半、晨会站成“汇报机器人”、以及产品经理在凌晨2点发来的那句：“这个需求很简单，明天上线就行。”
Gap的前两个月还挺爽，每天喝咖啡、刷LeetCode、用Claude写Python脚本自动抓GitHub Trending项目。但到了第三个月，银行卡余额开始疯狂提醒我：“兄弟，该找工作了。”
于是，我一边投简历，一边恶补技术栈——尤其是Spring Cloud Alibaba（SCA）。毕竟现在国内微服务架构面试题里，不提Nacos、Sentinel、Seata，都不好意思说自己做过分布式系统。结果还真有家公司面到第三轮时问我：“你们上一家怎么用SCA做高可用降级的？” 我差点当场表演一个原地蒸发。
痛定思痛，我决定把这半年复健+新工作实战中踩过的坑、调过的参、熬过的夜，全盘托出。这篇文章，既是给自己的复盘，也是给正在备战“微服务面试题挑战”的兄弟们一份避雷指南。
为啥是 Spring Cloud Alibaba？
我们新公司（坐标上海张江，租房就在公司对面，通勤5分钟，感动哭）是个做跨境电商SaaS平台的。去年双11前，老架构扛不住流量洪峰，直接崩了三次。老板一拍桌子：“重构！上微服务！用国产方案！”
于是技术总监直接拍板：Spring Cloud + Alibaba全家桶。理由很现实：
- Nacos替代Eureka + Config，服务发现+配置中心二合一
- Sentinel做熔断限流，比Hystrix更细粒度
- Seata搞定分布式事务，省得天天和DBA吵架
- 全部开源，GitHub Star数够高（Nacos都38k+了），社区活跃
说实话，一开始我是拒绝的。毕竟之前在大厂用的是自研中间件，文档全靠口口相传，源码藏得比女朋友的心还深。但转念一想：SCA现在几乎是国内微服务的事实标准，学它=多拿几个offer筹码。果断开干。
实战踩坑实录：从“Hello World”到线上炸服
坑1：Nacos 配置中心“看似简单，实则玄学”
本地跑Demo时，bootstrap.yml 配一配，@RefreshScope 一加，热更新妥妥的。但一上生产环境，问题就来了：
- 配置不生效：原因是Nacos client默认走内网地址，但我们K8s集群网络策略限制了Pod访问方式
- 配置覆盖混乱：
application.yml和 Nacos 配置同名key冲突，优先级搞反了
解决方案？强制约定配置加载顺序：
# bootstrap.yml
spring:
application:
name: order-service
cloud:
nacos:
config:
server-addr: ${NACOS_HOST:localhost}:${NACOS_PORT:8848}
file-extension: yaml
namespace: prod # 关键！按环境隔离
group: DEFAULT_GROUP
并且在启动脚本里明确指定 --spring.profiles.active=prod，避免本地开发配置污染生产。
吐槽一句：测试同学上周五晚上还在群里@我：“你改的超时时间怎么没生效？” 我一看，他连namespace都没切… 这锅我不背！
坑2：Sentinel 流控规则“纸上谈兵 vs 现实毒打”
面试题挑战最爱问：“Sentinel和Hystrix区别是啥？”
答：“Sentinel支持QPS/线程数/系统负载多维度流控，还能动态规则推送。”
但真上生产才发现：默认控制台规则是存在内存里的！重启就丢！
我们第一次压测完，运维重启了服务，结果限流规则没了，瞬间被打穿。当时真的想砸键盘。
后来赶紧接入Nacos持久化规则。步骤其实不难：
- 在Sentinel控制台配置规则时，勾选“推送到Nacos”
- 服务端引入
sentinel-datasource-nacos依赖 - 配置数据源指向Nacos对应group和dataId
@PostConstruct
public void initFlowRules() {
ReadableDataSource<String, List<FlowRule>> dataSource = new NacosDataSource<>(...,
"SENTINEL_GROUP", "order-service-flow-rules", source -> JSON.parseObject(source, ...));
FlowRuleManager.register2Property(dataSource.getProperty());
}
从此，规则跟着配置走，再也不怕服务重启“失忆”。
性能与架构设计：别让微服务变成“微灾难”
很多人以为上了SCA就万事大吉，其实架构设计才是命门。
数据库层面：Seata 的 AT 模式不是万能药
我们订单服务要同时扣库存、记账、发MQ。一开始直接上Seata AT模式，结果TPS从800掉到200。查了半天，发现全局锁竞争太严重——每个分支事务都要等全局锁释放。
后来做了两件事：
- 非核心操作异步化：发通知、埋点日志扔到MQ，不参与事务
- 关键路径拆分：库存和账务拆成两个独立服务，用最终一致性+对账补偿
| 方案 | TPS | 事务成功率 | 复杂度 |
|---|---|---|---|
| Seata AT 全链路 | 200 | 99.2% | 低 |
| 核心同步 + 异步补偿 | 750 | 99.95% | 中 |
结论：分布式事务能不用就不用，能少用就少用。Seata适合强一致场景（比如支付），但别滥用。
接口设计：别让Feign变成“慢请求放大器”
早期服务间调用全用Feign，结果一个下游慢，上游全卡住。尤其在促销期间，用户下单接口因为风控服务慢，直接拖垮整个链路。
后来统一规范：
- 所有Feign调用必须配 超时 + 重试
- 非关键依赖走 异步 or 降级
# feign配置
feign:
client:
config:
default:
connectTimeout: 500
readTimeout: 1000
retryer:
enabled: true
再配合Sentinel对Feign接口做线程隔离，终于把雪崩风险压下去了。
运维经验：生产环境不是你家后花园
最后分享几个血泪教训：
- Nacos集群必须3节点起：单机Nacos在我们预发环境挂过两次，一次是磁盘满，一次是OOM。现在生产全是3节点+Prometheus监控。
- Sentinel控制台要独立部署：别和业务服务混一起，否则服务挂了，你连看规则的地方都没了。
- 日志必须带 traceId：我们用SkyWalking + MDC，排查跨服务问题效率提升80%。没有traceId的日子，就像在黑暗森林里找Bug。
写在最后：技术人的“Gap期”不是空白期
这半年裸辞，有人说是“职业空窗”，但我觉得是战略蓄力期。
用GitHub追踪SCA最新Release，用Python写自动化部署脚本，甚至用Claude帮我理解Seata的AT模式源码——这些都不是浪费时间。
现在新工作虽然也有Deadline暴击、也有产品经理半夜改需求，但至少技术栈是我主动选择的，团队氛围也够open。上周刚用SCA优化完订单链路，TPS稳在900+，老板请全组吃了顿火锅（虽然是公司楼下38元自助）。
如果你也在Gap、在焦虑、在准备下一场面试题挑战——别慌。
真正的实战经验，从来不在PPT里，而在你解决过的每一个线上Bug、熬过的每一个深夜、和最终跑通的每一行代码里。
对了，我在GitHub建了个仓库 spring-cloud-alibaba-in-action，放了所有生产级配置模板和避坑清单。Star不求多，但求别再有人踩我踩过的坑。
共勉。
评论 0