如果你是後端軟件工程師，那麼在過去幾年裏，service mesh這個詞很可能已經深入你的潛意識了。各種事情神奇地匯聚在一起，結果就是service mesh就像Katamari ball一樣在業界滾來滾去，不斷地獲取更大的市場份額和聲望，同時絲毫沒有短期內消停的跡象。
service mesh誕生於雲原生生態的昏暗激流之中。這就意味着service mesh的大量內容是很悲劇地從“低營養”到——用學術名詞來說就是——“基本一無是處”。然而，如果能夠撥開這些迷霧，你會發現service mesh也有一些切實且重要的價值。
在本文中，我會努力提供一份誠實的、有深度的、聚焦於工程師的service mesh指南。我要談的不僅有service mesh是什麼（What），而且有service mesh爲什麼會產生(Why) 以及爲什麼在現在這個時間(Why Now)爆發。最後，我會努力闡述清楚爲什麼我認爲service mesh這項技術能夠贏得如此狂熱的關注——而這本身也是一個很有趣的故事。
我是誰
我是William Morgan，是Linkerd的創始人之一。 Linkerd是第一個service mesh項目，也是從這個項目開始，service mesh這個稱呼才正式誕生。同時我也是Buoyant的CEO。 Buoyant是一家初創企業，主要構建如Linkerd和Dive這一類便捷的service mesh工具。
因此你可能已經想到了，我對於service mesh這個話題是有些偏見和固執看法的。既然這樣，我就要儘量刨除春秋筆法（除去“爲什麼大家討論如此熱烈”一章。在這章我會闡述我自己的觀點），並用儘可能客觀的方式來撰寫本文。需要有理有據的時候，我主要拿Linkerd來舉例子；然而在Linkerd和其他service mesh實施方案有所不同的時候，我會直接指出。
好了，我們書歸正傳。
service mesh是什麼？
儘管名聲在外，service mesh從架構上來說十分簡單。service mesh不過就是一堆“緊挨着”各項服務的用戶代理（userspace proxies），外加一組任務管理流程（a set of management processes）。關於何爲“緊挨着”，我們之後將稍作解釋。代理在service mesh中被稱爲數據層（data plane），管理流程被稱爲控制層（control plane）。數據層截獲不同服務之間的調用並對其進行“處理”；控制層協調代理的行爲，並且爲你（也就是操作者）提供API，使你能夠操控和測量整個網格。
這些代理是什麼？他們是Layer 7的TCP代理，就像是haproxy和NGINX。代理的選擇多種多樣，Linkerd採用的是簡稱爲linkerd-proxy的Rust代理，這是我們專爲service mesh而創建的。其他的網格使用了不盡相同的代理；Envoy是個常見的選擇。當然了，代理的選擇是個純粹的實施細節了，和service mesh本身無關。
代理都做些什麼？他們當然是代理出入服務的各項調用了。（嚴格地說，他們同時充當了“代理”和“反向代理”的角色，同時處理了呼入和呼出的調用。）他們同時還實現了聚焦於不同服務之間調用的特性集。聚焦於服務之間流量的特性使得service mesh區別於API網關或者入口代理，後兩者整體上聚焦於從外部進入集簇的調用。
以上就是數據層。控制層更加簡單：就是一堆提供數據層有序運行所需的所有機制的組件集合，這些機制包括服務發現、TLS證書頒發、度量聚合……諸如此類。數據層調用控制層以通知其行爲；控制層反過來提供API以讓用戶整體上調整和檢測數據層的行爲。
上圖就是Linkerd的控制層和數據層的示意圖。可以看到，控制層擁有數個不同的組件，包括小型的從代理匯聚度量數據的Prometheus用例和諸如destination（服務發現）、identity（證書確認）和public-api（Web和CLI端點）的組件。作爲比較，數據層只是挨着應用用例的單個Linkerd-proxy。這個只是邏輯示意圖；一旦部署，每個控制層組件會有三個副本，每個數據層代理會有成百上千個。
示意圖中的藍色方框表示Kubernetes池子的邊界線。可以看到，Linkerd-proxy容器實際上和應用容器運行在同樣的池子裏。這一模式即sidecar容器。
service mesh的架構有幾重重大內涵。首先，因爲代理特性集（proxy featureset）是設計於用在服務到服務的調用的，service mesh只有在應用是建立在服務之上的時候纔有意義。你可以在單體應用上使用service mesh，但是那就需要費很大勁兒去運行單個的代理，同時特性集並不適用。
第二個後果是，service mesh需要很多很多的代理。實際上，Linkerd爲每個服務用例都增加一個Linkerd-proxy 代理。（有些其他網格實施時爲每個節點/主機/VM 增加一個代理。總之都會有很多代理。）如此大量的使用代理本身也是有幾方面內涵的：
- 不論這些數據層代理是什麼，其速度都要越快越好。每次調用都新增了兩個代理，一個是在客戶端的，一個是在服務端的。
- 同時，代理需要體積小且能耗低。每個代理都要消耗內存和 CPU，並隨着應用數量增加而線性增長。
- 要用系統來部署和升級這些代理。沒人願意手動操作這些的。
然而，這也就是從目力所及之處，我們能看到的service mesh爲何物了：部署大量的用戶代理來對內部的、服務到服務的流量做管理，同時用控制層來管理其行爲並對代理產生的數據做查詢。
前面說的是 What，下面開始講 Why。
Service mesh有什麼意義？
如果你是第一次聽說service mesh的理念，那你的第一反應是微微驚慌也就不足爲奇了。service mesh的設計就表明，它不僅爲應用增加延遲，而且還消耗資源，同時引入了一大堆組件（machinery）。前一分鐘你安裝了service mesh，下一分鐘你突然陷入要管理成百上千個代理的境地。有誰會對這種事情樂此不疲呢？
答案包含兩個方面。第一方面是，部署這些代理的成本可以大幅降低，這要歸功於雲原生生態的發展。稍後詳述。
第二個方面更加重要，service mesh的這種設計實際上是把傳統邏輯引入到系統當中的絕佳方法。你不僅可以直接增加許多功能，而且增加功能時可以不改變整個生態。實際上，整個service mesh模型都是基於這一視角的：在多服務系統中，不論各個服務的功能是什麼，服務間的流量都是插入新功能的理想位置。
以Linkerd爲例——其他大多數網格也都是如此，Linkerd擁有一套包括HTTP/2和gRPC[1]的特性集，其主要聚焦於HTTP調用。這個特性集十分廣泛，不過可以分爲以下三類：
- 可靠性功能。請求重試、超時、canaries（流量分割/遷移）等。
- 監測性功能。單個服務或者路徑的成功率、延遲和請求量的收斂；服務拓撲圖的繪製等。
- 安全性功能。雙向TLS、通道控制等。
這裏的許多功能都直接在請求層（request level）進行操作，也就是“L7代理”。例如，如果服務Foo向服務Bar發起了HTTP請求，Foo這一側的Linkerd-proxy可以負載均衡，這一均衡可以基於Bar的每個用例的延遲觀測來智能調用；如果失敗了並且是冪等的，則可以重新發起請求；他可以記錄相應代碼和等待時間，諸如此類。類似的，Bar這一側的Linkerd-proxy可以拒絕未經允許的調用，或者超過頻率限制的調用；他可以從自己的視角來紀錄等待時間；諸如此類。
代理在連接層（connection level）也可以“有所作爲”。例如，Foo這一側的Linkerd-proxy可以初始化一個TLS鏈接，Bar這一側的Linkerd-proxy可以終止這個鏈接，同時雙方都可以驗證對方的TLS證書[2]。這樣不僅能加密不同的服務，而且能加密每個服務的身份—— Foo和Bar都能夠“證明我是我”。
不論是在請求層還是連接層，不得不提的就是，service mesh的特性本質上是操作層面的。在Linkerd中，請求負載的語法不需要任何更改，比如向JSON添加新的字段或者轉換 protobuf。這是與ESB和中間件的顯著不同。
以上就是service mesh能夠提供的特性。那爲什麼不直接把這些實施到應用裏呢？爲什麼要費力折騰這麼多代理呢？
爲什麼service mesh很有用？
service mesh的特性集很有意思，不過其核心價值卻不在這裏。當然了，我們可以直接把這些功能實施到應用裏面。（實際上，稍後我們會看到這正是service mesh的緣起）。如果只能用一句話來描述的話，service mesh的價值是：service mesh 提供了對於運行現代服務端軟件（modern server-side software）至關重要的特性集，從而使其在整個技術棧是統一的並且是與應用代碼解耦的。
我們一點點解釋前面這句話。
對於運行服務端軟件至關重要的特性集。如果你是在開發一款服務端交易系統，這個系統連接了公網、從外部接受請求並在短時間內回覆請求——想想 web 應用、API 服務器和大量的現代服務端軟件——如果你正在把這個系統打造爲以同步的方式相互通訊的服務集合，如果你正在持續修訂這個軟件以增加更多功能，如果你接到任務說要在修改系統的同時保持系統運行——恭喜你，你就是在開發現代服務端軟件。前面列出的所有的功能對你來說都是不可或缺的。應用必須可靠、必須安全、必須能夠讓我們監測到所有行爲。這一切恰恰都是service mesh大展宏圖之地。
（我說一點個人保留意見。這是打造服務端軟件的現代方法。現在世界上還有不少人在建造單體軟件或者“響應式微服務”或者其他東西，那些都不適合上述定義。有人對此持有不同意見。我反過來也不贊同他們的“不同意見”，我認爲他們的觀點是“錯的”——但是不管怎樣，service mesh對他們都沒什麼用。）
在整個技術棧是統一的。service mesh提供的功能不僅是很重要的，而且這些功能適用於你的應用的所有服務，而無關乎這些服務是用什麼語言寫的、在採用什麼框架、誰寫的代碼、如何部署的或者其他的開發與部署細節。
是與應用代碼解耦的。最終，service mesh不僅僅提供了跨棧統一的功能，而且是以一種不要求任何應用更改的方式實現的。service mesh功能的全部所有權——包括配置、更新、運營（operation）、維護等等的運營權限——都是僅存在於平臺層面的，是獨立於應用之外的。應用可以在不捲入service mesh的情況下進行更改，service mesh也可以在不捲入應用的情況下進行更改。
簡言之：service mesh不僅提供了至關重要的功能，而且是採用全局的、統一的和獨立於應用的方式提供的。儘管的確service mesh的功能可以在服務的代碼中實施（甚至是作爲連接到每個服務的庫），但這種方式無法提供作爲service mesh價值核心的解耦性和統一性。
你要做的全部工作也僅僅是增加大量的代理。我保證，我們馬上就會談到增加那麼多代理的操作成本。不過我們首先要稍作駐足，從人的視角來檢驗一下這個解耦的觀點。
service mesh對哪些人羣纔有用？
再好的技術，要想真正發揮作用，必須得到人類的採用纔可以，這可能是聽起來有點兒彆扭。那麼，誰會採用service mesh技術？誰又會從中收益？
如果你正在開發我於前文描述的現代服務端軟件，你大致可以把團隊分爲兩類，一類是服務開發者（ service owners），主要開發業務邏輯；一類是平臺開發者（ platform owners），主要開發這些服務得以運行的內部平臺。在小型組織中，這兩類可能是同一批人，但是隨着組織壯大，一般這些角色會更加細分甚至進一步再分。（關於 devops 的性質變遷、微服務對組織的影響等都可以展開論述，不過我們現在先把那些論述作爲已知條件來對待。）
從這個角度來看，首先能從service mesh受益的是平臺開發者。畢竟，平臺開發團隊的目標是打造服務開發者可以運行其服務邏輯的內部平臺，而且是從組織運作角度讓服務開發者儘可能地保持獨立。service mesh不僅提供了實現這一目標的關鍵特性，而且是以一種不會反過來影響服務開發者獨立性的方式實現的。
服務開發者同樣受益，不過方式更加隱蔽。服務開發者的目標是儘可能高效地開發業務邏輯服務。在操作機制上花的精力越少，他們的工作就越簡單。不用爲諸如重試策略或者 TLS 這樣的實施花心思，相信平臺會解決後顧之憂後，他們就可以集中精力在業務邏輯問題上了。這對於他們來說也已經是很大的收益了。
在平臺開發者和服務開發者之間解耦的組織價值（organizational value）再誇大都不爲過。實際上，我認爲這是service mesh有價值的核心原因。
在Linkerd最早的採用者之一告訴我們他們爲什麼要用service mesh的時候，我們就學習到了這個：service mesh使得他們“不用非得和人溝通”。他們是一家大公司的平臺團隊，正在向Kubernetes遷移。因爲他們的 APP 處理的是敏感信息，所以他們希望在集羣上加密所有通信。公司有上百個服務和上百個開發者團隊，他們也沒有寄希望於說服每個開發團隊在路線圖中增加 TLS。通過安裝Linkerd，他們把這些功能的所有權從開發者手中轉移到了平臺團隊。對於開發團隊，增加 TLS 完全是份兒外的工作；對於平臺團隊，這就是最高優先級的事情。Linkerd更多解決的是組織問題（an organizational problem），而不是技術問題。
簡言之，service mesh更像是社會-科技問題（a socio-technical problem）的解決之道，而不是純技術問題的解決方法。[3]
service mesh能解決我的所有問題嗎？
當然……不能了。
看看前面列舉的三類特性——可靠性、安全性和監測性——你就明白service mesh對其中任何一類都不是包治百病的。在已知服務是冪等的情況下，Linkerd可以重試請求；如果服務器完全下線了，Linkerd無法決定向用戶返回何種信息——必須由應用來做出那些決定。Linkerd可以回報成功率等信息，但是卻無法深入服務內部並彙報內部參數——應用必須建立自己的指標。Linkerd可以“免費”做雙向 TLS 之類的事情，但是安全方案可遠不止於此。
service mesh提供的是前述三類功能中屬於平臺特性的子功能。具體到這個，我指的是以下功能：
- 獨立於業務邏輯。首先，計算Foo和Bar相互調用的流量延遲的柱狀圖的機制，必須與Foo要調用 Bar的原因完全無關。
- 正確實施有困難。因爲本地重試方式肯定會導致“重試風暴”和其他分佈式系統的失敗模式，所以Linkerd的重試由類似於重試預算（retry budgets）的複雜的東西進行參數化。
- 統一實施更有效。雙向 TLS 的機制決定了只有所有人都在用的時候他纔有用。
因爲這些特性是在代理層而非應用層部署的，service mesh在平臺層而非應用層提供這些特性。這樣service mesh就無關乎服務使用何種語言編寫、採用了什麼框架、誰寫的代碼或者服務如何運行等事項。這些代理獨立於前述所有事項運行，而這些功能的所有權僅存在於平臺層面——這些功能包括配置、升級、操作和維護等的操作所有權。
service mesh特性實例
| 監測性 | 可靠性 | 安全性 | |
|---|---|---|---|
| service mesh | 服務成功率 | 請求重試 | 所有服務的雙向 TLS |
| 平臺（非service mesh） | 日誌聚合 | 數據集的多副本 | 空閒時的數據加密 |
| 應用 | 應用內特性使用情況的檢測 | 整個組件失效時處理故障 | 確保用戶僅對自身數據有權限 |
總結一下：service mesh並非可靠性、監測性或者安全性的完整解決方案。 這些領域的主導權涉及的範圍更廣，必然包含服務開發者、運維和SRE團隊以及組織的其他部門。service mesh可以提供的僅僅是這三個領域在平臺層的“切片”。
爲什麼是到現在service mesh纔可行呢？
此時你可能會問自己：如果service mesh這麼牛，我們爲什麼不是十年前就在技術棧中添加上百萬的代理呢？
最淺顯的回答就是，十年前大家都在開發單體應用，所以沒人需要service mesh。這是真的，但我覺得這個說法不在點上。甚至在十年前，微服務的概念作爲一種構建高擴展系統的彈性方式都已經在廣泛討論，並且在諸如 Twitter、Facebook、Google 和 Netflix 的公司公開地大規模實踐了。普遍的觀點——至少在我接觸到的部分是，微服務是構建高擴展系統的“正確方式”，儘管其過程極其痛苦。
當然了，儘管十年前就有公司在運用微服務，他們大概率沒有到處安裝代理從而形成service mesh。如果細細觀察，你就會發現他們在做相關的事情：其中許多公司都授權使用了一種用於網絡通信的內部庫（有時稱爲“胖客戶端”庫）。Netflix 的是 Hysterix 庫，Google 的是 Stubby 庫，Twitter 的是 Finagle 庫。例如 Finagle 是 Twitter 的每個新建服務強制使用的，同時處理客戶端和服務端的連接、實施重試、請求路徑、負載均衡和檢測。他提供了對整個 Twitter 技術棧的連續的可靠性和監測性層，獨立於這些服務本身在做的事情。當然了，它僅支持 JVM 語言，並且你必須圍繞它的編程模式構建整個 APP，但是他提供的操作特性幾乎和service mesh的完全一致。[4]
所以，十年前不僅有微服務，而且有很多類似service mesh的庫，現在的service mesh解決的問題大部分都能用那些庫來解決。但那時我們沒有service mesh。有些東西必須首先革新。
這就是更深層的答案所在，這個答案深埋在過去十年發生的鉅變之中：部署微服務的成本已經大幅下降了。前面我列出的十年前在公開使用微服務的公司——Twitter、Netflix、Facebook、Google——都有着極大的規模和極其豐富的資源。他們不僅有需求，而且也有能力去構建、部署和維護大量的微服務應用。單單是 Twitter 從單體應用向微服務遷移過程的工程時間和產能消耗都是超乎想象的[5]，這種類型的基礎設施操作對於小公司是根本不可能的。
今非昔比，今天你可以看到微服務與開發者比例是 5:1 甚至 10:1 的創業公司——不僅如此，他們還能夠玩得轉。如果 5 個人的初創企業運行 50 個微服務是值得稱讚的方式，那麼肯定是有什麼東西降低了採用微服務的成本。
運營微服務的成本的大幅下降是容器和容器編排大量採用的結果。這也就是“哪些變化讓service mesh得以實現”的問題的深層答案。讓service mesh切實可行的正是讓微服務切實可行的東西：Kubernetes和Docker。
原因何在？Docker解決了一大難題，也就是打包問題。Docker使得我們可以將 APP 及其（非網絡）的運行時依賴項打包到一個容器中，APP 現在就變成一個任意安放和隨處運行的可替代單元。也是基於同樣的原因，Docker使得運行 a*polyglot *堆棧變得及其簡單：容器是最小的執行單元，所以對於部署和操作目的而言，容器內部是什麼、他是 JVM APP 還是 Node APP 還是 Go 的或者 Python 的或者 Ruby 的，就根本無關緊要了。
Kubernetes解決了下一步問題：現在我有了一堆“可執行的東西”，同時我也有一堆“可以執行這些東西的東西”（也就是機器），那我就需要二者之間的映射。在更廣義的層面上，你給Kubernetes一堆容器和一堆機器，Kubernetes就會計算出這個映射。（這個映射當然是動態的並且一直在變化的，因爲新的容器不斷涌入系統，運行過程也會不斷增減機器，諸如此類。但是Kubernetes可以解決。）
一旦你在運行Kubernetes，運行一個服務的部署時間成本和運行 10 個服務的差別不大，並且實際上和運行 100 個的差別也不大。將Kubernetes與容器結合，容器相當於鼓勵 polyglot 實施的打包機制，則結果就是一堆用各種語言編寫的、作爲微服務來實施的新應用——這正是service mesh最適合運行的環境。
最終，我們得出了爲什麼service mesh現在纔可行的原因：Kubernetes爲服務提供的一致性也正是可以直接適用於service mesh面臨的操作挑戰的。你將代理打包到容器中，告訴Kubernetes處處跟蹤他們，然後你就得到service mesh了，Kubernetes爲你解決了所有的部署時間機制。[6]
總結一下：爲什麼service mesh在當下而不是在十年前可行的原因是：Kubernetes和Docker的崛起不僅大幅增加了運行service mesh的需求，而且大幅降低了運行service mesh的成本。前一方面通過讓構建 polyglot 微服務架構的應用更加簡單來實現，後一方面通過提供部署和維護 sidecar 代理編組的機制來實現。
爲什麼人們對service mesh討論得這麼熱烈？
內容警告：此部分內容會有推測、猜想、內幕和個人意見。
只需要搜索“service mesh”，任何人都會發現一幅卡夫卡式的狂熱全景，其中滿是迷惑不清的項目、低價值的重複內容和通常都是迴音室般的歪理邪說。
好吧，這種情況部分歸咎於我。我已經盡了最大的努力，抓住每個機會，在不計其數的博文和 podcast 和像這篇一樣的文章裏，大講特講Linkerd和service mesh。但是我也不是特別厲害。真要回答這個問題，我必須聊聊service mesh全景。如果避開了一個特別的項目，Istio，那就無法討論這個全景。Istio是一款被視爲Google、IBM和Lyft合作項目的開源的service mesh。[7]
Istio引人注目的有兩個方面。第一，他背後有 Google 的大量的市場力量在推動。據我估計，今天知道service mesh的大部分人都是通過Istio知道這個概念的。第二，Istio的接受情況實在太慘了。顯然我司產品也是service mesh競賽中的一員，不過我儘量保持客觀，在我看來Istio已經引發了對於開源項目很不常見（儘管並非從未聽說[8]）的明顯的公衆反噬。[9]
關於正在發生的事情，撇開我的個人理論不談，我相信 Google 的介入纔是service mesh如火如荼的真正原因。特別是，以下三點的結合形成了一種沉重的、缺氧的環境，在這種環境中，理性思考的空間所剩無幾，同時對於雲原生的詭異的“鬱金香狂熱”持續存在着：
- Google 在大力推行Istio
- Istio的接受情況十分慘淡
- Kubernetes飛速崛起
當然了，從Linkerd的角度看，這個……我覺得我會將之描述爲福禍兼具。我指的是，service mesh現在終於是個“東西”了——這可不是 2016 年Linkerd剛問世的時候了，你要知道吸引人們的注意力是非常困難的。我們不再有這個問題了。但不好的是，service mesh全景是如此讓人分辨不清，要明白哪些項目是service mesh是如此困難，更不用說哪個service mesh與你的用例最匹配了。這對所有人都是有百害而無一利的。（當然有些場合下Istio或者其他項目是比Linkerd更合適的選擇——遠沒有萬全之策。）
在Linkerd這一方，我們的戰略是忽視噪音，繼續專注於爲社區解決真正的問題，然後基本就是等着時過境遷了。炒作終將消散，我們繼續生活。
但與此同時，我們所有人不得不共同經歷這一切。
那麼，作爲一個小小的程序員，我該關注service mesh嗎？
如果你是軟件工程師，關於你是否應該關注service mesh，我的基本建議如下。
如果你是單純的業務邏輯實施開發角色（a pure business-logic-implementin’ developer role）： 不用，你真的不用關注service mesh。我說的是，當然歡迎你關注service mesh，但是service mesh不會對你的工作有任何直接的影響。堅持開發那些讓周圍人付費的甜甜美美的業務邏輯吧。
如果你是一名在採用Kubernetes的機構中的平臺開發人員：是的，你百分百應該關注。除非你是在採用Kubernetes來運行單體應用或者運行批處理過程（這種情況下，我要鄭重地問一下爲什麼要用Kubernetes），否則你將會陷入如此境地：大量的微服務、各個微服務全都是由他人編碼的、微服務之間相互通信、微服務綁定在一起形成一大團運行時依賴項。你需要一種方式來解決這種困境。因爲你在運行Kubernetes，所以你就有好幾個service mesh選項，這時候你需要周全考慮後決定選擇哪個service mesh或者是否選擇其中任何一個。（先從Linkerd開始吧。）
如果你是一名沒采用Kubernetes的機構中的平臺開發人員，但是在“採用微服務”：是的，你應該關注，但是情況很複雜。當然了，你需要到處部署大量代理才能獲得service mesh的價值，但是Kubernetes的好的地方就在於部署模型。如果你不得不自己部署這些代理，那你的ROI方程將會看上去大不相同。
如果你是一名在開發單體應用的機構中的平臺開發人員：不用，你完全不用關注。如果你在運行單體應用，甚至是一堆定義良好並且通信模式不經常變化的“單體應用集合”，那麼service mesh並不能增加多少東西，你也可以忽視他並隨他遠去。
總結
對於“世界上炒得最熱的技術”一稱，service mesh很可能名不副實——可能比特幣或者 AI 現在更加火熱，而service mesh估計能排進前五名吧。但是如果你能透過噪音看本質，對於在Kubernetes上構建應用的任何人來說，service mesh都是提供了真正價值的。
最終，我還是希望你能試試Linkerd——在Kubernetes集羣上甚至是筆記本電腦的 Minikube 上，Linkerd大概只要 60 秒就能安裝完畢——你就可以親自檢驗下我通篇都在講的是什麼了。
問答
如果我對service mesh這一切視而不見，他是不是會隨風消散？
很不幸，service mesh就在這裏，不離不棄。
但是我不想用service mesh。
那就別用。不過請看看我的前述導引確定下你是否需要領會service mesh。
service mesh是不是 ESB/中間件又來了一遍？
service mesh集中於操作邏輯而非業務邏輯。這就是企業服務的失敗之處，保持二者的分離對於service mesh避免相同命運而言至關重要。
service mesh與 API gateway有何區別？
這樣的文章汗牛充棟。Google 一下會不會？
Envoy 是service mesh嗎？
不是，Envoy 不是service mesh。Envoy 是代理，他可以用來組建service mesh（以及其他很多事情。Envoy 是通用目的的代理）。但是它本身不是service mesh。
Networkservice mesh是service mesh嗎？
不是。儘管名稱裏有service mesh，Networkservice mesh並不是service mesh。（市場宣傳很搞笑，對吧？）
service mesh在基於響應式異步消息隊列的系統能用嗎？
不能，service mesh無能爲力。
我該使用哪種service mesh？
Linkerd。哈哈。
我覺得這篇文章好爛/我覺得你不行。
請把本文鏈接分享給你所有的朋友，這樣他們就能夠看到這篇文章有多爛/我有多不行了。
致謝
你可能已經從標題裏猜到了，這篇文章是受 Jay Krep 關於 Logs 的經典好文 The Log: What every software engineer should know about real-time data’s unifying abstraction 的啓發而來的。我在大概十年前 LinkedIn 面試時認識了 Jay，從那時起他就是我的靈感源泉。
儘管我喜歡自稱Linkerd維修工，事實上我基本上是維護Linkerd的 README.md 文檔的。如今Linkerd是許多、許多、許多、許多人的共同作品，並且沒有社區的衆多貢獻者和採納者也是無法實現的。
最後，特別緻謝Linkerd的發明人 Oliver Gould , 許多年前我們一同縱身一躍從此上了service mesh的賊船。
註腳
- FromLinkerd’s perspective, gRPC is basically the same as HTTP/2, you just happen to be using protobuf in the payload. From the developer’s perspective, of course, it’s quite different.
- “Mutual” means that the client’s certificate is also validated. This is as opposed to “regular” TLS, e.g. between a web browser and a web server, which typically only validates the server’s certificate.
- Thanks to Cindy Sridharan for introducing me to this term.
- In fact, the first version ofLinkerdwas simply Finagle wrapped up in proxy form.
- As does, frankly, the fact that it succeeded.
- At least, at the 10,000-ft level. There’s a lot more to it than this, of course.
- These three companies play very different roles: Lyft’s involvement seems to be in name only; they were the originator of Envoy but don’t appear to useIstioor even contribute to it. IBM contributes toIstioand also uses it. Google contributes heavily but as far as I can tell doesn’t actually useIstio.
- Systemd comes to mind. The comparison has been made, several times.
- In practice,Istioappears to have issues not just with complexity and UX but with performance. During our third-partyLinkerdbenchmark evaluation, for example, evaluators were able to find situations whereIstio’s tail latency was 100x that ofLinkerd, as well as low-resource environments whereLinkerdhappily chugged along butIstiocompletely stopped functioning.