微服務架構是一種方法，其中單個應用程序由許多松散耦合且可獨立部署的較小服務組成。

微服務（或微服務架構）是一種雲原生架構方法，其中單個應用程序由許多松散耦合且可獨立部署的較小組件或服務組成。

這些服務通常

• 擁有自己的技術棧，包括數據庫和數據管理模型；
• 通過REST API、事件流和消息代理的組合相互通信；
• 是按業務能力組織的，線分隔服務通常稱為有界上下文。

雖然關于微服務的大部分讨論都圍繞架構定義和特征展開，但它們的價值可以通過相當簡單的業務和組織優勢來更普遍地理解：

• 可以更輕松地更新代碼 - 無需觸及整個應用程序即可添加新特性或功能
• 團隊可以為不同的組件使用不同的堆棧和不同的編程語言。
• 組件可以相互獨立地擴展，從而減少與擴展整個應用程序相關的浪費和成本，因為單個功能可能面臨過多的負載。

微服務也可以通過它們不是什麼來理解。

與微服務架構最常進行的兩個比較是單體架構和面向服務的架構 (SOA)。

微服務和單體架構之間的區别在于，微服務由許多較小的、松散耦合的服務組成一個應用程序，而不是大型、緊密耦合的應用程序的單體方法

微服務和 SOA 之間的區别可能不太清楚。

雖然可以在微服務和 SOA 之間進行技術對比，尤其是圍繞企業服務總線 (ESB)的角色，但更容易将差異視為範圍之一。

SOA 是企業範圍内的一項努力，旨在标準化組織中所有 Web 服務相互通信和集成的方式，而微服務架構是特定于應用程序的。

微服務可能至少與開發人員一樣受高管和項目負責人的歡迎。

這是微服務更不尋常的特征之一，因為架構熱情通常是為軟件開發團隊保留的。

原因是微服務更好地反映了許多業務領導者希望構建和運行他們的團隊和開發流程的方式。

換句話說，微服務是一種架構模型，可以更好地促進所需的操作模型。

在IBM 最近對 1,200 多名開發人員和 IT 主管進行的一項調查中，87% 的微服務用戶同意微服務的采用是值得的。

也許微服務最重要的一個特點是，由于服務更小并且可以獨立部署，它不再需要國會的法案來更改一行代碼或在應用程序中添加新功能。

微服務向組織承諾提供一種解毒劑，以解決與需要大量時間的小改動相關的内心挫敗感。

它不需要博士學位。

在計算機科學中看到或理解一種更好地促進速度和敏捷性的方法的價值。

但速度并不是以這種方式設計服務的唯一價值。

一種常見的新興組織模型是圍繞業務問題、服務或産品将跨職能團隊聚集在一起。

微服務模型完全符合這一趨勢，因為它使組織能夠圍繞一個服務或一組服務創建小型、跨職能的團隊，并讓他們以敏捷的方式運行。

微服務的松散耦合還為應用程序建立了一定程度的故障隔離和更好的彈性。

服務的小規模，加上清晰的邊界和溝通模式，使新團隊成員更容易理解代碼庫并快速為其做出貢獻——在速度和員工士氣方面都有明顯的好處。

在傳統的 n 層架構模式中，應用程序通常共享一個公共堆棧，其中一個大型關系數據庫支持整個應用程序。

這種方法有幾個明顯的缺點——其中最重要的是應用程序的每個組件都必須共享一個公共堆棧、數據模型和數據庫，即使對于某些元素的工作有一個清晰、更好的工具。

它造成了糟糕的架構，并且對于那些不斷意識到構建這些組件的更好、更有效的方法是可用的開發人員來說是令人沮喪的。

相比之下，在微服務模型中，組件是獨立部署的，并通過 REST、事件流和消息代理的某種組合進行通信——因此每個單獨服務的堆棧都可以針對該服務進行優化。

技術一直在變化，由多個較小的服務組成的應用程序更容易和更便宜地随着更理想的技術發展而變得可用。

使用微服務，可以單獨部署單個服務，但也可以單獨擴展它們。由此産生的好處是顯而易見的：如果做得正确，微服務比單體應用程序需要更少的基礎設施，因為它們隻支持對需要它的組件進行精确擴展，而不是在單體應用程序的情況下對整個應用程序進行擴展。

微服務的顯着優勢伴随着重大挑戰。

從單體架構到微服務意味着更多的管理複雜性——更多的服務，由更多的團隊創建，部署在更多的地方。

一項服務中的問題可能會導緻或由其他服務中的問題引起。

