譯者注：本文將是您了解和評估何時以及如何采納服務網格的最佳參考資料。本文采訪了服務網格的締造者Buoyant創始人，Isito的產品經理，Enovy架構師Matt Klein等人，分別就誰應該何時以何種方式采納服務網格給出了意見并展望了服務網格的未來。

容器是IT行業的超級英雄，它與服務網格是最佳組合。它們聯手對抗混亂的網絡管理。

容器和微服務出現催生了一種稱為服務網格的新型網絡架構范例，但 IT 觀察家們對它是否能夠廣泛應用到生產上持有不同意見。

服務網格使用一個稱為 sidecar 的代理，它是附加在應用程序旁、虛擬機或運行在 Kubernetes 的 pod 中的容器，具體運行在哪里取決于所使用的服務網格的類型。然后，該代理可以連接到集中式的控制平面軟件，這些軟件收集細粒度的網絡遙測數據，應用網絡管理策略或更改代理配置，建立并執行網絡安全策略。

IT系統中的服務網格架構還處于初期階段，但與容器一樣它上升的很快。在 2017 年 12 月云原生計算基金會（CNCF）舉辦的 KubeCon 和 CloudNativeCon 上，服務網格已經取代容器成為 DevOps 前沿最熱門的話題。

“我們經常發現自己在構建應用軟件時，我們實際上在做的是一遍又一遍地編寫相同的代碼來解決某些實際上非常困難的計算機科學問題，這些問題應該被考慮到某種通用接口中”，微服務監控創業公司 LightStep 首席執行官 Ben Sigelman 在 KubeCon 的服務網格主題演講中表示。

“服務網格可以用來做發現服務、服務連接、斷路、負載均衡......安全和身份驗證” , Sigelman說，他是前谷歌工程師，OpenTracing 的創建者，OpenTracing 是開源的，提供供應商無關的 API。

服務網格簡史

最早版本的 sidecar 代理技術在 2016 年初開始出現在如谷歌和推特的網絡商店，微服務管理需要對網絡進行新的思考。與傳統的單體應用程序不同，微服務依靠外部網絡來溝通和協調應用程序功能。這些微服務通信需要密切監控，有時需要大規模重新配置。

用于微服務網絡管理自動化最早的技術依賴于庫，作為應用程序代碼的一部分進行部署，如 Netflix 的 Hystrix。因此，開發人員需要進行網絡管理。這些庫也必須用特定環境中使用的每種應用程序語言編寫。這提出了一個難題，因為微服務精神的一個主要原則是小團隊可以自由地使用任何語言進行獨立的服務管理。

大多數認為自己正在使用微服務的組織并沒有真正做到微服務?！?strong>Anne Thomas，Gartner 分析師

在 2016 年初，第一批在 Twitter 上實施微服務的工程師成立了 Buoyant 公司，該公司采用 sidecar 代理方法替代應用程序庫。Buoyant 在 2016 年年中創造了Service Mesh這個術語，其最初的服務網格產品 Linkerd 使用 Java 虛擬機（JVM）作為 sidecar，這種設計將網絡管理負擔從應用程序開發人員轉移出來，并支持對多語言的集中管理應用網絡。到目前為止，Linkerd 是主流企業級 IT 商店中唯一上生產環境的服務網格架構。使用的客戶包括 Salesforce、PayPal、Credit Karma、Expedia 和 AOL。

Linkerd 剛剛站穩了腳跟，Docker 容器和 Kubernetes 容器編排又將 Buoyant 工程師送回了原點。終于在2017 年 12 月，該公司發布了 Conduit，一種基于輕量級容器代理的服務網格架構，而不是 Linkerd 中使用的耗資源的 JVM。它專門用于與 Go 和 Rust 應用程序語言組合使用的 Kubernetes 。

Kubernetes 社區正在為 Go 編寫輕量級服務，可能需要 20 MB 或 50 MB 的內存才能運行，而 Linkerd 的 JVM 可能會占用 200 MB 的內存，對于 Kubernetes 愛好者來說這是一個矛盾點，William Morgan——Buoyant 的聯合創始人兼首席執行官這樣說。

