在构建高并发、低延迟的后端系统时，数据传输协议的选择往往决定了系统的性能上限和维护成本。最近，我将项目的核心服务从传统的 JSON 协议全面迁移到了 Protocol Buffers (Protobuf)。 这篇文章记录了这次迁移背后的思考、遇到的坑以及最终的架构收益。 为什么放弃 JSON？JSON 是 Web 开发的“通用语”，它直观、易读、调试方便。但在高负载的情况下，它的弱点也愈发明显：

背景：在确定了“房间粘滞（Room Affinity）”架构后，接下来的硬核挑战就是：如何实现一个高性能的连接分配器（Allocater）？ 让它能实时感知机器负载，并动态引导流量。 1. 简单的负载均衡为什么“不够用”？对于无状态的 HTTP 请求，轮询（Round Robin）或最少连接数（Least Connections）通常工作得很好。但在游戏/长连接场景下，这两个方案都有

背景补充：在之前的 架构大修记 和 全栈 Monorepo 实践 中，我曾提到过为了可扩展性而追求“全量 Redis 化”和“无状态后端”。但随着重构的深入，我开始重新审视这一选型。 1. 序言在构建一个支持多人实时协同的应用平台时，开发者通常会面临一个硬核的技术挑战：如何处理成千上万个长连接（WebSocket）在多台服务器间的同步？ 在重构项目后端时，我陷入了两条路径的深度纠结： 方案

1. 序言：为什么我们要重构？在早期的项目开发中，我们使用了最传统的“OSS 静态托管 + 传统 CDN 加速”模式。虽然能够支撑起步，但随着平台向 MPA（多页面应用） 架构演进，集成多个独立子项目时，传统 CDN 的局限性逐渐显现： 统一管理 SSL 证书： ESA 自动管理 SSL 证书，无需手动配置。并且提供免费的泛域名证书。 路由逻辑僵化：无法优雅地处理子目录下不同单页应用（SPA）的

刚刚还沉浸在服务器架构大升级的喜悦中，想着之后可以愉快的开发一个又一个新应用。突然一个问题在脑中飘过：以后子项目越来越多，那我的包体积岂不是要爆炸？我之前虽然有了解过可以懒加载某些模块，但从来没有系统的考虑过这个问题。另外应用更新了怎么办，全部重启？模块下架怎么办，代码删除？感觉不对啊，耦合的太厉害了。我得考虑每个模块是不是得单独打包单独部署，每个应用都已独立的前后端。另外有一个入口程序，也有单独

最近给我的项目 “兔特科技技术博客” 做了一次彻头彻尾的技术升级。折腾了好几天，踩了无数只有亲历过才会懂的坑，现在终于全线通车了，回头看，这不仅是服务器搬了个家，更是从“作坊思维”到“架构思维”的转变。 想把这段心路历程记下来，顺便给后面想折腾阿里云 CDN、OSS、NLB 和 WebSocket 的兄弟们留个“保命指南”。 1. 曾经的 1.0 时代：简单粗暴，大力出奇迹刚开始的时候，我的架构

AI 时代的文化传承与回归最近这段时间，看着 AI 以“周”为单位甚至以“天”为单位进化，我心里总有一种说不出的焦虑。 只要几秒钟，AI 可以写出一首像模像样的古诗，可以总结完一本厚厚的经书，甚至能精准模拟任何人的笔迹。当“效率”被推到了极致，我反而开始怀念一些“没效率”的东西。 我想做一个交互体验项目，一个有点“反时代”的项目。简单来说，它就是让大家坐下来，一笔一画地抄写、默写那些经典的古诗词、

聊聊 2024 年的 TGA。当《宇宙小机器人》（Astro Bot）拿了年度大奖（GOTY）那阵子，网上那是相当热闹，满屏的质疑和嘲讽。好多人觉得这一作品“不配”，理由无非是：不够 3A、太低幼、内容深度不够。还有人说这不就是抄任天堂吗？满脸写着马里奥和卡比的影子。 更有意思的是，大家都喜欢把《奥德赛》拉出来对比，觉得小机器人连《奥德赛》的一根头发丝都比不上，顺便还要替当年的《奥德赛》委屈一下—

《倒带大挑战》是一款基于音频处理技术的趣味交互应用，详情请参考 倒放的灵感。多人在线部分我们之前有你画我猜的经验，这里不做赘述。本文将深入探讨声音的录制、上传，存储和倒放实现。 上传和存储这里有两方面的考虑，一是实时性，关系到应用体验，二是存储和传输成本，关系到服务器成本。经过多方考虑，我选择客户端那临时鉴权，然后上传到阿里云oss。而下载通过 cdn 加速。这样既保证了实时性，又降低了服务器成本

灵感来源最近最近短视频上看到一种玩法。就是录一段音频，倒放。然后模仿倒放的音频，再录制进去后倒放。看能不能猜出原始的音频是什么。这让我想到了制作一个交互项目的创意，做成类似《你画我猜》的多人竞技应用，会非常有意思。 我可以将这一项目暂时命名为《倒放大挑战》。 核心机制出题环节： 每一轮由一名“主唱”玩家获得一个短语，最好是有趣有梗，（如“你是来拉屎的吧”、“鸡你太美”）。 主唱录音环节： “主唱”