Serverless 架構用來描述那些顯著或完全依賴於第三方應用或服務（“在雲端”）的應用程式。這些程式經常是移動端 APP 或者是最近幾年比較火熱的單頁 Web 應用。這些應用可以完全基於雲的服務進行構建，比如 AWS 的 S3 和 DynamoDB 或者是阿里雲的 OSS 和 TableStore。

不過，問題在於總是有一些獨立的伺服器邏輯程式碼需要執行，傳統的部署方法是使用雲伺服器來進行程序的託管。好在 FaaS (Functions as a Service) 的出現改變了這種情況。FaaS 能夠讓使用者將自己伺服器邏輯程式碼以 Serverless 的方式託管到雲上，讓使用者以應用函式為單位對應用進行開發、執行、管理，無需基礎設施層面的關心構建和維護工作。

Serverless 架構於 2014 年進入大眾視線，AWS、谷歌雲、微軟 Azure 和 IBM Bluemix 等雲廠商提供服務。業界認為，Serverless 化可大幅降低 IT 成本，將雲的費用減少 10%-90%。可口可樂架構師 Patrick Brandt 曾向外媒披露，向 Serverless 架構轉移是主要出於降低 IT 運維費用並且提高服務部署效率。

2017 年 4 月雲棲大會・南京峰會，阿里雲釋出了函式計算產品。阿里雲函式計算負責人不瞋認為，從雲端計算整體發展趨勢而言，Serverless 的出現是意料之中。雲端計算的第一階段是基礎設施即服務，使用者能夠使用和調動大規模的計算資源；接下來需要攻關的是如何高效利用資源、更加有效的降低成本，更加彈性的面對業務波動，這就是函式計算的用武之地。InfoQ 對不瞋進行了專訪，並將內容整理如下。

什麼是 Serverless？什麼是 FaaS？

其實，廣義的 Serverless 覆蓋範圍很大，很多雲服務產品可以被視作 Serverless 化的。以儲存服務的發展歷程為例：最初常見是雲伺服器，此種情況對使用者熟悉的原有開發方式的模擬，但是需要自行處理雲伺服器宕機帶來的資料不可用問題，雲磁碟上的資料也不便於分享；後來，物件儲存（OSS），檔案儲存（NAS），表格儲存（TableStore），訊息服務（MNS）等都屬於 Serverless 服務。這些服務不再有機器的概念，使用者能夠享受自動的擴容和負載平衡，效能水平擴充套件，通過 API 方便的讀寫資料，易於共享，並且按實際儲存的資料量以及訪問次數付費。此外，類似阿里雲大資料計算服務（MaxCompute） 也是 Serverless 的，提供了 MapReduce，和 Streaming 等多種計算框架，使用者不需要管理計算資源。

Serverless 是一個寬泛的概念，很多儲存、計算和中介軟體服務都是 Serverless 的。而 FaaS 是 Serverless 的子集，也是實現整個應用 Serverless 化的核心服務。

FaaS 的關鍵特徵是：事件驅動、細粒度呼叫、實時彈性伸縮，無需管理伺服器等底層資源。在不瞋看來，FaaS 興起是對現有技術很好的補充，配合使用已有的雲服務產品，即可以真正構建 Serverless 的應用。阿里雲之所以研發 FaaS 產品 – 函式計算，也是觀察到在儲存和計算業務中，從 server-base 到 Serverless 的演變趨勢和使用者的需求。

Serverless 與微服務是一脈相承的

微服務和 Serverless 是契合的，都強調系統的解耦。

將業務邏輯的實現拆分到 Function 的粒度再去實現，這種方法其實並不新奇；微服務本身是被越來越廣泛使用的模式，並且已經有 Netflix、Uber 等公司的成功經驗。使用者完全可以把一個微服務實現為 Function。阿里雲函式計算設計的一個重要目標也是使之成為以微服務方式構建應用的最好平臺。微服務式架構其實是很有挑戰的，在拆成成百上千的服務之後，需要高度自動化的釋出部署系統，管理各個微服務之間的依賴。從某種角度而言，Serverless 和微服務是不同層面、但又互相促進的：微服務式是開發模式，Serverless 是計算平臺。