日志數據（用于監控和解決問題）更加龐大，并且在服務之間可能不一緻。

新版本可能會導緻向後兼容性問題。

應用程序涉及更多的網絡連接，這意味着出現延遲和連接問題的機會更多。

DevOps 方法可以解決其中的許多問題，但 DevOps 的采用也有其自身的挑戰。

然而，這些挑戰并沒有阻止非采用者采用微服務——或者采用者深化他們的微服務承諾。

新的 IBM 調查數據 顯示，56% 的當前非用戶可能或非常可能在未來兩年内采用微服務，78% 的當前微服務用戶可能會增加他們在微服務上投入的時間、金錢和精力

微服務架構通常被描述為針對 DevOps 和持續集成/持續交付 (CI/CD) 進行了優化，在可以頻繁部署的小型服務的上下文中，原因很容易理解。

但另一種看待微服務和 DevOps 之間關系的方式是，微服務架構實際上需要DevOps 才能成功。

雖然單體應用程序具有本文前面讨論過的一系列缺點，但它們的好處是它不是一個具有多個移動部件和獨立技術堆棧的複雜分布式系統。

相比之下，鑒于微服務帶來的複雜性、移動部件和依賴項的大量增加，在部署、監控和生命周期自動化方面沒有大量投資的情況下使用微服務是不明智的。

雖然幾乎任何現代工具或語言都可以在微服務架構中使用，但有一些核心工具已成為微服務必不可少的邊界定義：

微服務的關鍵要素之一是它通常非常小。

（沒有任意數量的代碼可以确定某物是否是微服務，但名稱中的“微”就在那裡。）

當Docker在 2013 年迎來現代容器時代時，它還引入了與微服務最密切相關的計算模型。

由于單個容器沒有自己的操作系統的開銷，它們比傳統的虛拟機更小更輕，并且可以更快地啟動和關閉，使其成為微服務架構中更小、更輕的服務的完美匹配.

随着服務和容器的激增，編排和管理大量容器很快成為關鍵挑戰之一。

Kubernetes是一個開源容器編排平台，已成為最受歡迎的編排解決方案之一，因為它做得非常好。

微服務通常通過 API 進行通信，尤其是在首次建立狀态時。

雖然客戶端和服務确實可以直接相互通信，但 API 網關通常是一個有用的中間層，尤其是當應用程序中的服務數量随着時間的推移而增長時。

API 網關通過路由請求、跨多個服務扇出請求以及提供額外的安全性和身份驗證來充當客戶端的反向代理。

有多種技術可用于實現 API 網關，包括 API 管理平台，但如果使用容器和 Kubernetes 實現微服務架構，則網關通常使用 Ingress 或最近的Istio 來實現。

雖然最佳實踐可能是設計無狀态服務，但狀态仍然存在，服務需要了解它。

雖然 API 調用通常是為給定服務初始建立狀态的有效方式，但它并不是保持最新狀态的特别有效方式。

不斷的輪詢，“我們到了嗎？” 保持服務最新的方法根本不切實際。

相反，有必要将建立狀态的 API 調用與消息傳遞或事件流結合起來，以便服務可以廣播狀态的變化，而其他相關方可以監聽這些變化并進行相應的調整。

這項工作可能最适合通用消息代理，但在某些情況下，事件流平台（例如Apache Kafka）可能更适合。

通過将微服務與事件驅動架構相結合，開發人員可以構建分布式、高度可擴展、容錯和可擴展的系統，可以實時消費和處理大量事件或信息。

無服務器架構将一些核心雲和微服務模式得出其合乎邏輯的結論。

在無服務器的情況下，執行單元不僅僅是一個小服務，而是一個函數，它通常可以隻是幾行代碼。

将無服務器功能與微服務分開的界限很模糊，但通常認為功能比微服務還要小。

無服務器架構和功能即服務 (FaaS)平台與微服務的相似之處在于，它們都對創建更小的部署單元和根據需求精确擴展感興趣。

微服務不一定與雲計算完全相關，但它們如此頻繁地結合在一起有幾個重要原因——這些原因超越了微服務成為新應用程序的流行架構風格以及雲成為新應用程序的流行托管目的地的原因。

微服務架構的主要優勢之一是與單獨部署和擴展組件相關的利用率和成本優勢。

雖然這些優勢在一定程度上仍然存在于本地基礎設施中，但小型、獨立可擴展的組件與按需、按使用付費的基礎設施相結合是可以找到真正成本優化的地方。

