5亿会员融合技术实践,力促苏宁818井喷增长!

原创
开发 架构 开发工具
随着苏宁智慧零售的发展,现已形成六大产业布局,分别是:苏宁云商、苏宁置业、苏宁文创、苏宁投资、苏宁体育、苏宁金融。

[[200579]]

【51CTO.com原创稿件】随着苏宁智慧零售的发展,现已形成六大产业布局,分别是:苏宁云商、苏宁置业、苏宁文创、苏宁投资、苏宁体育、苏宁金融。

六大产业的资源整合中全产业会员融合是重中之重,全产业会员融合以苏宁易购会员帐号为基准进行全产业打通,以达到一个帐号全产业使用的业务目标,整个融合依托苏宁易购现有的基础技术、架构建设与现有业务系统的服务能力。

[[200580]]

我有幸参与了全产业会员融合的项目之一,在这里从基础架构、数据流转、营销、效益等方面展开给大家介绍苏宁易购、聚力 PPTV、苏宁体育、龙珠之间的会员融合技术实践。

我是技术出身,这里介绍数据融合和营销融合相关过程中碰到的相关事项,其中将重点介绍营销融合相关系统的一些设计。

基础架构融合

网络

苏宁易购、聚力目前在全国均是多 IDC 架构,IDC 数量不下于 10 个,其中聚力机房非自建。

全产业会员融合项目涉及到的系统众多,每个 IDC 都会有若干个系统部署在里面,系统之间相互调用经常会跨 IDC,导致 IDC 之间的网络拓扑相当复杂,网络链路也相当长。

解决网络延迟、网络链路过长问题主要是通过拉企业专线来解决。下图为城市 A 的 IDC 与其他城市的 IDC 之间的全拓扑结构,已经是相当复杂。

若每个 IDC 之间 Point To Point 的网络拓扑更复杂,专线数量如下图所示,企业专线成本也是相当高。

基于成本、性能考虑,业务系统划分为两类:

  • 时效性要求高的业务数据。
  • 对时效不敏感且可延迟同步的业务数据。

基于这两类业务进行 IDC 划分,从而减少拉企业专线的数量,同时同产业的同类业务尽量不跨机房,对专业需求做统一规划。这样在满足业务的 TP90、TP99 情况下也节省了成本。

基础组件

约定原则:

  • 各产业现有系统所使用的基础组件保持现状。
  • 新系统原则上可以使用苏宁易购基础组件。

部分公共组件:

部分公共系统:

  • Redis 高可用架构方案以及 Redis client Sedis 组件,支持横向扩展、数据迁移、大 KEY 发现。
  • 数据库操作组件 DalClient,兼容 DB2、MYSQL、支持跨 DB 事务,支持注解事务,SQL 解析,灵活的、可自定义分库分表等功能。
  • B2C-FC 是公共流控组件,支持按用户、URL、业务(商品、品类)等维度进行流量频次控制,支持令牌桶算法、用户轨迹验签、排队、实时 UA、IP 聚集分析等功能。
  • RSF 中间件是一套成熟的 SOA 解决方案软件套,包括服务注册、服务发现,服务治理,服务多版本管理、服务异常管理、流量控制、服务降级、服务资源隔离等。

易购基础组件就不例举了,苏宁以易购基础组件在各产业中为主基调进行使用,避免了后期在各产业中基础组件的重复研发,也推进了易购基础组件的发展,这样业务推动技术,技术驱动业务,形成一个良好的相互推动的生态循环。

数据融合

会员基础数据融合

会员基础数据融合中的一帐通项目是全产业会员融合中一个关键项目,重点是各产业之间会员的打通。目前现状如下图:

易购、聚力 PPTV、龙珠、体育各产业自身会员自成体系(会员帐号、会员成长体系),均有各自的会员帐号、会员基础数据、会员营销数据,也有各自的登录、注册门户。我们的业务目标是一个帐号可登录六大产业所有系统,且权益互通融合。

基于目前企业架构及系统架构,设立一个大而全的六大产业的会员中心,从数据复杂度、项目周期、成本上来讲都是难以接受的,在这种情况下我们把一帐通项目核心逻辑定义在会员关系绑定,会员资料互通的基本原则上。

