作者 | 淘系技術
來源 | 阿裡技術公衆号
在技術進步的巨變時代，價值書寫與思考沉澱至關重要。
過去的一年多，新零售業務快速發展，淘寶釋出躺平，重塑大家居行業電商模式；雲原生浪潮大起，核心交易系統百分之百上雲；端側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及網絡穩定的環境下載下傳。