18年实战：客户端云部署与网络优化跃迁

　　去年春晚那波流量洪峰，我原以为云部署的弹性扩容能扛住——结果CDN节点在江苏段直接熔断，监控大屏上红色警报跟放烟花似的。老张在隔壁工位摔了键盘，键盘帽弹到我显示器上，我盯着那个卡在87%的构建进度条，突然想起2008年做奥运直播APP时，我们用物理机扩容，运维小哥蹲在机房里手动插网线，冷风机吹得他鼻涕都冻出来了。

　　优胜劣汰这事儿，说起来轻巧。去年我们强推HTTP/3，结果测试环境好好的，上线当天被某运营商的中间件劫持，QUIC握手包全被丢进黑洞。小李蹲在消防通道里抽了半包烟，回来跟我说："要不咱们回退到HTTP/2？"我盯着他发红的眼睛，突然想起2015年做双十一活动，那时候还在用长连接，凌晨三点服务器CPU飙到99%，运维总监直接把空调温度调到16度，说"冷点能让机器多撑半小时"。那会儿我们哪知道什么边缘计算，就是靠堆机器、靠人肉值守。

　　外卖凉了三次，行政小姑娘把保温箱搬到测试区。小王盯着日志说："这QPS曲线不对啊，怎么比压测时低了30%？"我凑过去看，发现他用的还是旧版SDK——那玩意儿连TCP_NODELAY都没开，数据包在传输层攒着发，能不慢吗？我原以为大家早把这种低级错误戒了，结果去年Q3复盘时，运维报告里还写着"某业务线因未启用GZIP压缩，多消耗17%带宽"。这事儿我跟CTO吵过，他说"不能全怪开发，产品经理没在需求里写清楚"。我当场翻出2017年的技术规范文档，白纸黑字写着"所有API响应必须压缩"，他瞥了一眼说："哦，那可能是后来改需求时删了。"

文章配图，仅供参考

　　跟人吵架最烦的是"我觉得"和"数据说"。去年推广Service Mesh，测试环境跑得好好的，上线后RT涨了15ms。架构师说："这是观测开销，正常。"我说："用户可不管你是不是观测，15ms在弱网下就是卡顿。"他翻出PPT说："行业平均水平是20ms。"我指着监控说："我们用户里30%用的是4G，平均RT才80ms，你加15ms就是18.75%的劣化！"最后他妥协了，说："那咱们只给核心服务打侧车。"结果核心服务里有个老旧Java服务，启动要两分钟，Sidecar根本挂不上去——这事儿到现在还没解决，每次周会都被拿出来当反面教材。

　　跑题说个事儿。上周去面试个五年经验的，问他"HTTP/2的头部压缩怎么实现的"，他说"用HPACK算法"。我问"HPACK的动态表大小是多少"，他愣住了。我又问"如果服务端动态表满了会怎么处理"，他开始支吾。我原以为这种基础问题早该烂熟于心，结果翻他简历，发现他最近三年都在做低代码平台——可能现在的前端真的不用管这些底层细节了？但云部署和网络优化不一样啊，你连TCP拥塞控制是Cubic还是BBR都不知道，怎么调参？怎么排障？

　　回到去年春晚。熔断发生后，我们临时切了备用链路，把江苏节点的流量导到浙江。老张在群里发消息："浙江节点CPU快满了！"我让他把QPS限到80%，他说："产品经理会杀了我。"我说："不限的话，等CPU过载触发OOM，整个节点都得挂。"他咬咬牙打了限流命令，结果产品总监的电话立刻打进来："为什么用户看不到弹幕了？"我接过电话说："要么现在限流保基本功能，要么三分钟后所有用户都卡死——您选哪个？"电话那头沉默了五秒，说："...限流吧。"

　　现在说优胜劣汰容易，可当年哪有这么多"优"可选？2010年做Android客户端，连OKHttp都没有，全靠HttpURLConnection硬扛。有次用户反馈"图片加载慢"，我们查了半天发现是运营商在HTTP头里插了广告——那时候连HTTPS都没普及，更别说证书固定了。现在倒好，TLS 1.3、ALPN、0-RTT这些特性都用上了，可用户还是说"慢"——因为他们的手机是三年前的中低端机，CPU连解密都吃力。

　　我桌上的绿萝又黄了两片叶子，行政小姑娘说"该换水了"。我盯着监控大屏上终于稳定的QPS曲线，突然想起个事儿：去年我们推广gRPC，结果发现iOS客户端的连接数比Android多30%——因为Android有连接池，iOS没有。这事儿在周会上被拎出来当典型，说"iOS开发不专业"。可后来查日志发现，是Android端的重试策略太激进，每次失败就新建连接，把池子挤爆了。你说这算谁的锅？优胜劣汰？有时候劣的未必是技术，可能是人的认知。

　　下周要给新团队培训云部署，我准备把去年春晚的监控截图打印出来，贴在会议室墙上。让他们看看，什么叫做"平时吹得天花乱坠，关键时刻掉链子"。不过话说回来，现在这些云原生工具确实比十年前强多了——要是放在2015年，遇到这种流量洪峰，我们得提前两周准备，现在半小时就能扩容。但工具越强，人越容易懒——上次有个新人问我"为什么不能全自动化"，我说："因为总有些破事儿是机器搞不定的，比如运营商劫持、比如产品经理临时改需求、比如运维手滑输错命令。"他撇撇嘴，我补了一句："等你经历过三次春晚保障，就懂了。"

　　至于优胜劣汰到底站不站得住？我说不准。去年我们淘汰了自研的RPC框架，换了Dubbo 3.0，结果性能提升了20%。可前年我们淘汰了旧版监控系统，换了Prometheus，结果大促时查询延迟翻了三倍——最后不得不回退，还多花了两个月重构。所以啊，别太迷信"优胜劣汰"，有时候"劣"的只是暂时没遇到合适的场景，或者用的人不够狠。就像我桌上的绿萝，换个盆说不定就活了——但谁有空给它换呢？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!