如何设计一个亿级企业消息平台
来源 | OSCHINA 社区
作者 | 京东云开发者-京东零售 李孟冬
原文链接：https://my.oschina.net/u/4090830/blog/7867714
VOP作为京东企业业务对外的API对接采购供应链解决方案平台，一直致力于从企业采购数字化领域出发，发挥京东数智化供应链能力，通过产业链上下游耦合与链接，有效助力企业客户的成本优化与资产效能提升。本文将介绍VOP如何通过亿级消息仓库系统来保障上千家企业KA客户与京东的数据交互。
客户调用场景
消息仓库V1.0
消息仓库V2.0
分库新旧流程对比
分库新旧流程比对切换依据（供参考）
根据 ducc和 clientId决定是否写入到新库，ducc（bizMsgTransDbJson）中配置了切换开关、白名单、黑名单和分流范围
使用新库写入时，根据 clientId.hashCode % dbSource.size，得出使用哪个 dbSource
客户读取时，先从旧库查出，若无数据，则再读取一遍新库，dbSource选取方式同上
客户删除时，判断删除 ID是否大于一万亿（1000000000000），大于取新库，小于取旧库
痛点问题
海量数据：19年客户量及商品品类（商品量级）的大幅增加，及最初分库时提升了消息数据的存储时长由2-3天提升至7天（原因：考量政府、银行等客户重保期间不消费消息的空档期，但是后期验证空档期长达月维度），消息仓库的流量出现了频繁翻倍的增长，数据不均衡的情况也逐渐显现出来；
字段扩展：随着业务不断的演进，消息内容也逐渐复杂（如售后消息 会附带各环节信息，整个JSON消息体较大），入库或存在字段长度限制，调整字段较难；
高可用&扩展性：原有单体架构的情况，会有热点数据的冲击及热点商品类消息数据对订单类、对账类消息数据的写入和同步带来严重的时延问题及服务性能跳点问题。
运维成本高：由于面向广大开发者，因此系统必须兼顾各种各样的网络环境问题，开发者能力问题等。企业对接客户常常来咨询消息量及消息消费情况，内部无对应的审计数据可供参考。
目标
方案分析
存储成本：MongoDB存储优势明显——数据压缩和无冗余存储，相比Mysql+es会减少50%以上的总数据容量。
开发运维成本：MongoDB不需要数据同步，减少开发和运维难度；字段调整方面Mysql+es的架构下对于业务附带抖动风险，DDL相关问题风险高，易出错；MongoDB开发维护成本，存储架构简单，无数据一致性压力；扩容方面，MongoDB支持随时动态无脑扩容，基本不存在上限问题，但是Mysql的扩容需要保证hash一致，迁移数据灰度等情况，周期长且高概率存在对业务影响。
性能对比：经过压测，同样的4C8G的机器配置下，MySQL和MongoDB在大数据量下写性能基本一致。MySQL的读性单分片约6000QPS左右，ES的性能只有800QPS左右。而 MongoDB 单分片地读性能在3万QPS左右，远高于MySQL和 ES 的性能。
消息仓库V3.0
没有完美的架构，只有刚好的架构，没有满足一切的架构，只有满足目标的架构
消息接收阶段（vop-worker） ：该系统仅关注不同消息源的接入，当前已接入中台近百个消息源，且依赖BTE任务平台、订单&商品池&主数据&消息中心等服务，通过过滤，清洗，封装等手段封装需入库的业务消息数据中转发出。
消息中转阶段（JMQ集群） ：将消息中转出来，分级管控，当前分为四级，以此解决核心消息消费不及时，部分时段CPU内存飙升的问题。分级别设置消费线程数，低级别消息不影响高级别消息消费。低级别消息具备降级能力。
消息写入阶段（vop-msg-store） ：消息写入阶段，批量双写，MongoDB+ES（支持多维度的运维审计查询及数据导出）。MongoDB解决tps10000+、数据量日均5亿+、多查询条件和数据分布不均匀的问题，解决数据库无法支撑租户数据均匀和消息内容可扩展的问题；创建mongo表，设置租户id和事件id索引、设置租户id的分片规则、设置唯一索引和超时时间45天。ES解决消息运维过程中，审计、核查等问题。
消息可视化阶段（vop-support-platform） ：解决对客户生产/消费能力无认知、全局消息不可控和消息可视化的问题。并且数据可视化的不断完善又会反哺架构的可用性提升，为后续我们设立的优化专题打下坚实的数据基础。
补充：MongoDB分片集群无单点故障的原因——当 MongoDB 被部署为一个分片集群时，应用程序通过驱动，访问路由节点， 也就是 Mongos 节点 Mongos 节点会根据读写操作中的片键值，把读写操作分发的特定的分片执行，然后把分片的执行结果合并，返回给应用程序。那集群中的数据是如何分布的呢?这些元数据记录在 Config Server 中，这也是一个高可用的复制集。每个分片管理集群中整体数据的一部分，也是一个高可用复制集。此外，路由节点，也就是 Mongos 节点在生产环境通常部署多个。这样，整个分片集群没有任何单点故障。
支撑日均消息写入量5亿，现支持6wTPS和1wQPS
TP99从100ms提升至40ms，在高吞吐量情况下性能表现平稳
新架构边界清晰，新需求不涉及核心系统的改造
数据有效期7天提升至45天
It成本0增长
消息可视化方面大幅提升运维效率，已全面开放技术客服使用
消息仓库V3.0+（回首往事）
锁定目标定后,剩下的只是迈步朝它慢慢走下去。
流量治理（峰值情况下裁剪亿级消息量）
2）a、无效客户管控（LoadingCache），由于其他端外界客户接入VOP，存在部分不消费消息的无效客户，需进行主动屏蔽，以此解决无效客户消息中转存储的问题。b、缓存，减少耗时操作等等。
3）消息过滤器（jimdb），通过防重控制+时间窗口对客户未消费且重复sku进行去重，以此解决客户消息消费延迟，客户消息量大，重复消息多，客户系统重启后消息量巨大的问题，并大幅减少我侧MongoDB存储数据量。
这里补充一个小插曲，在流量治理过程中，我们也在数据中发现了一些问题，并作为指导我们产品优化的数据支撑，通过技术手段进行优化和处理。**如：通过数据分析，我们在整个消费过程中，部分客户（如：联通）消费较慢或者无效消费导致信息同步不及时的问题，因此从技术角度出发与客户技术侧沟通，通过建立自动补推功能，来提升客户与京东的同步率，即通过自助补推功能，来辅助客户同步异常情况下二次同步，以价格变更为例，通过客户下单价格不一致，来自助补推价格变更消息，以此挽回由于客户同步异常导致异常的订单，提升客户成单率， 进一步提升整体GMV产出。
这里也给我带来思考，无论引入还是自研，无论架构还是工具，落到实处，真实解决业务中的问题，在降本增效中带来价值，不论大小，均为创新。
系统稳定性（解决cpu毛刺及分片热点问题）
降低成本（非活动期间，白天消息量级相对晚上较少）
小结
展望
保持工匠精神，精益求精：在保证系统稳定性和扩展性的同时，以业务为重点，持续践行数据驱动的实践方法，进一步提升客户和VOP双方系统的各类消息同步率，通过技术手段不断优化产品，提升客户搜索体验及下单成功率。
消息数据治理：无论消息推送还是消息拉取方面都有一个极其明显的特征，在客户系统消费水平足够好的情况下，大部分数据是会在几秒内进行写删各一次，两次操作完成这条数据就失去了意义。（以前天为例，有3000W+消息数据生产消费几乎同速率）在这种场景，使用任何存储介质本身就不合理，就像是在存储介质中插入一条几乎不会去读的数据。这样生命周期极短的数据放在存储介质中，不仅资源浪费，也造成存储介质成为系统未来的瓶颈。考虑服务器本身的成本问题，可以针对升级过滤器或者参考计算机三级存储体系结构的思路，未来将大量的此类消息事务在Memory内完成，其他消息按照原有方式进行操作，该方式下千万级消息事务在Memory内完成，节省大量服务器资源。
推送方式标准化：轮询状态下，数据的实时性终究依赖于客户应用的轮询间隔时间，该方式下，API调用效率低且浪费机器资源，如何结合业务侧推动数据推送标准化，给客户提供实时可靠的双向数据交换通道，大大提升API调用效率也是我们后续着重考虑的方向。
END
这里有最新开源资讯、软件更新、技术干货等内容
点这里 ↓↓↓ 记得 关注✔ 标星⭐ 哦
微信扫码关注该文公众号作者