实时计算助力1688打造「实时挑货」系统-阿里云开发者社区

开发者社区> 阿里云实时计算Flink> 正文
登录阅读全文

实时计算助力1688打造「实时挑货」系统

简介: 内容是一个电商app不可或缺的组成部分。越来越多的人会使用碎片时间浏览手机app的内容,包含导购的帖子、短视频、直播等。1688挑货业务,打造了基于买家和商家之间老买卖关系的内容场。让商家通过内容维系老客户,挖掘新客户。

一、背景

内容是一个电商app不可或缺的组成部分。越来越多的人会使用碎片时间浏览手机app的内容,包含导购的帖子、短视频、直播等。1688挑货业务,打造了基于买家和商家之间老买卖关系的内容场。让商家通过内容维系老客户,挖掘新客户。让买家能第一时间获取到关注商家的上新、优惠、直播等信息,为自己的采购等决策提供帮助。
从宏观的背景分析,挑货业务有以下几个特点:
  1. 基于1688的老买卖关系: 关注关系、客户会员关系、星标关系、分销关系
  2. 内容的产生源头是供应商,供应商在1688网站的各种行为,都可以转变成内容信息
  3. 内容的消费源头是供应商的老买家(与供应商有老买卖关系)
  4. 内容形式比较多样:帖子、营销活动、店铺上新、商家动态、直播、短视频等一系列商家产生的有效内容
  5. 内容产生形式:供应商的主动行为、供应商的被动行为
基于上面的业务特点,我们梳理下挑货整体的业务架构。

二、业务框架

e5faa631388fc6b2d4acbcfd2836190b.png
  • 供应商在1688网站可以直接将动态和文章发布到挑货。
  • 供应商在1688网站的直播、店铺上新、报名营销活动、邀约客户等行为,会被挑货服务识别到,被动抓取到挑货。
  • 挑货将供应商产生的内容推送到供应商老买卖关系的买家收件箱中。
  • 买家访问挑货时,挑货服务会从买家收件箱中将内容渲染成各种业务卡片,呈现到客户手机端。
  • 买家可以对部分有时效性的内容(直播预告、未开始的互动)设置订阅提醒,当直播开始、活动开始时,挑货服务主动通过消息告知买家。
  • 买家可以通过挑货平台去到供应商的店铺和商品详情去购买商品,产生交易订单。
  • 挑货中的优质内容,可以投放到1688网站的其他模块,新用户看到后,能有效的产生交易和关系转化。
  • 新用户访问挑货时,挑货服务会推荐部分优质供应商给用户,用户可以关注供应商,看到供应商的挑货内容。
挑货的业务价值在于可以维系供应商的老买卖关系,提供买家快速获取供应商信息的内容,另外可以为供应商引入新的客户,并沉淀为老买卖关系。而挑货的优质内容可以投放到1688网站公域频道,一方面节省运营成本,另一方面为供应商引入更多的新用户。挑货在1688公域、私域流转上承担着枢纽的作用。

三、技术框架

为了实现挑货的业务架构,在1688无线领域孵化出多个技术方案。下面就其中关键的技术细节进行下描述。
挑货总架构图
fc25d7fe9e12c5733b59f1675c31b705.png
  • 业务对接方式:离线任务、消息对接、实时rpc
  • feeds流的推拉引擎:feeds动态生成器、feeds的收件箱推送、架构图未包含非活跃用户走拉的模式、feeds流查询服务
  • 动态组件的对接方案Cybert:业务模型和组件UI分离、动态生成native组件
  • 个性化算法对接方案(未包含)
  • 异构系统的监控体系(未包含):多种中间件平台实现同一个业务时,异构系统的监控成为一大难题。在挑货中,已经设计出了方案,目前正在对接中。
  • 数据统计系统
1. feeds流推拉结合的引擎
挑货的内容从供应商产生,到供应商的买家去消费,是典型的feeds场景。实现一个feeds流业界比较流行的主要是推模式、拉模式、或者是推拉结合的模式。
推模式:内容产生后,会为每一个订阅内容的粉丝复制一份内容,放入粉丝独有的收件箱中。
  • 优点:粉丝读取内容非常快,只是一个表查询。在写的过程中可以做很多业务干预。
  • 缺点:写的成本比较高,需要很多耗费存储,数据冗余。
