苏宁拼购 808 的火爆见证了砍价团的成功，作为一种新兴的购物营销玩法，砍价团展现出了巨大的商业潜力。不同于传统购物流程的单一模式，砍价团凝练了购物玩法和社群营销的精髓。
图片来自 Pexels
拼购砍价团平台化转型的战略契机
传统购物模式的劣势在于购物体验单一，更多的都只是选品→下单→支付的标准化流程， 另一方面则在于无法打通购物与社交的壁垒，实现两者的巧妙融合。
而砍价团模式则在这两个方向施以重彩：通过分享，帮砍流程使得购物充满趣味性和互动性，优化用户体验的同时也增加了用户粘性。借助于微信庞大的用户基数实现了产品在熟人社群中的快速传播，达成了良好的营销效果。
而熟人社群的传播也有利于精准遴选出更多对标用户，充分挖掘用户价值，正是这两把利刃，造就了砍价团模式的成功。
苏宁拼购 808 的成功同时也成为了进一步摸索砍价团发展模式的契机。
当前的砍价团仍然从属于拼购玩法，能够参与砍价的商品也局限于苏宁拼购的部分商品，更多的聚集在日用，快消等低成本商品，3C，家电等相对较少。
此外，砍价团玩法也可以与苏宁 O2O 模式深度嫁接，不仅仅局限于线上商品，同时也可以将线下门店纳入到砍价团版图之中，充分发挥苏宁的供应链优势，甚至连同置业，文创，乃至虚拟商品都可以和砍价团玩法深度融合。
线上与线下的齐头并进势必能为砍价团带来新一轮的爆发式增长。
笔者认为，砍价团的铺展离不开四个要素：足够有趣的玩法精准的目标用户群筛选良好的社交传播渠道优质的商品供应链
一方面可以通过主站引流，微信分享的方式实现用户群的拓展，另一方面砍价团也应该在选品方面进一步拓宽范围，给予用户更多的可选择性。
如果仅仅局限于苏宁拼购本身，那么除了商品范围的局限外，也无法吸引更多的优质商家入驻。
因此，砍价团亟待完成从玩法到通用性平台的战略转型，砍价团平台化战略，便由此应运而生。
砍价团平台业务架构设计
从一种玩法到一个平台，这种从单元到体系的跃迁背后是一种战略思路的成型。
砍价团平台本身带有一定的商业试探性质，一旦这种模式确定可行，便可迅速推而广之。除了砍价团之外，也可以吸收更多的优秀营销玩法。
这就要求砍价团平台应当具备通用性。既然面向苏宁的全产业提供服务，那么就势必要兼收并蓄，不仅仅是主站商品，线下门店商品，同时也要考虑置业，文创等产业模块。
在砍价团平台的业务设计上，要充分考虑不同类型商品的统一管理，同时也要为其他可能的营销玩法预留空间，而不仅仅是局限于砍价团。
通过实现高度的可配置与定制化，进而转型成为为全产业提供玩法定制服务的玩法平台。
在业务架构上，砍价团平台不能仅仅是复刻拼购原有的业务逻辑，而应当更具兼容性地做出相应业务架构改造。
比如对于团模式的设计而言，砍价团实质上并非传统的开团——参团模式，而更类似于单买模式，只不过引入了分享和帮砍流程。
因此对于老的成团模式，就需要废弃诸如“团满校验”，“参团流程”等冗余逻辑，而只需要记录帮砍人数与帮砍金额等信息即可。
而在活动设计层面，考虑到未来可能引入新的玩法，也应当在设计上具备充分的拓展性。
除了保留诸如活动编码，活动类型，起止时间等基本信息字段之外，也需要考虑到通过预留字段，拆分基本信息表和扩展信息表等方式为新玩法的引入留下空间。
就砍价团平台的设计初衷而言，其旨在于提供一套能够兼容各种购物玩法的中台式服务。
因而在玩法设计上应当提供具备通用性的接入模板，由业务方自由定制自身的玩法模式。这就需要对各种玩法所具备的共性要素进行精准抽绎，实现高度可配。
就前端而言，因为不同的玩法模式在用户侧展示的内容也有所差别，前端设计就需要足够灵活。
前端在开发过程中，应当在满足业务功能的基础上尽可能制定统一的开发标准，对于复用性较高的模块封装为组件，便于实现前端页面的可定制化。
就服务端而言，在服务组件的设计上要对业务模块进行细致拆分，避免业务之间的过度耦合，为新模块的引入，新玩法的配置留下空间。
在功能层面，要尽可能实现业务组件的原子性，除非涉及核心业务模块，否则不同功能之间应当尽可能解耦，便于功能的横向拓展。
比如对于活动阀值，玩法规则等一些通用性要素，其应该尽可能避免从代码层面去实现，而是通过苏宁统一配置平台加以配置。
当承接新的玩法需求时，只需要在统一配置平台进行相应的配置即可，而无需进行代码层面的改动。
百尺之台，不可止日毕功，砍价团平台化战略只能在试探和摸索中徐徐图之。不畏浮云遮望眼，风物长宜放眼量。试看前路，虽有坎坷，却亦是坦途。
砍价团平台技术架构设计
砍价团平台的架构纵向拆分
图 1：砍价团平台架构纵向拆分
在砍价团平台系统设计上，首先需要在业务层面进行逻辑解耦，砍价团平台(Bargain System，简称 BGS)在业务上可以主要拆分为四大模块，分别部署在不同的服务器集群上，不同的集群之间共享服务层的原子服务，并通过分布式远程调用框架协同工作。
①前台用户模块：前台业务模块，主要负责处理来自用户的业务请求，负荷最重同时也是最为核心的业务模块。
在硬件配置上要充分考虑本模块的机器配置能否应对庞大的的流量载荷，同时应当着重考虑本模块的容灾能力设计。
本模块主要处理活动，砍价玩法，物品，交易等服务，每种服务都由粒度更小的组件来实现，如砍价玩法下面又包含了规则，风控，金额，明细等专门业务组件。
②前台服务模块：前台服务框架层业务模块，本模块在业务上与前台用户层重合，区别在于本模块完全由服务框架层模块调度实现，主要负责分流一部分来自内网其他系统的访问请求。
如此设计的优势在于能够从流量层面对内外网的访问进行解耦，隔离部署不仅更便于精准配置机器资源，同时也能有效提高前台模块的抗风险能力，便于损害管控。
③后台模块：后台业务模块，本模块主要用于运维管理人员的日常数据维护，除了对活动信息的管理外，本模块还可以实现对玩法，规则等的高度可配置化，以便兼容更为丰富的购物玩法。
④中台模块：中台定时任务模块，本模块主要负责处理来自统一调度平台的定时任务调度请求，如过期团处理，过期订单处理等，实现对数据层的定时维护，保持数据时效性，避免产生数据冗余。
砍价团平台的架构横向拆分
图 2：砍价团平台架构横向拆分
①网络层：为了应对来自用户的巨大流量压力，苏宁在网络层采取了缓存设计，来自用户的静态资源访问请求一部分会由全局负载均衡器直接响应，以此减轻后端服务器的负载。
同时由于 BGS 系统采用双机房部署策略，因此回源请求会根据特定分拨策略被调度到两个不同的机房。
②负载层：对于进入后端服务器的请求，首先会由苏宁应用防火墙进行初步甄别。
防火墙除了负责对外网攻击，非法请求，垃圾请求进行拦截过滤之外，同时也负责在某些高并发场景下。
当流量超过阀值时进行流量控制，减轻后端服务器的压力，防止服务器引流量过高而宕机。
③应用层：穿过防火墙的请求由后端负载集群进一步分发到应用服务器进行相关的业务处理和落库操作，并响应给用户。
砍价团平台的数据层设计
图 3：砍价团平台的数据层设计
在数据层的设计上，考虑到 BGS 可能面对的巨大业务量，采取了数据库分库中间件技术。对一些业务量较大的表进行分库分表部署，进而提高数据读写效率。
比如对于团信息相关表，通过特定的算法将数据均匀铺展在多个分表中，而分表根据特定的取模算法分别部署在四个分库中。
分库中间件会根据访问请求的分片字段将请求分发到相应的分库，而无需代码层面的额外改动。
对于不带分片字段的请求，分库中间件可能需要对分库进行遍历，从而降低查询效率，因此 BGS 系统采取了额外的整库设计。
四个分库的数据通过数据迁移同步到单个整库中，对于不带分片字段或其他有特殊业务要求的查询请求，不经过中间件直接调度到整库，从而提高查询效率。
此外额外整库设计也可以在中间件与分库出现问题时承接数据库降级操作，保证业务的持续可用性。
由于数据迁移存在一定的同步延时，因此整库更适合处理对时效性要求较低的查询请求，对于写库请求和高时效性查询请求，则需要对业务进行进一步的评估。
此外， 中间件+数据库的设计也更加易于后期数据库的横向扩展，避免系统因为数据层的瓶颈而限制整个系统的并发处理能力。
砍价团平台的缓存设计
由于 BGS 系统可能面临的高并发情况，因此在数据层面除了中间件+数据库的设计之外，同时采用了 Redis 缓存来预处理一部分读写请求，减少对数据库的访问。
对此改进思路如下：对于下单支付的前置校验操作，如下单资格，库存等，在并发量很高的情况下配置降级，在用户下单前取消资格校验操作。在生成订单链路中，涉及到和中台的交互，采取异步化处理的方式，中台处理完毕后将结果反馈给砍价团平台系统即可，进而减少用户的等待时间。
而相应的这一改造思路也可以移植到一些对时效性要求较低的场景中。
如果系统本身只在特定的时间点面临高并发场景，那么可以选择专门开辟一个高并发代码分支，在面临大促，节日活动时用高并发分支取代常规分支即可。
这样可以避免因为不定期的各种活动而频繁对代码进行改造，进而减轻了代码层面的业务风险。
核心链路拆分解耦
链路级别的优化除了代码层面的异步化改造外，也可以对核心链路进行分流，将不同的链路流量引流到不同的集群上，拆分系统压力。
比如对于展示与购物链路，其所面临的流量压力存在显著差别，展示链路 TPS 要远高于购物链路 TPS。
因此在架构设计上，可以分别将代码部署在两个集群上，通过不同的域名对展示链路和购物链路进行分流。
同时对于域名配置降级开关，如果支付链路集群故障，可以通过修改配置将支付链路的流量回流到展示链路进行处理，从而进一步提高系统的容灾能力。
结语
笔者以为，对于承载复杂业务的系统而言，其受木桶效应的影响尤甚，因此要尽量平衡系统的各个要素，不可偏废。
当系统足够复杂，那么决定系统整体效能的往往是结构性层面的因素，各个模块和单元之间良好的协调关系是系统稳健运作的保证。
而系统的设计也应该以满足自身业务为第一要义，尽可能精简一些不必要部分。
虽然理论上庞大的系统集群具有更强的容灾能力，但是过高的维护成本也会成为系统的拖累。
因此，明确自身业务需求，选择适合的方案，才是系统设计的要义。
