點擊上方「朱小廝的博客」，選擇「設爲星標」面試
後臺回覆"書"，獲取編程
軟件行業走了很長一段路，在整個過程當中，軟件體系結構也已經發展了不少。經歷了1層（單節點），2層（客戶端/服務器），3層和分佈式，咱們在此過程當中看到了一些不一樣的軟件架構模式。
安全
微服務面臨的挑戰
大多數軟件公司，正從單體架構(Monolithic)過渡到微服務架構(Microservices)，而微服務架構(Microservices)也正在逐步接管軟件行業。單體架構雖然有不少好處，但在知足現代軟件開發需求時也有不少缺點。服務器
微服務架構使咱們可以更頻繁，更獨立地部署應用程序，並可靠地知足現代軟件應用程序開發要求。網絡
將單體應用分解爲微服務應用架構
微服務架構幾乎解決了單體架構的全部缺點。微服務提供了故障隔離，知足應用更小，更快的部署，具有應用的可伸縮性，使得不一樣服務能夠採用不一樣的開發技術，提升了開發效率，知足了以業務爲中心的需求。負載均衡
儘管微服務架構相對於其餘架構具備許多優點，但它也面臨着一系列挑戰。在微服務體系結構中，它必須處理與設計分佈式系統時遇到的問題。分佈式
微服務架構背後的思想是，咱們將擁有多個獨立的較小服務集，每一個服務提供單獨的業務功能，而不是擁有一個大型的單個代碼庫。經過這種方法，現代軟件應用程序將須要幾十個、甚至數百個單獨服務的協同工做。ide
經過微服務架構，引入了網絡依賴，並引起了可靠性問題。網絡可靠性，延遲，帶寬和網絡安全性，是咱們必須處理的一些與網絡相關的挑戰。微服務
在服務之間實現通訊也將是一項艱鉅的任務。隨着服務數量的增長，咱們必須處理它們之間的交互。除了服務之間的通訊外，咱們還必須處理整個系統運行情況的監視，容錯，日誌記錄和遙測功能，處理多點故障等等。使用微服務架構，因爲咱們必須處理許多服務間通訊和基礎網絡，所以調試問題可能會更加棘手。
隨着基於第三方類庫和組件的引入，克服了與微服務體系結構有關的上述挑戰，每一個服務也都具有了這些通用功能（監視，運行情況檢查，日誌記錄，遙測等），使得服務到服務的通訊順暢且可靠。可是，將這些功能整合到每一項服務中，這在開發和維護上都須要付出不少努力。
開發人員使用第三方類庫和組件（例如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 ????