千牛挂“虹(Rainbow)”,域和角色不胜数

  1. 云栖社区>
  2. 博客>
  3. 正文

千牛挂“虹(Rainbow)”,域和角色不胜数

云栖小秘书 2016-09-23 12:16:31 浏览6422
展开阅读全文

本文主要从千牛的架构开始谈起,然后解释了千牛的开放模式,进而分析了千牛的多域多角色特性,最后和大家分享了云数据前置服务的方案。

直播视频:点此进入

PDF下载:点此进入

以下为精彩内容整理:

 

千牛

千牛是全球领先的TO B端工作台,支持多域多角色,面向泛卖家领域的一站式经营工作台,千牛是一云多端的开放平台。

业务架构

633862ec0f43670923c4a825d44054fc1e1a619c

从下往上看,最下面是基础设施层,整个阿里的电商中台以及阿里云为ISV提供服务的部分;接下来是PaaS层,目前有御膳房、聚石塔、开放平台和千牛平台服务;所有的云端设施都会通过千牛端向ISV提供数据层、业务层、开放层的服务;然后通过千牛消息中心、数字面板、千牛的应用容器和千牛的任务通道等平台对商家输出,组织成商家经营链路里的各个工具。

技术架构

5b71fb63398d78f12d6b4557fac254c64c2d4d4b

从端上来说,端上最底层的业务开放层,服务商是基于这一层开发面向商家的软件或消息。业务层下,我们提供给服务商最基本的能力有插件互通协议、数据同步和监控等。端与云是打通的,电商中台&阿里云提供相关插件,千牛提供平台服务来支持千牛OS操作系统本身,千牛云端有接入层,接入层有上行通道和下行通道,下面的千人千面模块上有资源层开放给ISV使用,右侧有一些基础设施。千牛与淘宝开放平台是紧密合作,天然打通的。

问题和挑战

千牛作为商家的第一入口,面临的问题和挑战有以下三方面:

  • 高稳定:卖家work at alibaba,和卖家生计相关,平台本身稳定性要求非常高。
  • 平台模式:平台模式下,业务相对分散,如何从平台的角度把控稳定性。
  • 一云多端:PC端的存在,让多端同步变的更的尤为重要。

 

千牛的开放模式

e229bce7a4756275e05c26603ae28ed58f73585e

千牛是基于插件体系的能力开放,最上面为千牛数字面板,中间是插件入口,点进去后就是ISV具体的插件,右侧是目前千牛对外开放的部分能力,比如发旺旺消息、基础组件等。

最初进行移动开发时,面临着移动网络的三座大山,流量贵、不稳定性、速率慢,所有的网络请求都是相对比较昂贵的,如果不基于千牛开发,我需要解决哪些问题呢?

业内会有AppCache,它是H5提供的一套离线方案,AppCache解决了缓存问题,让更少东西在网络上传输;在移动开发中还有Spdy协议,它可以把多次Http请求复用到一根连接上,通过复用同一根连接来节省开销;此外,Webp能解决图片问题,起到压缩的作用。所有线上的官方实践证明,只有减少能让用户最大程度感知到性能提升。

长连接系统Rainbow

dfa3d282a55c35ce1353169d57eb67375e1e1305

当客户端连上时,会与服务端建立一个Rainbow的长连接,该系统为纯异步系统,对线程切换敏感,且线程隔离。

网络优化

9946ba6ba5074aba95799241dcf273c55ea9c7af

基于Rainbow做了网络优化。首先客户端有SDK层,SDK层拦截所有请求,同时可以进行切换,SDK层下面有逻辑判断层。我们针对开放平台和千牛服务做了优化,当上层业务掉到千牛网络层时,如果是开放平台或千牛服务器的请求,我们会把Http请求通过私有协议转换成一个Rainbow的TCP包,将TCP包通过Rainbow的长连接发到Rainbow的服务器上,Rainbow服务器收到TCP请求会还原成一个Http请求,由Rainbow代理客户端去请求目标服务器,再执行相同的逻辑把数据进行返回。在整个网络优化下,首先砍掉了三次握手,当发起Http网络请求时,变成了通过TCP请求只握手一次,剩下全部复用这个连接;其次本地没有DNS解析,所有DNS解析由服务端提供工作。

实践总结

效果:

  • 弱网环境下,速度提升2-4倍。Wifi环境下效果不大。
  • 采用私有协议和SPDY协议( http2)的选择。
  1. 核心是多路复用,压缩复用;
  2. 拆包,请求优先级,在千牛的场景下(不走大数据,只走业务数据)没有太多效果。
  • 稳定性监控和接口审查。

带给我们的成本有以下几点:

  • 业务服务提供方接入成本
  • 黑/白名单的维护成本
  • 中心化流量成本

开发容器的演变过程

一开始千牛尝试的就是AppCache,通过定义某些JS和CSS进行缓存来完成千牛插件的工作,但是在使用过程中有很多的问题,比如各OS版本支持良莠不齐;离线缓存更新下层,遵循HTTP缓存协议,多层缓存协议易出错;首次加载白屏时间不可控;数据统计难,扩展难度大。于是千牛切换到离线包模式,App不再像原来直接嵌入一个网页,而是直接将App相关的页面打包,通过离线包直接下发到客户端,保证了支持的一致性,还有丰富的打点统计和监控大盘,白屏时间几乎为零,去除网络消耗;但是用户有时使用H5页面还是会卡,对此,千牛尝试了native化,白屏时间再次提升,完全的非webview实现,渲染性能和执行性能都得到提升。

