與微服務一脈相承,Serverless適用何種場景?會帶來哪些衝擊?

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)研發經理,深度參與了阿裏雲係統研發和產品迭代的全過程。對大規模分布式計算,大規模數據存儲和處理有非常深入的理解。現為阿裏雲函數計算產品研發負責人,致力於構建下一代彈性、高可用的無服務器計算平台。
最後更新:2017-05-13 08:41:29