01 导读

　　APP运营系统是一个复杂但至关重要的体系，旨在确保 APP 能够有效地吸引用户、留存用户并实现商业目标。通常运营系统分为投放引擎和分发引擎两个核心模块，投放引擎的难点在于复杂的业务逻辑，分发引擎则需要承受巨大的流量压力。本文主要分享我们在建设高效的运营平台过程中积累的一些经验以及面临的挑战和思考。

　　02 背景

　　瑶光运营平台是一个灵活的管理平台，可以通过人群画像、APP版本、日期、地域、渠道等不同的维度，对APP各个页面的运营位进行方便的运营管理。

　　随着运营位数量的增多以及运营位的复杂度的提升，投放上的难度是较为容易处理的，然而到达分发端的时候，逻辑处理会变得更加复杂，原因是由于分发服务是流量承接处，某个维度的过滤逻辑处理效率低会被大量的请求无限放大，反馈到服务层面就变成了服务的可用性急剧降低，甚至可能会出现某一个运营位的分发逻辑变更导致整体服务的响应雪崩现象。

　　由于分发服务是面向用户层面，高可用、高性能、高扩展性是分发服务必须具备的特点，因此分发引擎优化是一个持续的、综合性的工作，需要不断地投入和创新，以适应不断变化的需求和技术发展。

　　03 瑶光运营平台

　　瑶光系统是一款专为 App 内运营位配置而设计的产品，它为运营人员提供了高效、便捷的配置工具。通过瑶光系统，运营人员可以轻松管理和定制 58同城App 内的运营位，实现内容的精准推送和个性化展示。瑶光系统具备智能化的推荐算法和数据分析功能，能够根据用户行为和偏好进行精准的内容推荐，提升用户体验和运营效果。同时，瑶光系统还支持多维度的数据统计和分析，为运营决策提供有力的参考依据。截止2024年8月份，已经有15个业务线接入、35个运营位投入使用。　　

图1. 瑶光运营平台的架构全貌

　　3.1 投放引擎

　　投放引擎主要由排期管理、创建投放、审核管理、投放管理、数据看板、策略配置等6大核心模块组成。从业务线运营人员申请排期开始，通过OA审核流程一步步引导用户完成最终投放，运营人员可以根据数据查看效果并且实时变更投放的策略。　

图2. 投放引擎

　　排期管理：由业务线人员发起请求，平台运营人员进行审核，解决完排期冲突后，审核通过便可进入创建策略阶段。

　　创建投放：业务线人员补充对应的图片、视频、文案、跳转链接等素材信息，完成策略的创建并提交OA审核。

　　审核管理：平台运营人员对投放进行审核，不符合的会打回重新提交，符合条件的投放会通过后同步到分发引擎的前置服务。

　　投放管理：针对已上线的投放进行下线、编辑、复制等操作。

　　数据看板：综合查看各个维度的投放效果数据和明细数据。提供详细的数据分析和报告，了解投放的效果和用户反馈，以便做出更明智的决策。

　　策略配置：针对线上的投放，数据效果表现不佳的可以实时修改分发策略，通过权重、阈值等手段控制各个投放的曝光流量。

　　3.2 分发引擎

　　分发引擎由前置服务和分发服务两部分组成。　　

图3. 前置服务和分发服务

　　前置服务是分发服务的数据源，对数据格式进行同步改造，使得分发服务数据做到统一格式，前置服务同时也是人工干预的入口，针对程序无法处理的问题可以人工介入，前置服务提供了丰富的接口，同步数据，编辑数据，灰度测试等。

　　分发服务则是投放的出口，流量承压系统，需要高效的缓存体系来应对巨大的流量冲击。

　　3.3 分发引擎优化实践

　　本次优化针对分发引擎的分发服务进行优化，也就是针对高并发流量的优化。

　　1. 优化前

　　如下图，该架构的核心是以分布式缓存redis作为中心化的数据源，作为最终数据来源，同时对于请求里同一个用户的多个维度参数相同的请求，以本地缓存为辅，应对相同请求可以快速处理，这是常见的重复请求处理方案，效果很好。　　

图4. 优化前架构

　　缺点是针对海量不同用户的请求仍然力有未逮，会造成大批量的请求打到中心化的redis服务器上，给redis造成很大的压力，超过阈值则会导致服务不可用，存在中心化依赖则无法通过水平扩展服务的方式解决高并发和海量流量的问题。

　　2. 优化后

　　运营数据，无论通过数据库的落地方案、还是redis分布式缓存，都无法彻底解决服务中心化和服务抖动。通过实现数据的本地缓存更新机制，解除对中心化服务的依赖，提升服务稳定性和性能。同时整个分发服务变成可水平扩展，在扩展过程中也不会影响中心服务的稳定性。　　

图5. 优化后架构

　　如上图，该架构的核心是以redis作为分发数据源，以本地缓存作为最终数据来源。本地缓存数据为主，则问题的关键转移到分布式缓存同步本地缓存的数据一致性问题上。通过主动加被动两种方式保证本地缓存与redis中的数据保持一致：

　　被动同步：投放的上线、编辑、下线等操作实时同步分布式缓存，分布式缓存数据的变动通过发布订阅模式主动通知订阅者，多个订阅者准实时的更新自己的本地缓存，缺点是可能在服务重启时未订阅到变更，解决方案是通过主动同步方式

　　主动同步：实例启动时候会主动从redis获取数据同步到本地缓存；启动中的实例通过定时任务主动与分布式缓存同步数据

　　通过最终数据源从分布式缓存转移到本地缓存，解决了中心化依赖的问题，平均响应时间降到4ms以下，提高了系统的可靠性和扩展性，应对高并发的请求。

　　04 总结

　　本文主要介绍了我们在建设运营平台过程中积累的一些经验以及面临的挑战和思考，先根据分发引擎的特点和面临的痛点提出设计原则（高可用、高性能、高扩展性），之后依据原则去思考和实现具体技术方案：

　　高可用：通过实现本地缓存，同步异步更新解决缓存导致数据不一致问题，即使存在部分实例宕机，也不影响整体服务可用性

　　高性能：缓解中心服务的流量压力，所有流量请求到本地服务的缓存，即内存数据，是目前最高性能的解决方案

　　高扩展性：去除了中心服务依赖，分发服务相当于单机服务，应对大数据量和高并发的冲击可通过水平扩展解决