譯者：

作為一個曾經(jīng)在新造車公司的基礎架構(gòu)團隊任職，為支持公司的“互聯(lián)網(wǎng)基因”和“數(shù)字化轉(zhuǎn)型”落地了云原生基礎設施平臺，并在嘗試采用服務網(wǎng)格未成的我來說，看到這篇文章深有感觸。尤其是文中所說的“人少，問題多，需要快速輸出價值”，直戳到了痛處。有限的人手有限的時間，我們需要將大部分精力集中在解決成熟度曲線較低的基本問題上，要想很好的運行復雜的系統(tǒng)是非常困難的。

服務網(wǎng)格是一個新的基礎設施層，可以承載很多的功能，未來還會有更大的想象空間和光明的未來。

以上的種種原因，也促使我后來選擇進入一家提供服務網(wǎng)格的產(chǎn)品企業(yè)，也希望服務網(wǎng)格可以被更簡單的使用。

“道阻且長，行則將至！”

本文翻譯自 Chris Campbell 的 How Unnecessary Complexity Gave the Service Mesh a Bad Name^[1]

關鍵要點

?采用服務網(wǎng)格有巨大的價值，但必須以輕量級的方式進行，以避免不必要的復雜性。?在實施服務網(wǎng)時，要采取務實的方法，與技術的核心功能保持一致，并小心干擾（譯者：注意力的分散）。?服務網(wǎng)格的一些核心特性包括標準化監(jiān)控、自動加密和身份識別、智能路由、可靠的重試和網(wǎng)絡可擴展性。?服務網(wǎng)格可以提供強大的功能，但這些功能會分散本應對核心優(yōu)勢的關注，并且這些功能也不是實施服務網(wǎng)格的主要原因。?在初始實施服務網(wǎng)格時沒有必要去關注那些明顯會分散注意力的功能，比如復雜的控制平面、多集群支持、Envoy、WASM 和 A/B 測試。

服務網(wǎng)格是 Kubernetes 世界中的一個熱門話題，但許多潛在的采用者已經(jīng)有些失望了。服務網(wǎng)格的落地受到壓倒性的復雜性和看似無窮無盡的供應商解決方案的限制。在我親自瀏覽了這個領域之后，我發(fā)現(xiàn)采用服務網(wǎng)格具有巨大的價值，但它必須以輕量級的方式完成，以避免不必要的復雜性。盡管普遍存在幻滅感，但服務網(wǎng)格的未來依然光明。

在工作中學習

我進入服務網(wǎng)格的世界始于我在一家老牌的財富 500 強技術公司擔任云計算架構(gòu)師的角色。在開始我們的服務網(wǎng)格之旅時，我身邊有許多強大的工程師，但大多數(shù)人幾乎沒有云計算開發(fā)經(jīng)驗。我們的組織誕生于云計算之前，完全實現(xiàn)云計算的價值需要時間。我們的傳統(tǒng)業(yè)務線主要集中在技術棧的硬件元素上，云計算的決策最初是由為運送硬件或為該硬件提供固件和驅(qū)動程序而開發(fā)的流程驅(qū)動的。

隨著該組織經(jīng)歷其“數(shù)字化轉(zhuǎn)型”，它越來越依賴于提供高質(zhì)量的軟件服務，并逐漸開發(fā)出更好的方法。但作為云計算架構(gòu)師，我仍在為優(yōu)先考慮硬件的業(yè)務流程，以及具有不同技能、流程和信念的工程團隊導航。隨著時間的推移，我和我的團隊在將 .NET 應用程序遷移到 Linux、采用 Docker、遷移到 AWS 以及與之相關的最佳實踐（如持續(xù)集成、自動化部署、不可變基礎設施、基礎設施即代碼、監(jiān)控等）方面變得熟練并成功。但挑戰(zhàn)依然存在。

在此期間，我們開始將我們的應用程序拆分為一組微服務。起初，這是一個緩慢的轉(zhuǎn)變，但最終這種方法流行起來，開發(fā)人員開始更喜歡構(gòu)建新的服務而不是添加到現(xiàn)有服務。我們這些基礎設施團隊的人把這看作是一種成功。唯一的問題是與網(wǎng)絡相關的問題數(shù)量激增，開發(fā)人員正在向我們尋求答案，而我們還沒有準備好有效地應對這種沖擊。

服務網(wǎng)格的援救

我第一次聽說服務網(wǎng)格是在 2015 年，當時我正在研究服務發(fā)現(xiàn)工具并尋找與 Consul 集成的簡單方法。我喜歡將應用程序職責卸載到“sidecar”容器的想法，并找到了一些可以幫助做到這一點的工具。大約在這個時候，Docker 有一個叫做“鏈接”的功能，讓你可以將兩個應用程序放在一個共享的網(wǎng)絡空間中，這樣它們就可以通過 localhost 進行通信。此功能提供了類似于我們現(xiàn)在在 Kubernetes pod 中所擁有的體驗：兩個獨立構(gòu)建的服務可以在部署時進行組合以實現(xiàn)一些附加功能。

