來源 | 阿里巴巴中間件

責編 | 晉兆雨

頭圖 | CSDN付費下載于視覺中國

前言

2019 年 3 月，我們跟隨著集團的步伐，將 Serverless FaaS 引入到飛豬，并取得了一定的階段性成果：

• 這一年，我們參與共建了 Node FaaS 研發平臺和穩定性監控大盤；

• 這一年，我們落地了 13 個業務場景，上線了30+函數，單日調用峰值達到2000w；

• 這一年，我們參與或者使用 FaaS 的開發人員占飛豬前端人員 33% 以上，其中 50% 是初次參與服務端開發；

2020 年， Serverless 和飛豬的故事故事還在繼續，立足當下，展望未來的同時，我們仍需了解下歷史，回到最開始的時候……

架構的演進

在看 Serverless 之前，我們先分別從服務器和軟件架構的視角分別回顧一下各自演進過程的幾個重要階段；

服務器視角

物理機時代：很久以前，上線一個站點，需要自己買物理機，安裝操作系統和數據庫，所有的代碼部署在一起，申請網址，維護這臺機器的用電和網絡，這個階段出現了一個角色叫 PE（運維），是專門來維護這一套運行環境，開發過程極其艱難；

IaaS 時代：隨后的 IaaS（Infrastuctrue as a Service）是一個質的飛躍，這個階段把物理機切割成一個個虛擬機，屏蔽了直接對物理機和操作系統、域名綁定等基礎設施的操作和維護，降低了一定的運維成本，也極大地提高了對機器資源的利用率，但這個階段開發人員還需要去搭建和維護自己的代碼運行環境和監控，PE 仍存在著；

PaaS 時代：PaaS（Platform as a Service）是在 IaaS 基礎上的擴展，這個階段開發人員不但不需要關心機器的磁盤，內存和操作系統等基礎設施，而且代碼的運行環境、監控都不需要關心，和容器鏡像技術的完美配合，讓開發人員只需要把自己可運行的代碼“扔”上去就行，這個階段很多公司的PE這一角色成為了歷史，應用開發開始大跨步前進。

FaaS 時代：如果說 IaaS 到 PaaS 讓開發脫離了物理機和運維，那么 FaaS（Function as a Service）則讓我們忘記了機器的存在，開發不再關心機器的容量和健康度，甚至不用關心代碼的依賴框架的版本，真正做到只關心業務代碼，這一階段機器被分割到更小的粒度 Pod ，按使用計費和自動縮擴容的特性讓人著迷，我們開始邁向真正的 Serverless 。

軟件架構視角

在從軟件架構的視角來看，主要經歷了這幾個階段；

1、單體應用

最開始的一個軟件架構包含了前端、業務邏輯和數據庫層，這一階段開發上線一個業務可能是成本最低的，也可能是最高的，所有的代碼都在一個地方開發、部署，具備極小的協同成本。但是隨著業務的發展，功能增多，這個架構越來越膨脹，開發一個功能變得越來越難，Bug 也越來越多，最終成為開發者的噩夢，重構仿佛是惟一的出路，但這條路成本高昂且不治本，因此，分布式架構脫穎而出。

2、分布式架構

分布式架構是將一個單體應用分隔成多個領域應用，例如商品中心 IC 、營銷中心 UMP 、交易中心 BUY ，各個應用可以通過接口相互調用，由此衍生了我們熟知的 Dubbo 、 HSF 等 RPC 框架，遠程接口調用雖然帶來了性能的損耗，但是分布式架構對于后期的維護，功能的復用所帶來的價值，利遠大于弊，并能有力地支撐著業務快速發展。

3、微服務

微服務也是近些年比較火的一個架構，簡單來說就是將單體應用細分為多個專業的服務，分別部署不同的服務器，也可以部署在一個服務器的多個容器，可以理解為是對分布式應用服務的再細化。

4、模板解耦

