在對應用程式進行重構和更新的過程中，往往會出現一些挑戰。更新應用程式的頻率越高，複雜性就越是會增加。讓應用程式在容器平臺上執行，並且它們之間可以互相通訊和連線，是通向模組化的、靈活的微服務架構的必經之路。但是微服務的這種靈活性也讓其變得更加複雜。這時就輪到Service Mesh發揮作用了！
Service Mesh向企業提供了他們所需要的中心化控制面板，同時依然能夠使用靈活的、基於雲的應用程式開發方式。我們可以把Service Mesh看成是用於微服務API的專門的第7層網格，它提供身份驗證、授權、安全和效能服務來最佳化服務之間的“east/west”流量。更重要的是，它能為你提供應用到這些策略的中心點，而不需要直接將所有這些編碼到應用程式的業務邏輯中。
Service Mesh就像是城市的水管網路。你的團隊控制著這些管道，根據需要連線它們並設定它們之間所有的流控制。無論是何種型別或用途，又或是Service Mesh所支援的應用程式的需求在不斷變化，資料都可以透過你的系統進行傳遞。
這種流量控制可以在中心位置進行，也正是在中心位置構建規則，來管理那些相互連線的資料流。這就像是在天上的巨大控制室一樣，你可以在農作物需要額外資源時，給加利福尼亞州的土地澆水，又或是邁阿密那邊濕的太透了，你可以排乾它們。最重要的一點是，這些操作都是可以自動執行並且動態調整的。
Service Mesh提供從網路或服務故障處自動恢復過來的智慧流量路由功能，這樣就可以追蹤到整個堆疊的問題，甚至能追蹤到服務間的中斷。
如果伺服器沒有響應，你的服務網格將會把它從單個服務、或者是活躍的、負載均衡的服務池中剔除掉，轉移到另一個池中，該池經常會檢查是否可執行。當該伺服器在合理的時間範圍內開始響應時，它又會被自動push回活躍的負載均衡池中。
透過提供服務層系統各個方面的視覺化，Service Mesh還可以用來debug和最佳化系統。這樣微服務中的髒水問題（murky water）就解決了。隨著時間推移，系統可以進行調整來擴充套件功能，滿足效能和穩定性的需求。
當你的團隊推出應用程式的新版本，或是要將應用程式託管的叢集遷移到新的資料中心時，安全團隊通常需要重新頒發證書並授權給系統中新的伺服器。這會花費大量的時間和精力，是推動生產改進的阻礙。
有了服務網格，將服務間通訊的安全性交給網格處理，這些關註點從應用程式本身抽象了出來，由服務網格處理所有這些限制，比如哪些服務可以相互通訊、哪些系統可以訪問哪些服務，以及哪些使用者可以訪問哪些服務。因此，升級網格中的應用程式不需要重新分配安全資源。
這樣一來，還可以讓圍繞網路和服務間通訊的安全問題能從任何內部開發的業務邏輯中獨立出來。如果網路組建出現安全漏洞，服務網格會去處理圍繞安全更新的更改，而不是重新架構每個應用程式。這就消除了在進行安全更改和更新相關工作時出現的大量停機時間。
不過服務網格有一個（巨大的）潛在的缺點。它添加了額外的容器，事實上，它讓容器規模加倍了。大多數服務網格的實現使用了sidecar代理，將一個代理實體和每個容器系結的微服務耦合在一起。這樣一來，它所帶來的好處大於運營成本，這也意味著服務網格對於小型環境來說通常過於龐大了。
但是，如果你正在管理數十個甚至數百個獨立的微服務，不妨考慮服務網格。有了服務網格，你的團隊可以更好的跟蹤問題，確保服務的可用性，維護路由表的正確分佈。對這些大型環境，無論是在公共雲、在你的企業資料中心、還是在混合雲的實現上，它們是雲應用程式難題的最後一塊拼圖，也是將你的整個產業聯絡在一起的關鍵部分。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
朋友會在“發現-看一看”看到你“在看”的內容