我總是抓住機會用簡單的方案來解決大問題，因此這些新功能的力量立即打動了我。雖然這個工具是為了與 Consul 集成而構(gòu)建的，但實際上，它可以做任何你想做的事情。這是我們擁有的基礎設施層，可以用來一次為所有人解決問題。

這方面的一個具體例子出現(xiàn)在我們采用過程的早期。當時，我們正致力于跨不同服務的日志標準化輸出。通過采用服務網(wǎng)格和這種新的設計模式，我們能夠?qū)⑽覀兊娜说膯栴}——讓開發(fā)人員標準化他們的日志——換成技術問題——將所有流量傳遞給可以為他們記錄日志的代理。這是我們團隊向前邁出的重要一步。

我們對服務網(wǎng)格的實現(xiàn)非常務實，并且與該技術的核心功能非常吻合。然而，大部分營銷炒作都集中在不太需要的邊緣案例上，在評估服務網(wǎng)格是否適合你時，能夠識別這些干擾是很重要的。

核心功能

服務網(wǎng)格可以提供的核心功能分為四個關鍵責任領域：可觀察性、安全性、連接性和可靠性。這些功能包括：

標準化監(jiān)控

我們?nèi)〉玫淖畲髣倮?，也是最容易采用的，是標準化監(jiān)控。它的運營成本非常低，可以適應你使用的任何監(jiān)控系統(tǒng)。它使組織能夠捕獲所有 HTTP 或 gRPC 指標，并以標準方式在整個系統(tǒng)中存儲它們。這控制了復雜性并減輕了應用程序團隊的負擔，他們不再需要實現(xiàn) Prometheus 指標端點或標準化日志格式。它還使用戶能夠公正地了解其應用程序的黃金信號^[2]。

自動加密和身份識別

證書管理很難做好。如果一個組織還沒有在這方面進行投入，他們應該找到一個網(wǎng)格來為他們做這件事。證書管理需要維護具有巨大安全隱患的復雜基礎設施代碼。相比之下，網(wǎng)格將能夠與編排系統(tǒng)集成，以了解工作負載的身份，在需要時可以用來執(zhí)行策略。這允許提供與 Calico 或 Cilium 等功能強大的 CNI 提供的安全態(tài)勢相當或更好的安全態(tài)勢。

智能路由

智能路由是另一個特性，它使網(wǎng)格能夠在發(fā)送請求時“做正確的事”。場景包括：

1.使用延遲加權(quán)算法優(yōu)化流量2.拓撲感知路由以提高性能并降低成本3.根據(jù)請求成功的可能性使請求超時4.與編排系統(tǒng)集成以進行 IP 解析，而不是依賴 DNS5.傳輸升級，例如 HTTP 到 HTTP/2

這些功能可能不會讓普通人感到興奮，但隨著時間的推移，它們從根本上增加了價值

可靠的重試

在分布式系統(tǒng)中重試請求可能很麻煩，但是它幾乎總是需要實現(xiàn)的。分布式系統(tǒng)通常會將一個客戶端請求轉(zhuǎn)換為更多下游請求，這意味著“尾巴”場景的可能性會大大增加，例如發(fā)生異常失敗的請求。對此最簡單的緩解措施是重試失敗的請求。

困難來自于避免“重試風暴”或“重試 DDoS”，即當處于降級狀態(tài)的系統(tǒng)觸發(fā)重試、隨著重試增加而增加負載并進一步降低性能時。天真的實現(xiàn)不會考慮這種情況，因為它可能需要與緩存或其他通信系統(tǒng)集成以了解是否值得執(zhí)行重試。服務網(wǎng)格可以通過對整個系統(tǒng)允許的重試總數(shù)進行限制來實現(xiàn)這一點。網(wǎng)格還可以在這些重試發(fā)生時報告這些重試，可能會在你的用戶注意到系統(tǒng)降級之前提醒你。

網(wǎng)絡可擴展性

也許服務網(wǎng)格的最佳屬性是它的可擴展性。它提供了額外的適應性層，以應對 IT 下一步投入的任何事情。Sidecar 代理的設計模式是另一個令人興奮和強大的功能，即使它有時會被過度宣傳和過度設計來做用戶和技術人員還沒有準備好的事情。雖然社區(qū)在等著看哪個服務網(wǎng)格“生出”，這反映了之前過度炒作的編排戰(zhàn)爭，但未來我們將不可避免地看到更多專門構(gòu)建的網(wǎng)格，并且可能會有更多的最終用戶構(gòu)建自己的控制平面和代理以滿足他們的場景。

服務網(wǎng)格干擾

平臺或基礎設施控制層的價值怎么強調(diào)都不為過。然而，在服務網(wǎng)格世界中，我了解到入門的一個主要的挑戰(zhàn)是，服務網(wǎng)格解決的核心問題通常甚至不是大多數(shù)服務網(wǎng)格項目交流的焦點！

相反，來自服務網(wǎng)格項目的大部分交流都圍繞著聽起來很強大或令人興奮但最終會讓人分心的功能。這包括：

強（復）大（雜）的控制平面

