导读：淘系技术将 2020 一整年的精华内容梳理合并，重磅推出《技术人的百宝黑皮书》，点击文末“阅读原文”即可下载本书。

作者｜淘系技术

前言

在技术进步的巨变时代，价值书写与思考沉淀至关重要。

过去的一年多，新零售业务快速发展，淘宝发布躺平，重塑大家居行业电商模式；云原生浪潮大起，核心交易系统百分之百上云；端侧 AI 实时智能决策，推理引擎 MNN 开源；音视频实时通信引擎将直播延时压至 1 秒以内，淘宝直播缔造全球内容电商场的技术顶峰……

新场景、新用户动线和新架构不断提出新挑战，新产品、新技术以及实时自我更新的淘系技术人，通过一次次思考和技术升级不断去逼近能够做到的最好的极限。

交易数字曾一次次俘获人们的注意力，我们认为，那些在背后耕耘与付出，支撑着全球领先的线上新零售技术平台的技术不应被掩盖在历史的备忘录中。

所以，我们相遇了。

这里是阿里巴巴淘系技术 2020 一整年的精华技术内容合集，涵盖了大前端、音视频、端智能、用户增长、客户端架构、服务端架构、云原生、技术质量以及 AI 类等多个技术领域，沉淀了 618、双 11 大促、阿里拍卖、淘宝直播等多个业务的技术解决方案，并有淘系工程师推荐书单、开源项目、顶会 paper 等多角度知识与价值的输出。

本书内容页数 1500+，全部内容将近 40 万字，下面我们对整本书的内容做个简单介绍。

各技术栈时新前沿的技术讲解

前端、算法、后端、音视频、客户端等，每个领域我们选取了今年内容里最新最热的技术文章，实时跟进技术前沿，是每个技术人都不容错过的事情。

前端篇

在前端篇，淘系前端在支撑淘宝、天猫这样复杂多变的业务场景的过程中，建立了前端工程、多端架构、 Node 架构、多媒体、互动、搭建、智能化等多个基础技术体系，并还在不断的演进和升级，我们侧重从前端与客户端结合突破多端体系，与云原生结合面向 Serverless 体系，与 AI 能力结合建立前端智能化应用场景这三个维度出发，向大家介绍一下我们的技术方案以及背后的思考。例如我们以 2020 年淘宝天猫双 11 的前端体系建设为例，给大家分享我们“既要”高效支撑保障业务先赢，“又要”确保体验和稳定性带给用户极致体验，“还要” 追求创新让前端持续演进的双 11 最新前端建设技术方案，包括应用大量优化手段和创新方案带来业务转化提升；将 FaaS、PHA、ESR 等技术应用在更多场景，分别向服务端、客户端、CDN 节点进一步拓展了前端的能力和边界；应用视觉还原、一体化研发等提升研发效率，大幅缓解资源瓶颈等，与业界同学分享我们的技术方案和思考沉淀。

算法篇

在算法篇，淘系技术有大量的算法应用场景，从这些场景中来，我们覆盖了内容和商品推荐、多模态内容理解、用户交互和工程结合的算法应用。例如我们在洋淘的场景里，为了提升用户的浏览深度，从召回， ctr 预估两大关键环节做出探索和创新：In_Match，用序列生成的 task 训练 decoder，抽取其顶层输出向量作内容召回，召回效果超越内容协同；In_CTR，将 motivation 由常规的序列兴趣的直接表达转换为序列兴趣的匹配程度，并根据这一先验设想设计了辅助 loss，鼓励模型有所侧重地去学习，最终离在线指标上都有斩获，结果大幅提升了推荐效果，取得了显著的业务收益。淘系技术的工程师们正在用崭新的人工智能方法， 重新定义和解决问题，突破原来的问题领域，实现更大的技术目标。这些解决问题的新方法、 新思路，结合解决问题过程中一手的工作经验，理论结合实践，值得算法从业者和对算法感兴趣的读者参考。

In_Match 的模型架构

后端篇

