支撑马蜂窝会员体系全面升级背后的架构设计

流量红利正逐渐走向终结，这已经再也不是什么秘密。后互联网时代，如何维系住用户群，提高用户在平台上的体验是整个行业都须要考虑的事情。正是出于这一缘由，如今全行业都在关注会员体系的搭建，这也是马蜂窝 2019 年重点投入的方向之一。 

面对这个全行业都在发力的会员市场，要对「马蜂窝特点」的会员体系进行有力的支撑，无疑对会员体系的架构设计提出更高的要求。

马蜂窝会员体系建设从 2018 年 9 月份开始启动，通过前期对会员身份和会员权益的摸索，伴随业务的快速发展，到 2019 年上半年，为了让更多用户体验到马蜂窝高质量的会员服务，公司推出了更灵活、维度更多、权益更丰富的会员模式。在这样的背景下，初期较为粗旷的底层技术也须要及时作出调整，对核心架构和服务进行升级。

1、会员身份策略改造

早期的会员身份模块由会员产品、用户属性和时间属性共同构成：

能够看到早期的会员产品比较单一，所以将产品信息设计成一级结构。这种设计的好处是逻辑简单，能够快速实现，但不易扩展，一旦新增会员类别以及不一样卡种之间出现复杂关系时，不管是对项目或者对代码自己而言，维护成本都将成倍增加。

从 2019 年年初开始，马蜂窝会员体系进行了全面升级，主要体如今如下几个方面：

• 更完善的获客渠道，增长了在小程序端的服务展现；
• 更丰富的会员类别，新增了很是多卡种，在最初的年度金卡和体验金卡基础上，增长了季度金卡、 7 日卡、「蜂享卡」，将来还计划推出月度金卡、学生卡等；
• 更低的获取门槛，早期的会员身份只能经过在 App 中购买得到，为了让更多用户享受到品质更高的服务，增长了经过完成用户激励任务、供应商合做、产品搭售、线下实体卡等会员获取方式。

这也意味着，同一时间段内用户的会员身份将变得愈发复杂，早期单一的会员身份策略和模型设计已经不能知足需求。从新设计会员身份的时候，咱们明确了将来不管业务线如何划分会员身份，底层结构都要可以较好地支持，所以决定把会员模块身份抽离出来。会员体系升级后，产品信息调整为以 SKU 做为最小粒度从新划分，同时增长了用户信息中的来源以及获取渠道信息：

2、会员中心架构设计和优化

在明确了新的会员身份策略后，咱们对整个会员体系进行了梳理，将现阶段的会员中心架构设计以下：

合上面的架构图来看，目前马蜂窝会员中心系统主要划分为数据存储、核心服务、接口层、应用层四大部分：

• 数据储存：主要基于 MySQL 和 Redis，以及马蜂窝统一日志系统 MES
• 核心服务：这是当前马蜂窝会员体系中最重要的一层。核心服务又能够分为三大块：

  （1）「四驾马车」：会员身份、权益、增值服务接入、会员积分，驱动着整个会员体系的运转；

  （2）交易营销：辅助四驾马车快速往前跑；

  （3）支撑模块：与会员体系对接的公司级别支撑模块，包括风控、监控、日志、消息总线、商家结算对帐等

• 接口层：会员体系对外暴露的接口，包括了会员身份、权益领取、蜂蜜消费等接口
• 应用层：主要是面向 C 端的应用，包括会员频道页、蜂蜜中心、用户权益中心、任务中心等

下面重点围绕「核心服务」层展开介绍。

2.1「四驾马车」

2.1.1 会员身份

目前，市面上不少常见的会员产品都是采用普通的续费模式，好比一些视频平台的年度会员、季度会员。这种模式的特色是只进行时间的区分，在会员身份后生效后享受的权益彻底相同，经过续费使权益时效获得相应延长。

