大家都在說的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代理，将一個代理執行個體和每個容器綁定的微服務耦合在一起。這樣一來，它所帶來的好處大于營運成本，這也意味着服務網格對于小型環境來說通常過于龐大了。