【.com原稿】苏宁购物808的火爆见证了百货集团的成功。BargainGroup作为一种新兴的购物营销方式，已经展现出巨大的商业潜力。区别于传统购物流程的单一模式，团购凝聚了购物玩法和社群营销的精髓。图片来自Pexels，团购砍价平台转型战略机遇期。传统购物模式的劣势在于购物体验单一，更多的只是选品→下单→支付的标准化流程。另一方面，无法将购物和社交联系起来。实现两者巧妙融合的壁垒。议价团模式侧重于这两个方向：通过分享，帮剪过程让购物充满乐趣和互动性，优化用户体验，增加用户粘性。借助微信庞大的用户群，实现了产品在熟人社区的快速传播，取得了良好的营销效果。熟人社区的传播也有利于精准筛选更多标杆用户，充分挖掘用户价值。正是这两个利刃造就了议价集团模式的成功。苏宁808团购的成功也成为进一步探索议价团发展模式的契机。目前的议价团仍隶属于团购，能够参与议价的商品仅限于苏宁集团采购的部分商品，更多的是日用品、快消品等低价商品商品。3C、家电等比较少。此外，议价团游戏还可以与苏宁的O2O模式深度嫁接，不仅限于线上产品，还可以将线下门店纳入议价团的版图，充分发挥苏宁的供应链优势，甚至联手与房地产、文创，甚至虚拟商品都可以与团购玩法深度融合。线上线下齐头并进，必将给议价群体带来新一轮的爆发式增长。笔者认为，议价团的传播离不开四个要素：足够有趣的玩法精准的目标用户群体选择良好的社交传播渠道优质的商品供应链一方面可以通过主站引流和微信分享来实现用户群体另一方面，议价组要进一步拓宽产品选择范围，给用户更多选择。如果仅限于苏宁购本身，那么除了商品种类的限制外，也无法吸引更多的优质商户入驻。因此，议价团迫切需要完成从苏宁购的战略转型。游戏玩法走向全民平台，讨价还价团的平台战略应运而生。团购平台的业务架构设计从玩法变成了平台。这种从单元到系统的转变背后，是一种战略思想的形成。团购平台本身就具有一定的商业探索性。一旦确认这种模式可行，就可以快速推广。除了讨价还价的群体，还可以吸收更多优秀的营销手段。这就要求议价团平台要具有多功能性。既然是为苏宁全产业服务，必然是不拘一格的，既有主站和线下门店的产品，也有地产、文创等产业模块。在议价团平台的业务设计中，需要充分考虑不同类型商品的统一管理，同时为其他可能的营销方式预留空间，而不仅仅局限于议价团。通过实现高度的可配置性和定制化，将转型为一个为全行业提供玩法定制服务的玩法平台。在业务结构上，团购平台不应只是复现团购原有的业务逻辑，而应以更加兼容的方式进行相应的业务结构改造。比如在拼团模式的设计上，议价团本质上并不是传统的开团-加团模式，更类似于单买模式，只是引入了分享和帮助的过程.因此，对于旧的团建模式，需要摒弃“团全验证”、“团参与流程”等冗余逻辑，只需要记录团员人数、团员金额等信息。在活动设计层面，考虑到未来可能会引入新的玩法，设计上也应该是充分可扩展的。除了保留活动代码、活动类型、起止时间等基本信息字段外，还需要考虑通过预留字段、拆分基本信息表和扩展信息表等方式为新玩法的引入留出空间。就团购平台的设计初衷而言，旨在提供一套兼容各种购物方式的中台服务。因此，在玩法设计上，应该提供一个通用的接入模板，业务方可以自由定制自己的玩法模式。这就需要准确提取各种玩法的共性要素，达到高度的匹配度。就前端而言，由于不同的玩法模式在用户端展示的内容不同，因此前端设计需要足够灵活。前端开发过程中，在满足业务功能的基础上，尽可能建立统一的开发标准，将复用性高的模块封装成组件，方便前端页面的定制化。就服务端而言，在服务组件的设计上，业务模块一定要小心拆分，避免业务之间过度耦合，为新模块的引入和新玩法的配置留有余地。在功能层面，尽可能做到业务组件的原子性。在不涉及核心业务模块的情况下，尽量将不同的功能解耦，以方便功能的横向扩展。比如一些常见的元素，比如活动门槛、玩法规则，应该尽量避免在代码层面实现，而是通过苏宁统一配置平台进行配置。在接受新的玩法需求时，只需在统一配置平台上进行相应的配置，无需在代码层面进行改动。百尺平台非一日之功，议价团的平台策略只能在尝试探索的过程中逐渐摸索出来。不怕浮云遮眼，远景要分寸。看看前方的路，虽然有坎坷，但也是平坦的路。团购平台技术架构设计团购平台架构纵向拆分图1：团购平台架构纵向拆分在团购平台系统设计中，首先需要在业务层面进行逻辑解耦，以及议价团平台（BargainSystem，简称BGS）在业务上主要分为四大模块，分别部署在不同的服务器集群上。不同集群共享服务层的原子服务，通过分布式远程调用框架协同工作。①前端用户模块：前端业务模块主要负责处理用户的业务请求。它的负载最重，也是最核心的业务模块。在硬件配置上，需要充分考虑本模块的机器配置是否能够应对巨大的流量负载，同时着重设计本模块的容灾能力。该模块主要处理活动、议价、物品、交易等服务，每个服务由更小粒度的组件实现。②前台服务模块：前台服务框架层的业务模块。该模块在业务上与前台用户层有重叠。不同的是，该模块完全由服务框架层模块调度实现。主要负责分流内网其他系统的一些访问请求。这种设计的好处是可以将内网和外网的访问从流量层面解耦。隔离部署不仅有利于机器资源的精准分配，也有效提升了前端模块的抗风险能力，便于损管。③后台模块：后台业务模块，该模块主要用于运维管理人员的日常数据维护，除了活动信息的管理外，该模块还可以实现高度可配置的玩法、规则等，从而更兼容丰富的购物玩法。④中台模块：中台定时任务模块，该模块主要负责处理来自统一调度平台的定时任务调度请求，如逾期组处理、逾期订单处理等，实现数据层的定时维护，保持数据的时效性，避免产生数据冗余。团购平台架构横向拆分图2：团购平台架构横向拆分①网络层：为了应对用户巨大的流量压力，苏宁在网络层采用了缓存设计，部分用户的静态资源访问请求将由全局负载均衡器直接响应，以减轻后端服务器的负载。同时，由于BGS系统采用双机房部署策略，回源请求会按照特定的分配策略被分派到两个不同的机房。②负载层：对于进入后端服务器的请求，苏宁应用防火墙会先进行初筛。防火墙除了负责拦截过滤外网攻击、非法请求、垃圾请求外，还负责某些高并发场景。当流量超过阈值时，进行流量控制，以减轻后端服务器的压力，防止服务器因过度引流而宕机。③应用层：通过防火墙的请求，由后端负载集群进一步分发到应用服务器进行相关业务处理和存储操作，并响应用户。团购平台数据层设计图3：团购平台数据层设计在数据层设计中，考虑到BGS可能面临的庞大业务量，采用了数据库分库中间件技术。一些业务量大的表，分库分表部署??，提高数据读写效率。例如，对于集团信息关联表，通过特定的算法将数据均匀分布在多个分表中，分表按照特定的取模算法部署在四个分库中。分库中间件会根据访问请求的分片字段，将请求分发到对应的分库，代码层面无需额外改动。对于没有分片字段的请求，分库中间件可能需要遍历分库，从而降低查询效率。因此，BGS系统采用了额外的全库设计。四个分库的数据通过数据迁移同步到一个全库。对于没有分片字段或其他特殊业务需求的查询请求，直接派发到全库，无需中间件，提高查询效率。此外，额外的全库设计还可以在中间件和分库出现问题时承担数据库降级操作，保证业务的持续可用。由于数据迁移存在一定的同步延迟，整个数据库更适合处理时效性要求不高的查询请求。对于数据库写请求和高时效性查询请求，需要对业务做进一步评估。另外，中间件+数据库的设计也更便于后期数据库的水平扩展，避免了数据层的瓶颈限制整个系统的并发处理能力。团购平台的缓存设计是由于BGS系统可能面临的高并发。因此，除了数据层面的中间件+数据库的设计之外，还利用Redis缓存对一些读写请求进行预处理，减少对数据库的访问。图4：议价团平台缓存设计以去库存场景为例，对于一些热销商品或活动抢购的商品，可能会在短时间内面临极高的并发压力。因此需要设计预操作步骤，一方面缓冲对数据库的直接压力，另一方面保证缓存和DB之间的数据一致性。当用户下单或支付成功时，Redis中的数据会被优先处理。Redis中的数据会定时同步到DB，同步周期可以根据业务需求配置。对DB和Redis的操作放在分布式一致性框架中，当某个步骤失败时进行回滚，避免数据不一致。同时Redis与Sentinel组成高可用集群，当某个Redis宕机时自动实现主从切换，保证缓存服务的高可用，防止缓存大量穿透造成的数据库雪崩效应。但是这种设计有一个特殊的场景需要考虑，就是当涉及到抢购、闪购等高并发场景时，对于Redis中的一些时间敏感的数据（比如库存），如果过期时间简而言之，可能会出现过期前最后一个同步周期的数据还没同步到数据库就失效的情况，导致部分数据缓存和DB不一致，导致活动超卖。针对这种特殊场景有两种技术方案：缩短数据同步周期，减少数据不一致的发生，但这种方案会增加数据库的压力，无法彻底解决数据不一致的问题。提前设置足够的缓存过期时间，防止数据在活动有效期内过期。这种方案虽然会增加Redis空间的占用，但是在技术层面风险较小，更适合高风险的场景。高可用系统的锻造和大促保障系统的架构设计，无非是满足两个方面的要求：尽可能满足系统所承担的业务需求，提高系统的承受能力尽可能多的压力。抗压能力必不可少，这对BGS系统的整体设计提出了更高的要求。在实现系统高可用方面，BGS系统采用了以下应对策略：双机房多活部署对于业务价值高的系统，多活部署几乎是必然的选择。BGS系统采用双机房部署策略分流用户请求，避免了单点部署策略中因意外因素导致宕机的风险，保证了服务的持续可用。在网络层，全局负载均衡器根据一定的sharding规则分配用户请求，分派到A、B两个机房；在负载层，根据相应的分配策略对流量进行两次分配。当网络层的流量拆分策略与负载层的流量拆分策略一致时，不会进行额外的流量分配；分配策略。负载层流量调度按系统维度划分，不同系统可根据实际情况配置分配策略。负载层除了对流量进行补偿外，还可以在网络层的分配策略失效后进行备选方案，保证不会因为网络层的分配失效导致单个机房的负载压力过大。在应用层，系统间的调用在机房集中处理。另外，针对数据层面的强一致性需求，可以在接口层面控制系统间调用，调度一些单机房的写操作，保证数据写入单机房的数据库.在数据层面，为了保证数据的强一致性，采用竞争策略保证主备数据库的数据一致性。主库写入的数据会同步迁移到备库进行热备份，保证主机房宕机时，备机房的数据库仍然可以切换到备机房的数据库，从而保证业务的可用性。单机房宕机降级方案单机房故障时（以主机房为例）：在网络层面，全局负载均衡器将所有回源请求统一控制分发到备用机房。在负载层面，对主机房的请求进行补偿调度，分配给备机房。确保未请求访问主计算机室。在应用层面，将分布式统一服务框架、数据队列等系统间的调用接口转移到备机房处理。在数据层面，通过切换数据库中间件，将数据的读写操作调度到备机房。对于备机房宕机，只需要完成网络层和负载层的流量切换，不需要对应用层和数据层进行任何操作。单机房降级的系统架构设计虽然侧重于把握系统的结构层面，但技术细节和具体的实际操作也不容忽视。看似完美的设计方案，在实际生产运作中总会面临各种考验，某些细节上的分歧往往会导致意想不到的后果。因此，无论设计多么完美，都必须在实战中进行检验。由于单机房宕机的情况过于极端，在生产环境中模拟单机房宕机风险过高，因此苏宁专门开发了模拟单机房宕机的故障注入系统。系统通过短时间关闭特定于机器的访问端口来模拟机器故障。主要涉及应用层、缓存层、数据库层的故障模拟。故障系统本身具有很强的可配置性，用户可以根据需要模拟的场景配置不同的故障注入任务。每个故障注入任务都有一个默认的自愈时间。当超过自愈时间后，端口状态会自动恢复，防止模拟故障时间过长造成事故。单机房宕机场景模拟大致可以分为六种场景：应用层宕机、单个缓存数据库宕机、缓存集群宕机、单个数据库数据库宕机、数据库集群宕机、以及单个系统的完全停机时间。可以覆盖所有单机房宕机的情况。在混沌系统的加持下，可以对系统的多活降级方案进行全覆盖测试，从而保证多活降级策略在生产场景下的可用性。高并发场景下的链路优化对于涉及高并发场景的系统，多活部署只是一种自下而上的应对极端情况的策略，单纯的横向扩展必然会因为边际效应递减而失败。业务需求。当结构层面的优化无法进一步提升系统性能时，就需要深入业务流程进行链路层面的优化。以议价团订单支付流程为例，该环节涉及与多个中台系统的信息交互，环节较长，在高并发场景下可能会拖累系统性能。改进思路如下：对于订单支付的前置验证操作，如订单资质、库存等，并发高时降级配置，取消用户前的资质验证操作下订单。在生成订单链接的过程中，涉及到与中台的交互，采用异步处理的方式。中台处理完成后，只需要将结果反馈给议价团平台系统，减少了用户的等待时间。而相应的改造思路也可以移植到一些对时效性要求不高的场景。如果系统本身只是在特定时间点面临高并发场景，可以选择创建高并发代码分支，在遇到大促和节日时，用高并发分支代替常规分支。这样就可以避免因各种不规律的活动而频繁修改代码，从而降低代码层面的业务风险。核心链路拆分解耦链路级优化除了代码层面的异步改造外，还可以对核心链路进行分流，将不同链路的流量分流到不同的集群，分流系统压力。例如，展示链接和购物链接的流量压力有显着差异，展示链接的TPS远高于购物链接。因此在架构设计上，可以将代码分别部署在两个集群上，通过不同的域名分发展示链接和购物链接。同时为域名配置降级开关。如果支付链路集群出现故障，可以通过修改配置将支付链路的流量返回到显示链路进行处理，进一步提高系统的容灾能力。结语笔者认为，对于承载复杂业务的系统来说，尤其容易受到木桶效应的影响，所以要尽量平衡系统的各个要素，不要忽视它们。当系统足够复杂时，决定系统整体性能的往往是结构性因素，而各个模块和单元之间良好的协调是系统稳定运行的保证。并且系统的设计也要以满足自身业务为第一要务，尽量减少一些不必要的部分。虽然理论上庞大的系统集群具有更强的容灾能力，但高昂的维护成本也会成为系统的拖累。因此，明确自己的业务需求，选择合适的解决方案，才是系统设计的精髓所在。作者：王翔简介：苏宁科技集团消费平台研发中心研发中心工程师，毕业于安徽大学电子信息工程专业，目前从事苏宁团购服务器开发，架构设计优化，并主要负责团购系统多活解决方案的设计搭建、购物系统架构的拆分优化设计、服务器系统开发等。【原创稿件，转载请注明原作者和出处.com在合作网站上]
