去年帮一家做SaaS工具的公司查故障，系统跑着跑着就卡死，日志里满屏报错，排查三天才发现——他们把所有服务都堆在一台物理机上，连数据库和消息队列都挤在同一个Docker容器里启动。这不是性能问题，是生态还没搭起来就先把自己绕进去了。
别把“集成”当“粘合”
见过太多团队拿着API文档一顿猛连，A调B、B调C、C再回调A，最后形成环形依赖。某次线上支付失败，追踪链路发现：订单服务→风控服务→用户画像服务→订单服务……兜了一圈，超时直接熔断。生态不是靠接口数量堆出来的，而是靠边界感养出来的。每个模块得清楚自己管什么、不碰什么，比如风控服务不该去读订单表，用户画像也不该写入交易流水。
配置漂移比代码出错更难查
开发环境用Redis集群，测试环境换成了单节点，上线又切回集群但忘了改连接池大小——结果压测时连接数暴涨，下游MySQL直接被拖垮。配置散落在yaml、环境变量、Consul、甚至硬编码在Java类里，改一处漏三处。建议统一入口管理，比如用Spring Cloud Config或Nacos，每次发布前跑个脚本比对关键配置项：
curl -s http://config-server:8888/app/prod | jq '.redis.max-active'日志不是越多越好，是得能串得起来
有团队每行日志都打TraceID，但上下游服务用的不是同一套生成逻辑，TraceID在网关一过就变样。查问题时看着一串ID，实际根本串不起来。不如老老实实统一用OpenTelemetry SDK，在HTTP Header里透传traceparent字段，网关、服务、MQ消费者都按规范解析。别自己造UUID拼接，也别用时间戳+进程号这种容易重复的土办法。
依赖升级不是版本号越大越稳
Kafka从2.8升到3.5，Consumer Group重平衡策略变了，原来用auto.offset.reset=earliest扛住重启的服务，突然开始重复消费。升级前没看变更日志，也没在预发环境跑够72小时真实流量。现在他们的做法是：新版本先上灰度集群，只接1%订单流量，同时用Flink实时比对新旧集群的消费位点和消息体MD5，偏差超0.01%就自动告警。
监控不能只盯CPU和响应时间
有个电商后台，CPU常年不到30%，但用户投诉“下单慢”。最后发现是Elasticsearch的bulk队列积压了两万条，而监控只报了ES节点健康状态绿，没设bulk reject rate告警。后来加了这条PromQL：
rate(elasticsearch_thread_pool_rejected_total{thread_pool="bulk"}[5m]) > 0.1