从小厂到大厂：技术人转型进阶指南之三

第 3 章 林默的第一次代码翻车：SSM 架构遇上云原生

林默入职 Z 厂后端团队的第二周，就迎来了职业生涯的 “大型社死现场”—— 他提交的支付模块代码，在团队代码评审（CR）会上被导师老周问得哑口无言。

“林默，你这数据库连接池为什么用单例模式？” 老周的鼠标停在代码截图上，语气平静却带着穿透力，“咱们现在是分布式部署，每个 Pod 里都跑一个单例，会导致连接池耗尽你知道吗？”

林默的脸瞬间涨成了番茄色，手指下意识攥紧了笔记本。他在小厂写了三年 SSM 架构代码，单例模式是 “减少对象创建、节省资源” 的 “最优解”，从来没人质疑过。“我…… 我以前在小厂都是这么写的，业务量小，没遇到过连接池问题。” 他声音发紧，不敢看会议室里其他同事的眼神。

老周没停，继续抛出问题：“那你考虑过熔断降级吗？如果数据库突然宕机，你的代码会直接把整个支付服务拖垮，怎么处理？”

“熔断降级？” 林默脑子一片空白 —— 这个词他只在技术文章里见过，小厂的单体应用从来没做过容错设计，出了问题最多重启服务，哪需要这么复杂的逻辑？

更让他无地自容的还在后面。老周翻到代码末尾：“单元测试呢？你这几百行代码，测试覆盖率连 10% 都不到，怎么保证上线后没问题？”

林默的头埋得更低了。小厂的开发节奏里，“功能跑通” 就是终点，单元测试是 “可有可无的额外工作”，他入职三年，写过的测试用例加起来不超过 10 个。“我…… 我以为先把功能实现了，后续再补测试也行。”

“在 Z 厂，没有测试的代码不能进主干。” 老周关掉截图，语气严肃了些，“小厂可能‘能用就行’，但咱们服务要支撑日均千万级交易，每一行代码都得扛住故障、经得住测试 —— 这不是‘额外要求’，是底线。”

CR 会结束后，林默坐在工位上，盯着屏幕上的代码发呆。他打开公司内部文档库，翻到 “分布式架构设计规范”，里面密密麻麻写着 “服务容错”“限流降级”“单元测试覆盖率≥80%” 的要求，突然觉得自己像个 “门外汉”—— 小厂那套 “SSM 三件套走天下” 的经验，在 Z 厂的云原生技术栈面前，真的像老周说的那样，“跟玩具没区别”。

当晚，林默在工位上待到了凌晨。他把老周提的问题列成清单，一条一条查资料：单例模式不适合分布式，就换成 Spring Cloud Alibaba 的动态数据源；没做熔断降级，就集成 Sentinel 配置流控规则；单元测试不够，就对着 Junit 文档，一行行补测试用例。凌晨两点，他终于修改完代码，重新提交 CR 时，手还在微微发抖 —— 这一次，他不仅改了代码，更第一次意识到：大厂的 “代码质量”，从来不是 “写对逻辑” 这么简单，而是 “在复杂场景下，把风险堵在上线前”。

第 4 章 深夜重构血泪史：从 SpringBoot 单体到 K8s 容器化

林默的 “转型阵痛” 还没结束。CR 通过的第二天，老周扔给他一个新任务：“把你之前写的支付模块，从 SpringBoot 单体应用改成 K8s 容器化部署，下周要上预发环境。”

“K8s…… 容器化？” 林默拿着任务单，感觉脑子都要炸了。他在小厂只听过 “Docker” 这个词，从来没实际用过 —— 以前部署应用，就是把 JAR 包传到服务器，用 Shell 脚本启动，哪需要什么 “容器编排”？

当天晚上，林默抱着《K8s 实战指南》在工位啃到十点，越看越懵：Pod、Deployment、Service、ConfigMap…… 一堆陌生的概念像天书，更别说写 yaml 配置文件了。他试着按教程写了个 Deployment 配置，把 JAR 包打包成镜像推到仓库，结果在 K8s 集群部署时，Pod 一直处于 “CrashLoopBackOff” 状态。

“日志里说‘端口占用’，可我明明没开其他服务啊？” 林默盯着 kubectl logs 的输出，急得抓头发。他反复检查 yaml 文件，直到凌晨一点才发现：小厂习惯把应用端口设为 8080，可 Z 厂的 K8s 集群里，8080 端口被默认禁止，需要改成自定义的 30080 端口 —— 就这么个小细节，他卡了三个小时。

解决了端口问题，新的麻烦又找上门：容器里的应用没法读取配置文件。林默以前在小厂，都是把配置写在 application.yml 里，打包进 JAR 包；可 K8s 里要用量化配置，得把配置放进 ConfigMap，再挂载到容器里。他跟着文档改了半天，配置还是读不到，最后只好在凌晨三点私信老周求助。

“你看 ConfigMap 的挂载路径对不对？还有权限，容器里的用户有没有读权限？” 老周的消息很快发来，还附了一个正确的 yaml 示例。林默对照着修改，把 ConfigMap 挂载到 /app/config 目录，再给容器加了 read 权限，终于在凌晨四点看到 Pod 变成了 “Running” 状态。

当他在浏览器里打开预发环境的支付接口，看到 “success” 的返回值时，突然鼻子一酸 —— 这三天两夜的熬夜，从不懂 K8s 到成功部署，他踩的每一个坑，都是小厂和大厂 “部署思维” 的差距：小厂追求 “快部署、能运行”，大厂追求 “可扩展、可管控、可复用”；小厂靠人工操作，大厂靠自动化编排；小厂出了问题靠重启，大厂出了问题靠容器自愈。

第二天早上，老周看到部署成功的消息，给林默发了个 “点赞” 的表情：“刚开始都这样，多踩几次坑就会了。记住，K8s 不是‘炫技工具’，是为了应对分布式部署的复杂性 —— 以后咱们服务要扩到几十上百个 Pod，靠人工根本管不过来。”

林默把这句话记在笔记本上。他知道，这次重构不只是 “学会了 K8s”，更学会了大厂的 “工程化思维”：任何技术选择，都要考虑 “未来的扩展性”，而不是 “当下的便利性”。