会员关系绑定采用单向系统绑定原则,均由苏宁易购会员系统(CMF)绑定,再异步推送绑定关系给其他产业的会员系统。

  • 用户在聚力PPTV注册,注册成功后聚力 PPTV 的会员系统会异步把消息推送到易购的会员系统。
  • 易购会员系统根据请求数据自动生成一个易购帐号,并把聚力 PPTV 帐号与易购帐号进行关系绑定,最后易购会员系统把绑定关系推送给聚力 PPTV 系统,从而实现了一个帐号可登录易购、也能登录聚力 PPTV。
  • 聚力 PPTV 老用户在登录时,会引导用户去做关系绑定操作,还是由易购会员系统进行关系绑定,并再异步给聚力 PPTV 系统。
  • 易购会员系统具备绑定关系、会员资料补发能力。

数据一致性:

  • 用户资料数据一致性由各产业会员系统定时发起一致性检查请求与对帐功能,类似事物消息的最终一致性。

安全:

  • 涉及会员敏感信息(会员资料),与用户端交互通信协议均采用 HTTPS+Token 验证。
  • 接入苏宁易购的风控系统,并建立特定的风控模型,防撞库、防刷、防 CC 攻击等。

营销融合

营销融合是基于上面的会员数据融合后获取数据,依靠用户基本数据与采集用户行为数据进行精准化营销。

对于苏宁易购来讲,营销融合在闭环营销平台都已经是支持的,各产业的融合带来的挑战是数据量、特征量、计算量等维度变化(针对原有模型增加特征)等挑战。

整体逻辑架构

我们先看整体逻辑架构图:

精准营销平台分离线营销(Offline Marketing)、实时营销(Real Time Marketing)。

实时营销的总体结构是实时采集苏宁易购、PPTV、体育等各端各渠道的数据,基于大数据实时计算的能力实时对数据分析、聚集、特征抽取计算进行精准营销,再依赖精准、可靠、快速触达的消息触达系统进行消息推送。

消息推送系统目前支持微信、Push、Email、SMS、站内信 5 种类型的消息。

随着 PPTV、体育业务数据的融合到系统,每天业务上的消息推送量呈上千万的增长,同时对推送时间要求更是在秒级以内。

比如:体育赛事结果的推送,都要求秒级以内完成,从赛事结果的出来,到通过计算用户基本数据与行为数据来确认哪些特征的用户需要推送此次赛事结果,全部都是在秒级内完成。

同时 818、双 11 这样的大促期间,发送的消息总量达到几亿条消息,这对触达系统在设计上满足这么大的消息量处理与保证时效性都具有很大挑战。

触达系统

下面是触达系统的整体逻辑架构图:

 

我们整个系统的设计原则就是任何模块越简单越好,当然简单并不代表缺少功能和逻辑。在外部数据来源、各模块功能上都基于简单原则设计。

触达系统为了保证其性能,我们在设计过程中聚焦在消息发送上,不对消息进行组装、发送额度等业务处理。

吞吐量与数据源

触达系统只接受来自按渠道+平台划分的 kafka topic 数据,这方面保证了触达系统的消息来源的单一性,同时触达系统也不对外提供任何协议的服务。

使用 kafka 也解决了与数据来源系统的耦合,在设计上每个 kakfa topic 的 partition 均按支持 2 万 TPS 设计。

每个渠道+平台对于消息量、消息时效性要求是不一样的,按 topic 来划分数据源方便于与按 kafka topic 降级和服务器扩展,即能满足量不大的服务容量需求,也能保证大容量需求的业务场景同时不至于浪费服务器。

渠道隔离与降级

每个 JVM 实例只会接受一个 kafka topic 的消息,这样就能轻松做到按 kafka 进行资源隔离,防止了相互之间的影响而可能引起的雪崩。

JVM 实例与 kafka topic 关系维护在统一配置平台同时支持 JVM 实例与 kafka topic 的映射关系支持热切换,在整个切换过程 JVM 监听线程池会停止对 kafka topic 的监听,消息处理线程、消息回执线程池均会停止工作,直到新的 topic 相关的线程池被拉起。

