你們都在說的Service Mesh，你什麼時候須要它？

在對應用程序進行重構和更新的過程當中，每每會出現一些挑戰。更新應用程序的頻率越高，複雜性就越是會增長。讓應用程序在容器平臺上運行，而且它們之間能夠互相通訊和鏈接，是通向模塊化的、靈活的微服務架構的必經之路。可是微服務的這種靈活性也讓其變得更加複雜。這時就輪到Service Mesh發揮做用了！

Service Mesh向企業提供了他們所須要的中心化控制面板，同時依然可以使用靈活的、基於雲的應用程序開發方式。咱們能夠把Service Mesh當作是用於微服務API的專門的第7層網格，它提供身份驗證、受權、安全和性能服務來優化服務之間的「east/west」流量。更重要的是，它能爲你提供應用到這些策略的中心點，而不須要直接將全部這些編碼到應用程序的業務邏輯中。

簡單的Service Mesh類比

Service Mesh就像是城市的水管網絡。你的團隊控制着這些管道，根據須要鏈接它們並設置它們之間全部的流控制。不管是何種類型或用途，又或是Service Mesh所支持的應用程序的需求在不斷變化，數據均可以經過你的系統進行傳遞。

這種流量控制能夠在中心位置進行，也正是在中心位置構建規則，來管理那些相互鏈接的數據流。這就像是在天上的巨大控制室同樣，你能夠在農做物須要額外資源時，給加利福尼亞州的土地澆水，又或是邁阿密那邊溼的太透了，你能夠排幹它們。最重要的一點是，這些操做都是能夠自動執行而且動態調整的。

Service Mesh加強了可靠性和可視化能力

Service Mesh提供從網絡或服務故障處自動恢復過來的智能流量路由功能，這樣就能夠追蹤到整個堆棧的問題，甚至能追蹤到服務間的中斷。

若是服務器沒有響應，你的服務網格將會把它從單個服務、或者是活躍的、負載均衡的服務池中剔除掉，轉移到另外一個池中，該池常常會檢查是否可運行。當該服務器在合理的時間範圍內開始響應時，它又會被自動push回活躍的負載均衡池中。

經過提供服務層系統各個方面的可視化，Service Mesh還能夠用來debug和優化系統。這樣微服務中的髒水問題（murky water）就解決了。隨着時間推移，系統能夠進行調整來擴展功能，知足性能和穩定性的需求。

Service Mesh保護服務間通訊

當你的團隊推出應用程序的新版本，或是要將應用程序託管的集羣遷移到新的數據中心時，安全團隊一般須要從新頒發證書並受權給系統中新的服務器。這會花費大量的時間和精力，是推進生產改進的阻礙。

有了服務網格，將服務間通訊的安全性交給網格處理，這些關注點從應用程序自己抽象了出來，由服務網格處理全部這些限制，好比哪些服務能夠相互通訊、哪些系統能夠訪問哪些服務，以及哪些用戶能夠訪問哪些服務。所以，升級網格中的應用程序不須要從新分配安全資源。

這樣一來，還可讓圍繞網絡和服務間通訊的安全問題能從任何內部開發的業務邏輯中獨立出來。若是網絡組建出現安全漏洞，服務網格會去處理圍繞安全更新的更改，而不是從新架構每一個應用程序。這就消除了在進行安全更改和更新相關工做時出現的大量停機時間。

研究大型微服務環境下的服務網格

不過服務網格有一個（巨大的）潛在的缺點。它添加了額外的容器，事實上，它讓容器規模加倍了。大多數服務網格的實現使用了sidecar代理，將一個代理實例和每一個容器綁定的微服務耦合在一塊兒。這樣一來，它所帶來的好處大於運營成本，這也意味着服務網格對於小型環境來講一般過於龐大了。

可是，若是你正在管理數十個甚至數百個獨立的微服務，不妨考慮服務網格。有了服務網格，你的團隊能夠更好的跟蹤問題，確保服務的可用性，維護路由表的正確分佈。對這些大型環境，不管是在公共雲、在你的企業數據中心、仍是在混合雲的實現上，它們是雲應用程序難題的最後一塊拼圖，也是將你的整個產業聯繫在一塊兒的關鍵部分。