不瞋稱其個人理解是，讓 Serverless 這種計算平臺變成支撐微服務開發模式的最好的平臺。當越來越多公司熟悉並實踐微服務的開發模式，那麼遷移到 Serverless 就會更順理成章，因為系統已經被解耦成了眾多鬆耦合的微服務。

所以，Serverless 和微服務的未來發展是相互借力的。一個有力的例子就是，大規模使用微服務的方式構建系統的公司，例如 Netflix，也在廣泛的使用 AWS Lambda 這類 FaaS 服務來構建 Serverless 應用。

但是，微服務化改造並非易事。將一個巨型單體應用以微服務的方式拆分解耦，繼而改造為 Serverless 應用，是採用漸進的方式逐步替換還是完全重寫？這是業界非常關心也經常討論的問題，不瞋認為需要依據情況而定：有時直接重寫更快；而在系統錯綜複雜的情況下，為了保險起見也可平滑過渡，一點點向微服務化演進。

拆分微服務有三個考量，組織結構（參考康威定律），運維釋出頻率（比如將每週釋出兩次的服務與每兩個月釋出一次的服務進行拆分）和邏輯呼叫頻度（將高頻呼叫邏輯和低頻呼叫邏輯分開，在 Serverless 架構下能夠進一步降低成本）。

以上三點需根據業務需求情況進行綜合考量，沒有普適性的優先順序之分。

Serverless 適用的兩大場景

場景一：應用負載有顯著的波峰波谷

Serverless 化與否的評判標準並不是公司規模的大小，而是其業務背後的具體技術問題，比如業務波峰波谷明顯，如何實現削峰填谷。一個公司的業務負載具有波峰波谷時，機器資源要按照峰值需求預估；而在波谷時期機器利用率則明顯下降，因為不能進行資源複用而導致浪費。

業界普遍共識是，當自有機器的利用率小於 30%，使用 Serverless 後會有顯著的效率提升。對於雲廠商，在具備了足夠多的使用者之後，各種波峰波谷疊加後平穩化，聚合之後資源複用性更高。比如，外賣企業負載高峰是在用餐時期，安防行業的負載高峰則是夜間，這是受各個企業業務定位所限的；而對於一個雲廠商，如果其平臺足夠大，使用者足夠多，是不會有明顯的波峰波谷的現象的。

 場景二：典型用例 – 基於事件的資料處理

視訊處理的後端系統，常見功能需求如下：視訊轉碼、抽取資料、人臉識別等，這些均為通用計算任務，可由函式計算執行。

開發者需要自己寫出實現邏輯，再將任務按照控制流連線起來，每個任務的具體執行由雲廠商來負責。如此，開發變得更便捷，並且構建的系統天然高可用、實時彈性伸縮，使用者不需要關心機器層面問題。

使用小 tips：函式的執行本身是無狀態的，如果要持久化資料則需使用 OSS 等儲存服務。雖然使用者可以使用本地的磁碟，但是需要假定這些資料在函式執行完成後就不再需要了。

Serverless 會帶來哪些衝擊？

 Serverless 不等於沒有運維，但是運維內容變了。

在 Serverless 出現之前，使用者運維時要考慮機器掛了怎麼辦，連線數暴漲了怎麼辦等等。

使用者用雲，從某種意義上講是為了提高效率，而效率又分為開發效率、運維效率和成本效率。Serverless 之後，運維從事的更多是業務運維，摸清依賴關係，設定監控項進行健康報警。

運維不再負責機器運維，而是業務運維。比如函式 A 呼叫函式 B，這樣的依賴關係是否合理；從業務邏輯上去評估哪些關鍵路徑需要報警，哪些是允許失敗的。原來的機器運維需要關心配置問題、作業系統、Kernel 升級和網路設定等。所以其實 Serverless 更加推動了 DevOps，Ops 工作被改變了，Serverless 對開發人員也更加友好。

長遠而講，會衝擊傳統 PaaS  

如果 Serverless 平臺可以解決通用問題，並且有吸引力，那確實會對傳統的雲端計算有衝擊；但是，這是個漸進的過程。Serverless 可以部署在公有云、私有云和混合雲上。（備註：目前阿里雲推出的產品尚限於公有云。）