在單體應用時代，前端代碼和服務端代碼完全雜糅在一起。隨著前端的迅猛發展，我們將 js/css 等靜態資源分離出來維護并部署到 CDN 。由于PC時代頁面需要綁定不同域名以及同步渲染等能力，所以模板一直部署在服務端代碼包中，這就造成了前端模板和靜態資源的割裂，以及和服務端的耦合，由此誕生了眾多的前后端分離方案，其中最為常見便是 Node.js 做 BFF 中間層支持 SSR ，其目的還是為了讓前后端都能具備高度的開發效率。

5、視圖解耦

2011 年前后，隨著無線時代到來，開始了 Mobile 為王、PC 黯然退場的階段，前端頁面的展示從寬大的瀏覽器搬到了各個窄小的手機 App ，用戶不再看到域名，同步渲染似乎也不是很重要，這個時候前后端模板自然解耦，而離線包和 Native 造成的長尾效應的出現，對數據驅動視圖提出了更高的要求，服務端需要更加關注視圖邏輯，這就又出現了新的問題——前后端視圖的耦合，由此出現了很多方案去降低這種耦合，例如曾經的無線服務端崗位專門處理視圖邏輯，再比如奧創、GPF、DinamicX 等領域解決方案。

從服務器和軟件架構的演進歷程，可以總結出一個目標，那就是“專業的人做專業的事情”，也就是實現云廠商專注于服務器的維護，專業領域應用開發提供專業的服務，業務應用開發專注于業務邏輯，前端則掌控靜態資源、模板和視圖，各自間協同作戰又互不影響。

Serverless 的興起

Serverless 概念最早提出可以追溯到 2012 年，無服務器架構是指服務端邏輯由開發者實現，應用運行在無狀態的計算容器中，由事件觸發，完全被第三方管理，AWS 的 Lambda 最早推出相應的實踐，目前最流行的兩種 Serverless 架構分別是 FaaS（Function as a Service），如阿里云函數計算FC；CaaS（Container as a Service），如 Serverless 容器服務 ASK ，其中 FaaS是應用最廣泛的。

Serverless 的發展歷程

2012 年甚至更早，Serverless 的理念被提出來，無服務化的想法讓全球很多開發者著迷，至此埋下了一顆希望的種子；

2014 年， AWS 發布 Lambda ，真正意義上實現了無服務化的架構并且商業化，一時間刺激了各大云廠商的神經，Google Cloud Function 和微軟 Azure Function緊隨其后，并取得了成功；

2016 年，云棲大會上特別設置了 Serverless 專場，開始了在 Serverless 領域的布局，阿里云因此成為國內首個提供 Serverless 計算服務的云廠商。隨后，騰訊云、華為云迅速跟進投入。

2019 年，阿里研究員畢玄的一篇《Serverless：云時代的軟件架構核心思想》在集團內引發了熱烈討論，同年 4 月，Aone 聯合 Ginkgo 開始打造面向集團內開發者的 Serverless FaaS 服務，與此同時，前端將 Serverless 作為該年重點方向之一，飛豬深入參與其中。這一年，前端作為集團 Serverless 的先行者，開發了研發平臺、 Midway ?FaaS Runtime ，并落地大量場景。

2020 年，阿里云函數計算突破了彈性擴容的速度和 0-1 的彈起速率的挑戰，研發平臺前端團隊希望通過研發平臺 2.0 提升研發體驗和穩定性，而飛豬則在圍繞穩定性、體驗、規模化、可度量方面推動 Serverless 定位的轉變（技術探索 -> 生產力工具），服務端的開發模式的轉變（PaaS -> FaaS），前端職責的轉變（端 -> 云 + 端）。

?飛豬技術架構的發展脈絡

從 2012 年的淘寶旅行（飛豬的前身）開始，不管是服務器還是軟件架構都已經發展了很久，站在巨人的肩膀之上，飛豬的技術架構經歷了幾個特殊的階段：

1、服務器架構

IaaS + PE（2012 - 2016）：這時候飛豬還叫淘寶旅行，這個階段應用的申請、部署、機器的操作、域名的綁定等有專門的PE支持，機器的劃分使用的是阿里自建的虛擬機技術 T4 ，運維在這個時期對于開發是一個比較復雜的能力，所以需要有專人支持，讓開發專注于代碼層面，但這種配合機動性較差，上線一個應用往往涉及人員較多，時間較長，極大地束縛了業務的開發。

