被Nacos整崩溃后，我写下了这份Spring Cloud Alibaba生产避坑指南

上周五晚上十点半，我又一次坐在工位上，盯着日志里那条“Service provider list is empty”的报错发呆。窗外深圳湾的夜景一如既往地璀璨，但我心里只剩下一个念头：这破微服务注册中心又双叒叕挂了？

说来惭愧，作为一个在腾讯系大厂摸爬滚打四年的老Java人，去年跳槽到一家创业公司后，第一次独立负责整个微服务架构的搭建，就栽在了Spring Cloud Alibaba上。当时老板拍着我肩膀说：“小张啊，你简历上写的可是‘精通微服务架构’，这个新项目就交给你了。” 我嘴上答应得爽快，心里却慌得一批——毕竟之前在大厂都是用现成的内部框架，哪需要自己从零搭一套？

不过话说回来，也正是这次“被赶鸭子上架”的经历，让我真正沉下心去研究Spring Cloud Alibaba的底层原理。辞职休息这段时间，我翻遍了Nacos、Sentinel的源码，甚至把Seata的分布式事务实现都啃了一遍。今天就来聊聊我在生产环境中踩过的那些坑，希望能帮到正在看这篇文章的你。

从“Hello World”到生产事故：我的血泪史

项目初期，为了快速上线，我们直接用了Spring Cloud Alibaba的默认配置。本地跑得飞起，测试环境也没问题，结果一上生产，各种诡异问题接踵而至。

第一个坑：Nacos服务发现延迟

用户反馈下单接口偶尔超时，查了半天发现是服务调用方获取不到最新的服务提供者列表。原来Nacos客户端默认的健康检查间隔是5秒，但在高并发场景下，这个延迟足以让大量请求打到已经下线的实例上。

# application.yml - 错误示范（生产环境千万别这么配）
spring:
  cloud:
    nacos:
      discovery:
        server-addr: ${NACOS_SERVER_ADDR:localhost:8848}
        # 默认配置，生产环境容易出问题

正确的做法是调整Nacos客户端的轮询间隔和超时时间：

# application.yml - 生产环境推荐配置
spring:
  cloud:
    nacos:
      discovery:
        server-addr: ${NACOS_SERVER_ADDR:localhost:8848}
        # 关键配置：缩短服务列表更新间隔
        watch-delay: 1000  # 1秒轮询一次
        # 健康检查相关配置
        ip-delete-timeout: 30000  # 实例删除超时30秒
        heart-beat-interval: 5000  # 心跳间隔5秒
        heart-beat-timeout: 15000  # 心跳超时15秒

第二个坑：Sentinel规则丢失

更离谱的是，某天凌晨三点被运维叫醒，说限流规则突然失效了。查了半天才发现，Sentinel默认是内存模式，服务重启后所有规则都没了！这在大促期间简直是灾难。

解决方案很简单但容易被忽略：必须配置持久化。我们最终选择了Nacos作为规则存储：

@Configuration
public class SentinelConfig {
    
    @PostConstruct
    public void initFlowRules() {
        // 从Nacos读取流控规则
        ReadableDataSource<String, List<FlowRule>> flowRuleDataSource = 
            new NacosDataSource<>("${nacos.server-addr}", "SENTINEL_GROUP", 
                "flow-rules", source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {}));
        
        FlowRuleManager.register2Property(flowRuleDataSource.getProperty());
    }
}

真正的生产级配置长什么样？

经过几次线上事故的洗礼，我总结了一套相对稳定的生产配置方案。下面分享几个关键组件的配置要点：

Nacos高可用部署

千万不要用单机版Nacos跑生产！我们采用的是Nacos集群+MySQL持久化模式：

配置项	开发环境	生产环境
部署模式	单机	集群(3节点)
存储方式	Derby	MySQL 8.0
JVM参数	默认	-Xms4g -Xmx4g -XX:+UseG1GC
网络策略	开放所有端口	只开放8848,9848,9849

启动脚本也很关键，要确保集群节点间能正常通信：

# startup.sh 生产环境启动参数
nohup bin/startup.sh -m cluster \
  -Dnacos.core.auth.enabled=true \
  -Dnacos.security.ignore.urls="/actuator/**" \
  > logs/nacos.log 2>&1 &

Feign + Ribbon的性能调优

早期我们遇到Feign调用超时的问题，后来发现是Ribbon的默认超时设置太保守：

