从深夜写JS到K8s部署：一个全栈的探索野路子
上周五晚上十一点，北京回龙观地铁站刚挤完最后一班13号线，我瘫在工位上盯着屏幕上闪烁的光标发呆。产品经理临时加了个“简单需求”——要在现有后台系统里嵌入一个实时数据看板，用WebSocket推最新订单状态。我心想：这不就是换个前端组件的事？结果一深挖，发现老系统还是jQuery写的，连模块化都没有。
那一刻我真的想砸电脑。
但转念一想，不就是干这个的吗？创业公司全栈开发，说白了就是“啥都得会点，啥都得顶上”。坐标北京，通勤一小时换来的是每天和deadline赛跑的快感（或者说是痛苦）。而技术探索，从来不是为了炫技，纯粹是被逼出来的生存技能。
今天就聊聊，我是怎么在夹缝中搞技术探索与实践的——没有大厂资源，没有专职架构师，只有几本翻烂的书、一堆Stack Overflow页面，和凌晨三点依然清醒的大脑。
那本救了我命的《JavaScript高级程序设计》
事情回到那个“简单需求”。我原以为用Vue或React快速搭个组件就行，结果发现后端API根本没做实时推送，数据库轮询效率低到爆炸。更惨的是，旧系统压根没用现代构建工具，连Babel都跑不了。
当时我就意识到：光改前端不行，得从底层重构通信机制。但时间只有三天，双11前必须上线。
怎么办？翻书！
我抽屉里那本《JavaScript高级程序设计》（第4版）已经被咖啡渍泡出包浆了。翻到第22章“高级技巧”和第25章“客户端存储”，突然想到：能不能先用Service Worker + WebSocket做个轻量级代理层，把实时能力“嫁接”到老系统上？
于是，我写了一个微型JS模块：
// realtime-bridge.js
const socket = new WebSocket('wss://api.ourcompany.com/ws/orders');
socket.onmessage = (event) => {
const data = JSON.parse(event.data);
// 利用事件总线通知老系统
window.dispatchEvent(new CustomEvent('orderUpdate', { detail: data }));
};
// 老jQuery代码里监听
$(window).on('orderUpdate', function(e) {
$('#order-count').text(e.detail.count);
});
别说，真跑起来了！虽然糙，但有效。最重要的是——没动老系统一行代码。
这就是我技术探索的第一原则：用最小改动解决最大问题。书不是用来收藏的，是用来救命的。
从浏览器到K8s：一次被迫的云原生之旅
解决了前端，后端又出事了。
测试同学反馈：高并发下WebSocket连接数一上来，Node服务直接OOM。我查了监控，Pod内存使用率飙到95%，然后被K8s无情干掉。
“你这服务是不是有内存泄漏？”运维小哥在群里@我，语气里透着“又是你们前端搞的鬼”的潜台词。
其实我心里清楚：不是泄漏，是架构问题。单体Node服务扛不住长连接。但重构成微服务？时间不够啊！
这时候，我脑子里闪过之前啃过的《Cloud Native Patterns》里的“Sidecar模式”。灵机一动：能不能把WebSocket逻辑拆出来，单独跑一个服务，通过内部网络和主服务通信？
说干就干。我用Go写了个超轻量的WebSocket网关（毕竟Go的goroutine处理连接太香了），然后在K8s里配了个Deployment：
# websocket-gateway.yaml
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: main-app
image: our-company/backend:v1
- name: ws-gateway
image: our-company/ws-gateway:v1
ports:
- containerPort: 8080
env:
- name: BACKEND_URL
value: "http://localhost:3000" # 同Pod内通信
同Pod内的两个容器共享网络命名空间，localhost就能互相访问。主服务只负责业务逻辑，WS网关专注连接管理。内存压力瞬间降下来，而且扩缩容时K8s能自动调度。
这次实践让我明白：技术探索不能只盯着语言本身，要结合运行环境思考。Javascript写得好，不如K8s玩得溜。
我的技术探索方法论：三本书+三个坑
复盘这几年踩过的坑，我发现有效的技术探索其实有套路可循：
以问题为起点，不是以技术为起点
别一上来就“我要学Rust”、“我要上Serverless”。先问：我现在卡在哪？瓶颈是什么？比如那次WebSocket问题，本质是连接管理，不是JS写得不好。快速验证，小步快跑
创业公司没时间做POC三个月。我的做法是：先写个50行的原型，跑通核心逻辑，再逐步加固。上面那个JS桥接方案，第一天就跑起来了，后面两天才加错误重连、鉴权、日志。善用已有知识迁移
我熟悉K8s，所以自然想到用Sidecar；我啃过JS红宝书，所以知道CustomEvent这种冷门API。技术不是孤岛，跨领域组合才是创新的源泉。
下面是我常翻的几本书，按使用频率排个序：
| 书名 | 使用场景 | 被我翻烂的程度 |
|---|---|---|
| 《JavaScript高级程序设计》 | 前端疑难杂症、面试装X | 封面掉了，用胶带粘的 |
| 《Kubernetes in Action》 | K8s配置、故障排查 | 电子版+纸质版双持 |
| 《Designing Data-Intensive Applications》 | 架构设计、选型讨论 | 看了三遍，每次有新感悟 |
别信那些“一年读100本书”的毒鸡汤。精读三本，胜过泛读三十本。
那些年，我和产品经理的“技术谈判”
当然，技术探索最大的阻力往往不是技术本身，而是沟通成本。
有一次我想引入TypeScript重构前端，写了份详细收益分析：类型安全、重构效率、减少Bug……结果产品老大回我：“用户又看不到，能多卖货吗？”
我当时差点脱口而出“那你去卖货别用系统啊”，但忍住了。后来我换了个说法：“如果因为JS动态类型导致发错优惠券，损失可能几十万。” 他立马点头：“那你搞吧，但别影响排期。”
你看，技术价值要用业务语言翻译。这也是全栈开发者的优势：既懂代码，也懂业务上下文。
写在最后：探索的本质是解决问题
回过头看，我的技术探索路径其实很“野”：没有系统的计划，没有导师指导，全靠项目逼、bug催、deadline赶。但正是这种高压环境，让我学会了在约束中创新。
深夜写代码效率高，不只是因为安静，更是因为那时没人打扰，可以全神贯注地和问题死磕。有时候一行代码改了十几遍，报错信息看了几十遍，突然灵光一闪——那种“啊哈！”的瞬间，比喝十杯美式都提神。
所以，别等“有时间再学”。最好的学习时机，就是问题砸到你脸上的那一刻。
下次当你面对一个看似无解的需求，不妨想想：手边有没有一本翻烂的书？脑子里有没有一个能组合的旧知识？手里有没有一行能跑起来的JS？
技术探索，从来不是阳春白雪，而是泥泞中的摸爬滚打。而我们这些创业公司的全栈民工，就是在这样的泥泞里，一点点把系统从“能跑”变成“跑得稳”。
对了，那个实时看板，双11当天扛住了每秒2000+的订单更新，没崩。运维小哥默默在群里发了个👍。
我回了个：JS yyds。
（完）
评论 0