深度使用了下 Serverless，太絲滑了！
云函數和 FaaS
最近在開發自己的小項目的時候，因為各種原因使用上了云函數這個東西，不夸張的說開發時間直接減少一半，當然也沒啥復雜業務邏輯，但是亂七八糟各種配置基本都可以摒棄掉了。
云函數就是一種 Serveless，準確來說，云函數屬于 Serveless 中的 FaaS（Function as a Service，函數即服務），典型的產品有阿里云函數、騰訊云函數、AWS Lambda、Google Cloud Functions、Azure Functions 等等。
FaaS 本質上是一種事件驅動的由消息觸發的服務，FaaS 供應商（比如阿里云、騰訊云）一般會集成各種同步和異步的事件源，通過訂閱這些事件源，可以突發或者定期的觸發函數運行。于傳統服務需要將應用程序（Application）部署到擁有操作系統的虛擬機或者容器中并且需要長時間駐留的機制不同，FaaS 是直接將程序部署上到平臺上即可，當有事件到來時觸發執行，執行完了就可以卸載掉。
IaaS、PaaS、SaaS、Faas
看完上面這些介紹一定還有很多同學一頭霧水，別急，下面我來詳細介紹下 FaaS 的發展背景：
云計算這個詞大伙肯定都聽說過，這個概念聽起來很牛逼，但其實核心目的就是云服務商能夠為用戶提供更強大、更便宜的算力。
當然，不要覺得云計算就是一個超大號的機房，只不過服務器更多些。
云計算的本質，不是算力資源的簡單堆砌，而是池化。它將大量的零散算力資源（廉價的算力資源）進行打包、匯聚，實現更高可靠性、更高性能、更低成本的算力。
具體來說，在云計算中，CPU、GPU、內存、硬盤等計算資源被集合起來，通過軟件的方式，組成一個虛擬的可無限擴展的“算力資源池”。如果用戶有算力需求，“算力資源池”就會動態地進行算力資源的分配，構建一個虛擬的“計算機”。用戶按需使用、付費，即可。相比于用戶自購設備、自建機房、自己運維，云計算有明顯的成本優勢，可以節約大量資金和人力。
根據提供算力資源的層級不同，云計算通常也分為 IaaS（基礎設施即服務）、PaaS（平臺即服務）、SaaS（軟件即服務）。如下圖所示：
圖片
那么，云計算這種 “租” 的方式，是不是最終極的算力資源使用方式呢？我們作為用戶，使用算力，還能更簡單一點嗎？
答案是肯定的。
不管是自建機房，還是云計算，用戶都需要和服務器打交道，和軟硬件環境打交道。這些都是工具和過程，而我們的最終目的是什么？是得到運算結果。
那么，為了得到結果，我們可不可以不要關心環境的搭建過程呢？能不能直接忽略掉數據庫、緩存、消息隊列等等各種亂七八糟的配置呢？或者說，既然環境可以租，那能不能直接 “租” 服務呢？
如此，Serverless 應運而生了！
Serverless 是架構、也是思想，它的目的就是在云計算的基礎上，再向前邁進一步，徹底“包攬”所有的環境工作，直接提供計算服務。
那 Serverless 具體怎么做到直接租服務的呢，核心就是這個服務足夠“細小”，變成了“函數級”的顆粒度。從層級上來看，Serverless 在傳統云計算 SaaS 的 Application（應用）層級之上，又加了一層 Function（函數），它的顆粒度更細，可以更靈活地滿足用戶的算力需求。
圖片
在 Serverless 架構下，開發者只需編寫代碼并上傳，云平臺就會自動準備好相應的計算資源，完成運算并輸出結果，從而大幅簡化開發運維過程。
我深度體驗了一把，這個開發體驗真的太太太太絲滑了，開發到部署無縫銜接，再回到之前的開發方式我只能說有、笨重。
Serverless = FaaS + BaaS
說了半天 FaaS，還沒有正式介紹 Serveless，簡單記憶：Serveless = FaaS + BaaS
又出現了一個新概念 BaaS（Backend as a Service，后端即服務），BaaS 可讓開發人員訪問各種各樣的第三方服務和應用。例如，云提供商可以提供認證服務、額外加密、云訪問數據庫以及高置信度使用數據。
而在 FaaS 下，開發人員仍然要編寫自定義服務器端邏輯，但它可以在完全由云服務提供商管理的容器中運行。
綜上，Serverless 的優點是勿容置疑的：
- 無需管理基礎設施：在 Serverless 中，云提供商負責管理底層的服務器和基礎設施，包括硬件和操作系統。這意味著開發者無需擔心服務器的配置、維護和擴展，可以將更多精力放在應用程序的開發和功能上。
- 自動伸縮：Serverless 可以自動伸縮資源以滿足流量需求，無需手動干預。這可以確保應用程序在高峰時期具有良好的性能，并在低流量時期降低成本。
- 按需計費：Serverless 模型按照實際使用的資源和執行時間來計費，因此開發者只需支付他們真正使用的部分，而無需預先購買或租賃資源。
- 快速啟動：Serverless函數通常在幾秒內啟動，因此可以迅速響應請求。這對于需要快速擴展或處理瞬時負載的應用程序非常有用。
- 事件驅動：Serverless 函數通常是事件驅動的，可以響應各種事件，如 HTTP 請求、數據庫更改、隊列消息等。這使得它們非常適合構建微服務和處理異步任務。
至于缺點，首先說定論，對于業務邏輯復雜的大型項目來說，Serverless 可能還不是一個非常好的選擇：
- 依賴云服務商：Serverless 的主動權掌握在云服務商的手上，就比如現在云函數主流還是用 Node.js 寫，各廠商對 Java 云函數的支持普遍還不是那么好
- 調試復雜性：在 Serverless 中，本地調試和跟蹤函數會更加復雜，因為函數的執行是在云提供商的環境中進行的。
- 狀態管理：要想實現自由的縮放，無狀態是必須的，而對于有狀態的服務，使用 Serverless 這就喪失了靈活性，有狀態服務需要與存儲交互就不可避免的增加了延遲和復雜性。
- 延遲：應用程序中不同組件的訪問延遲是一個大問題，我們可以通過使用專有的網絡協議、RPC 調用、數據格式來優化，或者是將實例放在同一個機架內或同一個主機實例上來優化以減少延遲。而 Serverless 應用程序是高度分布式、低耦合的，這就意味著延遲將始終是一個問題。
- 成本不可控：雖然 Serverless 按需計費有助于降低成本，但對于某些高負載或長時間運行的工作負載，可能會導致不可控的費用增加。
