Member support hornet's nest full upgrade system architecture design behind

Dividend flow is gradually coming to an end, this is no longer a secret. After the age of the Internet, how to maintain live user base, improve the user experience on the platform is what the industry needs to consider. It is for this reason, and now the whole industry members are concerned about the build system, one of which is the direction of the hornet's nest in 2019 focused input.

In the face of this industry-wide market force members, To 'features a hornet's nest "of strong support system for members, no doubt put forward higher requirements for system architecture design members.

Member hornet's nest construction system started from September 2018, after a preliminary exploration of the membership and interests of its members, with the rapid development of business, the first half of 2019, in order to allow more users to experience the hornet's nest high-quality member services, company It introduced a more flexible, more dimension, more abundant interest in membership mode. In this context, the beginning of a more rugged underlying technology also need to make timely adjustments, the core architecture and service upgrades.

First, the membership policy reform

Early membership Module consists of members co-products, user attributes and time properties:

You can see the early members of relatively simple products, so the product design information into a structure. The advantage of this design is simple logic, can be implemented quickly, but difficult to expand, as soon as the complex relations between the new membership categories and different card types, both for the project or for the code itself, the maintenance costs will be doubled increase.

From the beginning of 2019 began, hornet members conducted a comprehensive system upgrade, mainly in the following areas:

• Better acquisition channels , increasing the small end of the program service display;

• Richer membership categories , adding a very large card types, in the first annual Gold and Gold Experience, based on the increase in its quarterly Gold, 7th card, "Bee Label Card", the future also plans to launch a monthly Gold , student cards;

• Lower the threshold of access to early membership can only be obtained by purchasing the App in order to allow more users to enjoy a higher quality of service, increase the incentive by completing user tasks, suppliers, product tie-ins, the line obtaining membership cards and other entities.

This also means that the same time period the user's membership will become increasingly complex, early single membership strategies and model design can not meet the demand. When redesigning membership, we have defined the future no matter what line of business division membership, infrastructure must be better able to support, so decided to membership identity module pulled out. After the upgrade membership system, adjusted to product information SKU reclassified as a minimum size, while increasing the sources of user information and access to information:

Second, the architecture design and optimization Member Center

In clear the new membership policy, we combed the entire membership system, members of the center stage of architecture design as follows:

Combined architecture diagram above, the current major division hornet's nest Member data storage systems, core services interface layer, application layer four parts:

• Data storage : mainly based on MySQL and Redis, and a hornet's nest unified log system MES

• Core Services : This is a hornet's nest current membership system is the most important one. Core services can be divided into three large pieces:

  (1) "four carriages": membership, equity, access to value-added services, membership points, the operation of the entire membership drive system;

  (2) Trading Marketing: assisted four carriages quickly ran forward;

  (3) support module: with members of the corporate level support system docking module, including risk control, monitoring, logging, message bus, merchant billing reconciliation, etc.

• Interface Layer : Member of external exposure system interface, including membership, rights and interests receive, honey consumption Interface

• Application Layer : mainly used for the C-terminus, including members of the channel page, honey center, user rights centers, mission centers

The following describes the focus of expansion around the "core services" layer.

2.1 "four carriages"

2.1.1 Membership

At present, there are many common products are ordinary members of renewals mode, such as some members of the annual video platform, quarterly membership. This model features only distinction is the time, in exactly the same after the entry into force of the membership to enjoy the rights, the rights of aging by renewals get extended accordingly.

But the hornet's nest due to the special nature of the business, membership system needs to be designed to be more three-dimensional. If only a simple renewal mode, the impact of high customer loyalty experience.

• 首先，在同一类别的会员身份下，时长不同的产品对应的权益也不同。以金卡会员为例，季度金卡、年度金卡这种同类别下的会员身份，可以通过续费升级，但它们彼拥有的权益不完全相同，比如年度金卡 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 中存储。我们使用了滑窗模式的限流方式，当发现总访问量超过一定阈值则会将大流量或者过快的请求记录到会员疑似黑名单的表中，再进行路由层的限流处理并接入公司级别风控体系，根据对不同业务场景的识别采用相关风控策略；最终通过邮件、短信等方式通知到路由层相应的技术负责人，尽快处理。

三、总结和展望

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

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

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

彩蛋

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