「Serverless 能取代微服務嗎？」 這是知乎上 Serverless 分類的高熱話題。java
有人說微服務與 Serverless 是相背離的，雖然咱們能夠基於 Serverless 後端來構建微服務，但在微服務和 Serverless 之間並不存在直接的路徑。程序員
也有人說，由於 Serverless 內含的 Function 能夠視爲更小的、原子化的服務，自然地契合微服務的一些理念，因此 Serverless 與微服務是天做之合。數據庫
立刻就要 2021 年了，Serverless 是否終將取代微服務？從微服務到 Serverless 須要通過怎樣的路徑？ 在咱們深刻探討細節以前，先別急着「站隊」，不妨先基於你團隊的實際狀況，真實的去思考是否適合使用微服務，千萬不要由於 "這是趨勢 "而去作選擇。編程
微服務在 Serverless 中的優點後端
Serverless緩存
1.可選擇的可擴展性和併發性
Serverless 讓管理併發性和可擴展性變得容易。在微服務架構中，咱們最大限度地利用了這一點。每個微服務均可以根據本身的需求對併發性/可擴展性進行設置。從不一樣的角度來看這很是有價值：好比減輕 DDoS 攻擊可能性，下降雲帳單失控的財務風險，更好地分配資源......等等。架構
2.細粒度的資源分配
由於可擴展性和併發性能夠自主選擇，用戶能夠細粒度控制資源分配的優先級。在 Lambda functions 中，每一個微服務均可以根據其需求，擁有不一樣級別的內存分配。好比，面向客戶的服務能夠擁有更高的內存分配，由於這將有助於加快執行時間；而對於延遲不敏感的內部服務，就能夠用優化的內存設置來進行部署。併發
這一特性一樣適用於存儲機制。好比 DynamoDB 或 Aurora Serverless 數據庫就能夠根據所服務的特定（微）服務的需求，擁有不一樣級別的容量分配。框架
3.鬆耦合
這是微服務的通常屬性，並非 Serverless 的獨有屬性，這個特性讓系統中不一樣功能的組件更容易解耦。less
4.支持多運行環境
Serverless 功能的配置、部署和執行的簡易性，爲基於多個運行時的系統提供了可能性。
雖然 Node.js (JavaScript 運行時)是後端 Web 應用最流行的技術之一，但它不可能成爲每一項任務的最佳工具。對於數據密集型任務、預測分析和任何類型的機器學習，你可能選擇 Python 做爲編程語言；像 SageMaker 這樣的專用平臺更適合大項目。
有了 Serverless 基礎架構，你無需在操做方面花費額外的精力就能夠直接爲常規後端 API 選擇 Node.js，爲數據密集型工做選擇 Python。顯然，這可能會給你的團隊帶來代碼維護和團隊管理的額外工做。
5.開發團隊的獨立性
不一樣的開發者或團隊能夠在各自的微服務上工做、修復 bug、擴展功能等，作到互不干擾。好比 AWS SAM、Serverless 框架等工具讓開發者在操做層面更加獨立。而 AWS CDK 構架的出現，能夠在不損害高質量和運維標準的前提下，讓開發團隊擁有更高的獨立性。
微服務在 Serverless 中的劣勢
Serverless
1.難 以監控和調試
在 Serverless 帶來的衆多挑戰中，監控和調試多是最有難度的。由於計算和存儲系統分散在許多不一樣的功能和數據庫中，更不用說隊列、緩存等其餘服務了，這些問題都是由微服務自己引發的。不過，目前已經有專業的平臺能夠解決全部這些問題。那麼，專業的開發團隊是否要引入這些專業平臺也應該基於成本進行考量。
2.可能經歷更多冷啓動
當 FaaS 平臺（如 Lambda）須要啓動一個新的虛擬機來運行函數代碼時，就會發生冷啓動。若是你的函數 Workload 對延遲敏感，就極可能會遇到問題。由於冷啓動會在總啓動時間中增長几百毫秒到幾秒的時間，當一個請求完成後，FaaS 平臺一般會讓 microVM 空閒一段時間，等待下一個請求，而後在 10-60 分鐘後關閉（是的，變化很大）。結果是：你的功能執行的越頻繁，microVM 就越有可能爲傳入的請求而啓動並運行（避免冷啓動）。
當咱們將應用分散在數百個或數千個微服務中時，咱們可能在每一個服務中分散調用時間，致使每一個函數的調用頻率下降。注意 「可能會分散調用」。根據業務邏輯和你的系統行爲方式，這種負面影響可能很小，或者能夠忽略不計。
3.其 他缺點
微服務概念自己還存在其餘固有的缺點。這些並非與 Serverless 有內在聯繫的。儘管如此，每個採用這種類型架構的團隊都應該謹慎，以下降其潛在的風險和成本。
-
肯定服務邊界並不是易事，可能會招致架構問題。
-
更普遍的攻擊面
-
服務編排費用問題
-
同步計算和存儲（在須要的時候）是不容易作到高性能和可擴展
微服務在 Serverless 中的挑戰和實踐
Serverless
1.Serverless 中微服務應該多大？
人們在理解 Servrless 時，" Function as a Services（FaaS） " 的概念很容易與編程語言中的函數語句相混淆。目前，咱們正在處在一個沒有辦法劃出完美界限的時期，但經驗代表，使用很是小的 Serverless 函數並非一個好主意。
當你決定將一個（微）服務分拆成獨立的功能時，你就將不得不面對 Serverless 難題。所以，在此提醒，只要有可能，將相關的邏輯保持在一個函數中會好不少。
固然，決策過程也應該考慮擁有一個獨立的微服務的優點
你能夠這樣設想：「若是我把這個微服務分拆出來......」
-
它能讓不一樣的團隊獨立工做嗎？
-
可否從細粒度的資源分配或選擇性的擴展能力中獲益？
若是不能，你應該考慮將這個服務與另外一個須要相似資源、上下文關聯並執行相關 Workload 的服務捆綁在一塊兒。
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 等服務時，必定要爲每一個面向公衆的終端設置單獨的併發限制和節流策略。這類服務通常在雲平臺中會爲整個區域設置全局併發配額。若是你沒有基於端點的限制，攻擊者只須要將一個單一的端點做爲攻擊目標，就能夠耗盡你的配額，並讓你在該區域的整個系統癱瘓。
推薦閱讀
看完三件事❤️
若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
點贊，轉發，有大家的 『點贊和評論』，纔是我創造的動力。
關注公衆號 『 Java鬥帝 』，不按期分享原創知識。
同時能夠期待後續文章ing🚀