开放容器结构图

cb45becf7beec456fc2cc4fe66a3ec574bb83314

在千牛开发平台2.0中,Framework层提供生命周期管理、存储管理,同时提供一整套的千牛视觉规范以及UI组件,ISV可以基于组件直接进行开发,还提供一些打点的工具,底层有Web容器和Native容器,同时基于整个开发平台还提供了很多个工具。

云端监控

f87677068e171c044f38f1f5e09caf5a936ec44c

我们为所有ISV和插件提供了一整套的监控系统,千牛OS下面有应用容器,应用容器把所有用户请求进行相关的打点,包括页面渲染,将数据进行归集,由Native统一采集层采集,然后上传到服务端,计算完成后把数据展示在开发控制台和运营工作台上,同时可以在控制台上控制端上的一些行为,反向作用于千牛OS。

 

多域多角色

面向卖家的多域多角色

ac741379261f7d02ea61ac47d749d216f954e1bc

千牛是面向泛卖家领域,所以包括淘女郎、阿里云、1688以及服务商所有卖家用户都在千牛上使用。对于大商家而言,卖家是一个团队,团队中可能有客服、运营和仓储,我们提供了一系列基于卖家的子帐号,每一个子帐号对应一个岗位角色,随着卖家领域的深入,岗位不断扩充,我们的用户名非常多,岗位非常多。

多域多角色开放引擎

821389f01baf01f3795cde461ae4698cf34da734

千牛做了一个多域多角色开放引擎,使得资源接入方便,条件接入方便。资源设置了使用用户的人群后,千人千面相关的资源在客户端进行调用时,会首先将资源加载出来,然后根据设置条件加载用户身上属性,进行合并计算,返回给客户端,客户端就只能看到他使用的插件。

 

云数据前置服务

云数据前置概念提出的背景:

  • 高可用性压力下缓存数据的大面积使用:关键业务服务端离线尝试。
  • 数据更新要求更实时:插件数据变更;用户对多端数据同步要求越来越高;越来越多的决策式数据,需要快速而精准的投放。
  • 洪流效应:部分数据更新,如果采用服务端推送命令的模式,会给服务端产生大量的压力。

业务解决常用手段

130df635c285a2cc7f16a83d51d2c34c5b644c0f

当客服与用户聊天时,有一个业务叫快捷短语,当用户输入某几个关键字时,Native会计算关键字匹配的快捷短语,并且提示用户快速补全,所有的计算一定不发生在服务端,走网络请求会变得很消耗,我们需要把这部分数据全部推送到客户端上由本地进行计算。但客户端切入前台时,首先会调用快捷短语,如果发生数据变更,这时就会通知客户端写本地,通知客户端的过程有可能长连接是断开的,所以并不能保证消息的可达,所以当不在线时一定要做一次全量更新。

问题

数据洪流:

  • 每个业务都需要完成一次推拉结合和ACK,保证消息必达
  • 大量更新请求在切入前台或者登陆的时候发起,导致登陆或者切入相对较卡
  • PC端上班早高峰会有大量数据获取请求

高成本

  • 每个业务方都接入消息推送逻辑,都需要客户端排期。
  • 平台数据推送成本较高,每个业务需要搞一遍。

数据同步方案

6a54c5d7923d4013f8c64e7c6978b5819d6bce46

数据同步实现了一个云端表到本地表的同步方案。该方案具备易用性和灵活性。我们会有搜索引擎维护用户相关关系,同时我们会维护用户相关的有效设备,也会有面向目标的过滤层,存储用户同步日志等,右边是服务端的工具。

7013007917926378e7e5e55ef2848f243aceece2

搭建好数据同步方案后,数据推送会有平台数据(插件回调地址)和用户数据(插件在桌面上的排序)。这两个数据同步的难度是不一样的,用户数据只要同步给单向用户,一个平台数据改变,需要推送给这个平台数据关联的用户。当数据发生变更时,会向数据同步系统写入一条变更的Log,记录下来后写入操作就返回了,接下来如果在线的端会收到一条相关的Push,收到Push会把当前数据具体推送到某一个用户,推送之前会把数据存下来,如果收到ACK,标志这条数据已消耗。

0a82ded1625df272b05d3071fcbc870f4978cc5e

千牛数据同步方案接收层执行On的操作,目前提供API call的方式,未来可以监听云端库变动,同时也可以接收Notify、metaq的事件消息;关系层会呈现数据放大效应;用户层执行的是表的变更。

平台数据解决方案

aa40ef6961fc11f8c36cf6ca4835943965a26b2b

千牛整体的关系层目前通过三层过滤解决更新百万数据的难题。第一层为粗分桶,通过用户域的切分直接对用户进行粗过滤,基于基础的标签纳入到粗分桶的过程,我们通过阿里云的OpenSearch开放搜索引擎来做的;第二层为业务级过滤,主要依赖业务方真正实现这层的关系中心,对于业务方须看不同的Case;第三层为端兜底过滤,哪怕是百万级数据,也可以快速直接推送到端上,并且关系表达是准确的。

网友评论

登录后评论
0/500
评论
云栖小秘书
+ 关注