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