點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

軟件行業走了很長一段路，在整個過程中，軟件體系結構也已經發展了很多。經歷了1層（單節點），2層（客戶端/服務器），3層和分布式，我們在此過程中看到了一些不同的軟件架構模式。

微服務面臨的挑戰

大多數軟件公司，正從單體架構(Monolithic)過渡到微服務架構(Microservices)，而微服務架構(Microservices)也正在逐步接管軟件行業。單體架構雖然有很多好處，但在滿足現代軟件開發需求時也有很多缺點。

微服務架構使我們能夠更頻繁，更獨立地部署應用程序，并可靠地滿足現代軟件應用程序開發要求。

將單體應用分解為微服務應用

微服務架構幾乎解決了單體架構的所有缺點。微服務提供了故障隔離，滿足應用更小，更快的部署，具備應用的可伸縮性，使得不同服務可以采用不同的開發技術，提高了開發效率，滿足了以業務為中心的需求。

盡管微服務架構相對于其他架構具有許多優勢，但它也面臨著一系列挑戰。在微服務體系結構中，它必須處理與設計分布式系統時遇到的問題。

微服務架構背后的思想是，我們將擁有多個獨立的較小服務集，每個服務提供單獨的業務功能，而不是擁有一個大型的單個代碼庫。通過這種方法，現代軟件應用程序將需要幾十個、甚至數百個單獨服務的協同工作。

通過微服務架構，引入了網絡依賴，并引發了可靠性問題。網絡可靠性，延遲，帶寬和網絡安全性，是我們必須處理的一些與網絡相關的挑戰。

在服務之間實現通信也將是一項艱巨的任務。隨著服務數量的增加，我們必須處理它們之間的交互。除了服務之間的通信外，我們還必須處理整個系統運行狀況的監視，容錯，日志記錄和遙測功能，處理多點故障等等。使用微服務架構，由于我們必須處理許多服務間通信和基礎網絡，因此調試問題可能會更加棘手。

隨著基于第三方類庫和組件的引入，克服了與微服務體系結構有關的上述挑戰，每個服務也都具備了這些通用功能（監視，運行狀況檢查，日志記錄，遙測等），使得服務到服務的通信順暢且可靠。但是，將這些功能整合到每一項服務中，這在開發和維護上都需要付出很多努力。

開發人員使用第三方類庫和組件（例如Eureka，Ribbon，Hystrix）來提供這些通用功能，例如服務發現，負載均衡，斷路器，日志記錄和度量，遙測等。

結合了業務功能和網絡相關功能的微服務

但是，使用第三方庫和組件會帶來一系列不同的挑戰，例如：

• 緊密耦合-這些第三方庫/組件的編碼和配置與服務中的業務功能緊密相關。現在，應用程序代碼是業務功能和這些其他庫/組件配置的混合。

• 編碼/配置的復雜性增加-使用的第三方庫/組件，可能必須使用不同的編程和配置語言集

• 可維護性差—每當這些外部庫/組件升級時，我們都必須更新應用程序代碼，對其進行驗證并部署這些更改

• 調試/故障排除復雜度增加-現在服務是與第三方庫/組件的混合，如果出現應用故障，開發人員必須花費大量時間來了解代碼并排查問題

沒有服務網格體系結構的微服務

盡管微服務架構提供了很多好處，但是開發人員在面對上述挑戰時也面臨很多困難。這些挑戰促使開發人員找到了更好的替代方案–Service Mesh(服務網格)。

微服務的解決方案

服務網格可以定義為處理微服務架構中服務間通信的專用基礎結構層，從而降低了上述挑戰帶來的復雜性。Service Mesh使我們能夠成功，高效地運行分布式微服務架構，并提供保護，連接和監視微服務的統一方法。

服務網格背后的想法非常簡單。不要在服務代碼中增加其他與基礎架構/網絡相關的細節，而讓它僅關注其必須執行的業務功能。

通常，Service Mesh提供以下功能：

• 負載均衡

• 服務發現

• 健康檢查

• 認證方式

• 流量管理和路由

• 斷路器和故障轉移

• 安全管理

• 指標收集和監控

• 故障注入

有了Service Mesh，我們不必使用任何第三方庫/組件，就可以在每個微服務中提供與網絡相關的通用功能，例如配置，路由，遙測，記錄，斷路等。Service Mesh將把那些與網絡相關的通用功能抽象/外部化為一個單獨的組件/層，稱為“服務代理”。

服務網格將應用程序中使用第三方庫/組件的復雜性解耦。

現在，開發人員可以根據與應用程序或網絡相關的問題輕松排查任何問題的根本原因，從而使他們的生活變得異常便捷。借助Service Mesh架構，業務功能和與網絡相關的功能之間的職責分工清晰。

具有服務代理(Sidecar)的微服務

通常，Sidecar模式用于實現服務網格體系結構。在這種模式下，我們可以在服務旁邊部署服務網格代理。服務代理的Sidecar將復雜性從應用程序中抽象出來，并處理服務發現，流量管理，負載均衡，斷路器等功能。

具有服務網格架構的基于微服務的解決方案

總而言之，采用基于服務網格架構的微服務，開發人員：

• 無需擔心使用任何第三方庫/組件來提供與網絡相關的功能

• 所有服務到服務的通信將通過稱為“服務代理”的組件/層，因此我們不必在每個服務中都實現它

• 將業務功能與與網絡相關的功能分離

• 僅關注業務功能，而無需擔心與網絡相關的基礎功能，讓服務網格為你處理

• 無需擔心服務網格的開發，因為服務網格基于開放標準，例如HTTP，TCP，RPC，gRPC等。

結論

微服務架構由于其優于其他架構模式的優勢，正在積極地控制軟件工程行業。隨著越來越多的組織從單體架構過渡到微服務架構，作為開發人員，我們需要了解微服務架構中的挑戰并找到解決方法。Service Mesh架構解決了微服務架構引入遇到的一些挑戰。

現在我們知道了服務網格在微服務架構中的作用和重要性，下面讓我們看一下可以在下一次開發活動中使用的服務網格產品/平臺。Linkerd， Envoy Proxy， Istio， Consul， Kuma和 Open Service Mesh（OSM）是我們可以使用的一些領先的開源的Service Mesh平臺。它們中的大多數經過了大量測試，可以投入生產使用。

譯者：王延飛

譯文鏈接：https://dzone.com/articles/the-service-mesh-in-the-microservices-world

想知道更多？掃描下面的二維碼關注我

后臺回復"技術"，加入技術群

【精彩推薦】

• 超清晰的DNS入門指南

• 如何用ELK搭建TB級的日志系統

• 深度好文：Linux系統內存知識

• 日志采集系統都用到哪些技術？

• 面試官：為什么HashMap的加載因子是0.75？

• 原創|OpenAPI標準規范

• 如此簡單| ES最全詳細使用教程

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解
  

點個贊+在看，少個 bug?????

總結

以上是生活随笔為你收集整理的微服务的下一步，离不开服务网格的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。