Serverless/FaaS伴隨著Kubernetes的熱度增加，也成為了熱門話題。相關文章介紹了很多，這裡筆者不一一贅述，而是從個人見解上聊聊關於FaaS的架構和意義。
在筆者上學時，雲端計算剛剛火熱，IaaS/PaaS/SaaS的基礎概念已經逐漸深入人心。其中PaaS平臺的代表形式就是App Engine，其中最知名的當屬Google的GAE。GAE可以說取得了一定的成功，但是與後來的Docker的巨大成功相比，就略遜一籌了。Docker中以映象為代表的標準化交付方式，較之於GAE的原始碼式交付，可以得到更為靈活和廣泛的應用，對使用各種語言和框架開發的應用也更加友好，許多執行環境的問題如依賴等也更容易得到解決。
談FaaS為什麼會談到這個。主要是因為筆者看到目前的FaaS平臺很多都是透過上傳原始碼來進行支援的，比如支援Python/Java等。這不由得讓筆者想起GAE的使用。誠然，這種方式更容易管理和標準化。但是如果考慮到很多應用已經使用不同的語言和框架進行了大量的開發。那麼這樣的方式很可能也會侷限FaaS的應用範圍，使得很多應用的遷移成本增加，甚至導致難以遷移。筆者認為，未來的一個可能方式就是參考Docker，以映象的方式進行Function的交付。對其輸入輸出配置等進行規約標準，使得應用的遷移主要關註於架構的調整，而非程式碼的重構。同時，這樣的交付方式也更容易擺脫對於平臺或者廠商的依賴，得到更為廣泛的支援。
假使都使用映象來進行交付，那麼帶來的一個問題就是映象的種類多樣、映象拉取時間過長的問題。大量的映象可能會帶來一些管理方面的工作。另外，容器的啟動時間也會嚴重依賴於映象的拉取時間。使得映象拉取成為需要重點最佳化的一個過程。
映象拉取其實主要是兩部分，一部分是從映象倉庫中將映象檔案下載下來，另一部分則是將映象檔案進行解壓並複製到對應層的過程。在內網環境下，前者的速度其實非常快。而由於大量小檔案的原因，後者的速度往往會成為實際的映象拉取瓶頸。以筆者看來，可以考慮將映象儲存直接儲存於分散式檔案系統中。這樣容器啟動無需再去拉取映象，而可以直接啟動，將大大縮短容器的啟動時間。分散式的映象儲存可以有多種實現方式，這個以後有時間再做專題討論。
FaaS的優點如簡化運維、提高開發效率等，在許多文章中都已經提到了。這裡主要提的是在私有雲中，FaaS對於提升資料中心的排程質量，也有巨大的意義。
透過FaaS的改造，應用的執行方式從long running的任務轉變成為batch job。在原有的架構中，由於應用的負載難於預測（不確認任務會何時到來），出於安全方面等原因，會導致資源的空置。改造為FaaS後，可以實現資源的隨取隨用。且由於Function的容器擁有計算資源需求較小、延遲不敏感等特點，可以將容器用以充塞各個節點上的資源碎片，加以充分利用。並輔以驅逐系統，可以充分保證業務的資源使用。這樣以來，可以提升整個資料中心的資源使用效率，達到節約成本的目的。而且由於FaaS的延遲容忍、時間可控的特性，在排程規劃方面也會有很大幫助。
至於FaaS的應用場景，在筆者接觸的領域，目前其可以使用的範圍較窄，主要集中於圖片預處理等環節。以筆者的猜測，在一些延遲互動的領域，如短影片、AI等可能會有更為廣闊的前景。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
朋友會在“發現-看一看”看到你“在看”的內容