要很好地運行復雜的軟件是非常困難的。這就是為什么如此多的組織使用云計算來使用完全托管的服務來減輕這一點的原因。那么為什么服務網(wǎng)格項目會讓我們負責操作如此復雜的系統(tǒng)呢？系統(tǒng)的復雜性不是資產(chǎn)，而是負債，但大多數(shù)項目都在吹捧它們的功能集和可配置性。

多集群支持

多集群現(xiàn)在是一個熱門話題。最終，大多數(shù)團隊將運行多個 Kubernetes 集群。但是多集群的主要痛點是你的 Kubernetes 管理的網(wǎng)絡被切分。服務網(wǎng)格有助于解決這個 Kubernetes 橫向擴展問題，但它最終并沒有帶來任何新的東西。是的，多集群支持是必要的，但它對服務網(wǎng)格的承諾被過度宣傳了。

Envoy

Envoy 是一個很棒的工具，但它被作為某種標準介紹，這是有問題的。Envoy 是眾多開箱即用的代理之一，你可以將其作為服務網(wǎng)格平臺的基礎。但是 Envoy 并沒有什么內(nèi)在的特別之處，使其成為正確的選擇。采用 Envoy 會給你的組織帶來一系列重要問題，包括：

?運行時成本和性能（所有這些過濾器加起來?。?/span>?計算資源需求以及如何隨負載擴展?如何調(diào)試錯誤或意外行為?你的網(wǎng)格如何與 Envoy 交互以及配置生命周期是什么?運作成熟的時間（這可能比你預期的要長）

服務網(wǎng)格中代理的選擇應該是一個實現(xiàn)細節(jié)，而不是產(chǎn)品要求。

WASM

我是 Web Assembly (WASM) 的忠實擁躉，已經(jīng)成功地使用它在 Blazor^[3] 中構(gòu)建前端應用程序。然而，WASM 作為定制服務網(wǎng)格代理行為的工具，讓你處于獲得一個全新的軟件生命周期開銷的境地，這與你現(xiàn)有的軟件生命周期完全正交！如果你的組織還沒有準備好構(gòu)建、測試、部署、維護、監(jiān)控、回滾和版本代碼（影響通過其系統(tǒng)運行的每個請求），那么你還沒有準備好使用 WASM。

A/B 測試

直到為時已晚，我才意識到 A/B 測試實際上是一個應用程序級別的問題。在基礎設施層提供原語來實現(xiàn)它是很好的，但是沒有簡單的方法來完全自動化大多數(shù)組織需要的 A/B 測試水平。通常，應用程序需要定義獨特的指標來定義測試的積極信號。如果組織想要在服務網(wǎng)格級別投入 A/B 測試，那么解決方案需要支持以下內(nèi)容：

1.對部署和回滾的精細控制，因為它可能同時進行多個不同的“測試”2.能夠捕獲系統(tǒng)知道的自定義指標并可以根據(jù)這些指標做出決策3.根據(jù)請求的特征暴露對流量方向的控制，其中可能包括解析整個請求正文

這需要實現(xiàn)很多，沒有哪個服務網(wǎng)格是開箱即用的。最終，我們的組織選擇了網(wǎng)格之外的特征標記解決方案，其以最小的努力取得了巨大的成功。

我們在哪里結(jié)束

最終，我們面臨的挑戰(zhàn)并不是服務網(wǎng)格獨有的。我們工作的組織有一系列限制條件，要求我們對解決的問題以及如何解決問題采取務實的態(tài)度。我們面臨的問題包括：

?一個擁有大量不同技能的開發(fā)人員的大型組織?云計算和 SaaS 能力普遍不成熟?為非云計算軟件優(yōu)化的流程?碎片化的軟件工程方法和信念?有限的資源?激進的截止日期

簡而言之，我們?nèi)松?，問題多，需要快速輸出價值。我們必須支持主要不是 Web 或云計算的開發(fā)者，我們需要擴大規(guī)模以支持有不同方法和流程的大型工程組織來做云計算。我們需要將大部分精力集中在解決成熟度曲線較低的基本問題上。

最后，當面對我們自己的服務網(wǎng)格決策時，我們決定建立在 Linkerd 服務網(wǎng)格^[4]上，因為它最符合我們的優(yōu)先事項：低運營成本（計算和人力）、低認知開銷、支持性社區(qū)以及透明的管理——同時滿足我們的功能要求和預算。在 Linkerd 指導委員會工作了一段時間后（他們喜歡誠實的反饋和社區(qū)參與），我了解到它與我自己的工程原則有多么的契合。Linkerd 最近在 CNCF 達到畢業(yè)狀態(tài)^[5]，這是一個漫長的過程，強調(diào)了該項目的成熟及其廣泛采用。

關于作者

Chris Campbell 擔任軟件工程師和架構(gòu)師已有十多年，與多個團隊和組織合作落地云原生技術和最佳實踐。他在與業(yè)務領導者合作采用加速業(yè)務的軟件交付策略和與工程團隊合作交付可擴展的云基礎架構(gòu)之間分配時間。他對提高開發(fā)人員生產(chǎn)力和體驗的技術最感興趣。