可是马蜂窝因为业务的特殊性，会员体系须要设计得更为立体。若是只采用单纯的续费模式，会影响高忠诚度用户的使用体验。

• 首先，在同一类别的会员身份下，时长不一样的产品对应的权益也不一样。以金卡会员为例，季度金卡、年度金卡这种同类别下的会员身份，能够经过续费升级，但它们彼拥有的权益不彻底相同，好比年度金卡 96 折抵额上限为 500 元，季度金卡只有 100 元。
• 另外，同一用户在同一时间内，只要知足条件，就可同时拥有不一样类别的卡种，好比金卡和蜂享卡。

为了知足上述需求，咱们决定引入用户身份的叠加以及续费模型。经过增长会员 SKU 叠加、续费关系表，使用户在一个时间段内不只能够同时拥有多种身份，还能够续费已有卡种。

上图是会员身份的时间轴示意。横轴表明时间，纵轴表明不一样的卡种。咱们经过最终 SKU 时间轴即可以确认用户当前的会员身份。

咱们将用户已有的每一个 SKU 时间轴拉平，当用户在某个时间点发出购买新卡种的请求时，查看当前生效的时间轴中是否已有用户正在购买的 SPU，若是没有则叠加，如已有则须要再判断 SKU 之间的配置策略，决定是叠加仍是续费；而后继续计算出正在购买的 SKU 生效时间轴；接下来根据配置好的规则，对比当前购买生效时间轴和已有 SKU 时间轴的身份关系，决定用户是否能够完成这次购买，如：

• 前置身份：指必须已经购买某个 SKU，才能够购买当前 SKU
• 冲突身份：指若是已经购买某个 SKU，就不能够购买当前 SKU

为了知足不一样的业务需求，这里的叠加、续费关系都是能够经过运营来配置的。整个流程大体示意以下：

为了让用户的体验更好，当同时拥有多重身份的时候，咱们会根据数据分析结果调整会员 SPU 权重，优先展现权重高的权益。好比当前会员同时拥有金卡和门票卡，数据显示金卡权益的使用率或者关注度高于其余产品，则提高金卡权重，金卡身份和相关权益会在用户进入会员频道页时首先展现。

2.1.2 权益中心

除了身份体系，最重要的就是会员权益，它直接体现会员的不一样级别。会员项目发展初期，一切都是从零开始，对拓展性要求不高，每出现一种新的身份、卡种，都须要从头设计其所含权益，开发效率很低，后台的配置也很分散。后期为了支撑业务快速发展，咱们开始考虑将权益中心进行拆分，分红两部分进行改造。

第一步是权益池的搭建，下图是权益池的基本模型：

咱们将会员权益中通用的属性抽象出来，定义为原则上不变的基础属性，造成「权益物料」存放在权益池中，通用的属性主要包括：

• 权益类型：主要有兑换码、折扣购买、优惠券、三方跳转 4 种，目前能支持到马蜂窝全部的权益类型
• 供应商：不一样供应商提供了不一样的权益，甚至还有不一样的权益接入流程和权益消费流程，同时和涉及了不一样的供应商结算模式
• 下发时机：主动下发或者被动下发，例如金卡 96 折权益，是用户购买会员的核心权益，这种权益在用户购卡以后便直接下发至用户帐户。其余的权益例如机场贵宾厅、QQ 绿钻、腾讯视频季卡等则须要用户主动领取。
• 基础属性：权益的基础属性依赖于权益类型、下发时机、供应商，也就是说不一样的供应商或者不一样的权益类型和下发时机，都会组合出不一样的权益基础属性，这里的属性大可能是这些权益的固定属性。最终这 4 大属性共同组成了基本的权益物料。

下图是用户开卡及权益发放的流程示意：

当会员产品支付完成后，会员中心会通知权益中心发放权益；权益中心进行权益过滤以后通知优惠中心，最终由优惠中心完成被动权益的发放；须要用户主动领取的权益则只为用户发放使用权利，最终由用户决定是否领取。