在后端篇，我们淘系的服务端系统随着业务的深入发展，技术进入深水区，驱动了技术团队在架构方面的深入思考，形成了一系列业务平台，推进领域架构设计的进步，自底向上更高效的解决业务问题。例如我们自研的 IETF QUIC 标准化协议库实现 XQUIC 方案，论证了 QUIC 的核心优势在于用户态的传输层实现(面向业务场景具备灵活调优的能 力)，而非单一针对弱网的优化。在业务场景的扩展方面，除了 RPC、短视频、直播等场 景外，XQUIC 还可以对其他场景例如上传链路等进行优化。对于 5G 下 eMBB（Enhanced Mobile Broadband）和 URLLC（Ultra Reliable Low Latency）带来的不同高带宽/低延迟业务场景，QUIC 将能够更好地发挥优势，贴合场景需求调整传输策略(拥塞控制算法、ACK/重传策略)。这些内容从不同侧面呈现了这一年来在架构和基础技术上的探索，对于业内有重要的参考价值。

XQUIC 端到端架构设计和内部分层模块

音视频篇

在今年炙手可热的音视频领域，围绕淘宝直播和短视频核心场景，我们在编解码、低延时直播和直播看点等在 2020 年都取得了不错成果，例如 2020 年双 11，我们一次压上了由达摩院语音实验室、阿里云 PAI 团队、淘系技术直播 App 和端智能 MNN 团队组成的全明星阵容，通力协作之下，一举实现了工业界首个用于直播的移动端语音识别。在这个项目中，我们选取"基于 SAN-M 的离线端到端语音识别"方案，通过极致的模型压缩和性能优化，最终实现模型大小小于 15MB、内存占用低于 60MB、1s 语料识别快于 50ms 的高性能方案，解决了高精度高性能的本地语音识别、语音模型和资源包体积过大、端侧资源有限，性能压力大三大核心技术难题。

此外，还有客户端、MNN 与端智能技术，Flutter 实践等多个技术栈领域内的思考分享，同时也有各技术领域内常见的问题和解决办法和技巧分享，以及 2020 技术资讯下的专家解读，诸如对 WWDC 2020 的系列研究和分享，均值得技术同学阅读。

淘系技术大牛的职场&学习经验问答实录

如何学习？怎么评价？怎样看待？

那些在社区里最有热度的学习交流题和吃瓜讨论题，我们邀请了一些阿里工程师从个人角度，分享自身的实践经验，或者发表自己对某个技术话题的思考想法，收获了不少点赞和认同。我们将这些精彩问答集结起来，一次性“喂饱”你的好奇心和好学心。

举个栗子：

Q：在你做推荐系统的过程中都遇到过什么坑？

A：数据错误、离在线不一致、可以锦上添花不能雪中送炭，做推荐系统过程中最大的 3 个坑。

第一，数据错误

推荐算法是最容易发生数据错误的算法领域，很多机器学习应用的数据来自于标注，数据的错误可以很容易的发现，而推荐算法依赖的数据来自于用户的行为反馈，这个极易出错又极难发现。

用户在屏幕上的一个点击，行为发生的上下文和一个推荐物品的上下文，需要客户端发送给服务端，服务端把信息上报给日志系统，日志系统把数据导入到大数据平台，算法才能开始他的工作，而其中的物品推荐上下文，通过推荐接口透传给服务端，服务端带给前端，前端要解析好才能使用。

这样的一整条链路，有太多的出错可能，而出错时又很难意识到错误的存在，更别说错误的排查。

讲一个愚蠢的错误。在一个初上线的业务上，依靠几天的日志搭建了 Rank 模型，也有收益，看起来没有任何问题。当时唯一的怪现象，这个场景的 pv 是 uv 的 100 倍，也就是人均的浏览数是 100，按照经验这个数字高出之前同类业务的几倍，这个数字被暴露出来一周，大家只是奇怪，没人真的怀疑。

我大概从觉得不对劲，到动手查，确认原因，到解决问题，花了一周的时间。服务端有一个环节把创作者的 id 和用户的 id 弄混了，所以才有人均 100 的浏览，实际的 uv 是创作者的数量。问题修复后，推荐效果涨了一倍！

第二，离在线不一致

做排序模型的时候，以某一个离线指标为依据，疯狂地优化，然后幻想上线后指标能够大涨。实际上这时候距离成功还有一个巨大的坑——离在线一致性。

离在线一致性可以来自于人的失误，离线的特征处理和在线的特征处理天然是两个流程，出现问题的可能性非常大，但开始可以靠细致的检查来避免，甚至可以将离在线的关键流程用一套组件抽象和处理，降低认为出错的可能。而另一种离在线不一致性来自于系统本身，在系统限定下无可避免，当然可以通过系统的升级来缓解，但成本的曲线也会变得非常陡峭，下面就重点聊聊这个。

