2018年Service Mesh 元年，被譽為是下一代微服務架構

微服務適用於開發運維（DevOps），可是這些架構依賴的服務到服務通信在生產環境下運行和管理起來很複雜。這時候Service Mesh閃亮登場了：這是企業擴展、保護和監控應用程序的最佳方式。

Service Mesh是一個專用的軟體基礎設施層，用於控制和監控微服務應用程序中服務到服務的內部通信，讓服務到服務通信變得快速、安全和可靠。它通常表現為「數據平面」和「控制平面」。在這種模式下，開發者（「服務所有者」）並不意識到Service Mesh的存在，而運營者（「平台工程師」）被賦予一套新的工具，以確保可靠性、安全性和可見性。如果你在構建雲本地應用程序，就需要Service Mesh。

不妨把Service Mesh看成是用路由器和交換機互聯的設備組成的網路，只不過在這裡，網路存在於應用層（第7層），節點是服務，路由、交付及其他任務卸載給Service Mesh。目的在於，面對這個微服務Mesh，以一種可靠、安全、及時的方式獲得請求。這通常是使用「代理」以攔截所有進出的網路流量來實現的。Service Mesh架構中的代理是使用邊車（sidecar）模式來實施的：邊車在概念上附屬於主（或父）應用程序，提供平台功能以補充該父應用程序。藉助這種模式，你的微服務就可以將邊車用作同一個微服務容器裡面的一組進程，也可以用作其自個容器中的邊車，充分利用平台功能，比如路由、負載均衡、彈性、深度監控和訪問控制。

與開發團隊和運維團隊交流後，這一點很明顯：微服務有助於加快開發速度，但是這種架構面臨的複雜性和風險在於微服務依賴的服務到服務通信。Service Mesh是一種應用程序優先的方法，它為微服務提供了一種通信結構（fabric），為DevOps團隊提供了它們所需的靈活性和自主性，同時為運維團隊提供了生產級應用程序方面所需的策略、可見性和洞察力，以便深入了解微服務環境。

Service Mesh提供了一種強大的微服務通信結構，為擴展容器化應用程序提供了最佳途徑，無論應用程序在數據中心還是在雲（或兩者兼而有之）。最近還興起了企業級Mesh，以滿足企業生產環境的需求，應對其複雜性。Service Mesh不僅需要擴展應用程序，還需要監控和保護應用程序。一套受到支持的基礎設施讓DevOps團隊擁有所需的靈活性和自主性，同時為運維團隊提供了生產級應用程序方面所需的策略、可見性和洞察力，以便深入了解微服務。

Service Mesh的優點

不妨考慮一下貴企業在微服務方面的計劃。也許貴企業打算在Kubernetes集群中運行10個服務、50個服務、100個服務或1000個服務。那麼如何以一種高效而統一的方式在新的微服務和容器環境中管理所有那些服務？

你知道哪個服務在跟哪個服務聯繫、是否允許它們這樣？這種通信是否安全？出現故障時，你如何來調試某個服務？如何在不影響所有應用程序的情況下添加跟蹤或日誌功能？你知道發布其中一個服務的新版本對上下游服務的性能或質量有何影響嗎？

Service Mesh有助於回答那些問題。作為插入在微服務和網路之間的一個透明的基礎設施層，它為你在應用程序的通信路徑中提供了單一點，以便插入服務、收集遙測數據。你無需更改應用程序就可以做到這一點。

2018年：Service Mesh元年

Service Mesh是個比較新的概念。實際上，在2017年12月的KubeCon大會上宣布2018年是「ServiceMesh元年」之前，大多數人從來沒有聽說過Service Mesh這個概念。現在市面上有幾種開源產品，幾家公司在完善受到支持的Mesh，以便減輕管理微服務的負擔。Service Mesh如何讓企業組織能夠進一步利用容器和微服務值得拭目以待。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！