苏宁集团业务涉猎非常广，主要包括：苏宁易购，苏宁金融，苏宁体育，苏宁文创，苏宁置业，苏宁门店等业务领域。本文所阐述的是从 2015 年至今，苏宁金融营销系统的发展历程。苏宁金融营销系统不仅支撑了苏宁金融营销业务，也支撑了苏宁易购，苏宁体育，苏宁门店等部分营销业务。
2015 年至今，为了适应苏宁集团的发展，苏宁金融营销业务方陆续提出了很多目标。
可以总结为五大功能目标：
为了适应业务的发展，解决业务的需求，我们团队开启了苏宁金融营销系统重构之路。
2015 年，系统架构 V1.0 时代，苏宁金融营销系统包括：促销服务、电子券服务、任务服务。
促销服务：提供促销活动查询、扣减、管理、规则处理、活动配置等功能。
电子券服务：提供电子券管理、查询、使用、退券、规则处理、活动配置等功能。
任务服务：提供判断用户是否满足任务的规则，且事后发放营销福利的功能。
经过梳理上述系统的上下文，应用架构，核心功能。针对架构方面分析出如下问题：
1. 职责不清晰。
当时系统架构，电子券服务与促销服务，互相调用，两者的上下游系统基本一致。其实电子券服务和促销服务都是一种营销“实体”，它们只需要具备“实体”管理的基本功能，而且相对独立，各自为政。
2. 缺乏统一的活动管理。
当时系统架构，电子券服务和促销服务都包含活动管理和配置，并且分散管理。
这种情况下，无法满足活动全流程闭环管控，活动申请、预算控制等需求。
3. 缺乏营销数据分析。
当时系统架构，所有的营销行为数据都未记录，或者是分散记录。
这种情况下，无法满足营销数据可视化，活动效果数据分析等需求。
规则引擎引发的“血案”。
规则引擎及规则资格校验是一个计算资源消耗非常大的功能。营销前台、促销服务、电子券、任务服务都包含此功能。随着活动形式的持续增长，消耗的计算资源也持续上升。多个系统同时申请资源，导致资源的浪费。尤其是 818、1111 大促期间。资源申请需要与资源管理部进行博弈，有时会引发‘血案’。
2015 年至今，针对系统架构问题，系统不断的迭代，我们采用了很多针对性的解决方法。
1. 分工明确化。
电子券服务和促销服务作为一种营销“实体”，它们只需要具备“实体”管理的基本功能，而且相对独立。在它们的上层抽出一个统一营销服务，统一的对外服务。
2. 建设统一活动中心。
建设统一活动中心，包括：营销活动管理、营销活动审批、预算管控、促销状态管理、促销结算等。满足活动全流程闭环管控，活动申请、预算控制等需求。
3. 建设营销数据中心。
建设营销数据中心，包括：营销行为数据都采集，存储，分析，报表。满足营销数据可视化，活动效果数据分析等需求。
4. 拆分出规则引擎。
独立的规则引擎系统，承载上游所有促销形式的规则计算，节省资源。
现在，苏宁金融营销系统架构 V2.0 时代，总体架构图如下，苏宁金融营销系统以整体的形式一致对外服务，不再是“单干”。
图 1：整体系统架构 V2.0
核心系统包括：营销统一服务、促销服务、电子券服务、任务服务、商品详情页促销前置服务、营销规则引擎、营销规则资格校验、营销活动中心、营销数据中心。
营销统一服务：促销查询、扣减；电子券查询、使用、退券等统一对外服务。
促销服务：提供促销活动查询、扣减等功能。
电子券服务：提供电子券管理、查询、使用、退券等功能。
任务服务：提供判断用户是否满足任务的规则，且事后发放营销福利的功能。
商品详情页促销前置服务：应对流量较高的商品详情页、搜索等页面提供的促销查询服务。
营销规则引擎：提供促销、电子券、任务等规则引擎处理服务
营销规则资格校验：提供促销、电子券、任务等规则资格校验服务
营销活动中心：包括营销活动管理、营销活动审批、预算管控、促销状态管理、促销结算、规则分发、促销活动下发。
部分系统上下文如下：
图 2：统一营销服务系统上下文 V2.0
图 3: 任务服务系统上下文 V2.0
图 4: 商品详情页促销前置服务系统上下文 V2.0
自苏宁金融营销系统建立以来，尤其是 2015 年开始至今，业务迅猛发展，团队在实际系统运行过程中，遇到了不少麻烦，但我们的小伙伴坚忍不拔，各个突破，让系统稳定的度过每个大促节点。
1. 用户流量上升，活动种类增加，导致规则引擎与资格校验性能下降
2015 年，同一时间同时生效的营销活动已经接近 300 个。由于苏宁集团业务复杂，涉及线上，线下。因此，业务的活动种类诉求会越来越多。另一方面，苏宁金融与苏宁易购合作之后，用户访问量爆发性增长，业务及产品层面上，越来越重视用户体验。
2015 年，苏宁金融营销系统架构 V1.0 时代，未对营销场景做细致的区分，导致每次匹配相关规则是全量匹配，全量匹配结束后的资格校验也是全量校验，导致单人次请求后，系统过滤规则数据量较大，并且校验次数增多，特别是大促中活动增加的情况，单次用户请求，规则校验平均需要执行大约 1000 次以上方能匹配到用户实际能够享受的营销活动信息。
图 5：营销活动规则校验流程 V1.0
另外，规则引擎和资格校验服务未独立，促销服务、电子券服务、任务服务只能不断通过横向扩容，提高系统并发能力。显然这样做，一方面资源浪费，另一方面当活动种类增加后，单机的计算耗时上升，横向扩容能够提升的并发能力有限。
现在，苏宁金融营销系统架构 V2.0 时代，统一活动中心配置营销活动，且区分实时营销、事后营销（任务），同时区分线上活动、线下活动、全渠道活动。规则服务在接收营销活动配置后根据相关配置来生成不同的规则文件，以此减少规则匹配中的数据量问题，并且根据不同类型和渠道分开存储资格校验数据。统一营销服务和任务服务统一对外服务，请求数据区分系统、及区分线上、线下活动，降低规则匹配和资格校验的复杂度。
当然在系统架构层面上，还有规则服务独立。规则服务的资源扩容，完全根据规则的性能需求。
图 6：营销活动规则校验流程 V2.0
2. 活动总数的校验存在数据热点问题
2016 年，苏宁金融营销系统架构 V1.0 时代，有些活动允许所有会员参与，但有总次数、金额限制。这种类型的活动，每次用户请求必须校验，为了避免数据不一致性，总次数、金额需要集中存储，根据 key= 活动 ID 存储到某台缓存设备，一旦活动访问流量比较大，那么就会导致缓存热点问题。还有些配置了月次数、金额；周次数、金额；日次数、金额的活动，均会出现缓存热点问题。
现在，苏宁金融营销系统架构 V2.0 时代，缓存设备申请一主两从多组方式，并且设置 slave 参与读模式减少读取热点，而且通过类型及渠道的缓存分组，提高系统整体的缓存服务能力。
图 7：数据热点解决方案 V2.0
3. 面向会员的 6 个唯一资格校验问题
2016 年，苏宁金融营销系统架构 V1.0 时代，参与营销活动的会员的唯一校验，活动参与次数限定到个人。手机号、帐号、设备、身份证、银行卡、银行绑定手机号。
针对此种校验，单次请求数据 6 个唯一条件都需要一一进行判断，这样就对同一个活动增加了跟缓存交互次数。活动越多、应用跟缓存交互次数越多，耗时就越长，系统性能必然降低。同时为了保证相关唯一校验的可靠性，系统在处理中还对唯一数据入库处理，增加了系统负担。
现在，系统架构 V2.0 时代，通过合并请求，同一个活动相关的唯一性查询进行合并，减少跟缓存的请求次数，且应用的缓存采用持久化策略。
4. 活动存储数据已经约 1 亿
2017 年，苏宁金融营销系统架构 V1.0 时代，做了分表处理，由于营销活动较多，用户使用较多。促销活动虽然做了历史数据规整处理，但仍然存在单表数据量过大问题，导致对表操作产出性能瓶颈；尤其是撤销支付功能。撤销支付功能为了能取消用户占用资格，还需要对用户占用的资格数据进行回退，那么撤销操作会涉及历史表，而历史表数据量非常大，已经约 1 亿，因此影响到整体的性能。
现在，苏宁金融营销系统架构 V2.0 时代，活动业务数据进行业务分库分表操作（大约分为 10 个库，约 2000 张表），通过这样的分配减少单表数据量，提高数据库并发处理能力。
