移动互联架构升级：通讯、推送、内容分发三位一体日志驱动演进

文章配图，仅供参考

　　我原以为日志量涨了加机器就行，结果发现根本不是那么回事。推送模块的日志里混着大量重复的"消息已送达"字段，内容分发模块又把用户点击行为日志和缓存击穿日志揉在一起，通讯模块更绝——接口超时的堆栈信息里，一半是慢查询，另一半是脏数据导致的幂等失败。最搞笑的是，灰度期间有个定时任务突然跑偏，把三天的日志全吐出来了，ES的绿色监控线抖得跟心电图似的，我盯着屏幕看了十分钟，差点以为自己要犯心脏病。

　　后来跟产品撕了三天，他们非说"日志格式统一方便分析"，可分析个屁啊！推送模块要的是实时送达率，内容分发要的是用户行为路径，通讯模块要的是接口耗时分布，这三个需求能揉到一张表里？我当场把ES的查询语句拍在会议桌上："你们看这个聚合查询，光group by就写了五层，执行计划里全是全表扫描，QPS稍微高点就超时！"产品经理挠着头说："那...要不加个缓存？"我差点把咖啡喷他脸上——日志分析加缓存？这逻辑比咖啡机坏了还离谱。

　　不过话说回来，这次升级也不是完全没好处。去年二月那次事故后，咱们被迫把三个模块的日志拆开存，结果发现推送模块的日志量其实只占30%，内容分发占了60%，通讯模块最少。更绝的是，内容分发模块的日志里，80%是定时任务生成的脏数据——这些数据在旧系统里根本没人看，却占着磁盘空间和查询资源。拆分后，推送模块的ES集群负载直接降了70%，通讯模块的接口超时率从5%掉到0.2%，连运维小王都感叹："早知道这么简单，去年何必通宵回滚？"

　　可拆分也带来新问题。上周三下午，内容分发模块突然报"日志写入延迟"，我一查发现是灰度环境的ES分片不均衡，某个节点堆了200G数据，其他节点才50G。更坑的是，这个节点的磁盘是三年前的老型号，IOPS只有新磁盘的一半。我让运维小李去换磁盘，他蹲在机房里打电话谈房租，说"等房东回消息再弄"，结果拖到晚上八点，日志积压到100万条，直接触发限流，用户端的内容加载失败率飙到15%。那天产品经理在群里@我八次，我盯着手机屏幕直犯嘀咕：这锅到底该算日志拆分，还是算运维不积极？

　　说到运维，我想起上个月那个慢查询事故。内容分发模块的日志表结构改了字段类型，从varchar改成json，结果查询语句没改，导致全表扫描。更离谱的是，这个查询是定时任务调的，每小时跑一次，每次跑十分钟，把数据库的CPU压到90%。我查日志时发现，这个任务已经跑了三个月，之前因为数据量少没暴露问题，直到上个月用户量涨了五倍，直接雪崩。最搞笑的是，改字段类型的开发小哥早离职了，交接文档里只写了"优化存储"，没提查询语句要改。我盯着工位隔断上他贴的"今日事今日毕"便签，卷了边的纸在空调风里晃啊晃，突然觉得这行代码比便签还讽刺。

　　不过话说回来，这次升级让我明白个道理：日志驱动架构演进，说白了就是"优胜劣汰"。通讯模块的日志要实时，推送模块的日志要精准，内容分发模块的日志要全量——这三个需求天生矛盾，硬揉到一起只会互相拖累。去年二月那次事故后，咱们把日志拆成三套系统，虽然多了维护成本，但每个模块都能按自己的节奏优化。比如推送模块现在用Kafka+Flink做实时分析，通讯模块用ClickHouse做耗时统计，内容分发模块用HBase存全量日志，各玩各的，反而更稳定。

　　当然，这方案也不是没缺点。比如现在三个模块的日志格式不统一，产品要分析跨模块数据时，得写三个不同的查询语句，再手动合并结果。上周他们要算"用户从收到推送到点击内容的平均时间"，光数据清洗就花了两天，最后还因为时区问题算错了。产品经理又来找我："能不能把日志格式统一？"我指着他电脑上的Excel表格说："你们连时区都能算错，统一格式有什么用？先把基础逻辑理清楚再说！"

　　现在回头看，去年二月的架构升级虽然踩了坑，但至少让我们看清了问题的本质——日志不是越多越好，也不是越统一越好，而是要"恰到好处"。通讯、推送、内容分发这三个模块，就像三个性格迥异的室友：通讯模块爱干净，推送模块爱热闹，内容分发模块爱囤东西。硬让他们住一个房间，迟早要打架；分开住，各自布置自己的空间，反而能相处融洽。至于产品要的"统一分析"？等他们学会用Python合并数据再说吧——反正我工位上的咖啡机还没修好，没精力陪他们折腾。

（编辑：站长网）

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