PaaS + DevOps（2016 - 2019）：隨后容器技術的出現，使得運維發生了革命性的變化，容器技術和鏡像的完美結合，極大地簡化了運維的模式，讓開發懂得一點簡單的運維能力就可以支撐應用的正常運行，阿里將 T4 和 Docker 結合產出 AliDocker ，并推進了全集團應用的升級，隨之順利推進了DevOps的轉變，從此 PE 這個角色在阿里成為歷史。

PaaS + FaaS（2019 - 至今）：2019 - 2020年飛豬引入 FaaS 的能力，由前端作為先鋒，和集團 Node 等多個團隊一塊進行基礎建設和業務試點，取得了階段性結果，獲得了一些定性的結論，其中最重要的結論是 FaaS 對于效率的提升和資源的節省有突破性進展，在某些場景可以和傳統 PaaS 應用實現互補，自此我們開始 Serverless 的建設之路。

2、軟件架構

PC VM（2012 - 2014）：在 PC 為王的時代，由于獨立域名、同步渲染等要求，應用需要各自維護頁面模板，而此時 VM 模板是阿里 Java 框架 Webx 中的重要一環，此時前后端因為模板的耦合造成了開發體驗、線上穩定性等問題，這個階段隨著 PC 的落幕而逐漸成為歷史。

前后端分離（2014 - 2017）：這個階段可以說是 PC 時代的小插曲，為了能讓前后端解耦去解決效率和穩定性的問題，前端同學嘗試了很多方案，例如由前端單獨部署 xsl 、vm 模板，使用 Node.js 解析 velocity 語法在本地模擬一套 VM 運行的環境等，其中最為有效的便是用 Node.js 應用做中間層配合 SSR 實現前端對視圖的掌控，這套BFF架構解決了前后端分離的問題，并在沒有增加太大工足量的同時，保留了同步渲染的能力，適合一些需要做 SEO 或者要求秒出的核心頁面。

無線服務端（2014 - 2016）：這是 PC 向無線過渡的特殊時期，和 PC 時期不同的是，無線對數據模型的要求更為苛刻，另外 MTOP 網關也是對無線的特殊產物。過渡時期由于業務開發對這兩點的適應需要一個過程，所以出現了無線服務端這個歷史產物，其最大的工作就是作為介于業務服務端和端之前的一層，實現數據的聚合和處理，在過渡期實現業務的快速前進，完成了歷史的使命。

領域解決方案（2016 - 2020）：隨著業務的發展，新的難點出現，如飛豬商品發布頁、詳情頁，和下單頁需要承載Wi-Fi電話卡、簽證、線路、酒店團購等幾十個類目，此時各個系統和頁面已經變得十分臃腫，穩定性和效率都被拖累的“彈指可破”，于是出現了商品發布的 GPF ，詳情域的 TUD 和交易域的奧創等領域解決方案。其中交易域的奧創結合 DinamicX 演化為現在的新奧創，并通過平臺化統一了飛豬的全域下單。

FaaS BFF（2019 - 至今）：在 Node FaaS 出現之前，前端幾乎沒有涉及無線服務側的領域。總結下來有兩個原因：一是集團 Node.js 一直沒有支持 MTOP 的去中心化，二是應用運維和開發帶來的高難度和移動端不太需要 SSR 的特性，造成的投入產出比太低。但是前端需不需要做服務側的開發，答案是肯定的。因為對于業務服務端開發來說，不太想處理前端要求苛刻的 VO 模型，而前端也迫切希望完全掌控視圖邏輯，此時 Node FaaS 的出現完美的解決了運維開發的難度和 mMTOP 的問題，釋放了業務服務端，賦能了前端，其中典型的實踐便是使用 FaaS 實現評價發布器中間層。

未來的發展規劃

Serverless 的定位

