流量红利，已经逐渐接近尾声，这已经不再是秘密。后互联网时代，平台如何维护用户基础，提升用户体验，是整个行业需要思考的问题。正因如此，现在全行业都在关注会员体系的建设，这也是马蜂窝2019年重点投资的方向之一。面对这个全行业都在发力的会员市场，需要为具有“马蜂窝特色”的会员体系提供强有力的支持，这无疑对会员体系的结构设计提出了更高的要求。马蜂窝会员体系建设于2018年9月启动，经过前期对会员的会员状态和权益的探索，随着业务的快速发展，2019年上半年，为了让更多的用户体验借助马蜂窝优质的会员服务，公司推出了更加灵活、维度更多、权益更丰富的会员模式。在此背景下，当初粗糙的底层技术也需要及时调整，升级核心架构和服务。1.会员身份策略改造早期的会员身份模块由会员产品、用户属性和时间属性组成：可见早期的会员产品比较简单，所以将产品信息设计成一级结构。这种设计的优点是逻辑简单，可以快速实现，但不易扩展。一旦出现新的会员类别和不同卡种之间的复杂关系，无论是项目还是代码本身，维护成本都会翻倍。增加。2019年初以来，马蜂窝会员体系进行了全面升级，主要体现在以下几个方面：更完善的获客渠道，增加了小程序端的服务展示；会员品类更丰富，新卡多多在最初的年金卡、体验金卡的基础上，新增了季度金卡、7天卡、“蜜蜂共享卡”。未来还计划推出月金卡和学生卡；获取门槛低，早日入会。这也意味着同一时间段内用户的会员状态会越来越复杂，早期单一的会员策略和模式设计已经不能满足需求。在重新设计会员身份的时候，我们明确了无论以后业务线如何划分会员身份，底层架构都要能够更好的支持，所以我们决定将会员模块的身份分离出来。会员系统升级后，商品信息调整为以SKU为最小粒度重新划分，增加用户信息中的来源和获取渠道信息：2.会员中心架构设计与优化明确后新的会员身份策略，我们将整个会员体系进行了梳理，目前的会员中心架构设计如下：基于以上架构图，目前的马蜂窝会员中心体系主要分为四个部分：数据存储，核心服务、接口层、应用层：数据存储：主要基于MySQL和Redis，以及马蜂窝统一日志系统MES核心服务：这是目前马蜂窝会员体系中最重要的一层。核心服务可分为三个部分：（1）“四方”：会员身份、权益、增值服务获取、会员积分驱动整个会员体系的运行；（2）交易营销：助力四联（3）支撑模块：与会员系统对接的公司级支撑模块，包括风控、监控、日志、消息总线、商户结算对账等接口层：接口会员系统对外暴露的，包括会员身份、权限收集、蜜糖消费等的会员接口应用层：主要面向C端应用，包括会员频道页面、蜜糖中心、用户权限中心、任务中心等。下面重点介绍关于引入“核心服务”层。2.1“四方”2.1.1会员制目前市场上常见的会员制产品很多采用的是普通续费模式，比如一些视频平台的包年会员和季会员。该模式的特点是只区分时间，会员生效后享有的权益完全相同，并通过续费相应延长权益期限。但由于马蜂窝业务的特殊性，会员体系需要更加立体化的设计。如果只采用简单的续费模式，会影响高忠诚度用户的体验。首先，在同一个品类的会员身份下，不同时长的产品享有不同的权益。以金卡会员为例，同一品类的季金卡和年金卡会员可以通过续费进行升级，但权益不同。比如年金卡94折最高500元，季金卡才100元。另外，同一个用户可以同时拥有不同类型的卡，只要满足条件即可，比如金卡、蜜蜂共享卡。为了满足以上需求，我们决定引入用户身份叠加和续费模式。通过增加会员SKU叠加续费关系表，用户不仅可以同时拥有多个身份，还可以在一段时间内续费现有卡种。上图为会员状态时间线。横轴代表时间，纵轴代表不同的卡牌类型。我们可以通过最终的SKU时间线来确认用户当前的会员状态。我们将用户已经拥有的每个SKU的时间轴展平。当用户在某个时间点发送购买新卡类型的请求时，检查当前有效时间轴上是否已经存在用户购买的SPU。如果没有，叠加它。如果已经存在，需要判断SKU之间的配置策略，决定叠加还是续费；然后继续计算您购买的SKU的有效时间线；然后根据配置的规则将当前购买的有效时间轴与现有SKU进行比较时间轴的身份关系决定了用户是否可以完成购买，如：Pre-identity：表示你一定已经购买了某个SKUbeforeyoucanpurchasethecurrentSKUConflicttingidentity:意思是如果你已经购买了某个SKU，则不能购买当前SKU为了满足SKU的不同业务需求，可以通过操作配置这里的叠加和更新关系。整个流程大致如下图：为了更好的用户体验，当同时存在多个身份时，我们会根据数据分析结果调整会员SPU权重，优先考虑权益具有高权重。例如，当前会员同时拥有金卡和票卡，数据显示金卡权益的使用率或关注度高于其他产品，则金卡权重将增加，以及当用户进入会员频道页面时，首先会显示金卡状态和相关权益。2.1.2权限中心除了身份系统，最重要的是会员权限，它直接体现了会员的不同等级。会员项目开发初期，一切从零开始，对可扩展性的要求不高。每次出现新的身份或卡类型时，都需要重新设计其中包含的好处。开发效率很低，后台的配置也很零散。.为了支撑后期业??务的快速发展，我们开始考虑拆分股权中心，一分为二进行改造。第一步是股权池的建设。下图是权益池的基本模型：我们将会员权益的通用属性抽象出来，定义为原则上不变的基本属性，形成“权益材料”存入权益池。常用属性主要有：福利类型：主要有兑换码、折扣购买、优惠券、三向跳转四种。目前，各类福利均由马蜂窝支持。供应商：不同的供应商提供的福利不同，甚至有不同的权限获取流程和权限消费流程也涉及供应商结算模式的不同发放时间：主动发放或被动发放，比如金卡94折，是用户购买会员的核心权益。用户购卡后，福利直接发放到用户账户。机场贵宾室、QQ绿钻、腾讯视频季卡等其他福利需要用户主动领取。基本属性：权益的基本属性取决于权利的类型、发行时间和供应商。也就是说，不同的供应商或不同类型的权利和发行时间会组合不同的权利和利益的基本属性。这里的大部分属性都是这些兴趣的固定属性。最终，这四个属性共同构成了基础权益素材。用户开卡发放福利流程如下图所示：会员产品支付完成后，会员中心通知福利中心发放福利；利益中心在利益过滤后通知折扣中心，折扣中心最终完成被动利益的分配；用户主动领取的权益仅发放给用户，最终由用户决定是否领取。第二步是配置权益规则。第一步基础建立后，会员中心为权益池中的权益素材配置相应的权益规则，然后展示给用户。权益规则主要分为：条件规则：是指确定权益的一些基本前提条件，主要是指会员状态、之前请求的来源、当前业务等。其他操作规则：这是变化最多的权益规则，也是股权中心精细化运营的一部分。不同的用户身份有不同的权益价格、兑换价格、不同的标签，区分了用户的身份和特权。我们将权益规则中的共同属性抽象出来，形成统一的权益对外展示标准。当然，仅仅有一个通用的公平规则配置是远远不够的。因此，在不影响核心权益规则的情况下，在后台增加扩展规则模板的配置，以满足不同规则对特殊权益的需求，实现规则的动态配置。使用更灵活。2.1.3第三方权益接入部分权益池为现场权益，如核心金卡产品40折、马蜂窝优惠券、接送机机场等。发行消费这些权益都是在站内制定的统一规则下完成的，比较容易获取。部分权益池为现场权益，如4折核心金卡产品、马蜂窝优惠券、接送机机场等，这些权益的发行和消费均在统一规则下完成设在车站内，出入比较方便。另一部分是需要享受的场外福利，即为会员提供的增值服务，如机场贵宾室、旅游保险等。不同的第三方有其特殊的权益规则，目前无法抽象成统一的标准，也无法通过OpenAPI访问。现阶段我们在流程中整合了第三方权益的接入，最终形成了两种方式：一种是权益在马蜂窝收集，用户的所有操作完全在我们自己进行。申请，完成后异步调用第三方接口给用户发放福利。第二类是权益的申领过程完全在第三方系统中进行，主要是针对一些积分兑换的权益。用户点击领取福利后，跳转到第三方页面。交互完成后异步回调马蜂窝接口。马蜂窝系统根据回调情况加分或扣分。这种方式的缺点是用户体验完全由第三方决定，可控性不高；但好处是可以快速获取一些复杂的权益，比如一些游戏权益，避免在开发上投入大量精力。上图是两种采集模式的对比。可以看出，每一步中的三方连接都是异步进行的，这样当第三方系统出现故障时，不会影响马蜂窝的正常服务，从而保证了系统的可用性。2.1.4会员积分成长系统对于构建完整的会员体系非常重要。以内容社区起家的马蜂窝，在这方面有着天然的优势。我们决定引入现有的用户积分系统“Honey”来承载部分会员积分的功能。通过与会员中心打通，加强与会员用户的线上互动，提高用户活跃度和粘性。在不同的蜂蜜场景和蜂蜜策略下，用户可以获得积分，满足相应条件后可以兑换所需的权益；此外，我们也在拓展更多蜂蜜和B端结合的方式，希望能促进平台和商家的双赢。上图是使用蜂蜜中心提供的服务的会员系统和近期的一些计划。如何利用好激励机制完善整个会员体系，实现会员用户更精细化运营，是马蜂窝“内容+交易”战略深化的重要课题，也是研发团队需要努力的方向继续探索。2.2营销活动绩效优化会员中心、权益中心、第三方权益接入、蜜源中心的改造实现后，会员中心也完成了升级之路的第一步。为了让更多的用户了解会员机制，体验会员特权，我们推出了很多营销活动。其中很多活动都有秒杀场景。以下部分重点介绍技术优化，以确保这些活动的稳定性和可靠性。2.2.1并发控制在闪购场景中，需要防止高并发导致的库存超卖。业界对于这个问题已经有很多成熟的解决方案，比如悲观锁、分布式锁、乐观锁、队列序列化、Redis原子操作等，当然最理想的方式还是使用分布式锁。考虑到目前的并发水平和技术成本，我们现阶段决定使用MySQL乐观锁来实现闪杀功能。我们都知道数据库中同一行的Update是不允许并发的，只有当该行更新时才会释放。我们的解决方案是通过添加一个唯一的Version来防止超卖的情况：每次更新数据时，判断版本号是否与数据库中的版本号一致。如果不一致，说明当前库存已经被其他用户占用，此时抛出异常；如果一致，则完成当前用户对库存的占用。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点起，我们将从公众号后台选出7位评论质量最高的读者，送出马蜂窝季度金卡，不要错过！（扫描下方二维码关注公众号）