很多推荐系统的排序模型，在系统升级前或业务初期都是 T+1 更新的。在离线，使用 T-n 到 T-1 的 n 天数据训练模型，用 T 天的数据进行测评，拿到了很好的离线指标，比如 AUC 为 0.72。但是在线服务的模型，并不是这样的理想情况，一个模型每天重新迭代训练，需要新一天（T-1 天）的日志，日志从数据队列传输到大数据平台，进行日志的处理，新一天各种特征的计算，组织训练样本，进行模型训练，之后还要把模型从大数据平台更新到在线服务器，整个流程走下来个把小时总是要的（图中例子为 11 点 10 分）。那么在新模型上线前，也就是 11:10 分之前，在线服务的是 T-2 的模型，相当于在离线用 T-2 的模型去测评T天的样本，效果会大打折扣。因而线上一整天的平均测评指标，是低于离线测评指标的。

有的业务和模型下，有可能 T-2 和 T-1 的差距不大，但推荐系统非常依赖 ID 型记忆型特征，T-2 可能会导致非常差的结果。这个时候，让你的模型能越早上线，效果就越好。有可能你增加了离线特征的处理流程，使用了复杂的特征和模型，让 AUC 提升了一个点，但是模型晚上线了 3 个小时，在线效果可能就掉到了坑里。

升级到小时级模型更新，甚至流式更新，能避免这个系统性的问题。当然成本也会变大，也会要爬更多的新的坑。

再聊聊特征上的不一致，如果是天级别计算的离线特征，它有着和上面讨论的模型不一致的类似的问题。而使用实时特征，也有隐秘的不一致问题。

实时特征在线使用的时候，经过客户端上报，流式计算处理日志数据进入在线数据源或特征服务器，需要几秒到几十秒不等的时间。也就是说，如果你刚刚点击了鞋子，紧接着下滑翻页，系统是拿不到鞋子这个行为的。如果离线模型训练中有用到了带有鞋子的特征，由于近期行为的影响非常大，那么离在线的不一致会非常严重。

离线获取实时特征，一个是通过离线日志复现实时特征，依靠是日志中记录的时间戳，如果仅考虑样本的时间戳大于行为的时间戳，那么离在线不一致就发生了，相对明智的做法是流出一个时间 GAP，让离线和在线尽可能一致。另外要注意，样本的时间戳，不是用户曝光行为的时间戳，而是推荐系统的时间戳，否则也会用到在线无法拿到的穿越特征。

另一种方法，是将在线使用的特征直接依靠日志系统记录下来，在线的时间 GAP 假如是 5 到 40 秒飘忽不定的，整体上虽然离线在线一致了，但对于某个样本，有可能记录了最近的一个行为，有可能丢掉了最近的行为。这样做比离线复现实时特征的方法好多了，唯一的问题可能是要积攒一定天数的实时特征日志，才能完成初次模型上线，每次特征的修改也要等一段时间进行日志积累。

第三，可以锦上添花，不能雪中送炭

很多的产品经理把推荐算法当成产品最后的希望，把用户增长的希望压到推荐算法身上。但是，推荐系统只能锦上添花，不能雪中送炭。

没有或有一个弱的推荐系统，能挣 10 个亿，通过优化多挣 3 个亿，推荐系统就非常有意义。一个产品，没有多少用户，靠输血勉强维持体面，想几倍增长，单纯靠推荐算法真的是无能为力，一个不愚蠢的推荐系统和一个优质的推荐系统之间的差距已经没有几倍增长的可能了。

那些增长案例，如谷歌邮箱推出 5G 空间突破 outlook 实现增长，airbnb 发现用户在意的核心因素是房间的照片，扛着专业设备一个一个去拍照实现增长。这都是满足了用户未被满足的需求而聚集起大量的用户。一个不愚蠢的推荐系统没有什么门槛，升级到优质的推荐系统，并没有满足任何新的需求。靠推荐系统实现大规模的用户增长和产品成功，是错误的努力方向。

清晰有力、一针见血，我们还有诸多类似问答下的精彩回答，欢迎你下载整本书内容一起学习交流~

书中部分提问内容展示：

Q：如何写出优雅的代码？Q：CDN 是什么？使用 CDN 有什么优势？Q：前端 P6 什么水平？如何衡量？Q：后端同学是不是比前端同学理解业务更快？ Q：2020 年前端最火的技术是什么？Q：有哪些优秀的工作习惯值得学习？……