Morgan 說：“為此消耗大量內存是不最理想的，特別是其價值主張是成為開發人員不必擔心的底層基礎架構的一部分時。

但就在 2017 年初 Buoyant 工程師開始重新考慮其服務網格架構時，Kubernetes 的創造者谷歌和重量級技術公司 IBM 聯手 Lyft 公司的 Envory 創建了 Istio。鑒于其支持者的聲譽和谷歌內部管理大規?；谌萜鞯奈⒎盏慕涷?#xff0c;這種基于容器的服務網格引起了業界的廣泛關注。Google 基于其內部的服務控制工具向 Istio 提供控制平面軟件，而 IBM 則添加了控制平面工具 Amalgam8。Istio 是基于 Lyft 的 Envoy sidecar 代理，該公司是為了控制平面接收命令而建立的。它可以動態讀取到 sidecar 的配置更新，而無需重啟 。

Istio 的支持者正在與 Kubernetes 所在的 CNCF 進行長期管理談判。他們計劃在 2018 年第三季度發布 1.0 版本。

到目前為止，Linkerd 和 Istio 已經成為這個新興市場中最具影響力的項目，但是還有很多服務網格架構項目正在進行中，包括開源和專有選項。這些項目中有許多是基于 Envoy sidecar。Nginx 基于其 Nginx Plus代理引入了自己的集中式管理控制平面。其他早期的服務網格希望包括 Turbine Labs 的 Houston、Datawire 的 Ambassador、Heptio 的 Contour、Solo.io 的 Gloo 和 Tigera 的 CNX。

誰需要服務網格？

現在判斷服務網絡架構在主流企業 IT 商店中的普及度還為時過早，這些 IT 商店不適用于 Twitter 或 Google 。

Gartner 分析師 Anne Thomas 表示，對于以有限方式使用容器的組織，現有的 API 網關、Kubernetes 或 PaaS 軟件（如 Docker Enterprise Edition 或 Cloud Foundry）的服務發現和網絡管理功能可能已經足以提供微服務支持。

“大多數認為自己正在實施微服務的組織并沒有真正做到真正的微服務 “，Thomas 說?！拔也幌嘈耪嬲奈⒎諏⒊蔀閭鹘y企業中的主流。”

服務網格允許您以集中的方式管理流量，這種方式可以讓屏蔽環境對技術的影響 ，我覺得這在任何規模上都很有用?！?strong>Zack Angelo BigCommerce 平臺工程總監

對 Thomas 來說，真正的微服務是盡可能獨立的。每個服務處理一個單獨的方法或領域功能；使用自己的獨立數據存儲；與其他微服務依靠基于異步事件的通信；并允許開發人員設計、開發、測試、部署和替換這個單獨的功能，而無需重新部署應用程序的任何其他部分。

“很多主流公司并不一定愿意花將大量的時間和金錢投入到應用架構上”，Thomas 爭辯道?！八麄內匀辉谝愿至６鹊姆绞阶鍪虑也粫褂梅站W格，至少在網格以服務的方式添加到平臺，或者在出現新型開發框架之前“。

很多服務網格的早期用戶認為并不一定需要有大量的微服務才能從該技術中受益 。

“它可以讓你以集中的方式管理流量，流量在不同的環境和技術中是一致的，我覺得這在任何規模上都很有用”，位于德克薩斯州奧斯汀的電子商務公司 BigCommerce 的平臺工程主管 Zack Angelo 這樣說，他們使用 Linkerd 服務網格?！凹词鼓阒挥惺畮讉€服務，這也是非常有用的功能”。

Angelo 說，傳統的網絡管理概念，例如負載均衡器，無法按微小的百分比把流量路由到某些節點 ，以便進行金絲雀或藍/綠發布。傳統的網絡監控工具也不提供服務網格所提供的那種細粒度的遙測數據，能夠跟蹤 99% 的應用程序延遲中的微小異常，其重要性在微服務網絡中被放大。

