前言
常见的营销活动，总结来看就是“在各种限制条件下对于适合的人群进行适合的激励，从而完成拉新、促活等阶段性目标从而促成盈利”，每次进行的营销活动涉及到的激励规则不尽相同，但是涉及到的权益都比较类似，每次变的往往都是奖励规则、定价规则这些。结合最近的这几篇文章：“规则引擎在在营销活动中可以有的实践”、“底层代币账务模型” ，看看上层具体的使用，如果让发奖变得高度可配、功能更加强大。技术永远是以解决现实问题为导向的。
奖励发放的问题域
常规的抽奖、直接奖励发放难道满足不了活动场景下的奖励发放问题吗？为什么需要单独抽象一层奖励规则层，问题同方案一样重要，下面咱们就来看看活动发奖场景下的各类问题：主要从功能局限性、工程效率问题、维护成本、技术上的数据一致性保证来进行阐述。
各式各样的玩法儿 – 功能局限性
关于营销活动中的奖励发放的规则可谓是层出不穷，抽奖、领奖、瓜分、预领奖、组团红包等等若干，并且里面又会涉及各种匹配规则，不同人的不同的场景下，不同的奖励类型不同的奖励定价。我们没办法用代码穷举出所有的所有的情况并且全部代码的方式落地，即使能，整体的成本也是非常高的。 面对运营的各种花式诉求，选择一个降级“大致可以的”方案，我们实际上在限制运营的手段，比起其原本的想法，太多功能上的降级方案可能导致活动效果大幅度下降，针对奖励发放功能的局限性是首要需要解决的问题。
修改频繁 – 工程效率问题
文章一开始就提到了“在各种限制条件下对适合的人群进行适合的激励”，常见活动的整体玩法儿通常是相对固定的，但是其中针对目标的激励规则往往差异较大，看上去两次近乎相同的改动，比如说抽奖可能奖励方式就有很大差异：概率规则、概率模式、用户、库存、互斥等限制都可能是不同，面对各种时间紧 任务重的逻辑每次去打补丁改代码往往是不现实的。 即使核心规则确定，随着活动的进行，其中的奖励规则也是会伴随效果不断修改的，根据周期一个月活动，规则修改往往能到20次左右，并且都是属于效果反馈得出的预期内的合理改动。 能够快速落地一个活动奖励、在活动期间动态修改是一个非常突出的问题。
代码愈发的膨胀 – 维护代价
一个系统成长初期，本着快速迭代快速支持的目的，面对数量庞大的发奖规则、往往都是倒排的需求，通常会产生大批量的if-else各式各样的补丁，这里一块儿抽奖的逻辑，那里里一块瓜分的逻辑。实事求是，那些代码不是垃圾也基本是一团毛线似的逻辑。这些逻辑代码一定会在系统膨胀的过程中变成绊脚石，如果系统再经过几次交接，后果会变得不敢想象。 为了将来自己不被埋起来，所以必须对这部分逻辑就行收敛、抽象、重构，降低关于发奖的逻辑的维护成本，以此提升活动研发的工程效率。
数据一致性要求
整体来说活动场景的数据一致性要求并不是很高，但是奖励相关除外，奖励几乎可以说是一个活动的核心，而且数据不一致带来的问题往往会非常严重：大量客诉、资损。 先说客诉：用户费老劲达标获得奖励，奖励竟然发失败了，并且失败之后只能自认倒霉，实在太难为用户了，如果活动量级比较大甚至会带来舆情。 资损：资损往往都是数据不一致导致的，钱超发、不正确的时机发 都属于资损的范畴。 但是很多系统中奖励逻辑太多分散，补丁打的太多，不可能每个维护者都十分清楚某个角落的发奖逻辑其中一个if背后的逻辑，一旦修改异常数据不一致瞬间发生，并且由于逻辑太过分散，监控和对账很难全部覆盖从而导致，维护者一直被“蒙在鼓里”。
解决思路
可以有的方案
上面提到了n多的问题，汇总来看其实是营销活动核心的奖励问题的解决 “在一定的限制条件下，按照一定的规则对于用户进行合适的权益激励”，我们要封装的变化就是这部分“匹配”、“定价”的业务规则，然后收敛核心功能块。 1、对于易变的人&奖品之间的匹配选择规则、对于奖品的选择规则，我们可以通过集成之前提到的“规则引擎”，通过表达式来收敛这部分逻辑。 2、对于易变的出奖规则，比如概率抽奖、不放回抽样、全发等策略，我们可以单独维护成一个个的插件，用时选择，面向新增开发即可。 3、对于n多限制逻辑，比如库存限制、用户中奖限制、奖品间的中奖互斥逻辑，我们可以对于这部分逻辑开发通用的限制服务，同样基于插件的思路，用时配置插入即可。 这样所有的业务规则就变成了 我们系统的表达式输入，所有的发奖过程中的通用策略都被我们搞成了插件，再怎么变也不怕了。
盘一下整体的架构
对于营销系统来说这块通常存在于玩法之下，权益之上
首先我们有一部分系统处理的关键节点包括：并发、幂等控制、奖池的匹配及限制、发奖模式（出奖）、奖励定价、库存限制、用户限制、互斥限制等关键的功能节点，各节点内部的逻辑均可配置选择。
一个demo
以一次不同人群面向不同奖品集合的例子来说 对于选择：riskLabel == “normal” && userLabel == “new” && joinTimes in (3, 6, 9) 指向奖品集合A 奖品集合中存在奖品：1、2、3、4，由于出奖数量为1，按照概率抽出了奖品2，而奖品2为随机金额现金红包 对于定价：对于奖品2 进行定价：rand(1, 10) + (expectAmountSum – userHasReward) / surplusTimes 然后对于用户抽中的奖品2 ： 扣减库存、检查用户限制、检查奖品互斥限制 完成真是发奖，并触发用户发奖相关动作。
如何保证易用性
这个模块直接把配置暴露给运营是十分不友好的，即使有一个看上去像模像样的后台，这块仍让没有一个相对较好的解决方案，也希望大家能够提供一些好的idea。 下面是我想到的方式： 对于发奖、限制的选择我们可以通过提供选项的方式暴露给运营。 最头疼的规则，我们可以在B端配置n组常用的规则模版，运营只需要选择模版，然后适配参数即可。
写在最后
核心思路是围绕未来可预见的问题（需求也被看作问题的一种）及方向，不断的权衡质量和效率来抽离业务决策规则与代码决策规则，让代码变的整洁，让架构变得整洁。 这一篇算是对于代币服务、规则引擎 在奖励这个具体场景下的使用方式，其他业务场景也是需要根据业务特性，场景特点进行整合适配的，举个例子，一些服务费的定价逻辑、文章或者关键词的过滤筛选规则、资金或者说资产的定价、账务里的一些清分规则。 就写到这里了，有不足的地方还请大家指点～