# feign配置优化
feign:
  client:
    config:
      default:
        connectTimeout: 3000    # 连接超时3秒
        readTimeout: 10000      # 读取超时10秒
  # 启用Hystrix熔断（可选）
  hystrix:
    enabled: true

# ribbon负载均衡优化
ribbon:
  ConnectTimeout: 3000
  ReadTimeout: 10000
  # 关键：启用重试机制
  MaxAutoRetries: 1
  MaxAutoRetriesNextServer: 2
  OkToRetryOnAllOperations: false

Seata分布式事务的坑

说到Seata，那真是让我欲哭无泪。最初用AT模式，结果发现对业务代码侵入性太大，而且性能损耗严重。后来改用Saga模式，但Saga的补偿逻辑写起来简直反人类。

最终我们采用了混合模式：核心交易用TCC，非核心业务用最终一致性：

// TCC模式示例
@LocalTCC
public interface OrderTccService {
    
    @TwoPhaseBusinessAction(name = "createOrder", commitMethod = "commit", rollbackMethod = "rollback")
    boolean createOrder(BusinessActionContext actionContext, OrderRequest request);
    
    boolean commit(BusinessActionContext actionContext);
    
    boolean rollback(BusinessActionContext actionContext);
}

监控告警：别等用户投诉才发现问题

在大厂的时候，监控体系都是现成的，到了创业公司才发现监控有多重要。我们搭建了完整的Spring Cloud Alibaba监控体系：

1. Nacos服务健康检查：通过Prometheus + Grafana监控服务注册状态
2. Sentinel实时监控：自建Dashboard，关键接口QPS、RT、异常率一目了然
3. 链路追踪：集成SkyWalking，快速定位性能瓶颈

特别要提的是Nacos的服务健康度监控，我们写了个简单的健康检查脚本：

#!/bin/bash
# check-nacos-services.sh
NACOS_ADDR="http://nacos-prod:8848"
SERVICES=("order-service" "user-service" "payment-service")

for service in "${SERVICES[@]}"; do
    COUNT=$(curl -s "$NACOS_ADDR/nacos/v1/ns/instance/list?serviceName=$service" | jq '.hosts | length')
    if [ "$COUNT" -eq 0 ]; then
        echo "ALERT: $service has no healthy instances!"
        # 发送企业微信告警
        curl -X POST "https://qyapi.weixin.qq.com/..." -d "{\"content\":\"$service down!\"}"
    fi
done

代码人生：从API搬运工到架构思考者

说实话，刚工作那会儿，我觉得能把需求做完就行，什么高可用、什么性能优化，都是架构师该操心的事。直到经历了那次双11大促，系统崩了，用户投诉如潮，我才意识到：每一个Java程序员都应该对自己写的每一行代码负责。

现在回头看我的简历，从“熟悉Spring Boot”到“主导微服务架构设计”，变化的不仅是技术栈，更是思维方式。Spring Cloud Alibaba不是银弹，它解决了很多问题，但也带来了新的复杂性。真正的高手不是会用多少框架，而是知道在什么场景下用什么技术，以及如何优雅地处理技术债。

给正在踩坑的你一些建议

1. 不要迷信默认配置：生产环境的网络环境、硬件资源都和本地不同，一定要根据实际情况调优
2. 做好降级预案：当Nacos挂了怎么办？当Sentinel规则丢失怎么办？这些都要提前想好
3. 重视监控告警：没有监控的系统就像没有仪表盘的飞机，迟早要出事
4. 学习源码：遇到问题不要只会Google，去看Nacos、Sentinel的源码，你会发现很多配置项的真正含义

最后说个题外话，最近在考虑要不要重新找工作。投了几份简历，发现很多JD都写着“要求精通Spring Cloud Alibaba”，但面试官问的问题却停留在“Nacos是什么”这种层面。有时候我在想，到底是技术真的重要，还是简历上的关键词重要？

不过无论如何，这段从零搭建Spring Cloud Alibaba架构的经历，让我对微服务有了更深的理解。即使将来不用这套技术栈，这些底层原理的思考也会让我受益终身。

对了，如果你也在用Spring Cloud Alibaba，欢迎在评论区交流踩坑经验。毕竟在这个行业，独行快，众行远嘛！

---

P.S. 写完这篇文章已经是凌晨两点了，深圳的夜还是那么亮。想起当年在科技园加班的日子，虽然累，但那种解决问题后的成就感，真的很爽。希望每个在代码世界里奋斗的你，都能找到属于自己的那份快乐。