微服務體系結構是軟件開發中最熱門的趨勢之一。作為CTO，你需要知道何時使用它們。但你也需要對這個主題有更深入的了解才能真正掌握你的項目。通過進一步了解微服務中的設計模式，您将确切了解微服務是如何工作的，以及開發人員如何使它們更高效、可伸縮和更安全。滿足最流行的微服務設計模式。

在上一篇關于微服務的文章中，我們介紹了這種流行的軟件體系結構的基礎知識。有了這些知識，您就知道微服務最适合哪種項目了。但是一旦你決定去做它，會有更多的決定要做。這就是為什麼你應該學習設計模式。

如您所知，微服務是一個很大程度上獨立的應用程序組件，其任務是系統中的特定功能。多個微服務，每個微服務負責應用程序的另一個功能，再加上客戶端（例如web和移動應用程序的前端）和其他（可選）中間層，構成了基于微服務的體系結構。

這種類型的設置有許多優點，例如能夠用不同的技術編寫任何服務并獨立地部署它們，以及性能提升等等。但它也帶來了一些挑戰，包括複雜的管理和配置。

設計模式的存在旨在解決微服務中的此類常見挑戰，并提供經驗證的解決方案，使您的體系結構更高效，整個管理過程更省錢、更麻煩。因此，了解它們是更好地理解微服務的一個很好的方法——比實際的編碼更高層次，但又足夠具體，可以理解微服務的内部工作原理。

選擇正确的設計模式可以決定你的基于微服務的項目的成敗。它們是微服務本身并不是萬能藥的最好證明，要真正從中受益，你需要正确地使用它們。

如果您不關心微服務設計模式：

• 你的應用程序可能表現不佳（由于不必要的調用和資源使用效率低下），
• 整個系統将不穩定（例如連接和集成問題），
• 它可能面臨可伸縮性問題（添加更多的服務可能導緻難以維護依賴性，甚至可能使其成為事實上的一個整體），
• 它可能會通過向公衆公開微服務的端點或通過其他方式危害安全性。
• 您可能有更多的維護和調試工作要做，而不是做更好的準備。

微服務中的設計模式幾乎存在于架構的每個方面。一些最重要的問題可分為以下幾個方面：

通信

它涉及微服務和客戶端應用程序（前端層）之間的通信方法。

内部溝通

這些設計模式構成了微服務之間進行通信的各種方式。

安全

各種與安全相關的問題，如安全層的組織、不同類型用戶對特定微服務的授權和訪問級别等。

可用性

确保所有的微服務都準備好滿足系統的需求（不管流量有多大），确保盡可能少的停機時間。這包括确保微服務可以在另一台計算機上重新啟動，或者是否有足夠的計算機可用，微服務能夠自行報告其當前狀态，運行狀況檢查等等。

服務發現

它指的是微服務用來找到彼此并知道它們的位置的方法。

配置

設置參數并監控整個系統的性能，以便在您進行過程中不斷優化

在本文的後續部分中，我們将主要關注第一種類型，讨論三種最流行的通信模式——直接模式、API網關和前端後端（BFF）。它們提供了一個很好的機會來了解基于微服務的體系結構是如何工作的，以及開發人員的選擇對其性能的影響。

這是基于微服務架構的最基本的設置。在這種模式下，客戶端應用程序直接向微服務發出請求，如下圖所示。每個微服務都有一個公共端點（URL），客戶端可以與之通信。

這非常容易設置，對于相對較小的應用程序來說已經足夠了，但是随着應用程序的規模和複雜性的增長，這些挑戰會變得越來越明顯和麻煩：

性能問題

即使是應用程序的一個頁面也可能需要對不同的微服務進行多次調用，這可能會導緻較大的延遲和性能問題。

可伸縮性問題

因為客戶端應用程序直接引用微服務，所以對微服務的任何更改都可能導緻應用程序崩潰。這使得維護困難。

安全問題

沒有中間層，微服務的端點就會暴露出來。這不一定會使應用程序本身就不安全，但它肯定會使安全問題變得更難處理。

複雜性問題

此外，每個公共微服務都需要包含安全和其他跨服務任務。如果有一個額外的層，它們可以被包含在那裡，使所有的微服務更簡單。

由于微服務通常被推薦用于複雜的應用程序，因此必須有更具可伸縮性的模式。

當然有！API網關将這一切提升到一個級别。如下圖所述，它提供了一個額外的層，一組微服務和前端層之間的單一入口點。它解決了我們剛剛提到的所有問題，通過向公衆隐藏微服務的端點，從客戶端抽象對微服務的引用，并通過聚合多個調用來減少延遲。

然而，API網關模式仍然不能避免可伸縮性問題。當體系結構圍繞一個客戶機時，這已經足夠了。但是如果有多個客戶端應用程序，API網關最終可能會膨脹，因為它吸收了來自不同客戶端應用程序的所有不同需求。最終，它可能會成為一個單一的應用程序，并面臨許多與直接模式相同的問題。

因此，如果您計劃讓基于microservices的系統具有多個客戶機或不同的業務域，那麼您應該從一開始就考慮使用前端後端模式。

網關API本質上是BFF模式的變體。它還提供了微服務和客戶端之間的附加層。但它不是單一的入口點，而是為每個客戶機引入了多個網關。

使用BFF，您可以添加一個為每個客戶機的需求量身打造的API，從而消除了由于将它們都放在一個地方而導緻的大量膨脹。結果模式如下圖所示。

值得一提的是，這種特定的模式可能仍會擴展到特别複雜的應用程序。還可以為特定的業務域創建不同的網關。這個模型足夠靈活，可以響應任何類型的基于微服務的情況。

這是否意味着每個基于微服務的架構都應該使用BFF模式？不一定。設計越複雜，需要的設置和配置就越多。并不是每個應用程序都需要這樣做。但是如果你想創建一個應用程序的生态系統，或者計劃在将來擴展它，為了将來的可擴展性，你可以選擇更複雜的通信模式。

如果你想了解更多關于BFF的信息，一定要閱讀我們的前端案例研究的後端——這是一個應用程序生态系統的故事，它是使用模式重塑的。

正如我前面提到的，設計模式存在于微服務的各個方面。開發人員常常被迫在這兩者之間做出選擇，考慮到不同的因素。在其他一些情況下，它們可以組合在一起或一起使用。

對于内部通信，一些最流行的模式包括REST、gRPC、messagebroker或遠程過程調用。在安全性方面，訪問控制列表（ACL）可以用于每個微服務或每個網關，也可以作為獨立的微服務（或者根本不使用）。說到可用性，我們可以使用基于DNS或硬件的負載平衡。服務發現可以在客戶端或服務器端執行。至于配置，可以是外部化的（每個微服務都有自己的一個）或集中化（所有配置都在一個地方）。名單還在繼續。

另請參閱：gRPC實用介紹

随着微服務越來越流行，新的設計模式出現了，以幫助解決各種開發挑戰，并使體系結構更加高效。盡可能多地了解它們是值得的，但歸根結底還是要為特定的軟件生态系統選擇正确的軟件。說到這一點-相信你的開發人員，但要确保你知道他們的選擇和他們對你的軟件的影響。

本文：http://jiagoushi.pro/node/1088

讨論：請加入知識星球【首席架構師圈】或者小号【jiagoushi_pro】

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!