后端架构演进：从单体到云原生——一个异地程序员的踩坑日记
上周五晚上十一点半，我瘫在出租屋那张吱呀作响的宜家二手沙发上，一边啃着冷掉的黄焖鸡，一边盯着屏幕上 Kubernetes 的报错日志。手机震动了一下，是老婆发来的消息：“今天又加班？明天我坐高铁过来，下午三点到。”我回了个“嗯”，然后盯着聊天窗口发了会儿呆——这是我们这个月第三次见面，她在上海，我在杭州，房租3500，通勤40分钟，月薪22k。而这一切，都始于去年十月那个让我差点崩溃的项目重构。
一、起点：那个被老板拍肩说“信任你”的单体应用
时间倒回2022年10月。那时我刚跳槽进这家做SaaS的企业服务公司，月薪从15k涨到18k（税前），心里美滋滋。入职第三天，技术总监老张把我叫到会议室，拍着我肩膀说：“小李啊，你是Java老手了，我们核心系统‘企服通’就交给你带队重构吧。现在是个单体，但用户量涨太快，扛不住了。”
我嘴上说着“没问题”，心里却直打鼓。那套系统我看过代码——Spring Boot + MyBatis + MySQL，前后端没分离，所有业务逻辑塞在一个jar包里。最要命的是，它已经运行了五年，连单元测试覆盖率都不到10%。更别提什么CI/CD、监控告警了，上线靠手动打包，重启靠ssh登录服务器敲命令。
当时老婆还在杭州陪我，晚上回家还能一起煮个面。她说：“你不是一直想搞点高大上的架构吗？这不就是机会？”我苦笑：“高大上？我怕搞完直接变‘高危’。”
果然，第一次尝试拆分订单模块就翻车了。我把订单服务抽出来单独部署，结果因为数据库连接池配置没调，新服务刚上线三分钟就OOM崩溃。用户投诉电话直接打到CEO办公室。那天晚上我一个人在公司熬到凌晨三点，一边改配置一边啃泡面，心里默念：“老子是不是不适合干架构？”
二、踩坑实录：微服务不是银弹，而是“银坑”
痛定思痛，我和团队决定先补基础。我们做了三件事：
引入Nacos做服务注册发现
结果忘了配健康检查，某个节点挂了，流量还往里打，雪崩了。用Feign做服务调用
超时时间默认1秒，大促期间下游慢，上游全超时，用户看到“系统繁忙”刷屏。拆库拆表
分库键选错了，热点数据全挤在一个分片，CPU飙到90%，DBA差点拿拖鞋抽我。
这些坑，每一个都让我在凌晨两点的钉钉群里被@十几次。有次老婆视频问我：“怎么又黑眼圈了？”我说：“在和分布式事务谈恋爱。”她笑出声：“你谈的怕是虐恋吧。”
最崩溃的是去年12月。我们刚把用户中心、商品中心、订单中心拆成三个微服务，结果因为没统一日志格式，排查一个跨服务的Bug花了整整两天。那天周五，老婆本来要来看我，我临时说“项目上线延期，你别来了”。她在电话那头沉默了几秒，轻声说：“好，那你注意身体。”挂了电话，我坐在工位上，眼眶有点热。
三、转折：云原生不是选择，是生存必需
真正让我下定决心拥抱云原生的，是一次生产事故。
今年3月，杭州暴雨，机房网络抖动。我们的自建Kafka集群因为没做跨可用区部署，消息积压了两百万条。客户数据同步延迟超过6小时，赔偿金差点吃掉我半年奖金。
那天复盘会上，CTO直接拍桌子：“别再自己造轮子了！全部上云，用阿里云ACK + MSE + ARMS，三个月内完成迁移！”
说实话，我当时是抗拒的。总觉得“云原生”是大厂玩具，我们这种百人规模的公司玩不起。但现实狠狠打了脸——自建K8s集群运维成本太高，光是我一个人每周花在节点维护、镜像清理、网络策略调试上的时间就超过15小时。而老婆也在这时候告诉我，她拿到了上海一家外企的offer，薪资比现在高30%，但需要长期驻沪。
“你支持我去吗？”她问。
“当然支持。”我说，“但我可能……没法陪你去了。”
那晚我失眠了。如果继续陷在运维泥潭里，别说考公，连周末见面都成奢侈。我必须找到一条既能提升系统稳定性，又能解放人力的路。
于是，我开始啃官方文档，看极客时间的《云原生训练营》，甚至在B站刷半夜的直播教程。我把所有服务容器化，用Helm管理部署，接入Prometheus+Grafana做监控，错误率从5%降到0.2%。最关键的是，借助云厂商的托管服务，我不再需要半夜爬起来修节点。
四、开发心得：技术不是炫技，是解决问题
现在回头看，从单体到微服务再到云原生，最大的收获不是技术本身，而是心态的转变。
以前我觉得架构师要“设计完美系统”，所以疯狂追求DDD、CQRS、Event Sourcing。结果呢？业务需求三天一变，我的“完美模型”上线两周就过时。
现在我信奉“够用就好，快速验证”。比如最近做权限模块，我没上OAuth2.0整套流程，而是先用JWT+Redis简单实现，跑通再说。等用户量上来再迭代。老婆笑我：“你现在越来越务实了。”我说：“务实才能活下来啊。”
我还总结了几条血泪教训，写在这里，算是给后来人的技术分享：
- 不要为了拆而拆：如果你的QPS不到1000，单体完全够用。微服务带来的复杂度远超收益。
- 可观测性比高可用更重要：先确保你能快速定位问题，再考虑如何避免问题。
- 自动化是生命线：从代码提交到上线，全流程脚本化。我现在的发布流程，一键完成，再也不用求运维大哥。
- Java生态足够强：Spring Cloud Alibaba + Nacos + Sentinel，配合云原生基础设施，中小团队完全能hold住。
对了，最近我在用Java 17 + Spring Boot 3重构核心模块，GraalVM native image编译后启动时间从8秒降到0.3秒。虽然踩了不少反射兼容性的坑，但看到Pod资源占用降了40%，值了。
五、尾声：代码之外，还有生活
写这篇文章的时候，是周日下午四点。老婆刚走，高铁票是她自己买的，说“省得你报销麻烦”。桌上还留着她剥好的橘子，酸甜刚好。
我知道，很多人觉得程序员就该埋头写代码，谈什么感情、生活、考公。但我想说，技术从来不是孤立的。正是因为我想要更多时间陪她，才逼自己学会用云原生解放生产力；正因为我计划明年辞职备考公务员，才更珍惜现在每一行能复用、可维护的代码——毕竟，我不想让接手的人骂我祖宗十八代。
后端架构的演进，本质上是一场“减负”运动。从单体到云原生，不是为了追风口，而是为了让系统更稳、让团队更轻松、让自己有时间抬头看看窗外的阳光。
下周六，老婆又要来杭州。这次我答应她，不带电脑，不去公司，就去西湖边走走。或许路上我会跟她讲讲Service Mesh怎么自动注入sidecar，她大概会翻个白眼说：“你能不能聊点我能听懂的？”
但没关系。至少这一次，我不是在凌晨三点的办公室，而是在有她的周末午后。
最后的小建议：
如果你也在经历架构升级，别怕慢，别怕错。每个大神都曾被NPE支配过，每个架构师都曾在YAML缩进上栽过跟头。重要的是，技术为你所用，而不是你为技术所困。
共勉。
—— 一个准备考公的Java程序员，于杭州出租屋，2024年6月
评论 0