專訪阿里亞頓：Serverless正在顛覆開發模式，包括對工種的定義
Serverless 是一種“無服務器架構”模式，無需關心程序運行環境、資源及數量，只要將精力聚焦到業務邏輯上的技術。目前很多公司已經實現 DevOps 化，正在向 Serverless 邁進，而前端工程師也要關注 Serverless，可能會改變前後端聯調方式，亦可大幅度降低 Node.js 服務器維護門檻。
在 7 月 12 日深圳 ArchSummit 全球架構師峰會上，來自阿里高級前端專家亞頓將分享《BFF in Serverless》話題，在此之前，亞頓老師把其在實踐 Serverless 過程中的一些技術解決思路分享給大家，以饗讀者。
1 採用 Serverless 理念對 BFF 層進行改造
亞頓說，在傳統基於 Node.js 的 BFF 層，其痛點主要在於存在較高的發佈和運維成本，而引入 Serverless 的關鍵目標就是要解決這兩個問題。因此，為了提高發布速度、降低運維成本，團隊將 BFF 層的函數全部轉換為可動態執行的腳本並保存到數據庫中，同時提供統一入口用於函數的路由分發，這是阿里團隊改造中最核心的功能。圍繞這一核心，為了能提高用戶體驗以及開發效率，團隊還打造了針對用戶的統一入口和針對開發者的控制檯。
在改造的過程中，至關重要的兩個問題是：
1）存量應用如何平滑遷移？如果新方案和傳統方式差異過大，那較高的遷移成本將會阻礙改造計劃的全面推廣落地。2）穩定性如何保障？即如何確保函數運行的沙箱環境的隔離性和安全性，防止函數因自身影響整個平臺或其它函數的運行。這是我們最應該關注的兩個問題。2 Serverless 架構分層設計實踐
在架構分層中，主要包含運行與開發兩種時態。在運行時阿里團隊將其分為 FaaS 和 BaaS 這兩大核心模塊，即提供安全運行函數片段能力的 function sandbox runtime 和可以在函數中調用各種後端服務的 BaaS Service，其關注的重點是穩定和能力。而在開發時，主要提供了支持在線開發、配置、調試、發佈、回滾、監控等能力的一站式開發者控制檯及獨立 CLI，使開發者可以輕鬆創建和管理函數，其注重的是開發者的體驗。
也許有人會問，當前 BFF 有什麼樣的最佳實踐，有哪些公司已經標準化這樣的做法？亞頓回覆說，首先，目前進行 BFF 實踐的團隊或公司，幾乎無一例外都採用了 Node.js 來實現，其實這並不是偶然。BFF 就是 UI 的粘合層，而 UI 通常都由前端人員在開發和維護，所以 BFF 層也自然由前端人員採用了對其來說比較順手的工具來實現。所以，這是最重要的實踐理念：服務自治，即吃自己的狗食。其次，對於 BFF 層的價值，是將後端服務聚合和裁剪，為 UI 提供 API。故第二個實踐理念：BFF 只處理 UI 邏輯，業務邏輯下沉至後端服務。在不同公司由於基礎設施和場景不同，所以很難存在一種標準化的實踐方案，但整體方案上只要不偏離上面兩個理念，我們認為這就是當前場景下的最佳實踐。
前端在使用 Serverless 服務時，亞頓認為最主要痛點在於基礎設施的不完善。CNCF 針對 Serverless 給出了他們的定義：Serverless = FaaS + BaaS，然而目前大家主要還是聚焦在前者，對 BaaS 的關注度相對較少。雖然阿里有了一套完善的函數運行時，但真正的業務通常是無法通過一個純函數的執行而中間不調用任何其它依賴（比如 RPC、DB、Cache、MQ 等）就能獨立完成的。所以，亞頓團隊花了大量的精力將相關依賴封裝起來，形成一套統一的 BaaS SDK 供函數調用，使其能完成以往在 BFF 中能完成的所有工作。
3 Serverless & GraphQL
Serverless 是否應該與 GraphQL 結合？如果是的話是否會提升應用開發的複雜度，如何權衡？亞頓說，對於 UI 層來講， 使用 GraphQL 提供 API 確實是一個不錯的實踐，可以真正的實現按需查詢，但其也存在相應的問題。比如在有 BFF 的情況下，它增加了 BFF 層的工作量，需要將所有後端服務都封裝一遍來支持 GraphQL 協議；另外也增加了 Android、iOS 的工作量，你也得寫兩份的查詢語句。目前就大家遇到的場景來說，GraphQL 其所能夠提供的價值，和增加的工作量相比優勢不夠顯著。不過大家仍然認為它一個不錯的實踐，如果在有適當的場景將會繼續進行嘗試。
當前很少看到 Serverless 大規模使用的案例，究其原因，最大障礙在於配套依賴的不完善。對於使用各種雲服務的公司來說，目前大多數雲服務商提供的 FaaS 服務相對來說是獨立存在的，沒有完全和自己的後端服務打通，這給 FaaS 的大規模應用帶來了極大的不便；而像 BAT 這樣的公司，由於其各自內部中間件服務非常豐富，要將 FaaS 與這些中間件服務逐個打通，也是一個不小的挑戰。
這就衍生出另外一個問題，傳統模式向 Serverless 模式的轉變存在哪些阻力，如何克服？亞頓認為：研發模式轉變，需要考慮三個問題：1）新方案能否提供足夠的價值；2）線上應用如何遷移；3）新方案帶來的新問題，我們能否接受。
第一點其優勢想必已不必多談。對於第二點，如果是一個歷史包袱不多的新團隊或公司，這並不是一個問題，但對於已有大量線上應用的團隊或公司，應用的平滑遷移是需要重點考慮的。第三點，亞頓認為目前 Serverless 存在的最大問題是缺乏標準。由於團隊將原來的 BFF 應用打散成了一個一個的函數 ，那麼如何將這些函數有效的組織起來是需要思考的問題。不僅是在組織上缺乏標準，在實現上同樣如此。目前各大雲廠商都是基於自己的理念各自實現其框架，這導致以後幾乎不可能完成雲廠商的平滑切換。可喜的是已經看到 CNCF 發佈了第一版 Serverless 白皮書，使我們離標準化更近了一步；同時也出現了 Serverless Framework 這樣的框架，抹平了不用平臺服務的差異，能一定程度上解決這個潛在風險。
4 Serverless 對人及技術管理的影響
Serverless 只是全面雲服務大趨勢下的一個縮影，基礎設施最終都將由 Provider 提供，作為 Developer 只需關注在這種模式下如何有效的設計和組織業務架構。脫離 BFF 場景，當 BaaS 的能力逐漸增強之後，前端可以獨立完成以往需要後端才能完成的那部分工作，這將使前端向全棧的方向進一步演化；而後端將進一步下沉，將原有的一部分業務組裝邏輯交由前端完成，自身去實現更加底層的通用業務封裝，也就是常說的“大中臺，小前臺”。
亞頓個人認為後續工種將不會再分為前端、後端，而是產品研發和中臺研發：產品研發負責所有的上層業務邏輯組裝（如下單支付），而其中要使用到的一系列底層業務平臺（如用戶中心、訂單中心、支付中心、物流中心），由中臺研發負責。
所以，亞頓認為，對業務流程的深入理解和全局把控，將是今後前端人員的一項新的挑戰和方向。
閱讀更多 牛旦教育IT課堂 的文章
