鎮樓小姐姐
36份一線互聯網Java面試電子書
84個Java稀缺面試題視頻
容器是IT行業的超級英雄，它與服務網格是最佳組合。它們聯手對抗混亂的網絡管理。
容器和微服務出現催生了一種稱為服務網格的新型網絡架構範例，但 IT 觀察家們對它是否能夠廣泛應用到生產上持有不同意見。
服務網格使用一個稱為 sidecar 的代理，它是附加在應用程序旁、虛擬機或運行在 Kubernetes 的 pod 中的容器，具體運行在哪裡取決於所使用的服務網格的類型。然後，該代理可以連接到集中式的控制平面軟件，這些軟件收集細粒度的網絡遙測數據，應用網絡管理策略或更改代理配置，建立並執行網絡安全策略。
IT系統中的服務網格架構還處於初期階段，但與容器一樣它上升的很快。在 2017 年 12 月雲原生計算基金會（CNCF）舉辦的 KubeCon 和 CloudNativeCon 上，服務網格已經取代容器成為 DevOps 前沿 最熱門的話題。
“我們經常發現自己在構建應用軟件時，我們實際上在做的是一遍又一遍地編寫相同的代碼來解決某些實際上非常困難的計算機科學問題，這些問題應該被考慮到某種通用接口中”，微服務監控創業公司 LightStep 首席執行官 Ben Sigelman 在 KubeCon 的服務網格主題演講中表示。
“服務網格可以用來做發現服務、服務連接、斷路、負載均衡……安全和身份驗證” , Sigelman說，他是前谷歌工程師，OpenTracing 的創建者，OpenTracing 是開源的，提供供應商無關的 API。
服務網格簡史
最早版本的 sidecar 代理技術在 2016 年初開始出現在如谷歌和推特的網絡商店，微服務管理需要對網絡進行新的思考。與傳統的單體應用程序不同， 微服務 依靠外部網絡來溝通和協調應用程序功能。這些微服務通信需要密切監控，有時需要大規模重新配置。
用於微服務網絡管理自動化最早的技術依賴於庫，作為應用程序代碼的一部分進行部署， 如 Netflix 的 Hystrix 。因此，開發人員需要進行網絡管理。這些庫也必須用特定環境中使用的每種應用程序語言編寫。這提出了一個難題，因為 微服務精神 的一個主要原則是小團隊可以自由地使用任何語言進行獨立的服務管理。
大多數認為自己正在使用微服務的組織並沒有真正做到微服務。——*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 。鑑於其支持者的聲譽和谷歌內部管理大規模基於容器的微服務的經驗，這種基於容器的服務網格引起了業界的廣泛關注。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 說。“我不相信真正的微服務將成為傳統企業中的主流。”
服務網格允許您以集中的方式管理流量，這種方式可以讓屏蔽環境對技術的影響 ，我覺得這在任何規模上都很有用。—— Zack Angelo BigCommerce 平臺工程總監
對 Thomas 來說，真正的微服務是儘可能獨立的。每個服務處理一個單獨的方法或領域功能；使用自己的獨立數據存儲；與其他微服務依靠基於異步事件的通信；並允許開發人員設計、開發、測試、部署和替換這個單獨的功能，而無需重新部署應用程序的任何其他部分。
“很多主流公司並不一定願意花將大量的時間和金錢投入到應用架構上”，Thomas 爭辯道。“他們仍然在以更粗粒度的方式做事且不會使用服務網格，至少在網格以服務的方式添加到平臺，或者在出現新型開發框架之前“。
很多服務網格的早期用戶認為並不一定需要有大量的微服務才能從該技術中受益 。
“它可以讓你以集中的方式管理流量，流量在不同的環境和技術中是一致的，我覺得這在任何規模上都很有用”，位於德克薩斯州奧斯汀的電子商務公司 BigCommerce 的平臺工程主管 Zack Angelo 這樣說，他們使用 Linkerd 服務網格。“即使你只有十幾個服務，這也是非常有用的功能”。
Angelo 說，傳統的網絡管理概念，例如負載均衡器，無法按微小的百分比把流量路由到某些節點 ，以便進行 金絲雀或藍/綠髮布 。傳統的網絡監控工具也不提供服務網格所提供的那種細粒度的遙測數據，能夠跟蹤 99% 的應用程序延遲中的微小異常，其重要性在微服務網絡中被放大。
Linkerd 的負載均衡模式使用了一種稱為*指數加權移動平均*的技術，以便當服務網格跨主機分配網絡流量時，它會考慮下游服務響應的速度，然後將流量路由到服務性能最佳的地方，而不是傳統循環負載均衡技術。
獲取實時數據併為每位用戶提供個性化體驗這很重要。 Jennifer Lin ——Google 的 Istio 產品總監
“我們的應用分佈在多個數據中心，很高興能夠將該技術內置到我們的負載均衡器中，它能自動感知並選擇最快的網絡路徑 ”。Angelo 說。“從故障轉移的角度來看，這對我們也很重要”。
並不是說使用服務網絡時不需要權衡 ，特別是當涉及到 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 雲平臺和亞馬遜這樣百年企業，我們正處於該過程的初級階段”。
閱讀更多 李紅 的文章
