「微服務架構」面向CTO的微服務設計模式：API網關、前端的後端等
微服務體系結構是軟件開發中最熱門的趨勢之一。作為CTO，你需要知道何時使用它們。但你也需要對這個主題有更深入的瞭解才能真正掌握你的項目。通過進一步瞭解微服務中的設計模式，您將確切瞭解微服務是如何工作的，以及開發人員如何使它們更高效、可伸縮和更安全。滿足最流行的微服務設計模式。
在上一篇關於微服務的文章中，我們介紹了這種流行的軟件體系結構的基礎知識。有了這些知識，您就知道微服務最適合哪種項目了。但是一旦你決定去做它，會有更多的決定要做。這就是為什麼你應該學習設計模式。
微服務中的設計模式是什麼？
如您所知，微服務是一個很大程度上獨立的應用程序組件，其任務是系統中的特定功能。多個微服務，每個微服務負責應用程序的另一個功能，再加上客户端（例如web和移動應用程序的前端）和其他（可選）中間層，構成了基於微服務的體系結構。
這種類型的設置有許多優點，例如能夠用不同的技術編寫任何服務並獨立地部署它們，以及性能提升等等。但它也帶來了一些挑戰，包括複雜的管理和配置。
設計模式的存在旨在解決微服務中的此類常見挑戰，並提供經驗證的解決方案，使您的體系結構更高效，整個管理過程更省錢、更麻煩。因此，瞭解它們是更好地理解微服務的一個很好的方法——比實際的編碼更高層次，但又足夠具體，可以理解微服務的內部工作原理。
為什麼要學習設計模式？
選擇正確的設計模式可以決定你的基於微服務的項目的成敗。它們是微服務本身並不是萬能藥的最好證明，要真正從中受益，你需要正確地使用它們。
如果您不關心微服務設計模式：
- 你的應用程序可能表現不佳（由於不必要的調用和資源使用效率低下），
- 整個系統將不穩定（例如連接和集成問題），
- 它可能面臨可伸縮性問題（添加更多的服務可能導致難以維護依賴性，甚至可能使其成為事實上的一個整體），
- 它可能會通過向公眾公開微服務的端點或通過其他方式危害安全性。
- 您可能有更多的維護和調試工作要做，而不是做更好的準備。
微服務設計模式的類型
微服務中的設計模式幾乎存在於架構的每個方面。一些最重要的問題可分為以下幾個方面：
通信
它涉及微服務和客户端應用程序（前端層）之間的通信方法。
內部溝通
這些設計模式構成了微服務之間進行通信的各種方式。
安全
各種與安全相關的問題，如安全層的組織、不同類型用户對特定微服務的授權和訪問級別等。
可用性
確保所有的微服務都準備好滿足系統的需求（不管流量有多大），確保儘可能少的停機時間。這包括確保微服務可以在另一台計算機上重新啓動，或者是否有足夠的計算機可用，微服務能夠自行報告其當前狀態，運行狀況檢查等等。
服務發現
它指的是微服務用來找到彼此並知道它們的位置的方法。
配置
設置參數並監控整個系統的性能，以便在您進行過程中不斷優化
在本文的後續部分中，我們將主要關注第一種類型，討論三種最流行的通信模式——直接模式、API網關和前端後端（BFF）。它們提供了一個很好的機會來了解基於微服務的體系結構是如何工作的，以及開發人員的選擇對其性能的影響。
直接模式
這是基於微服務架構的最基本的設置。在這種模式下，客户端應用程序直接向微服務發出請求，如下圖所示。每個微服務都有一個公共端點（URL），客户端可以與之通信。
這非常容易設置，對於相對較小的應用程序來説已經足夠了，但是隨着應用程序的規模和複雜性的增長，這些挑戰會變得越來越明顯和麻煩：
性能問題
即使是應用程序的一個頁面也可能需要對不同的微服務進行多次調用，這可能會導致較大的延遲和性能問題。
可伸縮性問題
因為客户端應用程序直接引用微服務，所以對微服務的任何更改都可能導致應用程序崩潰。這使得維護困難。
安全問題
沒有中間層，微服務的端點就會暴露出來。這不一定會使應用程序本身就不安全，但它肯定會使安全問題變得更難處理。
複雜性問題
此外，每個公共微服務都需要包含安全和其他跨服務任務。如果有一個額外的層，它們可以被包含在那裏，使所有的微服務更簡單。
由於微服務通常被推薦用於複雜的應用程序，因此必須有更具可伸縮性的模式。
API網關
當然有！API網關將這一切提升到一個級別。如下圖所述，它提供了一個額外的層，一組微服務和前端層之間的單一入口點。它解決了我們剛剛提到的所有問題，通過向公眾隱藏微服務的端點，從客户端抽象對微服務的引用，並通過聚合多個調用來減少延遲。
然而，API網關模式仍然不能避免可伸縮性問題。當體系結構圍繞一個客户機時，這已經足夠了。但是如果有多個客户端應用程序，API網關最終可能會膨脹，因為它吸收了來自不同客户端應用程序的所有不同需求。最終，它可能會成為一個單一的應用程序，並面臨許多與直接模式相同的問題。
因此，如果您計劃讓基於microservices的系統具有多個客户機或不同的業務域，那麼您應該從一開始就考慮使用前端後端模式。
前端的後端（BFF）
網關API本質上是BFF模式的變體。它還提供了微服務和客户端之間的附加層。但它不是單一的入口點，而是為每個客户機引入了多個網關。
使用BFF，您可以添加一個為每個客户機的需求量身打造的API，從而消除了由於將它們都放在一個地方而導致的大量膨脹。結果模式如下圖所示。
值得一提的是，這種特定的模式可能仍會擴展到特別複雜的應用程序。還可以為特定的業務域創建不同的網關。這個模型足夠靈活，可以響應任何類型的基於微服務的情況。
這是否意味着每個基於微服務的架構都應該使用BFF模式？不一定。設計越複雜，需要的設置和配置就越多。並不是每個應用程序都需要這樣做。但是如果你想創建一個應用程序的生態系統，或者計劃在將來擴展它，為了將來的可擴展性，你可以選擇更復雜的通信模式。