1. 项目全貌为什么叫Apollo-11拿Apollo-11当项目代号多少带点浪漫主义。阿波罗11号是人类第一次成功登月的任务代号代表着目标明确、过程波折、最终落地。我们这个项目也是一样要做的事不算复杂但真正推进起来才发现越简单的需求背后越是暗藏汹涌。这个代号是某团队内部一次头脑风暴时定下来的后来一直沿用几经折腾也没换过。所谓Apollo-11本质上是一个面向移动端H5和小程序场景的多人共享体验平台。用户创建一个房间把链接发给别人大家进入同一个工作台后可以实时看到彼此的操作、共享同一个状态、在同一个画面上协作。想象两个人在同一张白纸上轮流写字一个人落笔另一个人立刻能看到这就是这个项目最核心的体验。这个项目解决的问题其实非常具体在弱网、多端、跨平台的环境下让多人共享同一个动态页面状态而且延迟要低、状态不能乱。听起来像是一个在线协作白板该做的事但放到真实业务里会发现很多团队并不需要那么复杂的协同编辑他们需要的只是一个轻量级共享容器把现有的H5页面、表单、播放器等装进去就能获得实时同步能力。合适谁来参考如果你是做前端、小程序、或者通信层开发的人这个项目的拆解会很有价值。尤其是那些正在做共享房间、联机互动、实时同步类功能的团队这篇文章里很多坑你应该都会踩一遍。开展这个项目之前我们其实评估过现成的开源方案也考虑过直接用第三方的实时协作服务。但最终决定自研原因有三点第一业务场景里有大量定制的权限逻辑现成方案改造成本不低第二数据要落到自己的服务器上满足存储和审计要求第三当时的业务并发量虽然不高但对成本敏感自研一套轻量方案长期算下来更稳妥。说白了就是需求不算大但定制多租不如买买不如造。这个决定谈不上多高明但在当时的约束下是最合理的选择。如果一个项目需求清晰、边界固定、没有复杂的定制逻辑用现成的方案绝对更快。但Apollo-11不一样它的核心壁垒恰恰在定制能力上。2. 技术选型与架构设计把同步这件事做稳2.1 通信层方案为什么放弃轮询死磕WebSocket最早做技术预研时团队内部有过一轮争论到底用轮询还是WebSocket轮询的方案实现最简单前端定时请求后端接口把最新的状态拉下来。但稍微推演一下就发现问题很大——共享体验的核心是实时如果轮询间隔设1秒那用户的操作到其他人屏幕上至少要延迟1秒以上稍微一卡顿就可能到3秒这在协同操作场景里是不可接受的。有人提出用长轮询也就是前端发起请求后后端不立即返回而是挂起一段时间有数据更新或者超时再返回。这个方案确实能缩短延迟但代价是服务器资源消耗大长连接的数量一多后端线程池很容易被打满。还有一个备选是SSEServer-Sent Events服务器单向推送消息给客户端。这个方案对某些场景是够用的比如一个页面状态只被一个人修改其他人只读。但Apollo-11的共享场景是双向的A用户在画布上画一笔B用户也需要能够回传自己的操作SSE的单向特性根本撑不起来。最后选定了WebSocket全双工、低延迟、协议成熟加上移动端浏览器和小程序对WebSocket的支持已经很完善不需要额外引入SDK。用一句话解释WebSocket和普通HTTP的区别HTTP就像你打电话时每说一句话就要挂断重拨而WebSocket是一条电话接通后一直不挂断双向说话随时说随时听。这天然契合共享体验的场景。WebSocket方案定下来后后续又补了几个关键设计心跳机制接收方和发送方每30秒发送一次ping帧一个周期内没收到pong就判定连接异常。这个参数不是拍脑袋定的而是多次压测后取的经验值间隔太短会空耗资源间隔太长则会延迟发现断线。断线重连前端监听到连接关闭或异常执行指数退避重连策略——第一次等1秒第二次等2秒第三次等4秒最多等30秒。这个策略避免了集体重连导致的服务端连接风暴。连接状态分级连接分为未连接连接中已连接重连中四个状态状态变化时同步更新UI展示。用户在线状态不再是模糊的在不在而是在线离开努力重连中体验会更直观。2.2 状态同步与序列化方案JSON一时爽protobuf顶大梁通信层的通道建立了接下来要解决的是数据怎么表达的问题。共享体验平台里实时同步的数据包括用户的坐标信息、页面操作指令、状态变更事件等这些数据结构不算复杂但频率很高。最初的版本用的是JSON前端把对象转成字符串通过WebSocket发送后端拿到解析完存进Redis再广播。上线后发现一个问题JSON的包体太臃肿了。一个用户的坐标信息用JSON表达大概是这样的{type:204,roomId:room_001,userId:user_a,x:33.45,y:67.89,ts:1620134567890}这段文本将近100字节但如果用二进制协议表达同样的信息只需20字节左右。别小看这几十字节的差距当房间里有100个人每人每秒钟发送5次操作时流量差距就非常可观了。更重要的是在弱网环境下包体越小意味着传输成功的概率越高。所以第二版我们引入了protobuf也就是Protocol Buffers一种高效的二进制序列化协议。定义一个消息体大致是这样的message Frame { int32 type 1; string room_id 2; string user_id 3; float x 4; float y 5; int64 ts 6; }同样的数据用protobuf编码后体积只有JSON的三分之一左右。这个升级带来的收益很直接带宽占用大幅下降同样的带宽可以支撑更多的在线用户。解析速度快二进制协议不需要做字符串解析CPU开销更低。兼容性可控protobuf天然支持字段的增删升级协议时不会导致旧客户端崩掉。从JSON切到protobuf不是没有成本前端的js版本需要引入对应的解析库后端的网关层也要做一次协议转换。但实测下来这个切换是值得的。如果现在的你正在做类似的实时通信项目一开始就直接上二进制协议不要走JSON再切换的弯路省下的重构时间比想象中多。2.3 跨节点协同Redis与消息队列的配合单机版本跑通了只是第一步。真实业务不会只有一个WebSocket节点一台服务器撑不住几千上万个长连接必须横向扩展。这就引入了一个经典问题用户A连接在节点1用户B连接在节点2A的操作如何同步给B有两个最朴素的方案方案一是直接在节点间建立长连接通道每个节点连到其他所有节点形成一个网状结构消息在节点间转发。这个方案实现简单但扩展性很差——节点从3个增加到10个连接数会从3跳到45随着集群规模扩大连接数会爆炸。方案二是引入一个独立的消息中间件节点收到消息后不是直接转发给目标节点而是先发给中间件中间件再按需推送给订阅了对应房间的其他节点。这个方案思路清晰也是行业里的主流解法。我们在方案二的基础上做了进一步简化用Redis的Stream特性充当消息队列。不用Kafka的原因很简单——Apollo-11的体量根本用不上Kafka的百万级吞吐能力多引入一个重度依赖意味着多一倍的运维成本。Redis本来就是系统里的基础设施顺手承担消息路由的职责毫无压力。消息流转大致是这样的节点1收到用户A的操作帧解析校验后写入Redis Stream消息带上房间号作为标识。节点1同时把操作帧存入内存同步给本节点上同一房间的其他用户。节点2通过一个轻量级的消费线程从Redis Stream中拉取属于自己节点用户所在房间的消息再推送给客户端。这套设计看起来简单但细节里藏着一个非常重要的问题消息至少需要投递一次但重复投递会导致状态错乱吗我们的解法是在消息帧里加上sequence序号客户端按序号排序重复的消息直接丢弃。这个序号就是所有客户端之间的共同语言。2.4 为什么不用数据库存状态有人会问实时状态为什么不用数据库存我们用Redis存状态而不用MySQL或者MongoDB核心原因就是读写的延迟和压力。一个用户操作引起状态变更这个变更要在几十毫秒内广播给同房间所有人而且这个操作可能每秒钟发生好多次。关系型数据库的每次写入都要走磁盘这个延迟天然不适合高频写场景。Redis是纯内存操作单次读写延迟在亚毫秒级别完全顶得住。再者状态数据本身是临时性的——用户退出房间后这条状态数据就没有价值了留在内存里还能快速过期不可能去占数据库的空间。当然纯内存方案也有风险。如果Redis崩溃内存里的状态会全部丢失各客户端的状态就不同步了。应对手段是定期做快照持久化同时客户端本地缓存最近的操作记录恢复连接后可以从断点续传。这两条防线保证了极端情况下也不至于全盘崩溃。3. 实操过程从零到一的六个关键步骤3.1 搭建连接层与心跳保活连接层是整个系统的门户所有客户端先连到这里。连接层的主要职责包括校验token、建立WebSocket长连接、维护连接状态表、处理心跳。先说心跳的具体实现。我们用的是应用层心跳也就是在WebSocket之上由业务层定义一套心跳协议客户端定时发送一个特殊的ping消息服务端收到后回应pong消息。如果服务端在60秒内没有收到任何来自客户端的消息就认为这个连接已经死掉了主动断开释放资源。这里有一个容易踩的坑WebSocket协议本身是有ping/pong帧的所以在协议层做心跳是可行的。但实际操作中发现HTTP代理、CDN等中间设备可能ping不通应用层心跳反而更可控。我们最终选择了应用层心跳并且把心跳和业务消息区分开心跳帧的类型字段填的是固定值解析时直接走心跳分支不进入业务逻辑减少不必要的处理开销。3.2 消息协议设计从JSON到protobuf的升级消息协议的升级是整个项目中后期最伤筋动骨的一次改动。当初第一版直接用了JSON一是开发速度快二是调试方便。但上线两周后就发现问题后台监控面板上WebSocket的流量占到了总网络流量的40%以上而实际业务请求量并没有那么夸张罪魁祸首就是JSON的冗余字段。换protobuf的时候留了个兼容方案不直接断掉JSON而是在消息头的type字段里增加一个protocol_type客户端根据这个字段决定走JSON解析还是protobuf解析。这样新老客户端可以同时运行一段时间等新版本覆盖到95%以上才彻底关掉JSON解析通道。这里分享一个经验协议升级一定要带兼容策略不管是格式升级还是字段调整别指望所有客户端一夜之间都更新完成移动端和小程序的更新节奏参差不齐如果强制切换必然有人卡在登录页进不来。3.3 状态一致性控制版本号与冲突处理共享体验最核心的难点就是状态一致。A在手机上画了一个圆B在平板上同时画了一个方形两个操作同时到达服务器谁先谁后如果处理不好就会出现状态错乱。Apollo-11选择的是中心化版本号方案简单说就是每个房间维护一个全局自增版本号version。任何客户端操作成功服务端都会把version加1然后连同最新状态一起广播。客户端本地记录自己已经处理到的最新version。收到新的广播帧时比对version如果相等说明是重复帧丢弃如果不相等则更新本地状态。这个方案在处理简单的顺序冲突时非常有效。对于复杂的同时编辑冲突Apollo-11直接采用后写覆盖的策略——以服务端收到操作的时间为准后到的操作覆盖先到的。业务方对这个限制是接受的因为我们的共享场景不是文档协作而是类似画板、互动播放器这样的场景后写覆盖并不违背用户直觉。如果是做多人文档或者实时表格这个策略肯定不行必须引入CRDT换一种无冲突的数据类型或者OT操作变换算法那属于另一个量级的复杂度了。3.4 权限与房间管理权限模块看起来不起眼但对共享体验来说没有权限控制就等于是把家门钥匙贴在楼道里。Apollo-11的房间权限分三层所有人可见谁拿到链接都能进只能观看不能操作。适合直播观看、演示分享。需要申请操作权限进入后默认是观察者要向房主申请操作权限房主审批通过后才能操作。适合培训教学、远程协作。密码保护进入房间前需要输入密码否则连观看都进不去。适合小范围内测、数据保密场景。落地的难点不在权限策略本身而在权限的实时撤销。比如房主把一个人的操作权限收回来了但这个人正在发送一个移动指令指令已经在半路上了。我们的方案是在服务端统一做权限校验而不是依赖前端拦截——客户端发送的任何操作帧服务端都会先查一下权限表没有权限就直接拒绝同时推送一个权限已调整的通知给该用户。前端隐藏按钮只能改善体验不能代替后端的这道约束。3.5 离线重连与断点续传移动端网络稳定性永远是个玄学。地铁过隧道、电梯里、甚至人多时因为信号协商失败WebSocket分分钟断开。Apollo-11做了两层保障。第一层是指数退避重连断开后客户端按照1秒、2秒、4秒的间隔尝试重连最多间隔30秒。如果连续重连失败5次则提示用户网络不稳定请检查网络设置不再无休止地尝试给用户一个明确的反馈。第二层是断点续传。用户断开期间服务端并不会立刻把它踢出房间而是标记为离线同时在Redis里缓存这个用户最后一次收到的消息序号。用户重连成功后客户端会带上自己最近收到的一条消息序号服务端把这个序号之后的消息重新推送给它这样就补上了离线期间错过的状态。断点续传用了一个比较抽象的设计思路实际操作时并不复杂本质就是让每个客户端都像一台录像机服务端的广播帧都有编号断开相当于录像暂停重连相当于从缓存里继续播放。3.6 前端落地从埋点到渲染前端工作是整个项目中最不像技术的部分但恰恰是用户体感最直接的。Apollo-11的前端架构是页面容器继承自一个统一的Room组件Room组件内部负责和WebSocket网关通信拿到状态数据后统一派发给各个子组件渲染。这个设计有这样几个考虑一是业务方不需要关心WebSocket细节只需实现一个render方法把状态渲染出来二是方便做统一的埋点监控连接状态、消息延迟、重连次数都集中在Room组件里上报不需要每个业务方自己做统计。前端的性能优化也有不少可以说的点。首屏加载时业务方经常传大量初始状态一次性渲染几千个DOM节点很容易卡死页面。我们用了分批渲染策略第一次只渲染可见区域的节点其余节点在滚动时动态加载。这种延迟加载的思路在共享画布、长列表、多维表格的场景下特别管用。4. 实战中的坑与排查思路4.1 断线重连风暴一场凌晨三点的MySQL连接爆满第一次遭遇大规模断线重连风暴是上线后第三个星期的凌晨两点。运维告警群里突然炸了锅数据库连接数直接打满出现大量slow query。排查下来发现不是数据库本身的问题而是那天凌晨网络运营商做割接全国有一部分用户的网络闪断所有客户端在同一时间触发了重连逻辑。几千个用户同时重连每个重连都要查询用户信息、创建房间上下文、拉取状态快照数据库当然顶不住。教训有两层。第一层是重连必须加随机抖动即在指数退避的基础上每次重连前加一个0到500毫秒之间的随机等待时间。这样的话即使一万个人同时掉线重连请求也不会排着队到达服务器。第二层是关键链路必须加缓存。用户基本信息和房间状态快照不应该每次重连都从数据库拉而是缓存到Redis重连时走缓存数据库只做最终的兜底校验。经过这次事故之后重连风暴再也没有出现过。4.2 消息乱序不是所有操作都按发送顺序到达还有一次印象深刻的bug是一个本该极简单的同步功能——用户A在画布上画了一个箭头结果用户B经常看到箭头先出现过一会儿才看到画箭头的轨迹。位置是对的但动画时序是乱的。问题出在WebSocket的消息不保证严格有序。虽然WebSocket协议本身按帧有序传输但当多帧消息到达单个通道时受网络缓冲和服务器处理并发的影响不同用户的写操作可能被中间件以不同的顺序转发出去。A画的箭头分成了开始画和画完两帧这两帧如果顺序颠倒体验就完全不对。解决办法分两侧进行。服务端在广播时给每条消息打上一个基于房间维度的自增序号客户端维护一个小的接收队列按序号处理消息不连续的消息先存起来。这个改动并不复杂但彻底解决了乱序问题。做实时系统一定要在心里预设消息会乱序、会重复、会迟到再针对这三种情况设计应对方案而不是假定网络完美。4.3 状态漂移用户的屏幕和服务器对不上状态漂移是多人实时系统里玄乎又最常见的问题。现象是有的用户屏幕上显示的是旧状态而其他用户看到的是新状态服务器上的状态也是新的只有那个用户的进程像定格了一样。排查了很久才定位到原因那个用户连接的是旧的WebSocket节点而新消息被路由到了新的节点上。老的节点和新的节点之间Redis Stream消费出现延迟导致投递不到。这本质上是一个消费滞后问题。解决手段是双管齐下。一方面给Redis Stream的消费组加上lag监控当某个节点的消费积压超过阈值主动把它标记为不健康停止向它分配新连接同时触发该节点上的客户端进行重连。另一方面在客户端和服务端都维护一个状态哈希值当状态更新时这个哈希会变化如果发现服务端的哈希比客户端更新客户端主动发起一次全量状态同步。这样即使滞后最终也能收敛到一致。4.4 常见问题速查表整理一下Apollo-11开发和上线过程中遇到的高频问题供各位参考。问题现象根因解决方案连接闪断频繁用户操作时提示网络不稳定心跳超时设置过短心跳间隔调至30秒超时调至60秒消息延迟突增操作后有1秒以上延迟Redis Stream消费堆积增加消费线程并监控lag内存缓慢增长节点运行几天后内存升高房间上下文未及时释放增加空闲房间的过期回收逻辑弱网下消息丢失用户短暂断网后状态缺失重连后无补发机制增加断点续传和消息缓存高峰期CPU抖动节点CPU使用率忽高忽低大量JSON解析耗CPU切换protobuf降低解析开销白屏无法进入进入房间后页面一直加载初始状态数据量过大分批渲染加首屏加载进度4.5 排查利器全链路日志与状态埋点最后说一个项目后期才补上的东西——全链路日志。早期排查问题基本上靠猜前端报一个错误后端报一个错误两边日志对不上。后来做了一个统一的requestId机制也就是从客户端发起一个操作帧开始这个操作帧就携带一个唯一的requestId网关收到后记录一条日志转发到Redis Stream以及广播给其他节点时日志里都带上同一个requestId。这样一来排查一次用户B看不到用户A的操作就可以直接把两个用户各自的requestId拉出来从头到尾串一遍看消息在哪一步断了。排查效率提升了不止一个数量级。实时系统的排错核心不是看代码而是看链路。5. 项目落地的长期收益与复盘Apollo-11从立项到稳定运行前后经历了大约五个月。这五个月的时间投入的研发人力并不多核心开发实际上只有三个人一个人负责网关和通信层一个人负责前端一个人负责后端服务和数据层。可以说这是一个小团队能完成的上限级别的项目了。复盘这个项目有几个决策值得单独拎出来讲。第一先搭骨、再填肉。项目启动第一周没有写任何业务代码只做了两件事搭好WebSocket网关的骨架定义好消息协议的前三版。骨架和协议是这座建筑的地基地基没打好后面加再多的功能都会晃。节奏上我们狠狠心把这一步拉长了一周后面证明是完全值得的。第二不要总想着一次到位。很多同学做技术选型时会纠结这个方案天花板不够高然后选一个复杂度极高、学习成本极大的方案。Apollo-11用的都是非常成熟、没有惊喜的技术WebSocket、Redis、protobuf。这些技术可能不够炫但足够稳。对一个业务场景明确的项目来说把八十分的技术用出九十分的效果远比用九十分的技术做出八十分的效果要强。第三性能优化要放在流量进来之前。很多项目是上线后用户暴增才开始优化那个阶段每慢一步都在流失用户。Apollo-11在上线前就做了一轮完整的压测模拟了3000人同时在线的场景发现WebSocket网关的线程模型有问题——同步阻塞式处理消息导致CPU利用率上不去。赶在上线前改成了基于事件循环的异步模型才顶住了后面的真实流量。第四做共享体验项目要始终记得延迟是体验数据是底线。延迟影响的是用户爽不爽数据的一致性和正确性影响的是用户信不信。宁可多花两倍的时间把状态同步和异常恢复做扎实也不要为了看起来流畅而牺牲准确性。用户不会因为一次慢就卸载你的产品但会因为一次数据错了而彻底失去信任。这个项目做完之后我们内部的技术栈里多了一个被反复复用的共享能力模块。后来的好几个新项目甚至在立项之前就直接把这个模块接进去省掉了大量重复造轮子的时间。回头看当初取名为Apollo-11有一点登月成功那样的里程碑意味——不是说技术有多难而是我们把一件从零到一的事情完整地做成了并且让它真正跑在了业务线上。这一点比任何技术方案的完美都要实在。