导读
APP运营系统是一个复杂但至关重要的体系，旨在确保 APP 能够有效地吸引用户、留存用户并实现商业目标。通常运营系统分为投放引擎和分发引擎两个核心模块，投放引擎的难点在于复杂的业务逻辑，分发引擎则需要承受巨大的流量压力。本文主要分享我们在建设高效的运营平台过程中积累的一些经验以及面临的挑战和思考。
背景
由于分发服务是面向用户层面，高可用、高性能、高扩展性是分发服务必须具备的特点，因此分发引擎优化是一个持续的、综合性的工作，需要不断地投入和创新，以适应不断变化的需求和技术发展。
瑶光运营平台
图1. 瑶光运营平台的架构全貌
图2. 投放引擎
-
排期管理：由业务线人员发起请求，平台运营人员进行审核，解决完排期冲突后，审核通过便可进入创建策略阶段。 -
创建投放：业务线人员补充对应的图片、视频、文案、跳转链接等素材信息，完成策略的创建并提交OA审核。 -
审核管理：平台运营人员对投放进行审核，不符合的会打回重新提交，符合条件的投放会通过后同步到分发引擎的前置服务。 -
投放管理：针对已上线的投放进行下线、编辑、复制等操作。 -
数据看板：综合查看各个维度的投放效果数据和明细数据。 提供详细的数据分析和报告，了解投放的效果和用户反馈，以便做出更明智的决策。 -
策略配置：针对线上的投放，数据效果表现不佳的可以实时修改分发策略，通过权重、阈值等手段控制各个投放的曝光流量。
3.2 分发引擎
分发引擎由前置服务和分发服务两部分组成。
图3. 前置服务和分发服务
-
前置服务是分发服务的数据源，对数据格式进行同步改造，使得分发服务数据做到统一格式，前置服务同时也是人工干预的入口，针对程序无法处理的问题可以人工介入，前置服务提供了丰富的接口，同步数据，编辑数据，灰度测试等。 -
分发服务则是投放的出口，流量承压系统，需要高效的缓存体系来应对巨大的流量冲击。
3.3 分发引擎优化实践
本次优化针对分发引擎的分发服务进行优化，也就是针对高并发流量的优化。
1. 优化前
如下图，该架构的核心是以分布式缓存redis作为中心化的数据源，作为最终数据来源，同时对于请求里同一个用户的多个维度参数相同的请求，以本地缓存为辅，应对相同请求可以快速处理，这是常见的重复请求处理方案，效果很好。
图4. 优化前架构
缺点是针对海量不同用户的请求仍然力有未逮，会造成大批量的请求打到中心化的redis服务器上，给redis造成很大的压力，超过阈值则会导致服务不可用，存在中心化依赖则无法通过水平扩展服务的方式解决高并发和海量流量的问题。
2. 优化后
运营数据，无论通过数据库的落地方案、还是redis分布式缓存，都无法彻底解决服务中心化和服务抖动。通过实现数据的本地缓存更新机制，解除对中心化服务的依赖，提升服务稳定性和性能。同时整个分发服务变成可水平扩展，在扩展过程中也不会影响中心服务的稳定性。
图5. 优化后架构
-
被动同步：投放的上线、编辑、下线等操作实时同步分布式缓存，分布式缓存数据的变动通过发布订阅模式主动通知订阅者，多个订阅者准实时的更新自己的本地缓存，缺点是可能在服务重启时未订阅到变更，解决方案是通过主动同步方式 -
主动同步：实例启动时候会主动从redis获取数据同步到本地缓存；启动中的实例通过定时任务主动与分布式缓存同步数据
总结
-
高可用：通过实现本地缓存，同步异步更新解决缓存导致数据不一致问题，即使存在部分实例宕机，也不影响整体服务可用性 -
高性能：缓解中心服务的流量压力，所有流量请求到本地服务的缓存，即内存数据，是目前最高性能的解决方案 -
高扩展性：去除了中心服务依赖，分发服务相当于单机服务，应对大数据量和高并发的冲击可通过水平扩展解决
本文分享自微信公众号 - 58技术（architects_58）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
