惠州网站公司,清远做网站公司,河南百度推广公司,域名建网站导读#xff1a;大家经常看到手淘里面的第二个TAB 就是微淘了#xff01;目前有几千万 DAU#xff0c;几百亿关注关系#xff0c;每天几十万的商家生产内容#xff0c;对系统的挑战较大。产品形态上目前以关注 feeds 流为主#xff0c;是商家非常重要的获取流量阵地… 导读大家经常看到手淘里面的第二个TAB 就是微淘了目前有几千万 DAU几百亿关注关系每天几十万的商家生产内容对系统的挑战较大。产品形态上目前以关注 feeds 流为主是商家非常重要的获取流量阵地自运营阵地下面和小编一起看看微淘技术演进史。 内容生态对淘宝的价值
1.辅助购物即帮助消费者做更好的购物决策
比如搜索、猜你喜欢透出内容辅助你挑选哪个商品好宝贝详情的主图视频、买家秀、大咖点评、客服直播等等帮助你该不该下单。用户在淘宝购物过程中总会出现各自各样的需求痛点我们就会尝试用内容的形式解决这些需求这是大家在手淘里面看到最多的内容也是内容对零售最基础的价值技术上我们构建了新零售内容平台以平台化的方式支撑各种各样的场景。
2.探索生活消费社区
目前淘宝的心智主要是购物大部分用户都是想买什么才来所以有“万能的淘宝”“只有想不到、没有买不到”的消费者心智如何结合购物延展心智服务更多消费者对淘宝是非常重要的。如果能有“想不到买什么有事没事空闲的时候来淘宝逛一逛” “解决上亿中产阶级有钱没的花找不到好东西”类似这样的心智形成那么我们离生活消费社区就更近一步了微淘、洋桃社区等业务就在这方面做探索。
微淘的技术挑战
内容消费业务通用的模型
基本上就这些模型非常简单但一些细微差别会带来的产品的心智完全不同但大体上从工程架构看可以抽象为一套。
账号大V、机构、店铺、消费者
内容类型短图文、长图文、短视频、直播
关系BC 关系CC 关系、单向双向
内容互动赞、收藏、评论、弹幕、负反馈不感兴趣、举报、拉黑。还有直播特有的连麦等实时互动
场景关注流、发现流、热门、附近等
当时做微淘时也负责手淘的主要社区对工程来说很类似同时手淘其他社区场景的同学也希望能复用我们的服务所以第一件事情是我们构建了。
淘宝社区 API 集
结合 PD 统一了手淘所有的内容互动 API 以及关系、账号 API 完成了 “社区平台雏形”为什么是雏形因为这个平台只有基础 API 当时思考是具体每个社区场景呈现都不一样所以上层业务需要基于 API 各自组织业务。整体研发效率上提升不少用户相关的内容互动、内容数据完成了统一。
timeline 引擎
微淘是基于关系的几年前 feeds 引擎业内是很火的基本上 Facebook 、 Twitter 、微博等大公司都在探索我们也伴随着业务沉淀了一套微淘业务与 timeline 引擎的关系如下 拉引擎我们内部也叫基于关系的搜索引擎。
拉模式的适合场景是关注数和粉丝数数严重不对等的情况比如微淘的场景部分店铺的粉丝数过千万但是用户的关注上限是几千这里面如果一个大 V 发一条 feed 走推模式要更新千万的用户 inbox 显然是不合理的。
但是对于关注数和粉丝数差不多的情况不建议走拉模式。比如朋友圈关注上限大概是500粉丝数大概也是500那么推模式更有效。
下面介绍下拉引擎关系搜索引擎的实现原理
举例比如我的淘宝--店铺关注列表里面对店铺名称的实时搜索。 从这里进去
对店铺的标题建索引输入 a 可以查到有这么多关注的店铺。 去取消关注后再输入 a 查询可以看到结果实时变化了~ **术语inbox 用户的收件箱outbox 用户的发件箱 **
两者数据结构是一样的类似邮件收件箱发件箱里面存了很多封邮件 每封邮件就是 doc 邮件有标题、副标题就是索引 index 。我们可以根据 index 来快速查找一个用户有多少匹配的邮件这个就是 inbox 的内部搜索
邮件系统是用推模式实现的 如果用拉模式来翻译的话。
我关注了很多人我想一次性根据某些索引查询这些人的发件箱中满足匹配的邮件并且按照一定排序规则来汇总。
以上面的关注搜索店铺名称为例店铺的标题、认证、简介等都是不同的 doc 索引是标题字符串
所以 outbox 就是 doc 数组。doc 则由 doc_idindex 数组 组成。
假设只有店铺标题一个doc。
我们调用引擎把店铺 iddoc [“xxx旗舰店”]写入到引擎里面
对于每一个店铺我们把 doc 数据先更新到 db 然后更新到分布式缓存店铺的 outbox 然后失效每台机器的本地缓存 outbox 。考虑到性能和时效性我们对 outbox 的 doc 数量做了上限doc 数量超过 3000 远满足一般性需求 当店铺的 outbox 第一次被访问时如果非热门店铺本地的堆外 LRU 缓存加载如果是热门店铺加载到静态缓存区域。
热门店铺的判断逻辑是离线计算粉丝数最高的 TOP N 店铺然后定期更新名单库这里面由于大号的粉丝特别多基本上热门店铺的关系数量占用全部的关系 50% 以上。
整个查询逻辑如下 整体本地内存命中率 95%本地加远程命中率 99.9%未来改为持久化缓存则 100%
堆外缓存可以大大减少FullGC概率。
另外 outbox 的压缩和解压缩非常关键索引字段全部采用原生类型先采用 Kyro 序列化然后 ZIP 压缩
端测渲染引擎
业界内容业务的特点总是交互体验创新层出不穷在微淘也不例外。
微淘又是手淘一个 tab 对性能要求更高尤其低端机型的性能。
对业务方来说交互体验差是无法接受的对于隔一个月发一次版本勉强是可以的但对于技术来说研发效率提升是我们要不断追求的。
所以整体微淘的端测渲染技术策略是体验为主、效率为辅。
在今天如果端测的 UI 渲染技术同时能满足体验和效率那就不用折腾了但是很遗憾目前没见到过。
下面是 2017 年初的现状灰色部分当时还没有。 在以体验为主效率为辅的策略下微淘端测动态化的几个阶段 当时卡片组件化最大的问题是限制了 UED 同学的视觉交互创新往往一个细微的创新看似很简单却发现组件化改动很大。比如给整个内容大卡片套一个外框则要求每个小卡片都做修改。过程中与 PD、UED 组件化的约定做了几次但是在创新面前还是败了。
我们在 2017 年开始打造以体验为主效率为辅的 TNode 引擎DSL 从最初的客户端语言到最后与前端共建升级到了 VUE 有效的解决了端测研发效率问题同时微淘性能在手淘主链路中保持中位数。
Tnode 的技术架构 这块主要是淘云、重哥、水军等同学实现我简单介绍下
1、首屏性能优化Duktape 引擎替换 WebView 低内存高性能。提供端测表达式引擎常规逻辑处理采用 Native 函数。 2、页面完成渲染后所有事件异步js驱动
3、DSL 二进制减少网络、解析大小。DSL 中表达式预编译。
4、Flex 层级优化如采用虚拟节点等方式
目前 TNode 是前端开发因为是效率为辅他仍然存在很多效率问题最大的两个问题是
不能完全满足 W3C 协议换句话来说以前端思维看这个还是很坑像是早些年前端同学兼容 IE6 感觉一样。
与手淘前端主流的 RAX 以及封装的 Weex Native 模块不融合这意味着没有生态。
但 TNode 确实解决了那些以体验为主效率为辅的场景架构组在了解 TNode 架构后基于 WEEX 生态在 2019 年初基本完成了 WEEX-EAGLE与微淘同学一起试点试图解决问题 2。
TNode 最大的价值是加速了整个手淘动态化演进的进程如果把当前的动态化技术比作混合电动车时代那他在市场上还是会存在一段时间但是最终一定会过渡到电动车让所有消费者无顾虑的接受。对于当前动态化技术是一样的在体验为主效率为辅的场景 与在效率为主体验要求不高的场景是两种不同的方案。然后最终有一天会融为一体甚至加上 BFF 三端一体未来都是大前端领域范畴。
内容分发平台
前面提到了我们构建了大量的社区基础 API 但是每个场景业务逻辑都不太一样场景层都要定制开发。
我们遇到了几个问题
1、系统比开发多内容分发社区的场景是非常非常多的前面提到我们要试图解决用户在购物路径中的各种需求而且业务升级频率高以往为了隔离都是一个业务一个系统业务大升级又得来一个系统久而久之业务系统比开发还多。
2、不同客户端版本兼容成本高客户端老版本兼容bug 修复带来了大量的 ifelse 而且好几年内都不能下线写完后代码过几天自己也看不懂了也不敢动了也不想看到了。
3、业务代码生命周期短、系统频繁重构怪圈徘徊于代码复制和复用的纠结如果新老业务代码复用复用代码改变则要回归很多历史版本在手淘开发中回归历史版本是一个很痛苦很低效率的事情如果复制一堆重复的代码则更乱。更进一步思考任何一个新系统在业务频繁升级的情况下代码就会堆积马上就变得难以维护然后系统启动很慢然后又开始进入重构的循环这个周期取决于业务需求数量一般也就两年左右就很臃肿了。
4、另一个背景是端测效率提升后客户端部分同学希望能更加的了解业务能全栈但是服务端的单元化、运维等很多东西很重希望能给全栈同学更轻松的更高效的研发环境。
5、还有 AB 实验效率问题目前业务侧的 AB 主要是新业务功能的 ab 不是算法策略的 ab 新功能的 ab 核心还是研发效率问题。比如微淘的页面坑位 Tab 新需求改动都要 ab 对比效果都要有多份数据存储
为了解决上述问题我们把业务代码打包成一个业务 bundle 做到业务和历史业务隔离业务和平台隔离结合内容分发业务现状集成 AB 、内容、分发策略、社区 API 整体构建了内容分发平台。 未来定位上仍然是解决内容消费场景的数据展示需求是一个业务平台。主要核心是为了解决1、2、3的问题第4点与现在流行的serverless有那么一点点关系后面看serverless演进成熟度再看结合点。
抢阿里云新用户专属优惠权益致电95187-1
原文链接 本文为云栖社区原创内容未经允许不得转载。
