1. 首頁 > 生活百科 > >

什么是 微服務( 二 )

生活百科單體


新的 IBM 調查數據 顯示，56% 的當前非用戶可能或非?？赡茉谖磥韮赡陜炔捎梦⒎?，78% 的當前微服務用戶可能會增加他們在微服務上投入的時間、金錢和精力
微服務架構通常被描述為針對 DevOps 和持續集成/持續交付 (CI/CD) 進行了優化，在可以頻繁部署的小型服務的上下文中，原因很容易理解 。
但另一種看待微服務和 DevOps 之間關系的方式是，微服務架構實際上需要DevOps 才能成功 。
雖然單體應用程序具有本文前面討論過的一系列缺點，但它們的好處是它不是一個具有多個移動部件和獨立技術堆棧的復雜分布式系統 。
相比之下，鑒于微服務帶來的復雜性、移動部件和依賴項的大量增加，在部署、監控和生命周期自動化方面沒有大量投資的情況下使用微服務是不明智的 。
雖然幾乎任何現代工具或語言都可以在微服務架構中使用，但有一些核心工具已成為微服務必不可少的邊界定義：
微服務的關鍵要素之一是它通常非常小 。
（沒有任意數量的代碼可以確定某物是否是微服務，但名稱中的“微”就在那里 。）
當Docker在 2013 年迎來現代容器時代時，它還引入了與微服務最密切相關的計算模型 。
由于單個容器沒有自己的操作系統的開銷，它們比傳統的虛擬機更小更輕，并且可以更快地啟動和關閉，使其成為微服務架構中更小、更輕的服務的完美匹配.
隨著服務和容器的激增，編排和管理大量容器很快成為關鍵挑戰之一 。
Kubernetes是一個開源容器編排平臺，已成為最受歡迎的編排解決方案之一，因為它做得非常好 。
微服務通常通過 API 進行通信，尤其是在首次建立狀態時 。
雖然客戶端和服務確實可以直接相互通信，但 API 網關通常是一個有用的中間層，尤其是當應用程序中的服務數量隨著時間的推移而增長時 。
API 網關通過路由請求、跨多個服務扇出請求以及提供額外的安全性和身份驗證來充當客戶端的反向代理 。
有多種技術可用于實現 API 網關，包括 API 管理平臺，但如果使用容器和 Kubernetes 實現微服務架構，則網關通常使用 Ingress 或最近的Istio 來實現 。
雖然最佳實踐可能是設計無狀態服務，但狀態仍然存在，服務需要了解它 。
雖然 API 調用通常是為給定服務初始建立狀態的有效方式，但它并不是保持最新狀態的特別有效方式 。
不斷的輪詢，“我們到了嗎？” 保持服務最新的方法根本不切實際 。
相反，有必要將建立狀態的 API 調用與消息傳遞或事件流結合起來，以便服務可以廣播狀態的變化，而其他相關方可以監聽這些變化并進行相應的調整 。
這項工作可能最適合通用消息代理，但在某些情況下，事件流平臺（例如Apache Kafka）可能更適合 。
通過將微服務與事件驅動架構相結合，開發人員可以構建分布式、高度可擴展、容錯和可擴展的系統，可以實時消費和處理大量事件或信息 。
無服務器架構將一些核心云和微服務模式得出其合乎邏輯的結論 。
在無服務器的情況下，執行單元不僅僅是一個小服務，而是一個函數，它通常可以只是幾行代碼 。
將無服務器功能與微服務分開的界限很模糊，但通常認為功能比微服務還要小 。
無服務器架構和功能即服務 (FaaS)平臺與微服務的相似之處在于，它們都對創建更小的部署單元和根據需求精確擴展感興趣 。
微服務不一定與云計算完全相關，但它們如此頻繁地結合在一起有幾個重要原因——這些原因超越了微服務成為新應用程序的流行架構風格以及云成為新應用程序的流行托管目的地的原因 。
微服務架構的主要優勢之一是與單獨部署和擴展組件相關的利用率和成本優勢 。
雖然這些優勢在一定程度上仍然存在于本地基礎設施中，但小型、獨立可擴展的組件與按需、按使用付費的基礎設施相結合是可以找到真正成本優化的地方 。
其次，也許更重要的是，微服務的另一個主要好處是每個單獨的組件都可以采用最適合其特定工作的堆棧 。
當您自己管理堆棧擴散時，可能會導致嚴重的復雜性和開銷，但是將支持堆棧作為云服務使用可以大大減少管理挑戰 。
換句話說，雖然推出自己的微服務基礎設施并非不可能，但不可取，尤其是剛開始時 。
在微服務架構中，有許多常見且有用的設計、通信和集成模式有助于解決一些更常見的挑戰和機遇，包括：
例如，在桌面上使用的應用程序將具有與移動設備不同的屏幕尺寸、顯示和性能限制 。

推薦閱讀