第二步权益规则的配置。有了第一步的基础以后，会员中心为权益池中的权益物料配置相应的权益规则，以后展现给用户。

权益规则主要划分为：

• 条件规则：指肯定权益的一些基本前提，主要指会员身份、前求来源、当前业务等
• 通用规则：指对外展现的标准，包括文案、排序、上下线时间、权益说明等等
• 运营规则：这是权益规则中变更最多，也是体现权益中心精细化运营的一部分。不一样的用户身份拥有不一样的权益价格、兑换价格以及不一样的标签，差别化地显示用户的身份特权

咱们抽象出了权益规则中的通用属性，造成权益对外展现统一的标准。固然，只有通用的权益规则配置是远远不够的，所以在不影响核心权益规则的前提下，在后台加入了扩展规则模板的配置，以便知足特殊权益不一样规则的需求，实现动态规则配置，使用起来更加灵活。

2.1.3 第三方权益接入

权益池中有一部分是站内权益，好比核心的金卡商品 96 折、马蜂窝优惠券、接送机等。这些权益的发放和消费在站内创建的统一规则下完成，接入起来相对容易。

权益池中有一部分是站内权益，好比核心的金卡商品 96 折、马蜂窝优惠券、接送机等。这些权益的发放和消费在站内创建的统一规则下完成，接入起来相对容易。

另一部分是须要接入的站外权益，也就是为会员供提的增值服务，好比机场贵宾厅、旅行保险等。不一样的第三方都有本身权益规则的特殊性，目前没法抽象成统一标准，也就没法采用 OpenAPI 的方式接入。

现阶段咱们把第三方权益的接入进行了流程上的整合，最终造成了两大类方式：

• 一类是权益领取在马蜂窝内完成，用户全部的操做彻底在咱们的应用里进行，完成后异步再调用第三方接口为用户发放权益。
• 第二类是权益领取过程彻底在第三方系统中进行，主要针对一些积分兑换的权益。用户点击领取权益后跳转至第三方页面，交互完成以后异步回调马蜂窝接口，马蜂窝系统根据回调状况进行积分的增长或者扣减。这种方式的弊端是用户体验彻底由第三方决定，可控性不高；但优点在于可以快速接入一些复杂的权益玩法，好比一些游戏类权益，避免投入大量精力去开发。

上图是两种领取模式的流程对比图，能够看到每一步的三方对接都是经过异步方式进行的，这样当第三方系统出现异常不会影响到马蜂窝的正常服务，使系统可用性获得保证。

2.1.4 会员积分

成长体系对于搭建完整的会员体系很是重要，之内容社区起家的马蜂窝在这方面有自然的优点。咱们决定引入已有的用户积分体系「蜂蜜」来承载一部分会员积分的功能。经过与会员中心打通加强与会员用户的线上互动，提升用户活跃度和黏性。在不一样的蜂蜜场景和蜂蜜策略下，用户能够赚取积分，知足相应条件后能够兑换所需权益；此外，咱们也正在拓展更多蜂蜜和 B 端的结合方式，但愿促进平台和商家的双赢。

上图是会员体系利用蜂蜜中心提供的服务以及一些近期规划示意。如何利用好激励机制使整个会员体系更加完善，实现对会员用户更加精细化的运营，对于马蜂窝「内容+交易」战略的深化而言是一个重要的课题，也是研发团队须要不断探索的方向。

2.2 营销活动的性能优化

实现了会员身份、权益中心、第三方权益接入、蜂蜜中心的改造后，会员中心也完成了升级之路的第一步。

为了让更多用户了解会员机制并体验会员权限，咱们推出了不少营销活动。其中很多活动都存在秒杀的场景。如下部分就来重点介绍为保障这些营销活动的稳定可靠而进行的技术优化。

2.2.1 并发控制

