Serverless

1、介紹

是指依賴於第三方應用程序或服務來管理服務器端邏輯的應用程序。 此類應用程序是基於雲的數據庫（如Google Firebase）或身份驗證服務。

無服務器也意味着開發爲事件觸發的代碼，而且在無狀態計算容器中執行。 這種架構一般稱爲功能即服務（FaaS）。

FaaS(Function as a service 函數做爲一種服務) 本質上是一個小程序或函數，它執行由事件觸發的小任務，而不像單個應用程序那樣作不少事情。所以，在FaaS架構中，咱們將應用程序分解爲小型，自包含的程序或功能，而不是在PaaS上運行並執行多種功能的單一應用程序。例如，API中的每一個端點均可以是一個單獨的函數，咱們能夠按需運行這些函數，而不是全時運行應用程序。

2、Serverless的主要優勢

開發者只須要專一於業務邏輯就能夠了，開發效率更高。開發一個典型的服務器端項目，須要花不少時間處理依賴、線程、日誌、發佈和使用服務、部署及維護等相關的工做，基於Serverless架構則不須要操心這些工做。
不須要關注雲主機、操做系統、網絡等基礎資源，Serverless框架還能夠根據負載量自動水平擴展。
不須要架構。Serverless架構自己就是高可用、高擴展的架構，基本上不須要架構師的參與。
按需付費， 成本相對比較低。用戶購買的ECS使用時間通常不到5成，可是爲另外5成閒置時間付費了。Lambda按照運行的時間收費，成本會低不少。

3、Serverless的主要缺點

不適合處理複雜的業務邏輯，它更適合調用雲上的其餘服務，粘合關鍵的產品。以AWS Lambda例，咱們一般使用Lambda寫一段邏輯將文件上傳到S3，將請求的數據寫入到DynamoDB或RDS數據庫等一些相對簡單的功能。
排查問題困難，由於邏輯散落在各處。
Serverless沒法用於高併發應用，爲每一個請求啓動一個進程開銷過高，流量瞬間爆發容易致使超時。例如雙十一支付寶高峯期每秒處理的交易數爲8.59萬筆，若是使用Serverless架構，意味着咱們的系統內每秒有8.59萬個進程被建立又被銷燬，這是難以負擔的開銷。
Serverless調用之間不能共享狀態讓編寫複雜程序變得極度困難。無狀態是互連網應用追求的目標，例如知足「12要素」的應用。但Serverless將無狀態進行的更加完全，在不一樣的調用之間沒法共享內存狀態，例如使用hashmap。咱們的AI應用中統計已處理圖片總數的全局計數器在傳統架構中只是一個全局變量，但在Serverless架構中它變成存儲在內存數據庫（Redis）中的一條記錄，更新成本、保證原子性等因素讓咱們的編碼變得數倍複雜。對於大多雲原生的互聯網應用來講，這種完全的無狀態架構是一個巨大的挑戰，而對於動輒有幾十萬、上百萬行代碼的、充滿了狀態的企業應用來講，Serverless的無狀態改造幾乎是一個沒法完成的任務。
業務拆分問題。如何將業務拆分紅成百上千個運行在獨立進程、運行時間受限的函數是巨大的挑戰。而是否須要如此細粒度的拆分是須要回答的第一個問題。有些問題或許變成無解難題又或成本極高，例如分佈式數據庫事務。
廠商鎖定。雲計算是贏者通吃的行業，大而全的雲廠商優點巨大，Serverless加重了這種趨勢。之前用戶還須要本身寫不少服務器端的邏輯，遷移的時候，把服務器端代碼從新部署一下。採用Serverless架構以後，代碼都是各個平臺的Lambda代碼片斷，無法遷移。從客戶的角度來看，是不但願本身被某家雲廠商所綁架的。因此雲計算行業須要作不少標準化的工做，方便用戶無縫在各類雲之間遷移。

對已存在的項目遷移困難。將現有的複雜的單體式應用進行如此細粒度的拆分須要極高的成本。

4、Microservice與Serverless的適用場景

Microservice適合構建複雜的應用。好比：構造一個分佈式數據庫。

Serverless 適合構建比較簡單的應用，好比上傳一張圖片、對一段音頻/視頻進行編解碼、對IOT設備的請求返回一小段數據等。