十年前一个WAR包打天下Tomcat一挂全站瘫痪。运维半夜爬起来重启开发在群里刷“好了吗”。那是单体架构的黄金年代也是它的黄昏。业务在长代码在腐部署在慢团队在等。单体不是错错的是让业务等架构。从单体到云原生这条路我们走了五年摔过跤也见过光。单体之困改一行而动全身最初的应用很纯粹一个工程一个数据库一台服务器。用户、订单、支付、库存全挤在一个进程里。改个字段要重新编译整个项目加个功能要全量回归测试。最怕大促流量一冲数据库连接池先崩接着线程池满最后整个应用雪崩。加机器可以但单体像一头大象喂再多草也跑不过猎豹。当部署频率从每周降到每月架构就已经在拖业务的后腿。我们决定拆不是为了时髦是为了让每个模块能独立呼吸。微服务边界比拆分更重要拆的第一刀砍在用户、订单、商品三个模块之间。各自建库各自部署HTTP通信。Spring Boot重写接口从内部调用变成远程调用。坑随之而来分布式事务、数据一致性、服务发现、链路追踪。微服务不是把单体切碎而是把边界划清。边界不清拆完只是把单体从一个大泥球变成一堆小泥球。我们花了三个月才让第一个服务稳定但回报是订单扩容不再拖累用户发布从每月一次变成每周两次。代价是复杂度指数上升没有可观测性拆得越细死得越快。容器与K8s交付方式的革命服务多了部署成了噩梦。十台虚拟机环境参差手工上线常出错。Docker来了镜像把环境打包终于一致。Kubernetes来了自动调度、滚动更新、健康检查运维从“人肉脚本”变成“声明式编排”。容器解决了一致性编排解决了规模。但学习曲线陡峭YAML缩进错一格排查两小时。记得第一次上K8s一个ConfigMap没挂对服务起不来全组熬到凌晨。技术栈升级的每一步都是对耐心的极限施压。云原生不止于技术更是文化如今我们用Spring Cloud K8s Istio服务三十多个日均调用百万。但云原生不是堆技术。它意味着不可变基础设施、声明式API、弹性伸缩、故障自愈。云原生的核心不是容器而是让架构适应变化而非让变化适应架构。它要求团队接受失败是常态用混沌工程验证韧性用可观测性代替猜测用自动化代替人肉。没有这种文化再多的K8s也只是昂贵的玩具。没有银弹只有权衡布鲁克斯说“没有银弹。”云原生也不是。小团队、简单业务单体反而高效。我们上云是因为业务复杂到必须分而治之。架构演进不是目的解决业务问题才是。从单体到云原生我学到的不是某个框架而是对边界的敬畏、对复杂性的克制、对演进的耐心。合久必分分久必合架构的钟摆永远在寻找平衡。路还长下一站也许是Serverless也许是回归模块化单体。但只要业务在跑演进就不会停。