年度精选技术人员必读书单

来自多位阿里工程师倾情推荐的本年度书单，涵盖了技术硬核参考、商业思维培养以及文化、科普、工具方法等多个类别，对技术人员的成长有很大帮助，希望成为你 2021 的精神食粮。

附上阿里巴巴淘系技术部资深算法专家乐田在推书时的推荐感言，供你参考选择。

《算法导论》：有段时间遇到的计算机科班的同学很喜欢讨论这本书的内容，为了建立共同语言，我读了这本书的大部分。我把里面的题也做了，包括数学证明。不过后来发现计算机科班的同学不讨论这个了，现在还有用的就是 DP，不动点。

《博弈论》：很酷，读了几篇古老的论文，为了搞明白 Brouwer 不动点定理还学了点拓扑学。博弈论分析非完全合作智能体构成的系统必备基础知识，包括前两年火起来的 GANs 也有博弈论的思想。

《枢纽》：探讨了何谓中国，从古至今，从国内到世界。从内部视角介绍了中原、草原、高原、海洋的统一联系，从外部视角讨论了中国作为连接海洋秩序到大陆秩序的桥梁的可能。

《经典力学》：搞机器学习的同学都熟悉最小化目标函数。我们高中学习的牛顿定律也有一个类似的表达，即最小作用量原理。朗道的《经典力学》提供了新的数学视角。美的理论应该最小化分类学的使用，代之以一个最小化目标函数，约束尽可能少。

淘系经典开源项目介绍

我们倡导以开源项目和技术产品的方式，回馈到社区中，共同建造繁荣的技术生态。这里的淘系 11 个经典开源项目，也离不开大家的参与和贡献，欢迎持续共建和讨论。

例如，给大家讲讲喜闻乐见的 Rax。它是一个可支持同时开发 Web/Weex/小程序多端的框架。使用 Rax 可以一次开发，多端运行，解放重复工作，专注产品逻辑，提升开发效率。

在前端这条道路上，淘宝 FED 一直以来的使命就是「用技术为体验提供无限可能」，Rax 自然也是在追求体验的道路上发展出来的。

从 2014 年开始，结合阿里双十一双十二的数据变化，无论从用户访问量还是最终成交量上都可以清晰的看到：「移动端已然是当下业务的主要阵地」，当业务重心向移动端偏移时，技术也在悄然发生变化，传统而成熟的 PC 端技术方案俨然已经无法满足移动端对体验性能、开发效率等各个方面的要求，这也开启了我们在无线端上的技术探索之路。

2014 年伊始，算是阿里无线业务起步的阶段，那时候大家把无线页面还称为 H5, 诸如 Kissy、jQuery 之类的库对于无线页面来说尺寸太大、加载太慢，于是我们基于社区成熟的 Zepto 迅速打造了 kimi 这个核心库，然后围绕业务不断完善 kimi 的组件生态以及包含工程化、性能检测等一系列生态。这套生态伴随着我们走过了将近两年时间，至今仍可以在一些页面上找到kimi的影子。

然而，kimi 始终是一个 Web 端的解决方案，即便可以通过一些方案去调用 Native 的原生方法，也无法跨域无线端上 Web 体验不及 Native 体验这样一个既定事实。于是，如何能让页面达到 Native 的体验成为我们的下一个探索点。

说起 Native 的体验，最直观的方案就是直接去写 Native 代码，然而 Native 的开发模式一直存在一些难以解决的问题：

成本与效率：iOS、Andriod、Web 三端需要不同的技术团队各自开发一套，成本大，效率低。灵活性：受限于 AppStore 的审核机制，版本发布周期较长，难以满足业务需求。

所以，我们需要一套基于 Web 的开发模式但可以产出 Native 页面的解决方案，效率与体验兼得。在这个思路下，阿里也有过一些尝试，不过都没有形成最终的解决方案，这里就不再详细讲述了。直到 2015 年中期，Facebook 开源了 React Native（RN），虽然初期只有 iOS 的版本，但丝毫不影响其对整个无线开发方案的巨大冲击。RN 基本完美解决了需要编写两端代码的问题，同时还有一个非常活跃完善的React社区，因此这个方案也得到了诸多开发者的青睐。

