我在阿里做Spring Cloud Alibaba生产实践的三年踩坑录

在阿里做交易链路侧三年多，技术栈是Java + Spring Cloud Alibaba全家桶：Nacos做注册中心和配置中心，Sentinel做流量防护，Seata处理分布式事务，RocketMQ做异步解耦。双11峰值QPS几十万的场景真实扛过，踩的坑能写本书。

从Nacos说起，注册中心不是配置中心

Nacos的注册中心和配置中心是两个逻辑独立的模块，数据模型、一致性协议、推送机制完全不同。我们最初把业务配置和注册信息全扔一个Namespace里，有次改配置手滑把服务列表搞乱，一堆实例掉线，正好赶上大促预热。后来学乖了：注册中心和配置中心必须分Namespace，这是铁律。

Nacos 1.x默认AP模式，基于Distro协议；2.x临时实例走AP，持久化实例走Raft。生产环境建议：服务注册用临时实例（AP），配置中心用持久化（CP）。原因：服务注册要高可用，一个节点挂了不能影响整体发现；配置要强一致，不能出现A读到旧值B读到新值。

我们线上Nacos集群3节点，2C4G ECS，跑200多个服务实例。压测时注册中心QPS飙到5000+稳稳接住。坑：Nacos 2.x的gRPC长连接对网络质量敏感，跨机房延迟超50ms会频繁断连重连。我们把集群放同城双机房，客户端连接本机房节点才解决。

Sentinel的坑，比流量控制更坑的是规则持久化

Sentinel默认规则存储是内存态，重启就丢。我们一开始用Dashboard配置规则，有次发布重启所有限流规则全没了，流量打爆下游，P0事故。

后来接入Nacos做持久化：

spring:
  cloud:
    sentinel:
      datasource:
        flow:
          nacos:
            server-addr: nacos-headless:8848
            dataId: ${spring.application.name}-flow-rules
            groupId: SENTINEL_GROUP
            rule-type: flow

细节：rule-type要写对，flow是流控，degrade是熔断，system是系统规则。写错不报错但规则不生效。

生产案例：去年双11营销服务被瞬时流量打挂，Tomcat默认200线程，每请求300ms，理论上限也就600多QPS，限流阈值却设5000，等于没设。后来改成线程池隔离+信号量熔断，阈值按实际容量来。限流阈值必须基于压测数据，拍脑袋设的值要么形同虚设要么误杀流量。

Seata，分布式事务的"能用就行"

只在订单创建和库存扣减用了AT模式。AT模式侵入小，但性能损耗明显，RT增加30-50%。有次大促订单服务因Seata全局锁等待超时大量回滚，查日志是库存服务某SQL没走索引导致行锁升级表锁，全局锁等不到。加联合索引后解决。

建议：能用最终一致性解决的场景别上Seata。消息队列+本地消息表或RocketMQ事务消息更轻量。真正需要强一致再用，且必须关注SQL执行效率和锁粒度。

网关层的选择与折腾

网关用Spring Cloud Gateway，注册到Nacos做动态路由。事故：有次上线新服务，路由Path写了/**，把所有流量导到新服务，线上雪崩。凌晨一点被叫起来回滚。从此网关路由变更必须走审批，Path匹配必须精确到具体前缀。

Gateway性能一般，压测单实例QPS约8000（4C8G），比Nginx差远。生产上Nginx做第一层扛静态资源和简单转发，Gateway做第二层处理动态路由和鉴权。

关于GPT-4和Java开发的几句闲话

GPT-4写Spring Cloud Alibaba的配置文件和模板代码质量不错，但涉及生产调优和故障排查就露怯，给的答案偏教科书式。比如问"Nacos 2.x为什么频繁断连"，它列一堆可能原因，真正原因——跨机房网络延迟——是我自己抓包分析出来的。GPT-4能帮你写代码，但不能帮你扛事故。生产经验还得自己踩坑。

写在最后

三年多从踩坑到填坑，挺有成就感。Nacos、Sentinel这些组件背后的设计理念才是真正值得深入理解的。想入行的兄弟别光背八股文，搭个demo把Nacos、Sentinel、Gateway串起来，遇到问题自己查日志解决，比刷一百道面试题都有用。