作者 | 劉子健（繁易） 阿裡巴巴進階前端工程師
前言
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 未來更多的可能性~
崗位描述：
- 負責 AliNode 的設計、研發和維護，支撐阿裡集團旗下公司的 Node.js 生态
- 負責 Serverless 場景 Node.js 函數運作時的設計和優化
- 負責高性能 Node.js C++ Addon 開發（C++ 崗位要求）
崗位要求：
- 有強烈的技術熱情，工作責任感，具備迅速掌握解決問題所需技術的方法和能力；
- 熟練掌握 Node.js 或 C++ 作為開發語言，具備優秀的程式設計素養；
- 熟練掌握調試工具和調試方法，具備調試複雜軟體的能力（比如虛拟機或編譯器）者優先；
- 具備下列一項或多項領域知識或設計和開發經驗甚佳：V8/JSCore/SpiderMonkey/Chakra等任一腳本引擎、系統性能分析工具和方法、編譯器設計和開發；
- 有良好的表達能力，善于營運開源項目和開源社群，持有具備影響力和 Javascript 語言技術相關的開源項目者優先。
有意向的同學可以發送履歷至
[email protected]，我們會第一時間安排面試。
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”