其次，也許更重要的是，微服務的另一個主要好處是每個單獨的組件都可以采用最适合其特定工作的堆棧。

當您自己管理堆棧擴散時，可能會導緻嚴重的複雜性和開銷，但是将支持堆棧作為雲服務使用可以大大減少管理挑戰。

換句話說，雖然推出自己的微服務基礎設施并非不可能，但不可取，尤其是剛開始時。

在微服務架構中，有許多常見且有用的設計、通信和集成模式有助于解決一些更常見的挑戰和機遇，包括：

• 後端換前端 (BFF) 模式： 此模式在用戶體驗和體驗調用的資源之間插入一層。

例如，在桌面上使用的應用程序将具有與移動設備不同的屏幕尺寸、顯示和性能限制。

BFF 模式允許開發人員使用該界面的最佳選項為每個用戶界面創建和支持一種後端類型，而不是嘗試支持适用于任何界面但可能會對前端性能産生負面影響的通用後端。

• 實體和聚合模式： 實體是由其身份區分的對象。

例如，在電子商務網站上，産品對象可能通過産品名稱、類型和價格來區分。

聚合是應被視為一個單元的相關實體的集合。

因此，對于電子商務網站，訂單将是買家訂購的産品（實體）的集合（集合）。

這些模式用于以有意義的方式對數據進行分類。

• 服務發現模式： 這些幫助應用程序和服務找到彼此。

在微服務架構中，服務實例會因伸縮、升級、服務故障甚至服務終止而動态變化。

這些模式提供了發現機制來應對這種短暫性。

負載平衡可以通過使用健康檢查和服務故障作為重新平衡流量的觸發器來使用服務發現模式。

• 适配器微服務模式： 以您在旅行到另一個國家時使用的插頭适配器的方式來考慮适配器模式。

适配器模式的目的是幫助翻譯不兼容的類或對象之間的關系。

依賴第三方 API 的應用程序可能需要使用适配器模式來确保應用程序和 API 可以通信。

• 扼殺者應用程序模式： 這些模式有助于管理将單體應用程序重構為微服務應用程序。

這個色彩缤紛的名字指的是藤蔓（微服務）如何随着時間的推移慢慢地超越并扼殺一棵樹（單體應用程序）。

雖然有很多模式可以很好地完成微服務，但同樣數量的模式可以很快讓任何開發團隊陷入困境。

其中一些——改寫為微服務“不要”——如下：

• 微服務的第一條規則是，不要構建微服務：更準确地說，不要從微服務開始。

一旦應用程序變得太大且難以輕松更新和維護，微服務是一種管理複雜性的方法。

隻有當您感覺到單體架構的痛苦和複雜性開始蔓延時，才值得考慮如何将該應用程序重構為更小的服務。

在你感受到那種痛苦之前，你甚至沒有真正擁有需要重構的單體。

• 不要在沒有 DevOps 或雲服務的情況下做微服務：構建微服務意味着構建分布式系統，而分布式系統很難（如果你做出的選擇會讓它變得更加困難，它們尤其困難）。

嘗試在沒有 a) 适當的部署和監控自動化或 b) 托管雲服務來支持您現在龐大的異構基礎設施的情況下進行微服務，會帶來很多不必要的麻煩。

省去你自己的麻煩，這樣你就可以把時間花在擔心狀态上。

• 不要通過将微服務做得太小來制造太多的微服務：如果您對微服務中的“微”走得太遠，您很容易發現自己的開銷和複雜性超過了微服務架構的整體收益。

最好傾向于更大的服務，然後隻在它們開始開發微服務解決的特征時才将它們分開——即部署更改變得困難和緩慢，通用數據模型變得過于複雜，或者不同部分服務有不同的負載/規模要求。

• 不要将微服務變成 SOA：微服務和面向服務的架構 (SOA) 經常相互混淆，因為在最基本的層面上，它們都對構建可重用的單個組件感興趣，這些組件可以被其他應用程序使用。

微服務和 SOA 之間的區别在于，微服務項目通常涉及重構應用程序以便更易于管理，而 SOA 關注的是改變 IT 服務在企業範圍内的工作方式。

一個演變成 SOA 項目的微服務項目可能會因自身的重量而崩潰。

• 不要試圖成為 Netflix：在構建和管理占所有 Internet 流量的應用程序時，Netflix 是微服務架構的早期先驅之一——這是一場需要他們構建大量自定義代碼和普通應用程序不需要的服務。

你最好從一個你可以處理的速度開始，避免複雜性，并盡可能多地使用現成的工具。

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