接着，我们也快速在手淘里尝试了 RN 的方案，受限于 RN 的兼容性问题以及用户可能在浏览器端打开页面，因此整个页面必须要有能力降级到 Web 版本。这时候回想下 RN 的口号：learn once, write anywhere。但这对于我们来说，或许还不够，我们真正需要的是：write once, run everywhere。此我们开始探索如何让 RN 的代码运行在 Web 端，这就是 react-web 方案。

社区里很多人关心 Rax 与 React 的优缺点以及相互取代的可能性，事实上，从上文的发展历程就可以看出来，Rax 只是无线端的解决方案，与 React 并无冲突。事实上淘宝 PC 端的新项目，依然主要是基于 React，并且我们也有一套基于 React 的解决方案名为 ICE，通过一系列的工具帮助开发者提高效率。

当然，Rax 跟 Preact 之类的方案也有本质区别，前者偏向于解决多端问题，后者偏向于解决性能问题，我们的 Rax 的特点：

设计上支持不同容器

Rax 在设计上抽象出 Driver 的概念，用来支持在不同容器中渲染，比如目前所支持的：Web、Weex、Nodejs。基于 Driver 的概念，未来即使出现更多的容器（如 VR 等），Rax 也可以从容应对。Rax 在设计上尽量抹平各个端的差异性，这也使得开发者在差异性和兼容性方面再也不需要投入太多精力了。

体积足够小

如上文所说，Rax 是一个面向无线端的解决方案，因此自身的体积对于性能来讲就显得非常重要。Rax 压缩 + gzip 后的体积是 8.0kb，相比 React 的 43.7kb，对于无线端友好了很多。

支持返回多个同级节点

任何用过 React 的同学大概都踩过同一个坑：方法返回了多个同级节点导致报错。在设计上 React 只能返回单个节点，因此页面上或多或少会产生一些冗余的节点，这在 PC 端并没有太多问题，然而在无线 Android 端嵌套层级越多，应用的 crash 率会不断提高，这一点在低端 Android 机上表现尤其明显。因此 Rax 支持了返回多个同级节点的功能，如：

import {createElement, Component, render} from 'rax';class Test extends Component {  render() {    return [1, 2, 3].map((item) => {      return <p>{item}</p>;    });  }}

这一特性可以有效减少页面的嵌套层级，从而减少应用因嵌套层级过多而出现的 crash 问题。

标准化

在上文里，我们不断的提各个端的一致性，一致则必有规范可依，Rax 遵循 W3C 标准，比如在 Weex 容器中已经可以直接调用 navigator、document、location、alert 等 W3C 的标准 API。

当然，受限于各个端的差异，标准化的道路还很长，「更标准化」这也是 Rax 未来的重要目标之一。

"Write once, run everywhere"，这是口号，亦是目标。Rax 未来会在更多的端上不断探索，比如 VR/AR，甚至之前微博上有同学提出的是否可以用 Rax 写微信小程序，也是一个蛮有意思的想法。对于开发者来说，当越来越多的端不断出现在眼前时，我们应该如何应对？是通过不断的踩坑来整理一份长长的 checklist，然后做项目时一一对照？或者让我们一起来探索 Rax？

多年来，阿里巴巴淘系技术一直积极拥抱开源事业，无论是开源软件的应用、回馈以至自研技术的开源都非常活跃，近两年我们更是开源了 MNN、飞冰 ICE、3D-FUTURE 以及 3D-FRONT 等项目，在开源社区中，也获得了广泛开发者的支持和使用。欢迎更多讨论和交流。

2020 淘系顶会 paper 全文

按照计算机协会定义的 CCF-A 类会议和期刊，我们精选出在大数据与数据挖掘领域、移动计算领域、信息检索领域等 7 个领域里的 19 篇顶会 paper，涵盖了 KDD 2020、SIGIR 2020、AAAI 2020 等多个国际会议。对相关领域感兴趣的技术从业者或许能窥见到自己这个领域下一步的方向。

最后

本书内容非常丰富。整体页数 1500+，全部内容将近 40 万字，我们怀抱着开放自由的交流心态，输出阿里淘系工程师对技术和商业的理解，并真诚期望能够在更丰富的场景中与大家沟通交流，共同探讨未来技术与商业的形态。

希望你喜欢，并分享给身边有相同兴趣的同事、朋友，一起切磋，共同成长。

点击文末“了解更多”，立即下载吧！

部分目录展示：

温馨提示：

1. 电子书目录可实现标题跳转，感兴趣的内容点击标题即可一键传输。

2. 文件较大，建议在 Wi-Fi 及网络稳定的环境下载。