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

容器是IT行業(yè)的超級英雄，它與服務網(wǎng)格是最佳組合。它們聯(lián)手對抗混亂的網(wǎng)絡管理。

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

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

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

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

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

服務網(wǎng)格簡史

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

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

大多數(shù)認為自己正在使用微服務的組織并沒有真正做到微服務。——Anne Thomas，Gartner 分析師

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

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

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

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

但就在 2017 年初 Buoyant 工程師開始重新考慮其服務網(wǎng)格架構時，Kubernetes 的創(chuàng)造者谷歌和重量級技術公司 IBM 聯(lián)手 Lyft 公司的 Envory 創(chuàng)建了 Istio。鑒于其支持者的聲譽和谷歌內部管理大規(guī)模基于容器的微服務的經(jīng)驗，這種基于容器的服務網(wǎng)格引起了業(yè)界的廣泛關注。Google 基于其內部的服務控制工具向 Istio 提供控制平面軟件，而 IBM 則添加了控制平面工具 Amalgam8。Istio 是基于 Lyft 的 Envoy sidecar 代理，該公司是為了控制平面接收命令而建立的。它可以動態(tài)讀取到 sidecar 的配置更新，而無需重啟 。

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

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

誰需要服務網(wǎng)格？

現(xiàn)在判斷服務網(wǎng)絡架構在主流企業(yè) IT 商店中的普及度還為時過早，這些 IT 商店不適用于 Twitter 或 Google 。

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

“大多數(shù)認為自己正在實施微服務的組織并沒有真正做到真正的微服務 “，Thomas 說。“我不相信真正的微服務將成為傳統(tǒng)企業(yè)中的主流。”

服務網(wǎng)格允許您以集中的方式管理流量，這種方式可以讓屏蔽環(huán)境對技術的影響 ，我覺得這在任何規(guī)模上都很有用。——Zack Angelo BigCommerce 平臺工程總監(jiān)

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

“很多主流公司并不一定愿意花將大量的時間和金錢投入到應用架構上”，Thomas 爭辯道。“他們仍然在以更粗粒度的方式做事且不會使用服務網(wǎng)格，至少在網(wǎng)格以服務的方式添加到平臺，或者在出現(xiàn)新型開發(fā)框架之前“。

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

“它可以讓你以集中的方式管理流量，流量在不同的環(huán)境和技術中是一致的，我覺得這在任何規(guī)模上都很有用”，位于德克薩斯州奧斯汀的電子商務公司 BigCommerce 的平臺工程主管 Zack Angelo 這樣說，他們使用 Linkerd 服務網(wǎng)格。“即使你只有十幾個服務，這也是非常有用的功能”。

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

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

獲取實時數(shù)據(jù)并為每位用戶提供個性化體驗這很重要。 Jennifer Lin——Google 的 Istio 產(chǎn)品總監(jiān)

“我們的應用分布在多個數(shù)據(jù)中心，很高興能夠將該技術內置到我們的負載均衡器中，它能自動感知并選擇最快的網(wǎng)絡路徑 ”。Angelo 說。“從故障轉移的角度來看，這對我們也很重要”。

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

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

其他公司看好 Istio 的集中化網(wǎng)絡監(jiān)控功能，計劃在 Istio 進入 GA 狀態(tài)后跟進。

“我們仍然有 PHP、Node 和 Go 中程序代碼，以及三種不同的方式來收集日志，監(jiān)控服務和運行狀態(tài)”，Harrison Harnisch說道，他是一名位于芝加哥的Buffer公司員工，該公司提供一個美國的分布式社交媒體管理平臺。”但如果我們能夠通過服務網(wǎng)絡獲得所有內容，我們就可以使用相同的模式進行日志記錄，并構建模板 dashboard 以便跨團隊共享，這在現(xiàn)在很難做到” 。

Istio 創(chuàng)造者對服務網(wǎng)格未來的展望

即使在銀行業(yè)等傳統(tǒng)行業(yè)中，開發(fā)人員也在創(chuàng)建復雜的面向消費者的應用程序，這些應用程序看起來更像是Google 這樣的大規(guī)模的網(wǎng)絡應用程序。

“重要的是，他們有實時數(shù)據(jù)，并且他們?yōu)槊總€用戶提供個性化體驗”，谷歌 Istio 產(chǎn)品管理總監(jiān) Jennifer Lin 說。“這需要一個更細粒度的服務集，允許這些創(chuàng)新的應用程序以安全的方式以極低的延遲處理大規(guī)模的流量 ” 。

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

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

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

“你可以想象它可以像 AWS Fargate 那樣工作，為每個用戶函數(shù)或容器旁自動注入一個如 Envoy 這樣的代理，而且用戶只需要了解這些功能而無需關心它們是如何實現(xiàn)的“ ，Klein 說。“它們可以獲得服務網(wǎng)格提供功能，但對那到底是不是服務網(wǎng)格并不重要 ”。

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

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

總結

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

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