五年前我负责的系统还是一个典型的单体应用一个Spring Boot工程打包成War丢进Tomcat数据库是单机MySQL。日活几千一切安好。后来业务爆发日活冲到几十万单体开始扛不住了。我们被迫走上架构演进之路从单体到微服务再到容器化和云原生。这一路踩的坑比读十本架构书都深刻。第一阶段单体拆分微服务——别拆太细单体的第一个瓶颈是数据库连接池频繁耗尽一个慢查询拖垮整个应用。我们决定拆服务按业务域分成用户、订单、商品、支付四个微服务。当时热血上头觉得拆得越细越“架构”。结果拆完第二周就出事了。踩坑记录订单服务调用用户服务查地址用户服务又调用商品服务查库存链路长达五跳。一次网络抖动整个下单流程超时。更麻烦的是分布式事务——订单创建成功库存扣减失败数据不一致。我们花了两个月引入Seata又因为Seata的性能损耗不得不改成最终一致性方案。教训微服务拆分粒度不是越细越好。初期按业务能力粗粒度拆分优先保证核心链路独立非核心功能先放一起。分布式事务能不用就不用用消息队列做最终一致性往往更稳。第二阶段容器化与K8s——配置和资源是两大坑微服务多了部署变成噩梦。我们转向Docker和Kubernetes。容器化本身顺利但上了K8s之后问题才真正开始。踩坑记录一配置管理混乱。每个服务都有application.yml环境变量、数据库密码、第三方密钥散落各处。一次预发环境误用了生产数据库配置差点写入脏数据。后来统一用ConfigMap挂载配置敏感信息走Secret才算规范。踩坑记录二资源限制拍脑袋。给每个Pod设了512Mi内存结果订单服务频繁OOMKilled。排查发现JVM堆默认占了容器内存的1/4但元空间和线程栈没算进去。改成1Gi并显式设置-Xmx后才稳定。另一个坑是健康检查——liveness探针超时设太短服务启动慢时被反复重启陷入死循环。教训容器资源限制必须结合JVM参数一起算健康检查的初始延迟要给足。配置中心不是可选是必选。第三阶段云原生进阶——Service Mesh和Serverless的诱惑服务越来越多服务间通信、熔断、限流、链路追踪都要每个服务自己实现重复劳动严重。我们引入了Istio做Service Mesh。Sidecar注入后流量管理确实省心了但新的坑来了。踩坑记录Istio的Sidecar给每个Pod增加了约50ms延迟对于内部高频调用链路累积延迟非常可观。更头疼的是Sidecar和业务容器生命周期不一致业务容器重启时Sidecar还在导致短暂流量黑洞。后来调整了注入策略只对跨团队调用的服务启用Mesh内部调用保持直连。我们也试过Serverless跑定时任务结果冷启动导致任务延迟十几秒对于时效性要求高的场景完全不可用。教训Service Mesh不是银弹延迟敏感型服务慎用。Serverless适合突发流量和低频任务不适合常驻核心链路。最后的思考从单体到云原生我们走了三年。回头总结三条原则第一架构演进由业务驱动不要为了技术而技术。日活不到十万单体加读写分离足够。第二每一步都要可回退。微服务拆分时保留单体入口容器化时保留物理机部署脚本。第三可观测性先行。没有日志、指标、链路追踪任何架构都是盲人摸象。云原生是方向但不是终点。真正的架构师懂得在合适的时间做合适的演进而不是一步到位。希望这些踩坑记录能让你少走一段弯路。