換個角度聊聊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等可能會有更爲廣闊的前景。