筆記。 翻譯。：服務網格是一種尚未穩定翻譯成俄語的現象（2 年多前我們提供了“服務網格”選項，稍後，一些同事開始積極推廣組合“服務篩選”） . 不斷談論這項技術導致了營銷和技術組件過於緊密地交織在一起的情況。 這篇來自原始術語作者之一的精彩材料旨在為工程師帶來清晰度，而不僅僅是。
漫畫來自
介紹
如果你是一名在後端系統領域工作的軟件工程師，那麼在過去的幾年裡，“服務網格”這個詞可能已經在你的腦海中根深蒂固了。 多虧了一個奇怪的巧合，這個短語越來越多地接管了整個行業，炒作和相關的促銷活動像滾雪球一樣越滾越大，越滾越大，絲毫沒有放緩的跡象。
服務網格誕生於雲原生生態系統的渾濁、有傾向性的水域。 不幸的是，這意味著圍繞它的大部分爭議範圍從“低熱量喋喋不休”到 - 使用技術術語 - 公然胡說八道。 但是如果你過濾掉所有的噪音，你會發現服務網格有一個非常真實、明確和重要的作用。
在這篇文章中，我將嘗試做到這一點：為服務網格提供誠實、深入、面向工程師的指南。 我要回答的不僅僅是問題： “這是什麼？”， - 但是也 “為了什麼？”和 “為什麼現在？”. 最後，我將嘗試概述為什麼（在我看來）這項特殊技術會引起如此瘋狂的炒作，這本身就是一個有趣的故事。
我是誰？
大家好！ 我的名字是 . 我是創作者之一 - 第一個服務網格項目和該術語出現的罪魁禍首 服務網格 因此（對不起伙計們！）。 (注意翻譯。: 順便說一句，在這個術語出現之初，即 2,5 多年前，我們已經翻譯了同一作者的早期材料，稱為“”。） 我也領導 是一家構建很酷的服務網格的初創公司，比如 Linkerd 和 .
您可能會猜到我對這個問題的看法非常偏見和主觀。 但是，我會盡量減少偏見（以下部分除外： “為什麼有這麼多關於服務網格的討論？”, - 在其中我仍然會分享我先入為主的想法）。 我也會盡我所能使本指南盡可能客觀。 在具體的例子中，我將主要依靠Linkerd的經驗，同時指出我所知道的其他類型的服務網格在實現上的差異（如果有的話）。
好的，是時候繼續治療了。
什麼是服務網格？
儘管大肆宣傳，但服務網格在結構上非常簡單。 它只是一堆位於服務“旁邊”的用戶空間代理（稍後我們將討論“附近”），加上一組控制進程。 代理統稱為 數據平面, 控製過程稱為 控制平面. 數據平面攔截服務之間的調用並對它們做“任何不同的事情”； 控制平面分別協調代理的行為並為您提供訪問權限，即運營商，API，允許網絡作為一個整體進行操作和測量。
這個代理是什麼？ 這是“第 7 層感知”類別的 TCP 代理 （即“考慮到”OSI 模型的第 7 層） 像 HAProxy 和 NGINX。 您可以根據自己的喜好選擇代理； Linkerd 使用 Rust 代理，名稱簡單 . 我們專門為服務網格編譯了它。 其他網格更喜歡其他代理（Envoy 是一個常見的選擇）。 然而，選擇代理只是一個實施問題。
這些代理服務器有什麼作用？ 顯然，它們代理服務的調用（嚴格來說，它們充當代理和反向代理，處理傳入和傳出的調用）。 他們實現了一個專注於通話的功能集 之間 服務。 這種對服務之間流量的關注是服務網格代理與 API 網關或入口代理（後者關注從外部世界進入集群的調用）的區別所在。 (筆記。 翻譯。：對於現有 Kubernetes Ingress 控制器的比較，其中許多使用已經提到的 Envoy，請參見 .)
所以，我們想出了數據平面。 控制平面更簡單：它是一組組件，提供數據平面以協調方式工作所需的所有機制，包括服務發現、TLS 證書頒發、度量聚合等。數據平面通知控制平面有關它的行為； 反過來，控制平面提供了一個 API，允許您更改和跟踪整個數據平面的行為。
下面是 Linkerd 中控制平面和數據平面的示意圖。 如您所見，控制平麵包括幾個不同的組件，包括從代理服務器收集指標的 Prometheus 實例，以及其他組件，例如 destination （服務發現）， identity （證書頒發機構，CA）和 public-api （網絡和 CLI 的端點）。 相比之下，數據平面是應用程序實例旁邊的一個簡單的 linkerd-proxy。 這只是一個邏輯圖； 在現實世界的部署中，您可能擁有每個控制平面組件的三個副本，以及數據平面中的成百上千個代理。
（圖中的藍色框代表Kubernetes pod的邊界。你可以看到帶有linkerd-proxy的容器與應用程序容器在同一個pod中。這種方案被稱為 邊車容器.)
服務網格架構有幾個重要的含義。 首先，由於代理的工作是攔截服務之間的調用，因此只有當您的應用程序是為一組服務構建時，服務網格才有意義。 網 人們可以 與整體一起使用，但這對於單個代理來說顯然是多餘的，並且不太可能需要它的功能。
另一個重要的結果是服務網格需要 巨大的 代理的數量。 事實上，Linkerd 將一個 linkerd-proxy 鏈接到每個服務的每個實例（其他實現將代理添加到每個主機/主機/VM。無論如何這很多）。 這種代理的積極使用本身會帶來一些額外的複雜性：
- 數據平面中的代理應該是 快速地，因為每次調用都會對代理進行幾次調用：一次在客戶端，一次在服務器端。
- 此外，代理必須是 小的 и 輕的. 每個都會消耗內存和 CPU 資源，並且這種消耗會隨著應用程序線性增長。
- 您將需要一種機制來部署和更新大量代理。 手動操作不是一種選擇。
一般來說，服務網格看起來像這樣（至少從鳥瞰圖來看）：你部署了一堆用戶空間代理，這些代理對內部、服務間的流量“做某事”，並使用控制平面來監控和管理它們。
是時候問“為什麼？”了
什麼是服務網格？
對於那些第一次接觸到服務網格的想法的人來說，有點敬畏是可以原諒的。 服務網格設計意味著它不僅會增加應用程序延遲，而且還會 消耗 資源和 將添加 基礎設施中的一系列新機制。 首先你設置了一個服務網格，然後你突然發現自己需要服務數百個（如果不是數千個）代理。 問題是，誰會自願這樣做？
這個問題的答案有兩部分。 首先，由於生態系統中發生了一些變化（稍後會詳細介紹），與部署這些代理相關的交易成本可以顯著降低。
其次，這樣的設備實際上是將附加邏輯引入系統的好方法。 不僅因為可以使用服務網格添加許多新功能，還因為它可以在不干擾生態系統的情況下完成。 事實上，整個服務網格模型都是基於這樣一個假設：在一個多服務系統中，無論 使 個性化服務，交通 它們之間 是添加功能的理想點。
例如，在 Linkerd 中（就像在大多數網格中一樣），功能主要集中在 HTTP 調用上，包括 HTTP/2 和 gRPC*。 功能相當豐富——可以分為三類：
- 相關功能 可靠性. 重試請求、超時、金絲雀方法（流量拆分/重定向）等。
- 相關功能 監控. 每項服務或單個目的地的成功率、延遲和請求量的匯總； 構建服務的拓撲圖等。
- 相關功能 安全. 雙向 TLS、訪問控制等。
* 從 Linkerd 的角度來看，gRPC 實際上與 HTTP/2 沒有什麼不同：它只是在有效負載中使用了 protobuf。 從開發人員的角度來看，這兩者當然是不同的。
許多這些機制在請求級別運行（因此稱為“L7 代理”）。 例如，如果服務 Foo 對服務 Bar 進行 HTTP 調用，則 Foo 端的 linkerd-proxy 可以根據觀察到的延遲智能地負載平衡並將調用從 Foo 路由到 Bar 實例； 它可以在必要時重複請求（如果它是冪等的）； 他可以記錄響應代碼和超時等。 同樣，Bar端的linkerd-proxy可以拒絕一個請求，如果不允許或者超過請求限制； 可以修復它的延遲等。
代理也可以在連接級別“做某事”。 例如，Foo 端的 linkerd-proxy 可以發起 TLS 連接，Bar 端的 linkerd-proxy 可以終止它，雙方可以驗證彼此的 TLS 證書*。 這不僅提供了服務之間的加密，還提供了一種識別服務的加密安全方式：Foo 和 Bar 可以“證明”它們是它們所說的那個人。
* “朋友的朋友”意味著客戶端的證書也經過驗證（相互 TLS）。 例如，在“經典”TLS 中，在瀏覽器和服務器之間，通常只驗證一側（服務器）的證書。
無論它們是在請求級別還是連接級別運行，重要的是要強調所有服務網格功能都是 操作 特點。 Linkerd 無法轉換有效負載的語義，例如向 JSON 片段添加字段或更改 protobuf。 這個重要的特性我們後面講ESB和中間件的時候再講。
這是服務網格提供的一組功能。 問題來了：為什麼不直接在應用程序中實現它們呢？ 為什麼要搞亂代理呢？
為什麼服務網格是個好主意
雖然服務網格的功能令人著迷，但它的主要價值並不真正在於功能。 最後我們 能 直接在應用程序中實現它們（稍後我們將看到這是服務網格的起源）。 一句話概括，一個服務網格的價值就是： 它提供了以一致的、堆棧範圍的、與應用程序代碼無關的方式運行現代服務器軟件的關鍵功能.
讓我們分析一下這個提議。
«運行現代服務器軟件的關鍵功能”。 如果您正在構建連接到公共互聯網的事務服務器應用程序，它接受來自外部世界的請求並在短時間內響應它們——例如，Web 應用程序、API 服務器和絕大多數其他現代應用程序——以及如果您將其實現為一組彼此同步交互的服務，並且如果您不斷升級此軟件，添加新功能，並且如果您在修改期間被迫保持此系統處於工作狀態 - 在這種情況下，恭喜，您正在創建現代服務器軟件。 上面列出的所有這些重要功能實際上對您來說都是至關重要的。 應用程序必須可靠、安全，並且您必須能夠看到它在做什麼。 服務網格幫助解決的正是這些問題。
（好吧，我堅信這種方法是構建服務器軟件的現代方法已經進入了上一段。其他人更喜歡開發單體、“反應性微服務”和其他不屬於上述定義的東西。這些人可能有意見這與我的不同，反過來，我認為他們是“錯誤的”——儘管在任何情況下，服務網格對他們來說都不是很有用）。
«整個堆棧統一”。 服務網格提供的功能不僅僅是關鍵。 它們適用於應用程序中的所有服務，無論它們是用什麼語言編寫的、使用什麼框架、誰編寫的、如何部署的，以及它們開發和使用的所有其他微妙之處。
«獨立於應用程序代碼”。 最後，服務網格不僅在整個堆棧中提供一致的功能，而且以一種不需要編輯應用程序的方式實現。 服務網格的功能基礎，包括配置、更新、操作、維護等任務，純粹是在平台層面，獨立於應用程序。 應用程序可以在不影響服務網格的情況下進行更改。 反過來，服務網格可以在沒有任何應用程序干預的情況下改變。
簡而言之，服務網格不僅提供重要的功能，而且以全局、統一和應用程序獨立的方式提供。 因此，雖然服務網格的功能可以在服務代碼中實現（例如，作為每個服務中包含的庫），但這種方法不會提供在服務網格的情況下非常有價值的統一性和獨立性.
而您需要做的就是添加一堆代理！ 我保證，我們很快就會查看與添加這些代理相關的運營成本。 但首先，讓我們停下來，從不同的角度來看一下這種獨立的想法 人.
服務網格對誰有幫助？
儘管可能不方便，但為了使技術成為生態系統的重要組成部分，它必須被人們接受。 那麼誰對服務網格感興趣？ 誰從它的使用中受益？
如果你開發現代服務器軟件，你可以粗略地把你的團隊想像成一個群體 服務所有者誰一起開發和實施業務邏輯，以及 平台所有者參與開發運行這些服務的內部平台。 在小型組織中，這些人可以是同一個人，但隨著公司的發展，這些角色往往會變得更加明顯，甚至會分成子角色......（這裡有很多關於 devops 不斷變化的性質，微服務的組織影響等）。n. 但現在，讓我們將這些描述視為理所當然）。
從這個角度來看，服務網格的明顯受益者是平台的所有者。 畢竟，平台團隊的最終目標是創建一個內部平台，服務所有者可以在該平台上實施業務邏輯，並以保證他們最大程度獨立於嚴酷操作細節的方式進行。 服務網格不僅提供了實現這一目標的關鍵功能，而且它以一種不依賴於服務所有者的方式實現。
服務所有者也從中受益，儘管是以更間接的方式。 服務所有者的目標是在實施業務流程邏輯時盡可能高效，他越少擔心操作問題越好。 他們可以專注於業務，而不是強制執行重試策略或 TLS，而希望平台處理其餘部分。 對於他們來說，這是一個很大的優勢。
平台和服務所有者之間的這種劃分的組織價值怎麼估計都不過分。 我認為她有貢獻 主要的 對服務網格價值的貢獻。
當一位早期的 Linkerd 粉絲告訴我們他們為什麼選擇服務網格時，我們吸取了這一教訓：因為它允許他們“保持最低限度的交談”。 以下是一些細節：一家大公司的人將他們的平台遷移到了 Kubernetes。 由於該應用程序處理敏感信息，他們希望對集群中的所有通信進行加密。 然而，由於存在數百個服務和數百個開發團隊，情況變得複雜起來。 聯繫每個人並說服他們在他們的計劃中包括對 TLS 的支持的前景並沒有讓他們高興。 通過安裝 Linkerd，他們遷移了 責任 從開發人員（從他們的角度來看，這是不必要的麻煩）到平台開發者，對他們來說這是最優先考慮的事情。 換句話說，Linkerd 為他們解決的與其說是技術問題，不如說是組織問題。
簡而言之，服務網格不是技術解決方案，而是 社會技術 問題。 （謝謝 介紹這個詞。
服務網格會解決我所有的問題嗎？
是的。 我的意思是，不！
看看上面概述的三類特性——可靠性、安全性和可觀察性——很明顯，服務網格並不是這些問題中任何一個的完整解決方案。 儘管 Linkerd 可以發送重複的請求（如果它知道它們是冪等的），但它無法決定在服務最終停止時返回給用戶的內容——此類決定必須由應用程序做出。 Linkerd 可以保留成功請求的統計信息，但它無法查看服務並提供其內部指標——應用程序應該有這樣的工具包。 雖然 Linkerd 能夠託管 mTLS，但成熟的安全解決方案需要更多。
服務網格提供的這些領域中的一部分功能與 平台功能. 我的意思是這樣的功能：
- 獨立於業務邏輯. 在 Foo 和 Bar 之間構造調用直方圖的方式完全獨立於是否 為什麼 Foo 調用 Bar。
- 難以正確實施. 在 Linkerd 中，重試是用各種奇特的東西參數化的，比如重試預算。 （重試預算），因為執行此類事情的頭腦簡單的方法肯定會導致出現所謂的“請求雪崩” （重試風暴） 以及分佈式系統特有的其他問題。
- 持續使用最有效. TLS 機制只有在所有地方都應用時才有意義。
因為這些功能是在代理層（而不是在應用層）實現的，所以服務網格將它們暴露在 平台，不是應用程序。 因此，服務用什麼語言編寫、使用什麼框架、誰編寫以及為什麼編寫都無關緊要。 代理的工作超出了所有這些細節，並且此功能的基本基礎，包括配置、更新、操作、維護等任務，僅存在於平台級別。
服務網格功能示例
總之，服務網格不是可靠性、可觀察性或安全性的完整解決方案。 這些領域的範圍意味著服務所有者、Ops/SRE 團隊和其他公司利益相關者的強制參與。 服務網格僅在平台級別為每個區域提供一個“切片”。
為什麼服務網格現在變得流行？
你現在可能想知道：好吧，如果服務網格這麼好，我們為什麼不在十年前開始在堆棧上部署數百萬個代理？
這個問題有一個平庸的答案：十年前每個人都構建單體，沒有人需要服務網格。 這是事實，但在我看來，這個答案沒有抓住要點。 甚至十年前，微服務的概念作為創建大型系統的一種有前途的方式在 Twitter、Facebook、Google 和 Netflix 等公司中得到了廣泛討論和應用。 普遍的看法 - 至少在我接觸過的部分行業 - 是微服務是構建大型系統的“正確方法”，即使它非常困難。
當然，雖然十年前就有公司在利用微服務，但他們並沒有到處貼代理來形成服務網格。 然而，如果你仔細觀察，他們做了類似的事情：許多這樣的公司強制使用一個特殊的內部庫來進行網絡連接（有時稱為胖客戶端庫， 胖客戶端庫).
Netflix 有 Hysterix，Google 有 Stubby，Twitter 有 Finagle 庫。 例如，Finagle 已成為 Twitter 上每項新服務的強制性要求。 它處理連接的客戶端和服務器端，允許重複請求，支持請求路由、負載平衡和計量。 它在整個 Twitter 堆棧中提供了一致的可靠性和可觀察性層，無論服務在做什麼。 當然，它只適用於 JVM 語言，並且基於必須用於整個應用程序的編程模型。 但是，它的功能幾乎與服務網格相同。 （實際上，Linkerd 的第一個版本只是以代理形式包裝的 Finagle。）
因此，十年前不僅有微服務，還有特殊的原型服務網格庫，它們解決了今天服務網格所解決的相同問題。 然而，服務網格本身當時並不存在。 在她出現之前必須有另一個轉變。
而這就是更深層次的答案所在，隱藏在過去 10 年發生的另一個變化中：部署微服務的成本急劇下降。 上面提到的十年前使用微服務的公司——Twitter、Netflix、Facebook、Google——都是規模龐大、資源豐富的公司。 他們不僅有需求，而且有能力構建、部署和運行基於微服務的大型應用程序。 Twitter 工程師為從單一服務方法轉向微服務方法所投入的精力和努力是驚人的。 （老實說，它確實有效。） 這種基礎設施操作對於小公司來說是不可能的。
讓我們轉到現在。 如今，有些初創公司的微服務與開發人員的比例為 5:1（甚至 )，而且，他們成功地對付了他們！ 如果一家 5 人的初創公司能夠毫不費力地運行 50 個微服務，那麼顯然可以降低實施成本。
Monzo 中的 1500 個微服務； 每條線都是規定的網絡規則，允許流量
運行微服務成本的顯著降低是單一過程的結果： 容器越來越受歡迎 и 編排器. 這正是對是什麼促成了服務網格的出現這個問題的深刻回答。 相同的技術使服務網格和微服務都具有吸引力：Kubernetes 和 Docker。
為什麼？ 好吧，Docker 解決了一個大問題——打包問題。 通過將應用程序及其（非網絡）運行時依賴項打包到容器中，Docker 將應用程序轉變為可在任何地方託管和運行的可替代單元。 同時，大大簡化了操作。 多種語言 堆棧：由於容器是執行的原子單元，因此對於部署和操作目的，無論是 JVM、Node、Go、Python 還是 Ruby 應用程序，內部的內容都無關緊要。 你只要運行它就可以了。
Kubernetes 將一切提升到一個新的水平。 既然有一堆“可執行的東西”和許多機器可以運行它們，就需要一種可以將它們相互匹配的工具。 從廣義上講，你給 Kubernetes 很多容器和很多機器，它把它們相互匹配（當然，這是一個動態的、不斷變化的過程：新的容器在系統中移動，機器啟動和停止等等。但是， Kubernetes 考慮到了所有這些）。
一旦 Kubernetes 搭建起來，部署和運行一個服務所花費的時間與部署和運行十個服務的成本相差不大（實際上，部署和運行 100 個服務幾乎是一樣的）。 添加到這個容器作為鼓勵多語言實現的打包機制，你有大量的新應用程序實現為用多種語言編寫的微服務，這正是服務網格非常適合的環境。
那麼，我們就來回答為什麼服務網格的想法現在流行起來的問題：Kubernetes 為服務提供的統一性直接適用於服務網格面臨的操作任務。 您將代理打包在容器中，讓 Kubernetes 盡可能地粘住它們，瞧！ 在輸出端，您會得到一個服務網格，而 Kubernetes 控制著其部署的所有機制。 （至少從鳥瞰圖來看是這樣。當然，這個過程有很多細微差別。）
總結一下：service mesh 之所以現在流行而不是十年前，是因為 Kubernetes 和 Docker 不僅顯著增加 需要 其中，將應用程序的實施簡化為多語言微服務集，但也顯著減少了 費用 通過提供部署和維護 Sidecar 代理公園的機制來運行。
為什麼有這麼多關於服務網格的討論？
慎重：在本節中，我採用了各種假設、推測、捏造和內部信息。
搜索“服務網格”會出現一堆回收的、低熱量的內容、奇怪的項目，以及一個值得回音室的萬花筒。 任何時髦的新技術都有這個，但在服務網格的情況下，這個問題尤為尖銳。 為什麼？
好吧，這部分是我的錯。 通過無數的博客文章和像本文這樣的文章，我已盡最大努力利用每一個機會來推廣 Linkerd 和服務網格。 但我沒有那麼強大。 要真正回答這個問題，我們需要談談一般情況。 不提一個項目就不可能談論它： 是由谷歌、IBM 和 Lyft 聯合開發的開源服務網格。
（這三個公司的角色非常不同：Lyft 的參與似乎僅限於命名；他們編寫了 Envoy，但不使用或參與 Istio 的開發。IBM 參與 Istio 的開發並使用它。谷歌在很大程度上參與了 Istio 的開發，但據我所知，實際上並沒有使用它。）
Istio 項目有兩點值得注意。 首先，尤其是谷歌在推廣上的巨大營銷力度。 我估計目前大多數了解服務網格概念的人首先是通過 Istio 了解到它的。 第二個特點是 Istio 的反響有多糟糕。 在這件事上，我明明是利害關係人，但盡量保持客觀，還是忍不住 ，不是很具體（雖然不是唯一的：想到 systemd， ...) 用於開源項目。
（在實踐中，Istio 似乎不僅在復雜性和 UX 方面存在問題，而且在性能方面也存在問題。例如，在 由第三方進行，專家發現Istio的尾延遲比Linkerd高100倍的情況，以及資源不足的情況，當Linkerd繼續正常運行時，Istio完全停止工作。）
撇開我關於為什麼會發生這種情況的理論不談，我相信圍繞服務網格的過度炒作是由於谷歌的參與。 即，以下三個因素的組合：
- Google 對 Istio 的大力推廣；
- 對項目適當的不贊成、批評態度；
- 最近Kubernetes的火爆，讓人記憶猶新。
這些因素共同構成了一種令人陶醉的缺氧環境，在這種環境中，理性判斷的能力減弱，只剩下各種各樣的奇異生物。 .
從 Linkerd 的角度來看，這是……我會把它描述為喜憂參半。 我的意思是，服務網格進入主流真是太好了——2016 年 Linkerd 首次出現時情況並非如此，很難引起人們對該項目的關注。 現在沒有這個問題了！ 但壞消息是，今天的服務網格情況非常混亂，幾乎不可能找出哪些項目真正屬於服務網格類別（更不用說找出哪個最適合特定用例了）。 這肯定會妨礙每個人（並且在某些情況下 Istio 或其他項目肯定比 Linkerd 更好，因為後者不是一個放之四海而皆準的解決方案）。
從 Linkerd 的角度來看，我們的策略是忽略噪音，繼續專注於解決社區中的實際問題，基本上等待炒作平息。 最終炒作會平息，我們可以繼續安心工作。
在那之前，我們都必須耐心等待。
服務網格對我這個謙虛的軟件工程師有用嗎？
以下問卷將有助於回答這個問題：
您是否專門處理業務邏輯的實施？ 在這種情況下，服務網格對你沒有用。 也就是說，當然，你可能對它感興趣，但理想情況下，服務網格不應該直接影響你環境中的任何東西。 繼續為你得到報酬而努力。
您是否在使用 Kubernetes 的公司維護平台？ 是的，在這種情況下你需要一個服務網格（當然，如果你不使用 K8s 只是為了運行單體或批處理——但我想問你為什麼需要 K8s）。 很可能，您會發現自己處於不同人編寫的許多微服務的境地。 它們都相互交互，並被捆綁在一堆運行時依賴項中，您需要找到一種方法來處理所有這些問題。 使用 Kubernetes 可以讓您“為自己”選擇服務網格。 為此，請熟悉它們的功能和特性，並回答是否有任何可用項目完全適合您的問題（我建議您從 Linkerd 開始研究）。
您是否正在為一家不使用 Kubernetes 但使用微服務的公司運行平台？ 在這種情況下，服務網格將對您有用，但它的使用意義重大。 當然可以 模擬 通過託管一堆代理來實現服務網格，但 Kubernetes 的一個重要優勢恰恰是部署模型：手動維護這些代理將需要更多的時間、精力和成本。
你在一家使用單體應用的公司負責平台嗎？ 在這種情況下，您可能不需要服務網格。 如果您正在使用具有明確定義且很少更改交互模式的整體（甚至是一組整體），那麼服務網格幾乎無法為您提供幫助。 所以你可以忽略它並希望它像噩夢一樣消失......
結論
或許，服務網格仍不應該被稱為“世界上最炒作的技術”——這個可疑的榮譽可能屬於比特幣或人工智能。 也許她在前五名。 但是，如果你突破噪音和喧囂的層次，就會發現服務網格為那些在 Kubernetes 中創建應用程序的人帶來了真正的好處。
我希望您嘗試 Linkerd——將其安裝在 Kubernetes 集群中（甚至是筆記本電腦上的 Minikube） 你可以親眼看到我在說什麼。
常見問題
- 如果我忽略服務網格，它會消失嗎？
- 我必須讓你失望：服務網格已經存在很長時間了。
— 但我不想使用服務網格！
- 好吧，沒有必要！ 只需閱讀我上面的調查問卷，看看您是否至少應該熟悉它的基礎知識。
— 舊的 ESB/中間件難道不是加了新醬料的嗎？
- 服務網格處理操作邏輯，而不是語義。 企業服務總線（). 保持這種分離有助於服務網格避免同樣的命運。
- 服務網格與 API 網關有何不同？
有一百萬篇關於這個主題的文章。 只是谷歌。
Envoy 是服務網格嗎？
- 不，Envoy 不是服務網格，它是代理服務器。 它可用於組織服務網格（以及更多 - 它是通用代理）。 但就其本身而言，它並不是一個服務網格。
- 網絡服務網格 - 它是服務網格嗎？
- 不。 儘管名稱如此，但這並不是服務網格（您如何看待營銷的奇蹟？）。
- 服務網格是否有助於我基於消息隊列的反應式異步系統？
- 不，服務網格不會幫助你。
- 我應該使用哪個服務網格？
- ，不用多想。
- 這篇文章糟透了！ / 作者 - 在肥皂上！
— 請把它的鏈接分享給你所有的朋友，讓他們相信這一點！
致謝
正如您可能從標題中猜到的那樣，這篇文章的靈感來自 Jay Kreps 的精彩論文“”。 十年前我在 Linked In 上接受采訪時認識了 Jay，從那以後他一直是我的靈感來源。
雖然我喜歡稱自己為“Linkerd 開發人員”，但實際上我更像是項目中 README.md 文件的維護者。 今天在 Linkerd 上工作 , , 人，如果沒有驚人的貢獻者和用戶社區，這個項目就不可能實現。
最後，特別感謝 Linkerd 的創建者， （第一），他在多年前和我一起一頭扎進了服務網格的所有這些大驚小怪中。
譯者PS
另請閱讀我們的博客：
- «“;
- «“;
- «“;
- «“;
- «“。
來源： www.habr.com