Linkerd 的負載均衡模式使用了一種稱為指數加權移動平均的技術，以便當服務網格跨主機分配網絡流量時，它會考慮下游服務響應的速度，然后將流量路由到服務性能最佳的地方，而不是傳統循環負載均衡技術。

獲取實時數據并為每位用戶提供個性化體驗這很重要。 Jennifer Lin——Google 的 Istio 產品總監

“我們的應用分布在多個數據中心，很高興能夠將該技術內置到我們的負載均衡器中，它能自動感知并選擇最快的網絡路徑 ”。Angelo 說?！皬墓收限D移的角度來看，這對我們也很重要”。

并不是說使用服務網絡時不需要權衡 ，特別是當涉及到 IT 運維人員不熟悉高級網絡概念管理的復雜性時。Angelo 表示，如果管理不當，集中式控制平面可能會成為單點故障，盡管企業可以通過在其服務網格設計中增加彈性來降低這種風險。

“如果在服務發現中發生了某些不好的事情，向 Linkerd 節點提供陳舊的數據或其他內容，負載均衡池中存在錯誤的主機，則即使服務發現信息不正確，Linkerd 失敗算法也會將其從池中取出，這真是太棒了“，Angelo 說。

其他公司看好 Istio 的集中化網絡監控功能，計劃在 Istio 進入 GA 狀態后跟進。

“我們仍然有 PHP、Node 和 Go 中程序代碼，以及三種不同的方式來收集日志，監控服務和運行狀態”，Harrison Harnisch說道，他是一名位于芝加哥的Buffer公司員工，該公司提供一個美國的分布式社交媒體管理平臺?！钡绻覀兡軌蛲ㄟ^服務網絡獲得所有內容，我們就可以使用相同的模式進行日志記錄，并構建模板 dashboard 以便跨團隊共享，這在現在很難做到” 。

Istio 創造者對服務網格未來的展望

即使在銀行業等傳統行業中，開發人員也在創建復雜的面向消費者的應用程序，這些應用程序看起來更像是Google 這樣的大規模的網絡應用程序。

“重要的是，他們有實時數據，并且他們為每個用戶提供個性化體驗”，谷歌 Istio 產品管理總監 Jennifer Lin 說?！斑@需要一個更細粒度的服務集，允許這些創新的應用程序以安全的方式以極低的延遲處理大規模的流量 ” 。

IBM 工程師 Daniel Berg 說，精細的流量路由和安全策略也將成為 IBM 推出的基于 Istio 的混合云概念的關鍵組成部分，并將用于管理私有云和公有云中的微服務。

“客戶將需要一個網格來幫助組織和管理傳統應用向云原生應用程序之間轉換所帶來的復雜性 ”， Berg 說?！叭绻_始一將網格作為應用程序的一部分，當您將其移植到另一個未使用該網格的供應商中時，盡管它仍可以運行，但會得到完全無法預期的結果，這種做法是不可取的“。

但 Envoy 的高級軟件工程師 Matt Klein 表示，主流企業最有可能等到服務網格成為公有云容器服務和 PaaS 產品的一部分時才開始真正使用它，這與 Gartner 的 Thomas 的預測相呼應 。

“你可以想象它可以像 AWS Fargate 那樣工作，為每個用戶函數或容器旁自動注入一個如 Envoy 這樣的代理，而且用戶只需要了解這些功能而無需關心它們是如何實現的“ ，Klein 說?！八鼈兛梢垣@得服務網格提供功能，但對那到底是不是服務網格并不重要 ”。

Klein 說，也有人猜測過度到這種狀態服務需要多長時間。

Klein 說：“在公共云中某種技術成熟大約需要 10 到 20 年的時間 ，對于像微軟 Azure、Google 云平臺和亞馬遜這樣百年企業，我們正處于該過程的初級階段”。

總結

以上是生活随笔為你收集整理的服务网格架构激活了容器网络管理—来自于服务网格创建者们的见解与展望的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。