【真·送金卡】支撑马蜂窝会员体系全面升级背后的架构设计

早期的会员身份模块由会员产品、用户属性和时间属性共同构成。由于当时的产品较为单一，因此产品信息设计成一级结构：

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

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

• 更完善的获客渠道，增加了在小程序端的服务展示；

• 更丰富的会员类别，新增了非常多卡种，在最初的年度金卡和体验金卡基础上，增加了季度金卡、  7 日 卡 、「蜂享卡」，未来还计划推出月度金卡、学生卡等；

• 更低的获取门槛，早期的会员身份只能通过在 App 中购买获得，为了让更多用户享受到品质更高的服务，增加了通过完成用户激励任务、供应商合作、产品搭售、线下实体卡等会员获取方式。

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

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

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

• 数据储存：主要基于 MySQL 和 Redis，以及马蜂窝统一日志系统 MES

• 核心服务：这是当前马蜂窝会员体系中最重要的一层。核心服务又可以分为三大块：

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

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

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

• 接口 层 ：会员体系对外暴露的接口，包括了会员身份、权益领取、蜂蜜消费等接口

• 应用层：主要是面向 C 端的应用，包括会员频道页、蜂蜜中心、用户权益中心、任务中心等

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

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

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

• 首先，在同一类别的会员身份下，时长不同的产品对应的权益也不同。以金卡会员为例，季度金卡、年度金卡这种同类别下的会员身份，可以通过续费升级，但它们彼拥有的权益不完全相同，比如年度金卡 96 折抵额上限为 500 元，季度金卡只有 100 元。

• 另外，同一用户在同一时间内，只要满足条件，就可同时拥有不同类别的卡种，比如金卡和蜂享卡。

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

上图是会员身份的时间轴示意。横轴代表时间，纵轴代表不同的卡种。我们通过最终 SKU 时间轴便可以确认用户当前的会员身份。

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

• 前置身份：指必须已经购买某个 SKU，才可以购买当前 SKU

• 冲突身份：指如果已经购买某个 SKU，就不可以购买当前 SKU

为了满足不同的业务需求， 这里的叠加、续费关系都是可以通过运营来配置的。整个流程大致示意如下：

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

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

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

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

• 权益类型：主要有兑换码、折扣购买、优惠券、三方跳转 4 种，目前能支持到马蜂窝所有的权益类型

• 供应商：不同供应商提供了不同的权益，甚至还有不同的权益接入流程和权益消费流程，同时和涉及了不同的供应商结算模式

• 下发时机：主动下发或者被动下发，例如金卡 96 折权益，是用户购买会员的核心权益，这种权益在用户购卡之后便直接下发至用户账户。其他的权益例如机场贵宾厅、QQ 绿钻、腾讯视频季卡等则需要用户主动领取。

• 基础属性：权益的基础属性依赖于权益类型、下发时机、供应商，也就是说不同的供应商或者不同的权益类型和下发时机，都会组合出不同的权益基础属性，这里的属性大多是这些权益的固定属性。最终这 4 大属性共同组成了基本的权益物料。

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

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

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

权益规则主要划分为：

• 条件规则：指确定权益的一些基本前提，主要指会员身份、前求来源、当前业务等

• 通用规则：指对外展示的标准，包括文案、排序、上下线时间、权益说明等等

• 运营规则：这是权益规则中变动最多，也是体现权益中心精细化运营的一部分。不同的用户身份拥有不同的权益价格、兑换价格以及不同的标签，差异化地显示用户的身份特权

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

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

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

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

• 一类是权益领取在马蜂窝内完成，用户所有的操作完全在我们的应用里进行，完成后异步再调用第三方接口为用户发放权益。

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

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

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

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

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

彩蛋

- One More Thingl -

你可能还想看：

马蜂窝 IM 系统架构的演化和升级

DDD在马蜂窝优惠中心重构中的实践

马蜂窝支付中心架构演进

你 「在看」 我吗？