营销通用发放设计及实现

点击「百度外卖技术团队」可快速关注

本文主要介绍了外卖营销方向，对外对内发放代金券，余额，兑换码等的统一解决方案——外卖通用发放平台的设计及实现，以方便使用和接入，降低开发成本，集中管理。

随着外卖和其他第三方联合运营的不断推广和合作，外卖对内对外的合作发放虚拟or实物物品的需求越来越强烈：比如合作发外卖代金券、外卖余额，或者外卖发糯米代金券、爱奇艺vip码等。在发放的基础之上又融合了各种发放的策略，而种类多样的策略设计每次都需要重新设计和开发。除此以外，查询和统计等需求并没有可靠方便的机制进行保证，无疑又增加了开发的工作量。

为了更好的服务联合运营需求，降低各业务方接入各类发放通道的开发和工作量，通用发放系统的需求也就应运而生：建立一个功能完善、易扩展、方便接入和使用的通用发放平台，服务于整个外卖公司的对内对外的各类发放需求。

整体系统流程架构图如下：

整个系统主要包括四层，接入层，策略层，服务层，数据层

✦ 接入层：主要对接入方的访问做权限校验，对请求频次做流量控制。

✦ 策略层：主要是做一些策略抉择，如发放类型，组合发放控制。

✦ 服务层：下游服务，对接内部和外部基础服务，如代金券发放，余额发放等。

✦ 数据层：将整个调用过程使用消息队列，异步记录日志，方便做问题追踪和实时监测。

内部授权平台设计两种权限：创建者和管理员的权限。

一、创建者可以由外卖内部人员进行创建，但没有审批授权上线的权限，创建后需通知给管理员进行审批。创建者在非上线状态可以进行编辑，上线后则不可编辑。创建者可以下线自己的授权活动。

二、管理员可以直接创建授权并审核上线，同时也可以进行下线操作

整个授权过程无需研发再次介入，可由管理人员在界面直接操作，进行整体控制；同时设计测试的联调活动用于外界联调测试。

授权主要分为对外业务授权和对内授权，对外授权需要生成通用des加密的对应token。授权信息保存在redis中，降低检验耗时，同时在db中冗余一份。

目前接入了多个业务方向的代金券，后期可接入组合发放等其他需求。

活动状态流转图：

详细功能点说明：

1.普通创建人只能看到自己创建的活动和状态，看不到别人创建的活动；管理员则可以看到所有的。

2.活动保存后可以编辑的信息：基本信息中的活动名称，结束时间；策略的编辑只能由管理员进行，如增删批次id，授权新的api等。

3.活动授权上线后只能由管理员进行批次的添加和修改；授权前可以由创建人自由修改。

4.活动下线后，可重新编辑后进行保存，并由管理员再次审核上线。

5.策略信息中点击批次id可以跳转至批次信息详情页面。

流量控制，使用脚本定时监控接口调用qps，平衡各接入方的接口qps，检测到qps到了预警值，根据各接入方的最高允许qps，按比例设定当前时间各个接入方的调用qps来进行调控，保证整体qps在预警值之下,保证系统的正常访问。

最理想的服务隔离设计，是在包括域名、集群、数据库、缓存等进行完全的隔离，保证服务的稳定性，降低与其他服务的依赖，具体设计如下：

1.申请独立域名和独立部署模块，包括机器集群，数据库，缓存等等。

2.qps总压力限制分内外部设计，内部调用方优先级高于外部调用方。

3.接入压力实时反馈，流控算法进行防御式限流。

4.内外接入方的统计信息消息进行隔离，消息队列拆分单独维护，异步统计。

在可视化平台，可以查看各个接入端的调用情况，做到实时监控，目前只做到监控各端调用频次，后期可以接入调用响应的字段统计，超时等等性能数据。

图为测试环境模拟实时调用效果图，如图为三个调用方同时调用通发服务，第一个交叉点检测到流量超过预制，脚本自动干预调控流量保证整体流量可控；第二交叉点检测到流量下降，恢复各接入方调用。

接口重入考虑，通发平台大部分接口是写入性接口，在一些重要业务场景如余额，高额代金券的发放必须要考虑到接口重入性，防止多发。由于通发平台，不做具体业务，重入的保证很大程度依赖业务下游来保证；通发平台再次基础上再次做了优化：

1. 第一次调用在下游上锁之后，把锁同步到通发平台，锁采用单线程模式的redis来实现。

2. 再次调用时验证锁的存在，这样在调用下游之前能够截住很大一部分不必要调用下游的重入流量，解决重入的同时，较低了对下游的压力。

▼
▼

‍

流沙，百度外卖用户产品部营销代金券方向负责人。负责外卖代金券对内对外相关业务的研发，主导研发通发平台，使得内部外部接入外卖券更高效、更可控、形成有效闭环，支持业务发展，致力于高并发情况下，保证代金券服务稳定性，支持外卖千万级代金券发放能力。

百度外卖用户产品部团队，直接面向用户，以用户需求为导向，致力于提高服务响应速度，丰富产品功能，优化用户体验，技术上以服务稳定性为宗旨，快速迭代，满足用户产品需求，期待与同行保持交流，共同进步。