to 前端：對于前端來說，Serverless 領域我們常用到的是 FaaS 模式，目前來看我們主要將其定位在應用于兩種場景：一是在 C 端場景作為中間的膠水層使用，主要實現的是數據的處理，包括合并接口、協議轉換，以及部分場景可能用到的 ABtest、SSR ；二是應用于中后臺場景，從數據庫、鑒權到展示，表單提交處理的 FaaS + Antd 的一體化研發，其目的是賦能前端掌控視圖，釋放業務服務端，提高需求交付效率。另外利用 Serverless 的 No Ops 和彈性擴容能力，可以降低前端開發服務的人力和資源成本。

to 服務端：對于 Java 服務端來說， FaaS 沒有前端同學那么迫切的體感，其原因是 Java 應用本來就比較收斂，一個應用往往承載一類服務，不像前端那么離散。另外運維對于服務端同學也是必備技能，所以 No Ops 顯得不是那么的有吸引力。對于服務端來說， FaaS 的定位主要是安放那些相對比較臨時或者長尾的低流量服務，其目的就是保持應用的純凈度，避免變的臃腫難以維護。

Serverless的規劃

對于飛豬來說，Serverless 的長遠目標是 Serverless 定位的轉變（技術探索 -> 生產力工具），服務端的開發模式的轉變（Paas -> FaaS），前端職責的轉變（端 -> 云 + 端）。這三個轉變希望能在三年內完成，今年我們的重點是圍繞著體驗提升和穩定性夯實、場景擴展、內部開發平臺和度量體系。

體驗提升和穩定性夯實：體驗提升主要是針對開發者，包括開發過程的調試以及上線后的灰度、回滾、監控，這部分主要依托集團的新研發平臺去解決，飛豬這邊更多是提出自己的訴求和參與部分的共建；穩定性的夯實主要是統一網關和監控體系，包括上線前的演練、壓測以及上線后的監控、容災。今年要做的是增加網關的 CDN 容災，演練和壓測常規化、標準化。另外就是共建 FaaS 的一體化監控體系，增加端到端的監控能力。

場景擴展：過去一年我們更多的是做基建和試點的技術探索，推動其成為生產力工具，今年我們的一個目標就是場景的擴展。為了達到這個目標，除了讓前端外的團隊具備認識和使用 FaaS 的能力，另外還在推動 Java FaaS 在飛豬的落地實踐，畢竟 Java 才是服務端的主力，我們需要找到更多的 Java 場景。

內部開放平臺：對于 FaaS 場景來說，更多是對于底層服務的二次封裝來快速滿足業務的需求交付，由一堆相對原子服務拼成一個符合自己需求的服務，所以我們需要讓 FaaS開發同學能夠快速找到自己所需的原子服務。我們的思路是通過集團的服務市場打造飛豬的內部開發平臺，將原子服務沉淀到這里，日積月累，從而支撐更多業務需求的快速開發上線。

度量體系：上面也有提過， FaaS 最大的好處是提效和節省資源，今年我們希望能夠將度量效率和資源的提升量化，目標是大幅節省機器數量，這里的節省主要是靠原有 PaaS 應用遷移到 Serverless 和彈性擴容完成。

結語

我們處在前端最好的時代，前有 React、Vue 框架配合 Webpack、Umi 解決端側開發的體驗和效率的問題，后有 Serverless 給前端插上了一對“翅膀”，賦予了本來只能在最底端做展示交互的前端工程師“翱翔云上”的能力。?

Serverless 是未來，而且未來已來，它帶來的 No Ops 和彈性擴容、按量收費能給企業節省大量的人力和資金成本，它將是未來開發模式的基礎“水電煤”，早日加入 Serverless 的技術浪潮中，就會早日受益。

更多閱讀推薦

• 藍色巨人IBM全力奔赴的混合云之旅能順利嗎？

• SQL分頁查詢方案的性能對比

• 大數據給教育帶來怎樣的可能？

• 機器人也開始"怕疼"了？科學家開發無需人工干預即可"自愈"的機器人

• 最新！百度首發 OCR 自訓練平臺 EasyDL OCR

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的当飞猪遇上 Serverless | 云原生 Talk的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。