作者 | 淘系技术
来源 | 阿里技术公众号
在技术进步的巨变时代，价值书写与思考沉淀至关重要。
过去的一年多，新零售业务快速发展，淘宝发布躺平，重塑大家居行业电商模式；云原生浪潮大起，核心交易系统百分之百上云；端侧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万字，我们怀抱着开放自由的交流心态，输出阿里淘系工程师对技术和商业的理解，并真诚期望能够在更丰富的场景中与大家沟通交流，共同探讨未来技术与商业的形态。
希望你喜欢，并分享给身边有相同兴趣的同事、朋友，一起切磋，共同成长。
点击下方链接，立即下载吧！
https://developer.aliyun.com/article/781214?utm_content=g_1000231312
部分目录展示：
温馨提示
- 电子书目录可实现标题跳转，感兴趣的内容点击标题即可一键传输。
- 文件较大，建议在Wi-Fi及网络稳定的环境下载。
