服務網格就像一輛電動汽車，你的朋友在談論它，它很時髦，但是你還沒有擁有。你可能希望稍等一下，看看其他人如何對其進行管理。但是，這種感覺就像是下一次技術演化。
最近幾個月，服務網格已經引起了廣泛的關注——它們有助於解決採用微服務架構後出現的許多問題。但是服務網格是否準備好供所有企業使用呢？事實證明，支持者並不認爲這項技術已經100％做好被廣泛採用的準備了。
11月18日舉行的北美2020年服務網專題討論會上，該領域的思想領袖有：Mat Klein，Lyft；Manish Chugtu，VMware；IBM的Dan Berg和Idit Levine，Solo.io。總體而言，小組成員承認服務網格領域當前的積極發展，例如Envoy周圍的整合。他們還強調了它的許多好處，包括爲微服務體系結構增加了聯網、可觀察性和路由功能。
但是，我們仍然沒有看到足夠的服務網格生產用例。並且，每個網格框架仍在成熟當中。使用服務網格的權衡包括增加的等待時間，陡峭的學習曲線和持續的維護開銷。網格間互操作性缺乏明確的標準化可能是另一個問題（SMI是一種提議的格式，但是現在行業似乎更傾向於Envoy的xDS API）。
所有這一切並不是說它不會成爲公司未來基礎架構的關鍵部分，也不是說它不會爲需要的用例提供有用的功能。簡而言之，服務網格是一個新興領域（這就是爲什麼該小組如此吸引人的原因）。當我們深入研究未來圖景的最新更新時，請遵循以下內容。讓我們一起來看看頂級專家認爲該技術的發展方向。
服務網格的新進展
服務網格空間的最新進展是什麼？好吧，現在大多數小組成員都將Envoy視爲大多數網格的已建立數據平面代理。我們還看到它非常適合作爲新的多雲範例的可觀察性機制。
“Envoy是我們正在看到出現的數據平面層”，Klein說。服務網格和API網關空間充斥着許多解決方案，應用程序也越來越傾向於無服務器。未來很難預測，但“像Kubernetes和Envoy這樣的基礎技術將是管道”，他說。
Levine還稱讚了Envoy的可擴展性特性，並舉例說明了最近用WebAssebnly擴展Envoy所取得的進展。她說：“Envoy是可行之道。”“它是建築的基石——所有不接受它的東西都會消失。”“儘管如此，市場上存在大量的營銷炒作，如果沒有適當的保護和治理，執行起來可能會很危險。”
同樣，Berg相信Envoy是未來，而多雲是現在。然而，他描述了團隊實現服務網格是多麼困難。他表示：“他們正在努力做到這一點，但很艱難。”護欄和治理的概念非常重要。除此之外，許多公司只需要Istio等成熟技術所能提供的一小部分能力。他呼籲簡化可用性和部署——我們需要“針對複雜問題的簡單解決方案”。
Chugtu讚揚了它在處理新的混合和多雲模式方面的優勢。這些現實正在出現，帶來了跨所有部署模式的通用可觀察性框架的需求。在安全性方面，Chugtu看到了通過威脅檢測等方式解決可擴展性問題的實際好處。根據Chugtu的說法，一個服務網絡收集的有用信息越多，它就越能幫助定義訪問屬性。因此，它有助於創建一個零信任模型。
使用服務網格的權衡
儘管如此，仍然存在很大的困難。總體而言，專家組認識到服務網格實施需要大量的人力資源——陡峭的學習曲線，可用性挑戰和持續的維護。此外，每個操作都佔用服務器空間，因此操作開銷和應用程序延遲是需要考慮的實際問題。最後，它可能會給不需要它的場景帶來過多的複雜性。
“這是一個很陡峭的學習曲線，”伯格說。“這不是一個漸進的改善——你從零開始，然後是一個飛躍。公司可以採用它來實現可觀察性和企業範圍的交互。隨着他們的進步和意識到有更多的價值，伯格補充道，他們必須理解許多資源，並融入這個網絡。從操作上講，SideCar也會隨着時間的推移消耗資源。“很多人剛開始構建的時候沒有考慮到這一點，”他說。他預測，託管解決方案可以幫助打開更多的可能性，以便更容易地採用。
Levine說：“我們正在嘗試採用一種尚未100％做好準備的方法。”服務網格本質上是操作，管理以及升級和維護的另一件事。她還承認設計固有的增加的延遲。不管潛在的弊端如何，Levine仍然相信集中式配置平面的好處勝過不利因素。
Chugtu說：“服務網格無法滿足客戶現在所在的需求。”他承認其複雜性和固有的學習曲線。但是，他仍然認爲值得付出努力，因爲這有助於平衡團隊動力。從根本上講，引入服務網格可以將基礎架構的所有權轉移回平臺和DevOps團隊，從而使開發人員可以專注於核心能力和應用程序開發。
在最近的一次採訪中，Palladino強調平臺團隊和開發者的分離是一件好事。他說：“應用程序團隊應該成爲連接的消費者，而不是連接的製造者。”
回到問題的根源，也許公司真正應該問的問題是：我們應該首先採用微服務嗎？當你採用微服務時，會帶來許多意想不到的結果，這些結果與運行單體架構有很大的不同。
從本質上講，行業不應該在沒有必要的時候把事情複雜化。當它被證明是合理的，“Sidecar代理解決方案是這些問題的優雅解決方案”，Klein說。
標準和服務網格接口
正如我最近介紹的那樣，由Solo.io牽頭的Service Mesh Interface（SMI）可能是一個令人振奮的提議，它將新興的Service Mesh領域帶來互操作性和可擴展性優勢。然而，專家組的總體情緒是對其實際使用的懷疑態度。
Levine支持SMI，以在網格之間形成供應商中立的標準接口。在未來的多網格世界中，在市場上擁有通用的服務網格配置模式可以增強公司的能力。但是，她承認SMI的障礙，特別是標準的“較低的共同點”效應和政治因素阻礙了它的引入。
其他人則不那麼確信SMI是必要的。伯格說：“如果你要用不同的網格，那可能是難以下嚥的。”“最終我們會有多少實現呢？”他問道。如果主要好處只是避免供應商鎖定，SMI可能不值得投資。
Klein將SMI描述爲一個理論上的好主意，但在實踐中並不認爲它有用。“我非常懷疑任何東西都是可攜帶的，”他說。在一天結束的時候，所有的服務網供應商都會有他們自己的解釋。Klein強調，行業應該避免增加不必要的抽象層。
一些座談會的專家沒有關注SMI，而是認爲圍繞Envoy xDS API的融合更加有意義。“如果一切都基於Envoy，那會不會收斂呢？” Klein問道。
準備採用服務網格
因此，瞭解所涉及的障礙之後，服務網格何時才能100％準備好？它適合什麼情況？答案各不相同。
一種方法是從現有技術堆棧的角度來看待它。Klein重申，公司應該在服務網格之前首先採用微服務。他說，不要因爲“技術嫉妒”而擁抱服務網格。取而代之的是，這應該是基於最大程度地減少操作痛點和最大化生產率的客戶至上的決定。
另一種觀點是考慮未來的發展方向。Chugtu說，服務網格可能是你公司或未來客戶願景的一部分。在這種情況下，你的歷史或當前體系結構可能不太重要。他說：“解決方案已準備好，你要解決的用例就很多。”
還有一個觀點是，沒有任何偉大的技術是完整的。服務網格何時可以100％準備就緒？“從不”，伯格說。總會有故障，以Kubernetes爲例：每個發行版都修補或引入了新問題，社區正在不斷改進它。同樣，市場上的每個服務網格都日趨成熟。他說，它們各有優缺點，“沒有一個是完美的”。
服務網格何時會成熟？對於Levine來說，首先需要通過絞擰器（痛苦的事情）放置服務網格。她說：“它們都不夠成熟。” 只有當人們在生產中運行它時，他們才能提供反饋以改善服務網格。儘管“還沒有一個人完全準備好”，但Levine確實預見到了一個適合更多組織的快速開放的市場。
服務網格是一個全新的概念，需要更多的生產用例來提高網格和Envoy的可擴展性。早期採用者應根據自己的情況進行正確的猜測，在選擇一個市場之前評估市場上的所有服務網格。對於後期的採用者來說，未來可用性的改進和管理服務網格的提供可以很容易地激勵一個組織變得網格化。
原文鏈接：https://containerjournal.com/topics/container-management/service-mesh-not-100-ready-for-wide-adoption/
Kubernetes管理員認證（CKA）培訓
本次CKA培訓在北京開班，基於最新考綱，通過線下授課、考題解讀、模擬演練等方式，幫助學員快速掌握Kubernetes的理論知識和專業技能，並針對考試做特別強化訓練，讓學員能從容面對CKA認證考試，使學員既能掌握Kubernetes相關知識，又能通過CKA認證考試，學員可多次參加培訓，直到通過認證。點擊下方圖片或者閱讀原文鏈接查看詳情。