在不瞋看來，Cloud-Native 應用是指基於各種雲的服務構建的高可用、可伸縮的應用。例如通過函式計算實現控制流邏輯、整合物件儲存、離線資料處理等雲服務，就能快速搭建一個實時彈性伸縮、高可用的業務系統。因此 Serverless 是構建 Cloud-Native 應用的理想方式。

開發模式和職責的改變  

未來，Serverless 一旦流行開來，使用者可以依託於雲端計算廠商提供的平臺類服務，快速構建彈性高可用的系統，從而專注於業務邏輯的創新。

四問阿里雲的函式計算

 阿里雲函式計算是不是一種跟風行為？

函式即服務（FaaS）並非阿里雲首創，2014 年 10 月 hook.io 推出了首個 FaaS 服務。同年 AWS Lambda 問世，2016 年 Google Cloud Functions 和 Microsoft Azure Functions 相繼商用化，具備開源版和商用版 IBM Bluemix 的 OpenWhisk 也提供類似的功能。Uber 曾經演示過其私有云平臺如何構建去模式化觸發（Schemaless triggers），和雲廠商的 FaaS 服務有異曲同工之妙的（https://eng.uber.com/schemaless-part-three/）。

不瞋稱，函式計算的推出其實是因為客戶在使用過程中產生了這種需求，並且同時也確實契合了雲的發展趨勢。

阿里雲做產品是由使用者需求驅動，比如觀察到使用者在使用 OSS 物件儲存時，通常需要由儲存事件觸發的資料處理。例如在音視訊行業中，上傳的視訊檔案通常會進行轉碼、鑑黃等處理。通過對這些需求的分析，然後去思考是否可以抽象為通用的技術解決方案。這是主要驅動力，當然同時也會觀察業界的發展，不過本質上還是與所服務使用者的需求相關。

從什麼時候開始積累函式計算的技術能力？

函式計算的技術可以分成兩個部分去看：

第一部分是 服務的核心：包括資源動態的排程，使用者函式的隔離執行，還有自動的負載均衡和流控，這是後臺必須要具備的能力。

第二部分是 服務的外延：當提供成計算服務供其他人去使用時，平臺需要為使用者提供優秀的 debugging 和 tracing 能力、函式依賴的管理、持續整合持續釋出等功能。

對於核心部分的技術，包括資源的排程，程式執行的隔離等等，阿里雲飛天計算平臺有長期的積累。相對而言，外延部分比較新；業界也處於早期階段，目前尚沒有統一的廠商構建標準，還有很大的發展空間。打造好的服務外延的出發點是，怎麼可以讓使用者基於函式計算構建複雜的 Serverless 應用，只有解決了這個本質問題，函式計算才能變成主流的通用計算服務。

除了函式計算技術本身，，函式計算的產品生態非常重要，函式計算本身是事件、訊息和資料驅動的計算模式，還需要其他雲服務與之協同配合應用於不同的場景中，比如 OSS 的多媒體資料寫入和訪問、LogService 的日誌、API Gateway 的請求、訊息服務的訊息到達，這些都為函式計算的技術生態提供了協作關係。此外，對於資料處理方案，不瞋稱使用者也可以接入第三方的資料處理服務。

按需付費，如何面對“缺斤短兩”的問題？

Serverless 計算的一個核心優勢是按需付費。因此關鍵的問題是，如何讓使用者能很容易預估費用？如何證明費用的真實性？

不瞋稱，雲服務的費用問題不是新問題，Serverless 服務需要給使用者提供簡潔的，易於預估的費用模型，非常豐富的計量指標和細粒度的賬單，讓使用者能夠推敲驗證。

此外，好的產品設計還需要考慮到如何幫使用者規避錯誤。有時候使用者實現的函式邏輯可能會有 bug，導致突然間錯誤消耗大量資源，比如在具有巨大計算能力的雲平臺上寫出了無限遞迴呼叫的函式；在這個方面，不瞋稱阿里雲也有考量，函式計算允許使用者設定費用上限，並且提供豐富的監控和報警功能，幫助使用者減少因為自身失誤帶來的資源過度使用的損失。

