阿里淘系所有程序員一整年的內部技術總結，都在這里了
本文經AI新媒體量子位（公眾號ID:QbitAI）授權轉載，轉載請聯系出處。
“淘寶雙十一網絡穩定性，背后由哪些關鍵技術支撐？”
“淘系高難度壓測，具體實行方案是什么？”
上面是淘系程序員，在開發這些關鍵項目時留下的內部技術總結。
單個技術崗？當然不。
前端、后端、客戶端、音視頻技術……
我們想辦法，搞來了整個淘系這一年，所有程序員的技術分享。
對這些資料進行整理后，我們得以窺見淘系過去一年的核心技術進展。
一起來看看。（文末附傳送門）
過去一年，淘系的技術進展
這些技術進展，既有各個技術崗單獨的研究成果，又有整個大型項目的迭代升級 （如天貓雙11）。
其中技術崗，又主要包括前端、后端、算法、客戶端、測試、音視頻與圖像、端智能與MNN……
以關注度最高的2020天貓雙11項目為例。
在這一大型項目中，測試、前端、后端、客戶端等技術崗的研究人員，都總結了各自崗位最新的技術成果。
先來看測試崗。
2020年的雙11，訂單創建峰值達到58.3萬筆/秒，涉及近20條業務線，100多個場景，400+鏈路。部分業務，甚至深度融入在導購、交易鏈路中。
為了讓系統不癱瘓，測試崗通常需要進行全鏈路壓測。
往年，壓測只針對C端用戶場景進行，因為商家端場景結構龐雜、且涉及諸多三方系統。
但如果不進行壓測，一旦出現故障，對用戶、商家都將造成極大的體驗傷害。
這是淘系首次針對B端（商家端）場景進行壓測。
從總結來看，壓測場景，包括IM消息體系端到端、三方服務商、三方小程序的全鏈路壓測三種。
在壓測實施過程中，需要解決各種問題。為此，淘系基于NIO，開發了長連接瘦客戶端。
這個客戶端能夠打通全鏈路消息業務、進行訂單推送全鏈路壓測，并基于歷史訂單數據，生成壓測模型、自動收集壓測結果。
例如，由于IM系統與服務端會建立長連接，因此用戶A發消息給B時，B會被動收到服務器的推送，而非主動拉取數據。
而瘦客戶端在收到消息推送后，則會加上一個“ACK”的消息回復，表示消息已收到。
這樣，就可以根據已讀比例，對消息進行已讀設置。
最新的技術要點，測試技術人員在這次總結中，都進行了詳細的分析和回顧。
……
而對于前端來說，今年的雙11，同樣是一場挑戰。
這次的雙11流量高峰期，由一個變成了兩個，期間包括預售、預熱等活動，大幅增加了前端的研發工作量。
面對暴增的工作壓力，前端的程序員這次將設計稿生成代碼（D2C）平臺Imgcook，進行了全面升級，用于智能生成代碼。
這其中，包括對UI多態、直播視頻組件、循環智能識別增強等技術的升級。
相比于去年的78.94%，今年雙11會場，D2C平臺Imgcook承擔了90.4%的新模塊代碼智能生成，大量降低了前端的工作壓力。
目前，前端技術人員也已經對這次技術，進行了詳細總結。
……
對于后端來說，雙11最大的挑戰，來源于不確定流量的互動消息。
如何將不確定性的流量，轉化為確定性流量，并將互動消息，更有序地呈現在用戶面前？
這其中，分優先級保障不同的消息QoS能力，是核心技術。
在這樣的基礎上，通過QoS分級機制承諾消息服務SLA，才能做到隔離/優先級/差異化處理，保證整體的消息順滑體驗。
……
除了這些，還有客戶端的技術人員，分析總結了今年手淘雙11中，最新的技術實踐——
PopLayer彈層領域研發模式升級。
PopLayer，在今年提出了名為“低研發搭投模式”的方案，具有快速搭建+可視化+多端多場景通用的特點，實施效果也非常好：
這一方案，直接讓彈層業務的上線成本，從3天+，降低到2小時，且保證線上0故障。
而技術的覆蓋率，甚至達到雙11大促期間的75%。
……
除了技術進展，這一年，也有不少程序員總結了自己在崗位上的所見所想。
頂尖人才水平、評價同行項目、研究新的小眾技術……
例如，阿里p6，憑什么拿到35萬年薪？阿里程序員，如何看待華為云？小眾直播技術WebRTC，錢途怎么樣？
“阿里p6到底是什么水平？”
在總結中，一位阿里大牛，對前端p6/p6+的JD （職位描述）進行了親自解讀。
這里的每一條要求，都對應具體標準，水平分為“初、中、高”，以此判斷面試者的能力。
例如，對于“熟悉react生態常用工具”最初級的要求，主要是知道react-router、redux、redux-thunk、react-redux、immutable、antd或同級別社區組件庫，以及它們的版本差異、基本使用方法。
而如果分析過全家桶源碼、知道核心實現原理和底層依賴，能直接說出原生js和redux怎么結合，以及從數據驅動角度說清楚redux，就算是達到了中級要求。
至于更高級的要求，就是基于全家桶構建過復雜應用了。例如，說出微前端和這些類庫結合時的注意事項、掉過的坑，以及解決方案。
表面上，就是知道用法、讀懂源碼，再到項目實踐。但其實在面試官眼中，這幾個階段的要求，都非常具體。
同樣的，還有“熟練掌握JavaScript”這條崗位要求。
它背后的初級目標，僅僅是“了解”某些原理和方法。如組合寄生繼承、event loop、ES6數組相關方法、基礎數據結構……
中級目標，則需要在“了解”的基礎上“融會貫通”。除了知道原理，還要能舉例說明、類比差異，如class繼承與組合寄生繼承的區別。
……
其余每一條職位描述，也都有詳細解讀，并給出了“初-中-高”的提升路線。
對于阿里p6來說，初級要求100%達成；中級要求，至少覆蓋60%；高級要求，則起碼覆蓋20%。當然，對于p7來說，高級要求必須覆蓋80%以上。
類似這樣的技術崗解讀，還包括算法崗（推薦算法標準）、后端（業務拆分）、測試（自動化）、圖像音視頻（WebRTC）……
除了這些內部資料，也有人對比了不同的熱門項目。
例如，一位阿里程序員，分析了華為的技術。
這個問題是這樣的：
原本大家只想吃個瓜，沒想到，這位程序員真的對兩個項目進行了分析總結。
華為云Cloud IDE，是基于eclipse-theia項目搭建的在線IDE服務；而gitpod，是最早基于Theia搭建的在線IDE服務。
早期Theia內核，繼承了Node.js、Java等主流語言的語言服務及調試器實現。
但在Theia架構支持VS Code插件后，可以無縫繼承大部分VS Code語言的相關插件了。
……
除了這些項目對比，還有人專門研究了一些“小眾”技術，如WebRTC。
在低延遲直播技術中，它以復雜度高、上手困難出名，因此研究的人也很少。
這樣的技術，究竟值不值得學習？會不會被其他技術所取代？
有人專門對比了Quic和WebRTC這兩種方案，前者上手容易，復雜度低，看起來是比WebRTC更有潛力的技術。
然而，在對比過程中發現，雖然Quic方案復雜度低，但如果想讓延遲更低，反而得引入更多的復雜度。
也就是說，短期采用Quic收益更大，但想要讓直播走得更長遠，這并不是一勞永逸的解決辦法。
……
更詳細的解讀，這本資料中還會呈現。
傳送門
1658頁，40萬字，耗費程序員們540小時寫成。
除了技術干貨，和淘系程序員經驗分享，這本資料中還包含2020開源項目總結、學術論文。
最重要的是，免費。
【阿里淘系2020技術干貨：技術人的百寶黑皮書1500頁+】傳送門如下：
http://t.tb.cn/7hdjzMpWrTdcabI12ALi1E
