2019 年初，淘系技術部啟動了 Serverless 研發模式更新計劃。而哇哦視訊作為首個落地的業務，迄今已有半年。
本次則會為大家分享哇哦視訊在這半年中發生的故事，與大家一起看看在一線業務同學的眼中，Serverless 會給前端同學帶來什麼，而我們又能收獲什麼？
分享内容
本次分享我會從以下三個部分出發：
- 業務落地
- 從零到一
- 未來抉擇
哇哦視訊是在手淘首頁的短視訊導購業務。
“三高”業務
而其作為手淘的導購業務，其具有“三高”的特點：
- 流量高
- 穩定性要求高
- 疊代頻率高
流量高指的是哇哦視訊業務體量大，日常流量高，随着高流量所帶來的，就是穩定性要求高的特點，且作為導購業務，其疊代頻率也是非常高的。
開發痛點
在長達一年的開發實踐中，我逐漸發現了業務在開發中遇到的一些痛點。
在這裡我以最近三次首頁改版的時間為例。通過下圖這個時間軸，我發現整個業務疊代的過程中開發聯調時間較長，進而導緻需求完成時間往往會超過 10 天。
基于此我也開始在思考業務研發模式中存在的一些痛點。
首先站在整個業務的大背景來看，有兩個特點：
- 淘系大力推行中台化戰略，業務能力實作了中台化，日常需求基本可以通過中台能力組裝實作
- 導購業務一直處于高速疊代期，從未停歇。
基于以上的背景，我們會發現在目前業務的研發模式中有着諸多的痛點。
聯調
首當其沖的痛點則是聯調。在聯調期中前後端需要不斷對資料字段、業務邏輯進行确認，進而確定需求實作的正确性，而這種密集的溝通所帶來的成本是非常高的。在哇哦視訊這兒，我們發現聯調成本一般要占到開發成本的 30% 左右。
居高不下的聯調成本，一方面使得工程師們精疲力盡，另一方面也不利于業務的快速疊代。
業務開發的枯燥
對于業務開發來說，日常工作就是取資料調接口，枯燥且重複。
前端資源化
值得一提還有前端資源化的痛點。
在目前前後端的分工模式中，前端隻負責互動邏輯與相對應的 UI 實作，對于業務核心邏輯無需過多了解。雖然這使得前端團隊可以快速完成某些業務，但同樣也帶來了前端資源化的隐患。而在強調前端要深入業務，具有商業化思考能力的今天，前端資源化實際上是不利于前端的自身發展的。
因為很多時候前端想去深入業務，想進一步更新自己的能力，但往往會苦于沒有相關場景。至于說介入後端的工作領域，畢竟術業有專攻，很多事情也摻和不進去。
研發模式更新戰役
恰好 2019 年的 4 月份，淘系前端開啟了研發模式更新的戰役。而我也參與進去負責導購體系 Node FaaS 相關建設的工作。基于 Node FaaS 提供的能力，我開始重新思考上面碰到的業務痛點，并認為研發模式更新是可以解決以上的痛點問題的。
對于為什麼研發模式更新可以解決上述提到的痛點，我個人認為主要有以下三點：
- 單人負責前後端，且均使用 JS，能極大的減少溝通與聯調成本，滿足業務高速疊代需求
- 離使用者最近，熟悉業務規則，業務方溝通成本低。
- 前端對于自身能力更新的渴望。對于身為前端的我來說，我不想也隻是作為一個資源，每次被調配，我也希望自己可以去對業務負責，也希望可以有機會去賦能業務，去做更多的事情。
而對于後端同學來說，目前端負責前後端，後端同學則可以從業務中釋放出來，進而選擇去開辟更多的新戰場，去做更多更有挑戰性的事情。
業務遷移
帶着以上這些思考，我仔細閱讀了業務的後端代碼并梳理整體的業務邏輯，發現其具有以下的特點：
- 後端無狀态
- 複雜度适中
這兩個特點使得業務非常适合使用 Serverless 技術來承接。而在正式進行遷移前，我和業務方溝通了這個事情對于業務可能産生的影響以及後續規劃。業務方對于技術側的改造是沒有意見的，隻有一個訴求，那就是業務不受影響。
整個訴求看似簡單，拆解下來包括以下三部分：
- 不會為技術側改造預留時間，原定需求要按時完成
- 遷移後線上不能出任何問題，線上對遷移無感覺
- 後端工作交接至前端後，對後續需求推進無影響
說起來就是既要快，又要穩，還要能扛住後續需求。而在充分梳理和分析後，我确認我可以在“不坑業務”的基礎下，完成整個遷移。
在開始遷移後，事情進展比我們想象中的要順利很多。下面是我們研發過程中的一些資料。
在遷移完成後，我又嘗試接了幾個需求，并對前後所用的時間做了一個對比。
可以看到在之前完成一個業務疊代，前端總共需要投入 10 天，整體投入人數是 2 人。而在研發模式更新後，前端總投入時間增加到12天，雖然看起來投入時間增加了，但是卻減少了一個人的投入。總的來看還是節約成本的。
這部分我主要我想講清楚一個問題，那就是業務從開始遷移，到研發完成上線，這個過程中都發生了什麼？
在這裡我把它主要分為以下4個部分來講述：
- 需求承接
- 本地研發
- 部署與調用
- 運維
遷移的基礎是原有需求的承接，而需求承接的核心就在于需求評估。在業務方提出需求時，我們會按照如下的節奏開始需求工作流：
- 召開需求評審會，确認需求與具體内容
- 召開技術評審會，确認實作方式與涉及到的二方平台
- 需求開發、釋出等
- 經驗積累總結
而在需求承接的過程中其實會遇到一個難題，那就是如何确認需求是可實作的？這是一個前期困擾我許久的問題，然而答案卻也簡單，那就是：如果需求的實作不涉及三方平台的，那麼依據自身能力評估即可。如果是涉及到三方的需求，則需要讓業務方組織技術評審會，會上确認是否該需求是可實作。
整個本地研發，按照時間順序主要分為以下四個步驟：
- 函數開發
- 服務調用
- 單元測試
- 函數釋出
值得一提的是，在之前我提到過：“哇哦視訊作為淘系首個落地 Node FaaS 技術的項目，其開發的整個過程，也與 Serverless 體系的成長密不可分。”
是以這部分即會講述到本地開發，也會講述到哇哦視訊從遷移伊始到上線這段時間内，給 Node FaaS 帶來的一些改變。
多函數的目錄結構
在這之前，主流 FaaS 項目結構如我圖中所畫的那樣。每個函數間是互相隔離的，這樣雖然比較幹淨，但其實也帶來了非常多的一些痛點。比如跨函數邏輯複用困難，重複的依賴安裝和重複的檔案。
是以我們在思考，既然 FaaS 的優勢在于零運維，那我們不應該為了運維的優勢而強行降低開發者的效率。
是以我們提出了新的目錄結構方案。在新的目錄結構中，我們使得多函數可以複用同一依賴，避免重複的檔案與依賴。且我們也提出了新的打包方案，每個函數入口檔案都會被打包為一個函數單獨部署。
至此，我們獲得了應用級的開發體驗，也獲得了 FaaS 零運維的優勢，進而達到開發者提效，專注業務邏輯開發的目标。
整潔架構的探索
在開發過程中，哇哦視訊也對業務的架構做了一些新的探索。在此我參考了整潔架構的一個實踐，事後證明配合 IoC 與依賴倒置，有效的減少了業務的疊代難度。
同時關于這個架構與具體的落地實踐，外部有非常多的案例，有興趣的同學可以自行查閱。
服務市場 - HSF 調用一站式解決方案
在業務開發的過程中，一定會遇到的就是 HSF 的服務調用。為了簡化開發工作量，盡可能的提升研發效率，對此我們也提供了對應的解決方案：服務市場。
服務市場囊括了HSF服務，從調用到測試的全流程支援。是我們在開發業務時的一把利器。
在之前的 Midway 項目中，是預設支援使用 Mocha 測試的。
而正好在今年的 JavaScript 開發者報告中，關于測試架構一項，Mocha 的人氣在持續的走低，而 Jest 作為近兩年的新起之秀，人氣在不斷的升高。是以我們在原有的Mocha支援上，又新增了Jest的支援。
同時哇哦視訊有着通過單測保障代碼品質的需求，是以我們也打通了 FaaS 函數在内部 Ci 系統單元測試的鍊路。
錯誤處理
其實這部分與實際的代碼書寫風格相關，雖然說是戰時盯着螢幕看監控，但是如何第一時間發現錯誤源于何處，是否需要處理其實是值得琢磨的問題。畢竟無效的監控一多，人就會陷入到報警疲勞中。
在這兒，哇哦視訊采取對于錯誤采取了以下的幾個小政策，確定線上可以快速定位問題：
- 錯誤分級：将錯誤分為 忽略/警告/重視 3 種等級，友善一眼确認重要錯誤
- 自定義錯誤名：将錯誤自定義名稱，而非是籠統的 Error，友善迅速确認具體錯誤
- 攜帶關鍵資訊：針對不同錯誤，攜帶不同關鍵資訊，友善快速定位與複現問題
簡單示例如下：
而在實際業務中的監控中，實際上會較容易的區分與定位錯誤：這樣最終是對于線上問題的排查與修複是有幫助的。
Java 兜底
對于 Java 兜底，我現在就一個感覺，真香！雖然這是一個臨時性的方案，但是在你出問題時還有兜底的服務可以幫忙扛着，無比安心呀。具體實作上非常簡單，實際上就是在請求自己接口失敗時，再去請求一次 Java 接口，確定可以提供服務。畢竟兩個應用同時都當機的幾率是非常低的。
釋出流程
這部分主要與代碼的釋出，我們提供了一站式的研發平台，來幫助你管理函數，實作版本管理與復原等功能。
調試閉環
對于現代化的開發而言，調試是必不可少的一項能力。在此 Sandbox 平台 提供了一站式的調試閉環服務。我們可以在函數中啟用遠端調試，然後在預發去調試代碼，進而幫助我們更快的去定位問題。
函數監控
關于函數監控，在此我們也提供了一站式全功能的Node.js治理平台，Sandbox。包括運維資料、鍊路分析、監控告警、白屏化日志四大功能。
運維資料
在此，我們可以通過 Sandbox 提供的功能，清楚的看到目前函數的運作資料。功能也非常簡潔明了。
鍊路分析
在阿裡做後端，怎麼能缺少全鍊路分析的輔助。
在此，Sandbox 也對全鍊路分析做了支援。對于函數的每個請求，我們可以檢視到其鍊路的詳情與對應的鍊路，幫助我們快速定位到鍊路問題。而針對于錯誤鍊路，在這裡也能看到其對應的鍊路分析與錯誤的日志。
白屏化日志
Sandbox 也提供了白屏化日志的功能，通過檢視實時日志，可以有效的了解函數情況。
監控報警
Sandbox 提供了監控報警的功能，在這裡我們可以設定自己的報警項。在報警觸發時，會通過短信電話等方式實時通知到同學。
配合之前提到的那些功能，可以使得快速發現并定位修複故障。
FaaS 的業務能力
基于以上的這些功能，與哇哦視訊業務長達半年的實踐與踩坑，我們可以說：
“FaaS 函數工具完備，完成業務就像是搭積木一樣！”
如果有相關業務需求的同學，可以大膽的放心的使用 FaaS 去完成。
這部分是業務遷移 FaaS 半年後，個人的一些思考與總結。
研發模式更新推論
首先先看一個研發模式更新的推論。
- 因為：我們在技術上使用 Serverless
- 是以：實作前端能力更新
- 結果：助力業務先赢
這個推論聽起來好像是很正确的一件事情，但卻讓我想起我之前聽到的一個故事。
故事：科技改變生活
都說科技改變生活，以前我們遇到不懂的問題，要去圖書館查資料。而現在，遇到不懂的問題，我們隻需要掏出手機，然後，你就會忘記這個問題。
而這個故事和之前研發模式更新的推論，在我看來是差不多的。雖然我們有了新的方式去解決問題，但最後的結果可能天差地别。
在這裡我就發現前端能力更新，并不一定能助力業務先赢，這也是困擾我長達半年之久的問題。
我在哇哦視訊的選擇
“研發模式更新究竟能否助力業務先赢？”
這個問題就像心魔一樣在我心頭萦繞，但遇到問題就要解決問題。總得試試看，是以在半年内，分為 3 個階段，我做了如下的一些嘗試。
支撐（19.06 - 19.09）
第 1 個階段我稱為支撐，時間是19年的6月份到19年的9月份。
在這期間我對自己的要求就隻有一個，那就是“活下來”。因為首先要能做業務，才有後續與業務談價值的可能性。否則都隻是空中樓閣罷了。
對話（19.10 - 19.11）
第 2 個階段我稱為對話。
在能做業務的基礎上，我開始嘗試去了解業務資料，主動去溝通、學習、了解相關業務領域知識。并且在遇到問題時會習慣性與業務方進行溝通，看看這個問題，從業務視角出發是如何了解的。
助力（19.12 - 至今）
第3個階段我稱為助力。
在逐漸了解業務規劃、與業務方也有了一定的信任後，我開始嘗試參與部分業務規劃，與業務方一同去挖掘痛點。同時同時站在技術的角度上做一些技術預研，嘗試為業務帶去更多的發揮空間。
抉擇
在我剛提到的第一階段“支撐期”時，我經曆了非常長一段時間的思想抉擇。
在我可以支撐業務時，當時的我面臨着兩個選擇：
- 做一輩子的業務工具人：業務說什麼我做什麼，承接需求就好
- 嘗試做一次業務合夥人：試着給自己提出的問題（研發模式更新究竟能否助力業務先赢？）找一個答案
當時的糾結在現在看來，主要是以下幾點：
- 作為一名技術同學，嘗試着做非常多看起來與技術不相關的事情，風險高難落地拿不到結果
- 受非技術因素影響多，業務的走向與起起落落，并非是技術可解的問題
- 做成了可能與技術無關，做不成卻一定有自己的問題
但最終我還是選擇嘗試做一次“業務合夥人”，因為我覺得如果研發模式更新如果不能證明它能助力業務先赢，那麼整個戰役實際上是失敗的。對于自己而言，也隻是簡單的完成了一次業務遷移的過程，而沒有真正的去解決問題。
比起拿到遷移的結果，我更想知道研發模式更新的答案。
業務對話
在下決定後，我開始按自己的思路去做這一切的事情。
首先是對既有經驗的一個學習。正好最近阿裡經濟體前端委員會在阿裡技術論壇出品了《技術與業務同行》這個專題，裡面有非常多業務思考的文章，細細拜讀後收獲頗多。
在拜讀相關文章後，我開始主動去了解業務的資料，目标與未來的規劃，且在此基礎上，我開始主動要求與産品經理，去做一個溝通，希望能去與業務方，共同了解整個産品業務的規劃與交流。
在這之後，我被邀請去參與哇哦視訊使用者調研活動。這也是我第一次面對面的去與使用者對話，了解使用者的真實需求。而在與使用者面對面溝通後，我發現自己業務思考上的諸多盲區。這件事情也是一個警醒，雖然我自诩為前端是離使用者最近的崗位，但實際上與使用者面對面之後，才知道實際上相差甚遠，比起自嗨，我們仍然需要更多的去傾聽使用者的聲音。
例子：承接手淘 Push
哇哦視訊的業務方之前一直存在一個痛點，那就是業務入口流量不足。在與業務頻繁對話的那段時間，這個問題時常會被提起。
針對這個問題，我開始嘗試與業務方讨論有沒有相應的解法，最終将目标鎖定在使用手淘 Push 消息的能力來為業務導流。與業務方溝通并達成一緻後，技術側迅速開始了改造，為哇哦視訊新增了承接手淘 Push 的能力，且随着消息的推送，不斷進行相應的調整與優化。在多日的持續優化下，哇哦視訊通過手淘 Push 實作 UV 單日最高提升 20%+的結果。
而在經過這件事情後，我想我找到了“研發模式更新究竟能否助力業務先赢”這個問題的答案：Serverless 是前端撬動業務場景的一把利劍。
總結：FaaS 給前端帶來的變化
在我之前寫的文章《哇哦視訊 ❤️ FaaS - 遷移前後的那些事兒》中，公司的同僚留了一句評論：
而對于我來說，後續的目标則是希望在助力業務成長上去探尋到更多的可能性。基于 FaaS 的研發模式更新，實際上是為了助力業務先赢。
我們不要因為走得太遠，而忘記為什麼出發。
好書推薦：
前端代碼是怎樣智能生成的
關注「Alibaba F2E」
回複 電子書，立即下載下傳