函式計算產品短期和長期的目標是什麼？

阿里雲的 FaaS 產品與業界相比的差異在哪裡？坦白講，目前還在發展的初期階段，未來則會根據使用者場景進行不斷優化。目前使用函式計算的使用者來自於電商、遊戲、IoT 等領域，使用者的主要訴求是可以專注於業務邏輯開發，不再維護後端伺服器；此外使用者也非常看重按需付費，削峰填谷等特性。

短期主攻數個典型的使用者場景，打造出尖銳的使用者體驗，自下向上的積累理解和經驗。阿里雲的函式計算目前還只支援 Node.js，在多語言支援上有待提高。還有一種做法是去語言化，定一個與語言無關的 http 互動協議。但是後者的使用門檻稍微高一些：前者是寫一個 Function，而後者卻需要使用者實現一個 mini web server。

在此基礎上，從雲發展的巨集觀角度思考，自上而下地制定中長期目標。持續改進服務的核心和外延能力，讓平臺變成構建複雜應用的核心計算平臺。

還有，如何拓展技術的邊界，計算場景是否可以發生在不同的計算環境中，不同的計算介質如 FPGA、GPU、邊緣節點、端裝置。其中邊緣節點計算需求在工控領域中尤為突出，比如如何收集偏遠地區風力發電站的資料以實現智慧化？在惡劣環境下，網路傳輸並不總是可靠且成本很高，這時就需要在本地對資料進行處理，然後再將提煉的資料傳到雲端。為什麼這種情況函式計算適合？因為它已經脫離了機器概念，抽象出了統一的計算模型去支撐雲端和邊緣計算。

基於 Serverless 寫的程式，是不需要考慮如何部署、管控和重度運維。使用者可以自己在遠端的辦公室進行調控，比如將某些計算任務部署到邊緣節點上，實現和雲端類似的監控，在網路良好時，再進行資料的傳輸。而且在本地對噪聲資料進行處理提煉，能有效的降低傳輸到雲端的資料量，大幅降低成本。

Serverless 未來光明，但挑戰猶在

比起微服務、DevOps，Serverless 的落地和流行將更快。

使用函式計算構建 Serverless 架構，以很高的開發效率去構建一個系統，並且這個系統天然就是實時可伸縮的。對於使用者而言，良好落地 Serverless 的要點主要在於架構設計，使用者需要首先理解 Serverless，然後從現有的業務中提煉出業務邏輯。即 Serverless 流行起來難度不在於開發門檻，而在於思維和架構的轉變。如果熟知微服務，對 Serverless 的理解會更加方便。

正如前文所說，Serverless 讓微服務的實現更輕鬆，更適應基於微服務的鬆耦合系統設計。但是反觀微服務化和 DevOps 改造實施起來比較重，技術門檻不低。而 Serverless 很輕，和微服務的目標趨同，但是釋出、運維等環節的雲服務化更徹底；使用者只需設定資源和釋出部署等規則，因此 Serverless 會更加容易落地。

不過，Serverless 對於使用者而言，還是很新的概念。縱然 DevOps、微服務等已經被廣泛認知了，但是全面落地尚且遙遠，怎麼看待 Serverless 的推進呢？任何新的概念的落地，本質上都是要和具體業務去結合，去真正解決具體問題。這要取決於，一開發人員對技術的理解度，二是使用者在實施中的漸進與積累，三是企業對按需付費的強烈意願。

沒有什麼業務需求是空穴來風，也沒有什麼技術發展是一蹴而就。

受訪人簡介

不瞋，函式計算研發經理。2010 年加入阿里雲，參與了阿里雲飛天分散式系統的研發，歷任批量計算的架構師，表格儲存（NoSQL）研發經理，深度參與了阿里雲系統研發和產品迭代的全過程。對大規模分散式計算，大規模資料儲存和處理有非常深入的理解。現為阿里雲函式計算產品研發負責人，致力於構建下一代彈性、高可用的無伺服器計算平臺。

文章來自微信公眾號：高效開發運維