先停止监听线程池工作,再等待消息处理线程池、消息回执线程池处理完所有 Task 后再切换,整个系统各模块之间通信采用事件监听模式进行交互:

  • 降级支持按 topic 降级、流量控制降级、按速率降级(在消息监听模块中使用)实现了消息方按一定的速率(速度可配,可随时更改)从 kafka partition 中取出数据(使用的是令牌桶算法)。

营销执行平台

营销执行平台基于营销事件、营销标签、用户特征计算符合条件的用户,使用 ES 做数据聚合分析、排重、标签筛选等。

依靠 Hbase、Hive、DB2 等对数据存储持久化,基于用户画像、用户标签等做离线的用户需求特性化分析、预测,使用 Spark、Storm 基于用户属性模型、行为模型等做实时预测与营销。

小集群大规模

用户特征基本数据、营销标签数据、排重数据等数据总量达到月度十亿以上,均在 ES 大集群里,分 30 个小的 ES 集群,每个集群为 5 个 Shard,形成一个大的 ES 集群。

从架构上解决了单索引量大与查询时跨多 shards 后数据聚集到单 ES 实例导致此 ES 宕机等问题,同时提升了响应时间。用户数据由用户唯一标识进行路由来决定落在哪个小集群,路由规则借鉴了 Redis 的 slots 解决方案。

离线营销 JVM 抢占

离线营销由运营人员在各营销门户创建营销活动,离线营销活动特点是计算数据量大,当多活动同时跑时可能会出现多活动路由到同一 ES 小集群里会瞬间对此 ES 集群造成大冲击。

基于此情况,设计了一个基于 ZK 锁抢占 JVM 设计 ,确保一个 ES 小集群同时间只有一个活动任务计算。

效益展望

“一账通”实行后,多平台导流效果表现较好。数据表明,PPTV 的新增用户有超过一半会导流到苏宁易购,其中有效转化率与易购平台本身的转化率相似,产生购买行为。

另外,用户权益更加集中,会员享受服务更加全面。在拥有更多元、更优惠的玩法同时,服务基本覆盖衣食住行及文体娱活动。

聚力 PPTV 新增注册用户很大比例导流结合易购新人 199 礼包也成功为聚力导流为易购新增用户,订单转化率也增高。

聚力 PPTV 与苏宁易购实现线上流量互导,跨业态导流,产业间交叉引流,后续进行会员权益跨产业共享互通,其他权益正在打通中,进一步促进流量互引。

流量互引后就是全产业会员数据完全整合,全方面采集会员各维度数据,用大数据、人工智能相关技术分析用户行为、特性,让我们更了解用户所需,对市场进行预测。

[[200585]]

尹坚

苏宁云商IT总部高级架构师

主要负责基础软件架构、系统架构建设和基础组件技术研发工作,同时,参与 818、双 11 大促保障、系统稳定和性能优化工作。在苏宁的任职期间,经历了公司线上线下的快速融合,以及公司技术能力的飞速发展,曾参与与负责苏宁易购大聚惠、四级页、云信、流控排队等系统的架构和研发工作。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

责任编辑:武晓燕 来源: 51CTO技术栈
相关推荐

2020-06-01 08:41:29

苏宁分析大数据

2020-11-10 09:05:45

用户画像苏宁

2016-09-01 10:11:18

CDN

2018-11-12 12:45:19

2017-08-11 17:12:09

商用办公

2018-11-06 09:30:38

数据仓库架构苏宁

2017-08-23 18:28:40

华为

2017-11-16 09:22:00

物流电商快递

2019-12-24 09:30:59

苏宁高可用高并发

2013-02-20 10:07:29

苏宁电器苏宁云商云服务

2018-05-25 22:56:14

AI技术短视频苏宁易购

2017-08-02 09:39:54

2018-11-13 08:00:14

苏宁iOS开发

2013-11-07 12:27:07

2013-10-29 09:28:38

苏宁云商

2018-05-09 14:45:50

苏宁前端Nodejs

2019-02-19 09:00:00

深度学习知识抽取苏宁

2015-08-14 14:43:59

统一客服平台苏宁华为

2010-07-21 16:12:40

三网融合

2019-04-09 08:00:00

苏宁发票中心系统
点赞
收藏

51CTO技术栈公众号