微服務(或微服務架構)是壹種雲原生架構方法，其中單個應用由許多松散耦合的較小組件或服務組成，這些組件或服務可以獨立部署。
這些服務通常
盡管大多數關於微服務的討論都圍繞著架構定義和特征，但是它們的價值可以通過相當簡單的業務和組織優勢得到更普遍的理解:
微服務也可以用不是什麽來理解。
與微服務架構最常見的兩種比較是整體架構和面向服務的架構(SOA)。
微服務和單片架構的區別在於，微服務是由許多較小的、松散耦合的服務組成壹個應用，而不是大的、緊密耦合的應用的單片方法。
微服務和SOA的區別可能不太清楚。
雖然可以對微服務和SOA做壹個技術上的比較，尤其是圍繞企業服務總線(ESB)的作用，但是更容易把區別當成範圍之壹。
SOA是企業範圍內的努力，旨在標準化組織中所有Web服務相互通信和集成的方式，而微服務架構是特定於應用程序的。
微服務可能至少和開發人員壹樣受高管和項目負責人的歡迎。
這是微服務比較不尋常的特性之壹，因為架構熱情通常是留給軟件開發團隊的。
原因是微服務更好地反映了許多業務領導者想要建立和運行他們的團隊和開發過程的方式。
換句話說，微服務是壹個架構模型，可以更好的推廣所需的運營模型。
在IBM最近對超過65，438+0，200名開發人員和IT高管進行的壹項調查中，87%的微服務用戶同意采用微服務是值得的。
也許微服務最重要的特點是，因為服務更小，可以獨立部署，它不再需要國會的法案來改變壹行代碼或向應用程序添加新功能。
微服務為組織承諾了壹劑解毒劑，可以緩解與耗費大量時間的小變化相關的內心沮喪。
不需要博士學位。
看到或理解在計算機科學中提高速度和靈活性的更好方法的價值。
但是速度並不是以這種方式設計服務的唯壹價值。
壹種常見的新興組織模式是圍繞業務問題、服務或產品將跨職能團隊聚集在壹起。
微服務模型完全符合這壹趨勢，因為它使組織能夠圍繞壹項服務或壹組服務創建小型的跨職能團隊，並讓他們以敏捷的方式運行。
微服務的松耦合也為應用程序建立了壹定程度的故障隔離和更好的靈活性。
小規模的服務，加上清晰的邊界和溝通模式，讓新的團隊成員更容易理解代碼庫，並迅速為其做出貢獻——這在速度和員工士氣方面有明顯的好處。
在傳統的N層架構模式中，應用程序通常共享壹個公共堆棧，其中壹個大型關系數據庫支持整個應用程序。
這種方法有幾個明顯的缺點——最重要的壹個是，應用程序的每個組件都必須共享壹個公共的堆棧、數據模型和數據庫，即使有明確的、更好的工具來完成某些元素的工作。
它會導致糟糕的架構，並讓那些壹直意識到可以用更好更有效的方式來構建這些組件的開發人員感到沮喪。
相比之下，在微服務模型中，組件是獨立部署的，並通過REST、事件流和消息代理的某種組合進行通信，因此每個單獨服務的堆棧都可以針對該服務進行優化。
技術壹直在變化，隨著更理想的技術的發展，由多個更小的服務組成的應用程序變得更加容易和便宜。
使用微服務，您可以單獨部署單個服務，但也可以單獨擴展它們。好處是顯而易見的:如果做得正確，微服務比單片應用程序需要更少的基礎設施，因為它們只支持需要它的組件的精確擴展，而不是在單片應用程序的情況下擴展整個應用程序。
微服務的顯著優勢伴隨著巨大的挑戰。
從單壹架構到微服務意味著更多的管理復雜性-更多的服務，由更多的團隊創建並部署在更多的地方。
壹項服務中的問題可能會導致其他服務中的問題，或者被其他服務中的問題所導致。
日誌數據(用於監控和解決問題)要大得多，並且可能在服務之間不壹致。
新版本可能會導致向後兼容問題。
應用程序涉及更多的網絡連接，這意味著出現延遲和連接問題的機會更多。
DevOps方法可以解決其中的許多問題，但是采用DevOps有其自身的挑戰。
然而，這些挑戰並沒有阻止非采納者采納微服務——或者采納者深化他們的微服務承諾。
根據新的IBM調查數據，56%的當前非用戶可能或非常有可能在未來兩年內采用微服務，78%的當前微服務用戶可能會增加在微服務上的時間、金錢和精力投入。
微服務架構通常被描述為針對DevOps和持續集成/持續交付(CI/CD)進行了優化。在可以頻繁部署的小型服務的上下文中，原因很容易理解。
但另壹種看待微服務和DevOps關系的方式是，微服務架構實際上需要DevOps才能成功。
盡管單例應用程序有壹系列本文前面討論過的缺點，但它們的優點是它們不是壹個復雜的分布式系統，沒有多個活動部件和獨立的技術棧。
相比之下，鑒於微服務帶來的復雜性以及移動部件和依賴性的大量增加，在部署、監控和生命周期自動化方面沒有大量投入的情況下使用微服務是不明智的。
盡管幾乎任何現代工具或語言都可以在微服務架構中使用，但壹些核心工具已經成為微服務的基本邊界定義:
微服務的壹個關鍵要素是，它通常非常小。
(再多的代碼也不能決定壹個東西是不是微服務，但名字裏的“微”是有的。)
Docker在2013迎來現代容器時代的時候，也推出了與微服務關系最密切的計算模型。
因為單個容器沒有自己的操作系統開銷，所以它們比傳統虛擬機更小更輕，並且可以更快地啟動和關閉，這使得它們非常適合微服務架構中更小更輕的服務。
隨著服務和容器的激增，安排和管理大量的容器已經迅速成為關鍵挑戰之壹。
Kubernetes是壹個開源的容器編排平臺，因為它非常好，所以已經成為最流行的編排解決方案之壹。
微服務通常通過API進行通信，尤其是在狀態剛建立的時候。
雖然客戶端和服務確實可以直接相互通信，但是API網關通常是壹個有用的中間層，尤其是當應用程序中的服務數量隨著時間的推移而增加時。
API網關充當客戶端的反向代理，路由請求，將請求分散到多個服務中，並提供額外的安全性和身份驗證。
可以用來實現API網關的技術有很多，包括API管理平臺，但是如果用container和Kubernetes來實現微服務架構的話，通常是用Ingress或者最近的Istio來實現網關。
盡管最佳實踐可能是設計無狀態服務，但是狀態仍然存在，服務需要理解它。
盡管API調用通常是為給定服務初始建立狀態的有效方法，但它不是保持狀態最新的特別有效的方法。
不斷地投票，“我們到了嗎？”保持服務最新的方法是不切實際的。
相反，需要將API調用與消息傳遞或事件流結合起來建立狀態，這樣服務就可以廣播狀態變化，其他相關方就可以監聽這些變化並做出相應的調整。
這項工作可能最適合壹般的消息代理，但在某些情況下，事件流平臺(如Apache Kafka)可能更適合。
通過將微服務與事件驅動架構相結合，開發者可以構建壹個分布式的、高可伸縮的、容錯的、可擴展的系統，該系統可以實時消費和處理大量的事件或信息。
無服務器架構從壹些核心雲和微服務模型中得出邏輯結論。
在沒有服務器的情況下，執行單元不只是壹個小服務，而是壹個函數，通常可以只是幾行代碼。
無服務器功能和微服務的分界線很模糊，但壹般認為功能比微服務小。
無服務器架構和FaaS平臺與微服務相似，它們都對創建更小的部署單元感興趣，並根據需求精確地擴展它們。
微服務不壹定與雲計算完全相關，但它們如此頻繁地結合有幾個重要原因——這些原因超出了微服務成為新應用程序流行的架構風格的原因和雲成為新應用程序流行的托管目的地的原因。
微服務架構的主要優勢之壹是與單獨部署和擴展組件相關的利用率和成本優勢。
雖然這些優勢在某種程度上仍然存在於本地基礎設施中，但是將小型、獨立和可擴展的組件與按需和按使用付費的基礎設施相結合，可以找到真正的成本優化。
其次，也許更重要的是，微服務的另壹個主要好處是，每個單獨的組件都可以采用最適合其特定工作的堆棧。
當您自己管理堆棧激增時，可能會導致嚴重的復雜性和開銷，但將支持堆棧用作雲服務可以大大減少管理挑戰。
換句話說，雖然推出自己的微服務基礎設施也不是不可以，但是不可取，尤其是剛開始的時候。
在微服務架構中，有許多常見和有用的設計、通信和集成模式，可以幫助解決壹些更常見的挑戰和機遇，包括:
例如，在桌面上使用的應用程序將具有與移動設備不同的屏幕尺寸、顯示和性能限制。
BFF模式允許開發人員使用界面的最佳選項為每個用戶界面創建和支持後端類型，而不是試圖支持適用於任何界面但可能會對前端性能產生負面影響的公共後端。
例如，在電子商務網站上，可以通過產品名稱、類型和價格來區分產品對象。
聚合是應被視為壹個單元的相關實體的集合。
因此，對於電子商務網站來說，訂單將是買方訂購的產品(實體)的集合。
這些模式用於以有意義的方式對數據進行分類。
在微服務架構中，服務實例會因擴展、升級、服務失敗甚至服務終止而動態變化。
這些模式提供了壹種發現機制來處理這種短暫性。
負載平衡可以使用服務發現模式，通過使用運行狀況檢查和服務故障作為觸發器來重新平衡流量。
適配器模式的目的是幫助翻譯不兼容的類或對象之間的關系。
依賴第三方API的應用程序可能需要使用適配器模式來確保應用程序和API可以通信。
這個花花綠綠的名字指的是藤蔓(微服務)如何隨著時間的推移慢慢超越並殺死壹棵樹(單個應用)。
雖然有許多模式可以很好地完成微服務，但相同數量的模式會很快讓任何開發團隊陷入困境。
其中壹些——重寫為微服務“不要”——如下:
壹旦應用程序變得太大，難以輕松更新和維護，微服務就是管理復雜性的壹種方式。
只有當妳感覺到單壹架構的痛苦和復雜性開始蔓延時，才值得考慮如何將應用重構為更小的服務。
在妳感受到那種痛苦之前，妳甚至沒有真正擁有壹個需要重建的單體。
試圖在沒有a)適當的部署和監控自動化或b)托管雲服務來支持您的龐大異構基礎架構的情況下做微服務，會帶來很多不必要的麻煩。
給自己省事，這樣妳就可以把時間花在擔心上了。
最好傾向於較大的服務，然後僅當它們開始開發微服務解決方案的特征時才分離它們——也就是說，部署變得更加困難和緩慢，公共數據模型變得過於復雜，或者服務的不同部分具有不同的負載/規模需求。
微服務和SOA的區別在於，微服務項目通常涉及重構應用程序以使其更易於管理，而SOA則側重於改變IT服務在企業內部的工作方式。
壹個演變成SOA項目的微服務項目，可能會在自己的重壓下崩潰。
妳最好以妳能處理的速度開始，避免復雜性，盡可能多地使用現成的工具。