拉模式:内容产生后,只会存入内容产生者的发件箱。读取时,需要粉丝读取每一个被关注用户的发件箱,实时将内容聚合到一起排序,最终展现给粉丝。
  • 优点:存储耗费少,写入速度快。
  • 缺点:查询都需要耗费很多计算资源做内容聚合,业务干预规则多时,会更加加重查询复杂度,查询性能会下降。
推拉模式:综合推模式、拉模式的优缺点使用的方案。
我们从挑货业务的特点和已有的技术积累两个方面,选取了推拉结合,以推为主、拉为辅的技术方案。
  • 1688有独立的关系团队维护了1688所有的老买卖关系数据,已经成为1688底层基础服务。而微淘的关系和微淘的内容之前是在一个团队孵化出来的。目前1688关系是B类的老买卖关系,和淘系的关系没有打通。基于老买卖关系的挑货不能直接复用微淘关系的技术。
  • 微淘开发的timeline的拉引擎,使用多级缓存,很好的支持了微淘业务的发展,在feeds流拉模式上有很强的专业性。而集团搜索团队的igraph图数据引擎也能很好支持数据多维度拉取功能。igraph有详细的文档、成体系化的接入和运维方案、专业的答疑。从对接的成本和后期运维角度,我们选择了igraph作为拉引擎。
  • 选择以推为主,拉为辅的策略的原因:
    1. 数据规模比较小:1688的老买卖关系总量在4亿,一个粉丝比较多的供应商的粉丝数量级在几十万,而在挑货频道活跃的粉丝,对应一个供应商量级在5万以下。更多的在几百到上千。所以这种量级的数据,使用推模式能很好的支持查询性能。
    2. 集团的中间件平台非常成熟:在blink平台开发feeds流的收件箱推送功能,能根据数据规模扩缩容资源,有效的支持大规模数据的推送。tablestore是一个单表支持10PB数据的nosql,作为挑货买家收件箱非常合适。
    3. 业务的规则干预比较多:需要支持屏蔽动态这样干预feeds展现的业务规则。
下面看下挑货feeds流引擎的架构图:
e2cf14accc354949ea6e03adfd3d4f6b.png
  • 内容数据流入动态生成器,产生挑货feeds,挑货feeds生成后发送metaq消息,被运行在blink上推送任务监听到,将动态索引写入到用户到收件箱。
下面3张比较细节的图:
  1. 活跃用户-推模式
    0e6a11fea5e39b4d77392457f591f50d.png
    2.非活跃用户-拉模式
    7ca4882632fb7fa727726cc6d059f40e.png
    3.非活跃用户激活策略
    f9cf5120a6b25486a3f1a9437b241f57.png
