Serverless是一種構建和管理基於微服務架構的完整流程，容許你在服務部署級別而不是服務器部署級別來管理你的應用部署。數據庫
它與傳統架構的不一樣之處在於，徹底由第三方管理，由事件觸發，存在於無狀態（Stateless）、暫存（可能只存在於一次調用的過程當中）計算容器內。構建無服務器應用程序意味着開發者能夠專一在產品代碼上，而無須管理和操做雲端或本地的服務器或運行時。編程
Serverless真正作到了部署應用無需涉及基礎設施的建設，自動構建、部署和啓動服務。後端
微服務的概念很是適合Serverless功能的結構，能夠輕鬆實現不一樣服務在部署和運行時隔離。在數據存儲方面，使用諸如DynamoDB之類的數據庫，還使得每一個微服務都能擁有獨立的數據庫，並在須要獨立擴展它們時變得更加容易。緩存
在咱們深刻研究細節以前，請考慮微服務對於你的特定項目和團隊而言，其好處是否大於其缺點。請不要由於「微服務是趨勢」，就要必須選擇它。單體架構(Monolith)也有他的適用場景。服務器
Serverless中微服務的優點
1. 選擇性地可伸縮性和併發性
Serverless功能使管理應用程序的併發性和可伸縮性變得容易。在微服務架構中，咱們充分利用了這一點，每一個微服務均可以根據須要具備本身的併發/可伸縮性設置。
這是有價值的：減輕DDoS攻擊的可能性，減小沒法控制的雲帳單的財務風險，更好地分配資源等等。
2. 細粒度的資源分配
經過選擇性的可伸縮性和併發性，能夠對資源分配優先級進行詳細控制。
每一個（微）服務能夠根據其需求和目的具備不一樣級別的內存分配。面向客戶的服務能夠分配更高的內存，由於它將有助於縮短執行時間，提升響應速度。能夠經過優化的內存設置來部署對延遲不敏感的內部服務。
存儲機制也是如此，DynamoDB或Aurora Serverless等數據庫能夠根據（微）服務的需求而具備不一樣級別的容量分配。
3. 鬆耦合
這是微服務的基本屬性，這樣它可使具備不一樣用途的系統組件更容易解耦。
4. 支持多運行時環境
Serverless功能配置，部署和執行的簡便性爲基於多個運行時的系統提供了可能性。
儘管Node.js是後端Web應用程序中最流行的技術之一，但它不可能成爲每一個任務的最佳工具。但，對於數據密集型任務，預測分析和任何形式的機器學習，Python可能會成爲你的選擇。專用平臺（例如SageMaker）則更適合於大型項目。
藉助Serverless基礎架構，在運維方面，你無需再花額外的精力就能夠爲常規後端項目選擇Node.js，爲數據密集型選擇Python。固然，這將在代碼維護和團隊管理方面增長一些工做。
5. 開發團隊的獨立性
不一樣的開發人員或團隊能夠在各自的（微）服務上工做，修復錯誤，擴展功能等。
AWS SAM，Serverless之類的工具使得在操做方面也具備更大的獨立性。AWS CDK constructs 可實現更大的獨立性，而無需犧牲更高級別的質量和運維標準。
Serverless中微服務的缺點
1. 難以監視和調試
Serverless帶來的許多挑戰中，監視和調試是最有難度的。由於計算和存儲系統分散在許多不一樣節點中，更不用說緩存等的其餘服務了。
2. 可能會經歷更多的冷啓動
調用功能時，Lambda會檢查microVM是否已激活。若是有空閒的microVM可用，它將用於服務新的傳入請求。在這種特殊狀況下，沒有啓動時間，由於microVM已經啓動而且代碼包已在內存中。這稱爲 熱啓動。微信
相反的方法-必須從頭開始提供新的microVM來知足傳入的請求-被稱爲 冷啓動。架構
當FaaS(Function as a Services)平臺（例如Lambda）須要啓動新的虛擬機來運行功能代碼時，就會發生冷啓動。若是你的應用對延遲很敏感，則它們可能會出現問題，由於冷啓動會在總啓動時間中增長几百毫秒到幾秒鐘。
由於在完成一個請求後，FaaS平臺一般會將microVM閒置一段時間，而後在10-60分鐘後關閉。所以，函數執行的頻率越高，microVM越有可能運行傳入的請求（避免冷啓動）。
當咱們將應用程序分散在數百或數千個（微）服務中時，咱們還可能分散每一個服務的調用時間，從而致使每一個功能的調用頻率下降，可能會經歷更多的冷啓動。
3. 其餘缺點
微服務概念自己還具備其餘固有的缺點。這些並非與Serverless固有的聯繫。儘管如此，每一個採用這種架構的團隊都應努力下降其潛在的風險和成本：
肯定服務邊界並不是易事併發
更普遍的攻擊面less
服務編排開銷運維
同步計算和存儲並不容易
Serverless微服務的挑戰和最佳實踐
1. Serverless中微服務應該是多大
微服務（MicroService）是軟件架構領域業另外一個熱門的話題。若是說微服務是以專一於單一責任與功能的小型功能塊爲基礎，利用模組化的方式組合出複雜的大型應用程序，那麼咱們還能夠進一步認爲Serverless架構能夠提供一種更加「代碼碎片化」的軟件架構範式，咱們稱之爲Function as a Services（FaaS）。
而所謂的「函數」（Function）提供的是相比微服務更加細小的程序單元。例如，能夠經過微服務表明爲某個客戶執行全部CRUD操做所需的代碼，而FaaS中的「函數」能夠表明客戶所要執行的每一個操做：建立、讀取、更新，以及刪除。當觸發「建立帳戶」事件後，將經過AWS Lambda函數的方式執行相應的「函數」。從這一層意思來講，咱們能夠簡單地將Serverless架構與FaaS概念等同起來。
在Serverless中，常常會將「Function as a Services（FaaS）」的概念與你所選擇的編程語言中的函數語句混淆。
咱們正在進入一個沒法畫出完美界限的領域，可是經驗代表，使用很是小的Serverless功能並非一個好主意。
你應該記住的一件事是，當決定將（微）服務分拆爲單獨的功能時，你將不得不該對Serverless困境。只要有可能，將相關邏輯保持在單個功能中就會有不少好處。
-
-
我能夠從細粒度的資源分配或選擇性可伸縮性功能中受益嗎？
若是不是，則應該考慮將該服務與所需的組件等捆綁在一塊兒。
2. 鬆耦合你的架構
經過組成Serverless功能來協調微服務的方法有不少。
當須要同步通訊時，能夠進行直接調用（即AWS Lambda RequestResponse調用方法），但這會致使高度耦合的架構。更好的選擇是使用Lambda Layers或HTTP API，這使得之後能夠在不中斷客戶端請求的狀況下，修改或遷移服務成爲可能。
對於異步通訊，咱們有幾種選擇：消息隊列（SQS），主題通知（SNS），Event Bridge或者DynamoDB Streams。
3. 組件隔離
諸如Lambda之類的Serverless平臺已經提供了隔離功能的API。但這自己就會致使實現細節泄漏，理想狀況下，咱們將在功能之上添加一個不可知的HTTP API層，以使其真正隔離。
4. 使用併發限制策略
爲了減輕DDoS攻擊，在使用AWS API Gateway等服務時，請確保爲每一個面向公衆的終端節點設置單獨的併發限制策略。
此類服務在雲平臺中具備針對全局併發配額。若是你沒有基於端點的限制，則攻擊者只需將一個端點做爲目標便可耗盡你的資源配額並使整個系統癱瘓。
總結
不管你是遷移舊系統仍是從頭開始構建某些產品，確保其按預期順利運行都是一個持續的挑戰。在本文中，咱們研究了Serverless的優勢和缺點，Serverless的微服務挑戰和最佳實踐等等。
譯者：王延飛
譯文連接：
https://dzone.com/articles/microservices-and-serverless-winning-strategies-an
