三年元数据架构设计，支撑创业项目0到10亿增长

　　去年七月那会儿，我正蹲在机房改元数据血缘分析的SQL——空调坏了，汗顺着后颈往下淌，运维小张蹲在旁边啃煎饼，油滴在服务器托盘上，他擦都不擦，说“反正这批机器下个月就淘汰了”。当时我们刚把元数据架构从单体拆成微服务，数据量从每天三百万条涨到三千万，老架构的ETL任务卡得死死的，凌晨三点还在跑批，产品经理在群里骂“用户看不到数据还用什么产品”。我原以为拆完微服务就能松口气，结果新问题跟着就来了——元数据版本控制炸了，A团队的变更把B团队的血缘关系冲了，两边在飞书群里吵了俩小时，最后发现是配置中心没做权限隔离。那会儿我盯着监控大屏，看着错误率从0.3%飙到5%，心想这破架构怕是要黄。

文章配图，仅供参考

　　但最让我后怕的不是技术问题，是去年双十一前一周。那天暴雨，我打着伞去机房，裤脚全湿了，进门就看见测试小妹蹲在服务器前哭——她负责的元数据质量检测脚本跑不通，可双十一的促销活动数据全指着这脚本。我凑过去一看，好家伙，她用的还是老架构的API，新架构的字段名全改了，文档里没写清楚。我一边骂文档组“这都能漏”，一边帮她改脚本，改到一半，产品经理冲进来喊：“数据延迟了！用户看不到实时销量！”我抬头看了眼监控，新架构的实时采集模块确实卡了，但老架构的备用通道还在跑，赶紧切过去，数据延迟从三分钟降到十秒。那天晚上，我蹲在机房门口抽烟，想着要是没做备用通道，这项目怕是要凉在双十一前夜。

　　说到备用通道，其实一开始我们没打算做。当时CTO说“微服务容错率高，不用搞双活”，我信了，结果第一次大促就栽了——某个元数据存储节点挂了，整个采集链路卡死，用户端显示“数据加载中”，投诉炸了。后来我们咬着牙加了备用通道，虽然多花了20%的服务器成本，但换来的是99.99%的可用性。现在回头看，这钱花得值——去年双十一，我们扛住了每秒十万的元数据写入，备用通道一次都没用上，但我知道，它就像灭火器，平时看着没用，真着火的时候能救命。

　　不过也不是所有“优胜劣汰”都顺顺利利。有次我们想用图数据库优化血缘分析，测试环境跑得飞快，结果上线后，生产环境的图数据库把CPU吃满了——原来测试环境的数据量只有生产的1/10，图数据库的查询复杂度是O(n²)，数据量一上来，性能直接崩了。最后我们只能回滚，改用关系型数据库加缓存，虽然慢点，但稳定。这事儿给我整明白了：技术选型不能光看测试数据，得把生产环境的极端情况考虑进去，不然就是给自己挖坑。

　　现在项目数据量快到十亿了，元数据架构还在跑，但我知道，它早晚会被更优的架构淘汰——就像我们淘汰老架构一样。上周五下班前，我收到一封邮件，是新来的架构师写的方案，说要用Serverless重构元数据采集模块，成本能降40%。我看了眼，没急着回复——先让他在测试环境跑跑，优胜劣汰嘛，能跑通再说。

（编辑：站长网）

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