2. 动态组件的对接方案Cybert
Feeds列表原有纯native的技术解决方案,对业务的核心痛点就在于发版周期和覆盖率的限制;1. 半个月的发版周期严重限制了业务日常营销活动、用户活跃提升的运作方式,业务更希望营销类的活动卡片做到快上快下,不跟随发版节奏;2. 纯native卡片还是依托与发版,新的营销活动为了达到最佳效果,还期望于版本的覆盖率,虽然目前安卓、ios的新版本覆盖周期已经越来越短,但不代表可以做到像weex一样立马全版本覆盖。
鉴于这些业务痛点,我们可以采用的技术方案有两种1. 全weex化;2. native动态化。先从weex化来说起,去年整个营销场在整体完成性能优化后,我们已经做到ios95%会场秒开,安卓超过85%,这个秒开率对于挑货feeds来说已经足够。但当时没有采用全weex化的方案更多出于以下几点考虑:1. 交互或者后期的tabview支持,挑货feeds作为第二个主tab性能、交互、稳定性都必须去强保证,会场一些tab切换层面我们可以接受刷页面的方案,但在核心主tab我们还希望做到更佳的用户体验;2. 改造成本,原有native卡片化的方式,如果整体切换就意味这页面全部重做,这个改造成本不小。因此,我们考虑是否可以把应用在首页、工作台的native动态组件化方案做能力扩展,支持类似挑货这类列表组件由“数据驱动ui”的渲染方式,老卡片仍然采用native方案,新组件采用dinamic组件插入,既做到老方案兼容,有做到新组件动态发布。在技术改造成本、动态性、业务支撑、交互体验多个点上做平衡。
这里,我先简单介绍下目前首页cyber动态组件化方案的业务价值、技术架构和能力。CyberT原生孵化于首页,核心点就是native组件化方案,后续因为业务对于动态性能力的要求,支持了weex组件、dinamic组件的扩展,两个动态化组件化方案看dinamic组件在首页的性能从渲染耗时、内存开销上更优。由服务端下发页面布局协议、组件ui协议、服务端数据协议来驱动端上的渲染,同时在ui协议上打平后可以做到组件单端投入双端生效,后续也在进一步支持h5外投方案。
0702a2ea7a0730cb9a2be84eb0095ea3.jpg
而对于feeds列表的场景,我们如何升级能力做到“数据驱动ui”?这主要是升级List复杂容器的支持,list组件的特点是由数据决定有多少个cell。cybertron 的layoutprotocl 支持list组件声明其cell的类型 ,根据服务端返回的list数据,结合cellMapping & datamapping规则,会生成一个个cell实例,并且在框架层支持了常见的分页加载(page模式和offset模式)。
16b35c26aa09397f696faa6f2a041c3a.jpg
这样,由搭建平台配置组件和映射协议,业务服务端下发数据,通过cybert容器的客户端sdk实现协议、数据解析进行页面的动态渲染。
3. 挑货个性化算法对接(实时特征计算)
  • 优化内容排序:用户在1688手机阿里上各种访问行为,特别是在挑货的访问行为,会被抽象成用户的行为特征。通过这些行为特征,根据对应的算法,将用户收件箱中最感兴趣的内容排序到最前面,增加用户的阅读体验。
  • 提取优质的内容:用户的对内容行为,通过一定的算法,可以给内容进行评分,提炼出优质的内容。这些优质内容可以投放到其他公域场景,为商家带来更多的价值。
4. 异构系统的监控体系
整个挑货系统,数据在多个系统中流转,一旦某个系统出现故障,很难排查和追踪问题。现有的监控体系对同构的应用的链路监控已经支持的很完善。一旦涉及到在线应用、离线任务、实时流计算多个异构的系统,就无法有效的做到串联。为了保证挑货的稳定性,我们设置了全局的uuid,将整个系统的日志采集到云日志中。通过专门的监控系统,去分析日志,做到链路预警和数据可视化。
5. 数据统计系统
挑货业务承接是1688整个买家的内容需求。从业务在挑货的展现的PV、UV到具体的业务转化率,再到新业务的AB效果对比,都离不开数据化支持。所以数据化是挑货系统的必不可少的组成部分。我们实现思路,从规范业务打点方式入手,到数据日志输出规范、数据统计模块、可视化系统,完成一个闭环的数据化系统。

四、未来发展

  • 内容对接平台化(配置化、数据化):打造一个内容对接流程、内容数据展现、内容投放的配置后台。
  • feeds引擎的抽象,支持更多的业务。
作者简介
葛圆根,就职阿里巴巴,花名水锋,采源宝和手机阿里挑货技术负责人。13年起先后负责过1688内容平台、阿里头条、采源宝、挑货等多个产品的架构和研发工作。在内容平台的架构、电商app架构设计和开发、流式计算上经验丰富。
1534419398608-c7f96240-1531-48ef-867b-48

如果您有实时报表/实时数据大屏/实时金融风控/实时电商推荐等相关实时化数据处理需求,可以加入如下钉钉交流群!
TB1HzWqB7CWBuNjy0FaXXXUlXXa-157-150.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: