手機淘寶短視頻業務「哇哦視頻」遷移上 FaaS 筆記公開

做者 | 劉子健（繁易）  阿里巴巴高級前端工程師

前言

2019 年，在阿里巴巴集團內部技術論壇上對於 Serverless 和 FaaS 的討論很是火熱。

在看了那麼多「技術原理/頂層設計/平臺建設」相關的文章以後，我相信你對 FaaS 確定產生過躍躍欲試的感受，但也確定存在諸多疑惑，例如：

• FaaS 在業務中能落地嗎？
• FaaS 能幫助前端同窗實現能力升級嗎？
• ……

而這些疑惑對於剛開始接觸 FaaS 的我而言，只會多不會少。剛好，我所負責的「哇哦視頻」業務是淘系第一個基於 Node FaaS 開發的線上業務，在線上已經穩妥當當的跑了 4 個月，這期間不只接手了 Java 同窗的工做，同時也順利的承接了平常與雙十一需求。

關於上面的這些疑惑，通過了這四個月的考驗，我想我已經有了本身的答案。接下來我將會向你們分享我這四個月的歷程，帶你們一塊兒看看，在一名一線業務同窗的眼中，FaaS 究竟會給前端同窗帶來什麼？

背景

哇哦視頻是在手淘首頁的短視頻導購業務，業務核心目標以下：

打造圍繞「人用物」爲核心有 「溫度」的短視頻；引導更多的商家視頻，商家模板化生產;增長首頁分發效率，讓用戶快速的且容易定位到本身想看的視頻內容。

而其做爲手淘的導購業務，具備「三高」的特色：

因爲是身處手淘首頁的業務，其流量相對於普通業務而言是比較高的，屬於大流量業務。而流量高的特色也帶來了穩定性高的要求，因爲用戶衆多，所以線上的任何不穩定都有可能產生輿情。

而做爲導購業務，業務自己還有一個迭代頻率高的特性。爲了能實現更好的導購效果，業務須要不斷的推陳出新，快速建場，從而得到更好的導購效果。

淘系導購研發模式

1. 中臺化

在淘系，隨着中臺化戰略的成熟與導購側近幾年的發展，導購業務的開發工做由獨立開發各類能力向中臺化支持轉變。業務所須要的絕大部分能力都可以由中臺提供。

這麼作帶來的好處是顯而易見的。大部分常見的導購業務，均可以經過中臺能力的組裝從而實現快速上線，避免重複開發帶來的人力物力的浪費。以下圖所示，此時在哇哦視頻，後端絕大多數的工做在於調用中臺的在線服務與離線服務，編寫相關的業務邏輯來完成相關需求。

2. 工做流

在淘系導購業務現今的開發中，通常都由一位前端搭配一位後端一塊兒完成，每一個需求的開發，都須要遵循開發 + 聯調 + 測試的完整流程去進行。

而我也針對於哇哦視頻最近的幾回需求開發作了時間的分析，具體結果以下圖所示：

後端同窗得益於中臺能力的完善支持，許多代碼能夠複用，所以開發工做量會小一些。而前端則因爲 UI 開發的特性，許多東西須要推倒重來，難以複用（首頁改版，總體樣式都換了），因此工做量會稍微大一些。

這一套流程實際上已經至關成熟，但成熟並不表明完美。實際上開發過程當中，痛點仍是有不少的。

研發模式痛點

1. 聯調成本太高

首當其衝的痛點則是聯調。在聯調期中先後端須要不斷對數據字段、業務邏輯進行確認，從而確保需求實現的正確性，而這種密集的溝通所帶來的成本是很是高的。

以下圖所示，在業務開發中咱們發現聯調成本通常要佔到開發成本的 30% 左右。

居高不下的聯調成本，一方面使得工程師們精疲力盡，另外一方面也不利於業務的快速迭代。

2. 前端資源化

值得一提還有前端資源化的痛點。

在目前先後端的分工模式中，前端只負責交互邏輯與相對應的 UI 實現，對於業務核心邏輯無需過多瞭解。雖然這使得前端團隊能夠快速完成某些業務，但一樣也帶來了前端資源化的隱患。而在強調前端要深刻業務，具備商業化思考能力的今天，前端資源化其實是不利於前端的自身發展的。

由於不少時候前端想去深刻業務，想進一步升級本身的能力，但每每會苦於沒有相關場景。至於說介入後端的工做領域，畢竟術業有專攻，不少事情也摻和不進去。

碰見 FaaS

吐槽歸吐槽，可是工做仍是要繼續的。既然天天的工做有這麼多痛點，那麼是否有辦法去嘗試解決它呢？

剛好今年的四月份我開始參與淘寶導購體系 Node FaaS 相關建設的工做，開始接觸到一些 Serverless & FaaS 相關的工做。在通過一段時間的基礎建設後，咱們須要一個業務做爲試點業務來檢驗工做成果。

出於對自身能力升級的渴望，我主動梳理與分析了當前業務的特性，而且主動要求將哇哦視頻做爲 Node FaaS 的首個試點業務。

哇哦視頻後端分析：

哇哦視頻是一個主打純視頻的導購業務，流量高。基於對後端代碼與平常需求的剖析，總結其特色爲：運營位多、強依賴算法推薦、數據源多、無狀態服務 四點。 其中運營位多 + 強依賴算法推薦的特性，使得業務具備必定的複雜度，改造工做量主要在於理解業務規則，填充數據。

而數據源多則表明其引用的外部服務較多，如視頻服務、話題、特斯拉資源位定投等。該部分工做量主要在於熟悉上下游系統。

最後無狀態服務是改造 FaaS 的大利好消息，無狀態則意味着橫向拓展極其便利，完美契合 FaaS 的工做場景。（其餘導購業務應該也相似）

總結：哇哦視頻複雜度適中，無狀態的業務模型十分契合 FaaS 的業務場景，且我的在通讀完代碼後，有把握能 Hold 住整個後端業務遷移 FaaS 的需求。所以我認爲哇哦視頻遷移 FaaS 平臺是具備高可行度的。

很是順利，也沒有任何波折的，哇哦視頻成爲了淘系首個 Node FaaS 試點業務。懷揣着對於能力升級的渴望，我開始嘗試將現有的業務邏輯遷移至 Node FaaS 實現。

指望達到的效果以下圖所示：

遷移進行中

在正式進行遷移前，我和業務方溝通了這個事情對於業務可能產生的影響以及後續規劃。業務方對於技術側的改造是沒有意見的，只有一個訴求，那就是業務不受影響。

整個訴求看似簡單，拆解下來包括如下三部分：

• 不會爲技術側改造預留時間，原定需求要按時完成；
• 遷移後線上不能出任何問題，線上對遷移無感知；
• 後端工做交接至前端後，對後續需求推動無影響。

提及來就是既要快，又要穩，還要能扛住後續需求。

針對這個訴求與當時的實際狀況，我採起了如下三個措施，來保障整個遷移對業務側沒有影響：

• 快速 Copy Java 代碼上線
• 使用 Java 兜底，保障線上穩定性
• 謹慎評估後續需求，確保需求可實現

1. Copy Java 代碼上線

Copy & Paste 聽起來像是不光彩的事情，但這並非一件須要遮遮掩掩的事情。相反我如今還很慶幸本身在遷移剛開始時選擇了這樣的方式，而沒有愣頭青同樣選擇另起爐竈，從零開始。畢竟學會跑以前得先學會走路。

前面也提過，哇哦視頻是一個大流量導購業務。即便諸多能力已經中臺化，但必要的膠水代碼 + 相關的業務邏輯代碼，總行數也高達 5000 行左右。

選擇從零開始當然炫酷，可是這樣難以保障代碼的穩定性，畢竟原有的業務代碼不只包含必要的業務邏輯，也包含了諸多的錯誤處理與邊界處理，而技術側改造是必需要考慮到穩定性問題的。

且對於原有 Java 代碼的 Copy 也算是一種另類的學習方式了，在這個過程當中對於 Java 開發也有了足夠的瞭解，畢竟在整個集團都是 Java 技術棧的狀況下，對於 Java 的學習與瞭解很是有利於後續工做的開展。

很是幸運的是，後端同窗的代碼質量很高，該有的註釋一個不缺（以下圖所示），所以整個讀代碼 & Copy 的過程很是流暢。

也所以在後續 FaaS 版本的哇哦視頻提測時，是 0 BUG 直接上線的，節約了大量的返工時間，從而避免對業務需求形成影響。

2. 使用 Java 兜底

這其實算是一個開發中的小 Tricks 了，但卻足夠好用。

在以前的導購研發中，爲了不後端宕機對線上帶來的影響，所以網關層作了一個 CDN 容災方案，以下圖所示：

註釋：

• XCtrl - 前端調用 mtop SDK
• TCE - 淘寶導購網關

對於前端同窗而言，當請求線上接口失敗時，前端的請求 SDK 就會根據當前請求數據，去 CDN 上獲取最近成功的數據，從而確保對於用戶端產品是可用的。

但目前導購側的業務基本都接入了千人千面的算法，而 CDN 容災的一個缺點便在於只是隨機取一份成功數據存入 CDN，並不支持千人千面。

很是不妙的是，在我遷移 FaaS 時，底層能力還相對羸弱，時不時會有宕機等問題，這時候即便有 CDN 容災能保障產品可用，但用戶側的體驗依然是有必定損失的，屬於有損降級。

而此時其實產品需求並未發生較大的變動，原有的 Java 接口也能繼續使用，所以靈機一動準備將 Java 做爲兜底的數據源，確保在降級的請求用戶體驗是完整的。

總體思路其實很是簡單，請求路徑整理以下：

• 以前的：Java 接口 - CDN容災
• 如今：FaaS 接口 - Java 接口 - CDN 容災

得益於這種設計，哇哦視頻在上線後，頑強的活了下來。即便那段時間底層時常不穩定，但對於用戶體驗來講並無多少損失（兩個接口 RT 都很短，請求兩次基本無感）。

遷移以後

在完成代碼遷移以後，便開始籌備上線的事情。上線的過程當中卻是沒有什麼故事能夠說，波瀾不驚的按照既定節奏進行灰度、放量，慢慢的也就上線了。

在整個業務真正交接到本身手中的時候，我開始遇到了真正的麻煩。

這個需求我該怎麼作？

隨着技術側改造的完成，業務交給個人新需求也得繼續推動，因而迷迷濛濛的去參加了不少場業務需求會，接觸了不少本身以前做爲前端根本不會接觸的方面。

但事情的進展並不順利，本身剛轉型成後端，不少事情都是迷迷糊糊的，似懂非懂。因而那段時間天天最大的疑惑就是：「這個需求我該怎麼作？」雖然說導購業務都是調用中臺，可是一個需求到我手上，哪些應該調中臺，哪些應該本身完成我都是不清晰的。

因而那段時間整我的的工做都變的很是拘謹，開始主動 Push 本身去學習和了解更多業務知識，瞭解更多後端的業務中臺。整我的面對需求，進入了一種「謹慎評估」的狀態。

遇到需求，首先作的不是一口答應承接下來，而是和業務肯定具體要作的事情，而後拆分需求。根據業務方的指引與本身的認識，開始不斷找各個對應的後端同窗去學習和了解完成需求的方式。我記得有好幾個下午，我都坐在以前哇哦視頻後端同窗的身邊，不斷詢問和學習着後端完成問題的思路。

逐漸的，本身的狀態從 「這個需求我該怎麼作」 開始向 「這個需求我以爲應該這麼作」 轉變，整我的面對後端的工做狀態從手忙腳亂像遊刃有餘轉變。（其實這也算能力升級吧~畢竟能夠 Hold 住更多的事情了）

總結

在整個遷移的過程當中，我的最深入的感覺即是「撕裂」。由於 Serverless & FaaS 並不只僅只是一種編程方式，它更多的是給了你去 Owner 業務的機會。

而爲了把握住這個機會，你須要或主動或被動的去 Push 本身學很是多的東西，也須要思考比以前多的場景，好比：

• 業務的完整鏈路
• 業務需求與最終目標的關係
• 後端的工做方式
• 中間件、數據庫、運維……
• ……

不斷的學習新東西，不斷的思考更多，不斷的對原有本身形成更大的衝擊。若是要給我遷移 FaaS 期間的感覺下一個總結，那麼必定是：「在撕裂中成長」。

回到咱們最初的疑惑，我想我能夠對第一個問題進行解答了：

Q：FaaS 在業務中能落地嗎？ A：能，雖然過程很辛苦，但如今大家落地應該會好不少，由於坑都被咱們填的七七八八了

而關於第二個問題：「FaaS 能幫助前端同窗實現能力升級嗎？」，我想看徹底文的你，心中已經有了答案。

Q：FaaS 能幫助前端同窗實現能力升級嗎？ A：能，且能力升級並不止於技術，更多的是業務思惟的成長。FaaS 使得前端有機會能夠更深刻業務，從而更好的去支持業務。技術能力與業務思惟共成長，非凡不止一面。

招聘

淘系技術部 - Node.js 架構組招聘啦，招聘級別： P6/P7 ，工做年限 2 年以上。對 Node.js 感興趣的小夥伴必定要抓住機會，咱們須要優秀的你與咱們一塊兒，探索 Node.js 將來更多的可能性~

崗位描述：

1. 負責 AliNode 的設計、研發和維護，支撐阿里集團旗下公司的 Node.js 生態
2. 負責 Serverless 場景 Node.js 函數運行時的設計和優化
3. 負責高性能 Node.js C++ Addon 開發（C++ 崗位要求）

崗位要求：

1. 有強烈的技術熱情，工做責任感，具有迅速掌握解決問題所需技術的方法和能力；
2. 熟練掌握 Node.js 或 C++ 做爲開發語言，具有優秀的編程素養；
3. 熟練掌握調試工具和調試方法，具有調試複雜軟件的能力（好比虛擬機或編譯器）者優先；
4. 具有下列一項或多項領域知識或設計和開發經驗甚佳：V8/JSCore/SpiderMonkey/Chakra等任一腳本引擎、系統性能分析工具和方法、編譯器設計和開發；
5. 有良好的表達能力，善於運營開源項目和開源社區，持有具有影響力和 Javascript 語言技術相關的開源項目者優先。

有意向的同窗能夠發送簡歷至 fanyi.lzj@alibaba-inc.com，咱們會第一時間安排面試。

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」