在秒杀场景中，须要防止由高并发致使的库存超卖。关于这个问题业界已经有很多成熟的解决方案，好比采用悲观锁、分布式锁、乐观锁、队列串行、Redis 原子操做等等，固然最理想的是用分布式锁来实现。

考虑到目前的并发量级以及技术成本，咱们决定先采用 MySQL 乐观锁的方式来实现现阶段的秒杀功能。你们知道数据库内部 Update 同一行是不容许并发的，只有当该行被更新后才会释放。咱们的方案是经过增长惟一的 Version 来防止超卖的状况发生：在每次数据 Update 的时候判断版本号是否和数据库中的一致，不一致则表示当前库存已经被其余用户占用，此时抛出异常；若是一致则完成当前用户对库存的占用。

2.2.2 流量削峰

要缓解由瞬间流量爆发形成的数据库压力，咱们首先要明确会引发瞬间 QPS 剧增的场景。

一种状况是接口被恶意重刷。因为咱们的秒杀业务须要用户必须登陆，伪造 Session 的可能性较低，所以若是这种状况发生，颇有多是由同一个 UID 遍历刷接口致使的。这里只须要加上 UID 的 Redis 锁，使一个 UID 在必定时间内只能透过一次请求，这样绝大部分的遍历刷接口行为就能被拦住。

还有一种状况是由流量突发引发，多是真实的抢购用户数量巨大，也多是对方使用了大量设备请求，这才是咱们目前面对的实际场景。前面咱们提到的加 MySQL 乐观锁来避免超卖，若是瞬时流量巨大 MySQL 的读写、锁表等现象会比较严重，当数据库压力达到极限就会被打挂。所以为了减少数据库的瞬时压力，咱们须要在服务层作好限流。好比当库存只有 1000 件，可是有 1w 请求打到数据库时，其实后面的请求都没有意义。咱们知道不管是 Memcache 仍是 Redis，单机下每秒扛住 10w 请求都不会有太大问题。因此在没有完成分布式锁的状况下，咱们是用 Redis 来作最基本的限流，使大部分的请求被拦截在服务层，只有少许请求会穿透到数据库。

上图是当前秒杀体系简单的流程图。后续若是这类会员营销活动依旧是业务重点，咱们仍是会采用 Redis 分布式锁的方式来优化，搭建更为完善的秒杀体系。

2.3  风险控制

关于支撑模块的部分主要分享与风险控制相关的内容。为了保证享受到会员服务的是真实用户，咱们须要识别并抵御由黑产带来的潜在风险，保障系统的正常运行，严控由此带来的损失。

上图是目前会员体系中安全控制的结构示意。API 路由层主要负责数据收集和风险预估，收集上来的数据统一写入到公司的日志系统 MES 中存储。咱们使用了滑窗模式的限流方式，当发现总访问量超过必定阈值则会将大流量或者过快的请求记录到会员疑似黑名单的表中，再进行路由层的限流处理并接入公司级别风控体系，根据对不一样业务场景的识别采用相关风控策略；最终经过邮件、短信等方式通知到路由层相应的技术负责人，尽快处理。

3、总结和展望

在进行马蜂窝会员体系架构的搭建的实战过程当中，咱们积累了不少有价值的经验，其中感觉最深的就是切忌盲目优化，系统层面上的重构更要首先以业务为导向去关注核心框架的升级和技术体系的演进，不要由于过分陷入技术细节而迷失方向。

从此，咱们还将积极调研和应用更多主流、前沿技术，好比会员标签、用户画像体系的引入，真正把这些技术用好用活，使会员中心发挥更大价值。

本文做者：马蜂窝电商会员项目研发团队。

彩蛋

欢迎你们关注马蜂窝技术公众号后台，并针对本文积极留言，发表观点或者进行更多相关的技术交流。截至 7 月 27 日 7:00 pm，咱们将从公众号后台筛选出留言质量最高的 7 位读者赠送马蜂窝季度金卡，千万别错过！（扫描下方二维码关注公众号）