Service Mesh大咖訪談：使用服務網格的微服務通訊與治理

關鍵點

• 服務網格框架用於處理服務間的通訊，並提供連線、管理和保護微服務的平臺。

• 服務網格通過處理需要複雜編碼的功能來幫助應用程式開發人員，例如路由決策，這些決策在網格層級完成，而不是在應用程式中完成。

• 它還提供了可以編入網格的安全策略。例如，您可以設定一個策略，以限制網格中某些服務的入站網路流量。

• 像Istio這樣的服務網格可以在Kubernetes平臺上無縫工作，但在其他平臺上使用還比較麻煩。

• Sidecar代理使得應用程式與管理服務通訊的操作方面有效和可靠。

服務網格是一個專用的基礎設施層，用於處理服務間通訊，並提供連線、管理和保護微服務的平臺。

服務網格使得微服務之間的通訊變得靈活可靠。它提供了分散式服務所需的關鍵功能環境，如彈性、服務發現、負載均衡、加密、授權、容錯（通過服務重試和斷路器）。

InfoQ與服務網格領域的主題專家進行了交談，以更多地瞭解為什麼服務網格框架已成為雲本機體系結構的關鍵元件。

本文下面的部分提供了與我們交談的小組成員的詳細資訊，虛擬小組中包含的問題以及小組成員的答覆。

討論嘉賓：

• Matt Klein，Lyft

• Dan Berg，IBM

• Priyanka Sharma，Lightstep

• Lachlan Evenson，微軟

• Varun Talwar，Google

• Oliver Gould，Buoyant

---

InfoQ：您能否定義Service Mesh以及它在微服務互動和治理方面帶來了哪些的優勢？

Matt Klein：微服務從業者面臨的兩個最困難的問題是網路和可觀察性。即服務彼此如何可靠地通訊？當出現問題時，如何快速確定問題，修復和解決問題？可靠的微服務網路和可觀察性需要多種技術，包括服務發現、負載均衡、超時、重試、斷路器、執行狀況檢查、高階路由、統計、日誌記錄、分散式跟蹤等。從歷史上看，大多數現代架構都構建了功能豐富的庫，這些庫可以直接拿來使用。但是如果需要做多語言適配的話，就需要用多種語言重新實現和維護大量複雜的功能。

“服務網格”背後的想法是使用與每個應用程式並行執行的程式外的“sidecar”代理。該代理可以以非常高的效能實現了微服務架構的所有複雜網路和可觀察性需求。由於代理在專用程式中實現了所需的功能，因此它可以與任何應用程式語言一起使用。當每個應用程式都有一個關聯的sidecar代理並通過它來路由所有流量時，應用程式本身不再需要知道底層網路細節並可將其視為抽象。這允許應用程式開發人員只要關注業務邏輯，而不需要考慮組織內可能使用的什麼語言。

Dan Berg：服務網格是一個術語，用於描述組成應用程式的微服務網路以及對它們之間互動的管理。其中一個例子是Istio，這是一種開放技術，為開發人員提供了一種無縫連線、管理和保護不同微服務網路的方法——無論平臺、來源和供應商。通過將複雜且容易出錯的邏輯從應用程式程式碼中移動到服務網格，這可幫助開發人員提高工作效率。例如，服務網格管理流量路由，確保服務之間的安全通訊，捕獲網路遙測以及網格內所有服務的安全策略實施等。通過內建的斷路支援，服務網格可確保更高的服務彈性，從而在服務無法到達目的地時以優雅的方式處理故障。

Priyanka Sharma：服務網格是服務間通訊的基礎架構層。它確保您的訊息在整個系統中的可靠傳遞，並與服務的業務邏輯分開。服務網格通常被稱為sidecar或代理。

隨著軟體開發進入微服務時代，服務網格將變得非常重要。通過服務網格，您不僅可以確保彈性網路通訊，還可以在不改變應用程式執行時的情況下實現可觀察性和控制。

通過服務網格，組織可以更輕鬆地在工程團隊中使用具有一致工具的微服務。開發人員也可以專注於他們的服務，並讓網格負責網路層通訊以及圍繞微服務的工具。

Lachlan Evenson：服務網格是一組應用程式，可以在微服務體系結構中實現統一的服務間通訊。服務網格使微服務開發人員和運維人員都能夠以規定和預期的方式與依賴服務互動。這通過為所有通訊提供單一介面和單點策略執行而不是定製或樣板實現來輔助治理。

Varun Talwar：服務網格是一種架構模式，微服務所需的所有服務通訊和通用功能均由平臺層（外部程式碼）統一處理。當像這樣的平臺層可以統一實現像路由和負載均衡這樣的常見網路功能時，彈性功能（如重試和超時）、安全功能（如身份驗證、授權和服務級別監視和跟蹤）可以顯著簡化微服務開發人員的工作，智慧組成的基礎架構可以使組織能夠在更高的服務抽象層面進行管理（獨立於底層網路和基礎設施）。

Yuri Shkuro：“服務網格”一詞相當誤導人。在直接解釋中，它可以用來描述組成分散式應用程式的微服務網路以及它們之間的互動。然而，最近這個術語主要應用於處理服務間通訊的專用基礎設施層，通常實現方式是與應用程式程式碼一起部署的輕量級網路代理（sidecar）。應用程式程式碼可以將架構中的任何其他服務視為在同一主機上的本地埠上執行的單個邏輯元件。它使得應用程式程式碼不必瞭解現代雲原生應用程式的複雜拓撲結構。它還使基礎設施團隊能夠專注於在單個sidecar元件中實現諸如路由、服務發現、斷路、重試、安全性、監控等高階功能，而不是通過現代應用中典型的多種程式語言和框架來支援。

Oliver Gould：服務網格是一個專用基礎設施層，用於在微服務之間進行安全、快速和可靠的執行時通訊。在Twitter裡我們瞭解到，這種通訊是應用程式執行時行為的關鍵決定因素，但如果您沒有明確地處理它，最終會形成一個脆弱、複雜的系統。服務網格為運維人員提供了除錯和管理此通訊所需的控制機制。如果你想深入挖掘，就深入瞭解一個服務網格是什麼以及為什麼需要它，你可以在這裡找到。

InfoQ：企業服務匯流排（ESB）模式在過去幾年一直流行，特別是在面向服務架構（SOA）模型中。對於ESB和服務網格模式各位怎麼看？

Klein：我不打算討論SoA與微服務，或者ESB與服務網格之間的差異。坦率地說，我認為這幾乎沒有真正的區別，名稱的變化主要是由於廠商試圖區分新產品導致的。一般而言，計算和工程是由迭代變化驅動的。近年來，大多數SoA/微服務通訊已經轉移到REST和更新的強型別IDL，如Thrift和gRPC。開發人員通過直接來自程式庫和集中式訊息匯流排的網路呼叫來支援簡單性。不幸的是，大多數正在使用的程式庫不足以解決執行微服務架構時出現的操作難題（Finagle和Hystrix/Ribbon是例外，但需要使用JVM）。我認為“服務網格”實際上只是ESB體系結構中的一個現代應用，適應了微服務從業者所喜歡的技術和流程。

Berg：從較高層次上看，ESB和服務網格很類似，因為它們都是管理一組服務之間的通訊；但是，它們之間有根本的區別。一個關鍵的區別是訊息被髮送到ESB後ESB再確定向哪個端點傳送訊息。ESB是進行路由決策、執行訊息轉換以及管理服務之間安全性的集中點。另一方面，服務網格是一種分散式方法，客戶端代理通過服務網格控制平面進行程式設計，以管理路由、安全性和metric收集。因此，服務網格將關鍵責任推送給應用程式，而不是將功能封裝在集中式系統（如ESB）中。這使得服務在高度分散式的系統中更具彈性和擴充套件性，例如雲原生應用程式。

由於將客戶端方法與服務網格一起使用，因此可以有比ESB可實現的更復雜的路由規則、策略實施和斷路器等彈性功能。另一個關鍵區別是應用程式邏輯不知道自己加入到了服務網格。網格主動調整以採用應用程式。使用ESB時，必須調整應用程式邏輯才能參與ESB。

Priyanka：ESB和服務網格有很多共同之處，特別是它們為什麼被構建。ESB在SOA時代開始流行起來——它們管理網路通訊，並負責管理一些業務邏輯。構建ESB的原因與我們今天構建服務網格的原因相同——隨著服務數量的增加，整個系統需要一致性和可靠性，並且訊息匯流排/輔助代理是實現這一目標的好方法。

服務網格與ESB不同，因為它們專為雲原生的微服務架構而構建。在雲端計算領域，ESB功能不佳。它們承擔了服務中過多的業務邏輯，並通過建立另一個依賴和組織孤島來減緩了軟體開發的速度。

總而言之，我認為服務網格是ESB技術的下一代發展。核心動力是相同的，但是實現更加複雜並且是為雲原生時代量身定做。

Evenson：就像ESB是SOA的代名詞一樣，服務網格與微服務也是如此。主要區別在於ESB和服務網格實現的服務的範圍和大小。ESB在功能集和後端系統支援方面要大得多。ESB通常關注大型企業和行業標準、協議等，而服務網格足夠輕量級以便為微服務增加價值。

Talwar：ESB是關於集中式架構的，其中一個核心部分承載了作出決策的能力。隨著時間的推移，中心部分變得複雜，並且缺乏微服務架構的能力，每個團隊/服務都想要快速配置、測試、部署和擴充套件其服務。服務網格的新架構代表了SOA模式從笨拙端點、智慧管道（大型單體分層應用程式）到智慧端點（服務特定功能）、笨拙管道的轉化。

Shkuro：ESB和服務網格之間的關係類似於基於單體和基於微服務的應用程式之間的關係。它們都起到類似的作用，主要區別在於它們如何做到這一點。ESB是位於架構中所有其他服務之間的單個系統。它為服務之間的每個訊息交換提供單一控制點。它還引入了單點故障並增加了所有通訊的延遲。相反，通過sidecar實施的服務網格執行相同的功能，但是以分散式、分散的方式。服務網格的控制平面提供了與ESB相同的策略和路由決策的集中許可權，但不處於每個請求的關鍵路徑上。資料平面由與應用程式程式碼一起執行的sidecar實現。例如，在一個典型的Kubernetes設定中，每個微服務例項執行在它自己的服務網格sdiecar副本旁邊的一個容器中。所有進出微服務的流量都會通過sidecar的例項，而不會對其他集中式子系統造成嚴重依賴。

Gould：目標並非完全不同，但是優先順序和實施細節極為不同。ESB傾向於實現為一個集中的單點故障，而像Conduit這樣的服務網格使用“sidecar”代理來明確分散和可擴充套件。

此外，可以僅在應用程式的一小部分中使用它，這意味著服務網格的採用可以是增量式的，不需要全面的架構鎖定。最後，服務網格重點關注通訊的操作方面，並儘量避免實際感知應用程式的業務邏輯細節。服務網格的目標是可操作的，而不是架構或整合。

InfoQ：企業中誰應該關心服務網格？這是典型的開發人員在部署應用程式時應該注意的事情嗎？

Klein：服務網格背後的想法主要是將網路抽象為應用程式開發人員。應用程式開發人員仍然需要了解一般網路概念，例如重試、超時、路由等（因為他們將參與配置），但是他們不需要知道它們是如何實現的。因此，典型的開發人員應該關心服務網格，因為這意味著他們可以刪除大量的一次性的網路設定和關於可觀察性的程式碼，並獲得統一的、功能更豐富、更可靠的免費解決方案！

Berg：使用服務網格和強大的雲平臺，小型公司也可以建立那些以前只有大型公司投入大量資源，在傳統模式下使用定製程式碼並重新配置每臺伺服器才能建立的應用程式。雲、服務網格和微服務使開發人員能夠靈活地使用不同的語言和技術工作，從而提高速度和生產率。

一個典型的開發人員應該意識到他們正在參與一個服務網格並瞭解他們正在與網格中的其他服務進行通訊。他們應該接受這樣一個事實，即服務網格可以幫助他們避免需要複雜編碼的功能，例如路由決策，因為這些功能是在網格級而不是應用程式本身完成的。服務網格最終可以提高開發人員的工作效率。遙測資訊和故障注入是一種強大的開發工具，可用於檢測問題並最終將其從應用程式中刪除。

Priyanka：基礎架構和平臺團隊通常是在軟體組織中設計和實現服務網格的人。對於這些團隊及其工程領導者來說，為公司的最佳戰略和實施共同努力至關重要。

雖然服務網格通過將網路通訊與服務分離開來以提高開發人員的生產率，但他們應該瞭解服務網格所提供的特定服務發現和可觀察性功能。這將幫助開發人員知道什麼會自動工作以及需要自定義哪些功能。例如，如果服務網格使用OpenTracing進行檢測，則開發人員可以保證整個系統具有最高的可觀察性。然後他們可以選擇使用OpenTracing來測試他們的服務，以獲得更多詳細的錯誤或效能降級追蹤。

Evenson：服務網格對開發人員來說應該是透明的，它提供的服務被視為平臺的一個特性。然而，運維人員也會對服務網格感興趣，因為這堆東西也需要他們來維護。

Talwar：服務網格的一個有趣方面（限制）是它將諸如開發人員、運維人員、生產安全、網路運維、CIO、CTO等眾多不同的利益相關者聚集在一起。對於開發人員來說，服務網格是由另一個組織完成的，開發人員無需為許多常用功能（理想情況下只需要編寫業務邏輯）編寫程式碼，並且可以部署到結構中（使用網格）來在執行時處理功能（通過策略）。

Shkuro：服務網格解決方案通常由基礎設施/網路團隊負責。典型的應用程式開發人員不需要了解多少。他們可能需要知道為了向服務X發出請求，他們需要將它傳送到為該服務保留的本地埠Y，或者將所有請求傳送到同一個埠，但是需要通過HTTP頭或特定的API來指示目標服務RPC框架。當然，在許多組織中，同一個開發人員也是他們服務的隨叫隨到人員，這意味著在出現問題時，瞭解如何監控sidecar程式也很有用。在Uber，我們有一個工具，可以自動為每個服務提供一個儀表板，顯示來自服務所使用的許多基礎架構元件的metric，包括sidecar程式生成的度量，例如請求和錯誤計數，請求延遲直方圖等。

Gould：企業應該關心它，因為它為執行時操作帶來了一層標準化，類似於Docker和Kubernetes提供的執行時操作的標準化。平臺運維人員（將Docker和Kubernetes引入組織的人員）會支援服務網格，因為這使他們擺脫了除錯和執行微服務的關鍵路徑。

開發人員（以及更一般的服務所有者）也會受益，因為服務網格可以將應用程式程式碼與執行時所屬的操作邏輯分離。網格提供了可操作的功能，可以讓開發人員更快的開發，而不用擔心造成破壞。

InfoQ：服務網格解決方案如何在服務重試、超時、斷路器、故障轉移等方面支援彈性？

Klein：Sidecar代理代替應用程式實現大量高階功能，如服務發現、負載均衡、重試、超時、斷路器、區域感知路由等。這些功能非常難以正確使用，而微服務程式碼庫通常散佈著錯誤或不完整的版本。將這種型別的功能剝離到高效能一次實現到處是用的單個實體，效率會大大提高。

Berg：與網路緊密耦合的應用功能（如斷路器和超時）與服務程式碼/業務邏輯明確分開，並且服務網格的這些功能便於在雲中開箱即用。大規模分散式系統具有一個明確的特徵：小型區域性故障有很多機會變成全系統災難性故障。服務網格旨在通過使用雲工具（如容器）的敏捷性和可移植性來防止這些故障升級，以在底層系統接近其極限時快速解除安裝負載並快速失敗。

這一切都是在應用程式中可用的客戶端代理（sidecar）中完成的。該sidecar負責將請求轉發到另一個sidecar代理在轉發到該應用之前接收該請求的服務。當發出請求時，代理將自動斷開斷路器，並且當上遊服務不可達時，可能會將流量重新路由到另一個版本。服務之間的超時設定可能會失敗。像Istio這樣的服務網格可以幫助您避免不良使用者體驗和超時中斷，因為Istio允許您將故障直接注入網格，從而使您無需猜測就可以測試和驗證連線超時。

Evenson：服務網格資料平面元件位於所有微服務的所有資料通訊的路徑中。考慮到這種佈局，他們意識到資料網格，因此可以制定支援彈性功能的策略驅動決策。

Talwar：服務網格有兩個部分。資料平面和控制平面。像Envoy（用於Istio）的可插入API驅動資料平面允許配置重試和超時，以便輕鬆配置和更改這些資料平面。Envoy還可以定義斷路器的配置以及池中所有例項的粗粒度和細粒度執行狀況檢查，以實現負載均衡和從故障/高延遲例項進行路由。有關更多詳細資訊，請參見此處。

Shkuro：這些功能中的很多功能在服務網格的特定實現之間會有所不同。技術本身並不新鮮，但許多技術仍然是研究和創新的活躍領域。服務網格的特殊之處在於它們從應用程式程式碼中抽象出這些問題並封裝到單個基礎架構層中。這樣做可以保持應用程式程式碼的輕量級，並允許服務網格開發人員快速迭代並針對這些問題開發最佳的解決方案。例如，採取故障轉移的問題。當特定可用區域中的某項服務遇到問題時，通常最安全的恢復方法是將流量轉移到另一個可用區域，前提是它具有足夠的過剩容量。通過改變控制平面中的一些設定，服務網格可以完全透明地完成架構中其餘的服務。要在每項服務中都支援這種故障轉移功能將會困難得多。

Gould：服務網格提供的最重要的可靠性特性是第7層負載均衡。與L3/L4負載均衡器不同，像Conduit這樣的服務網格知道每個請求的後設資料，並且可以幫助自動尋找緩慢或失敗的例項、機架故障等。

一旦這些負載均衡器知道服務級別目標（通常以延遲和成功率的方式），它們可以令人難以置信的做出何時不應將流量傳送給特定例項的明智決定。

如果這是一件安全的事情，服務網格還可以自動重試應用程式的請求。但是，請注意，重試實際上可能使中斷更加嚴重；您可能會遇到長時間執行的重試迴圈，這些重複迴圈會佔用資源並可能導致系統級聯故障。所以正確地引數化是很重要的，例如像我們在Linkerd所做的那樣，採用基於預算的方法來重試。這極大地改善了最壞情況的行為。

InfoQ：服務網格如何支援身份驗證和授權等安全功能？它如何幫助實施執行時安全策略？

Klein：儘管大多數安全團隊都會說他們希望在服務之間進行身份驗證和授權，但很少有組織最終會大規模部署解決方案。這是因為系統範圍的認證和授權是非常困難的問題！服務網格在這方面有很大幫助。使用mTLS和SPIFFE等技術可以相對容易地部署認證。應用程式/安全開發人員需要指定策略，但不必擔心底層加密和身份驗證是如何實現的。同樣，sidecar代理可以使用來自mTLS會話的認證資料在L7路由級別進行驅動授權。例如，指定/servicea只能由服務A訪問，而/serviceb只能由服務B訪問。

Berg：這起源於一些關鍵因素。服務網格具有管理網格內證書頒發機構的元件。此身份驗證元件負責對客戶端代理進行程式設計，以使用相互TLS（傳輸層安全性）自動在網格中的服務之間建立信任關係。如果開發得當，這些證書的壽命會很短，這樣如果服務受到損害，在證書被迴圈使用之前，只有一小部分安全漏洞視窗，從而導致原始的無用功能。

服務網格具有可程式設計的安全策略。例如，您可以設定一個策略，以限制網格中某些服務的入站流量。如果您只想允許入站Internet通訊服務A，則由於客戶端代理攔截所有到應用程式的入站和出站通訊，所有其他入站Internet通訊都將被拒絕（如果它偏離A以外的服務）。服務網格強化了服務之間的強標識宣告，並限制了可以訪問服務的實體，所有這些都是在不更改應用程式程式碼的情況下完成的。

Priyanka：服務網格在部署時建立了更多的靈活性和控制權，因為對應用程式程式碼的依賴很少。我覺得我們這些服務網格提供者最好談論具體實現以實現彈性和身份驗證。

Evenson：服務網格控制平面只能提供在服務網格執行的平臺上固有支援的功能。在Kubernetes上執行服務網格的情況下，認證和授權在服務網格中表示並轉換為強制執行的底層Kubernetes資源。

Talwar：一旦服務網格攔截了所有的服務間通訊，它們就可以加密並強制認證所有通訊，而無需開發人員參與（巨大優勢），併為誰可以呼叫誰啟用授權策略。由於所有流量都流經服務網格的資料平面，因此可以通過服務網格來確保所有受支援/隧道協議的加密以及允許/禁止每個服務的出口/入口。

Shkuro：Sidecar方法的一個巨大好處是它的身份可以與實際的微服務的身份互換使用，因為可以設定容器上的網路策略，使得微服務除了通過sidecar程式無法通過其他方式訪問。這允許將許多安全問題轉移到sidecar上，並在整個組織中對其進行標準化。認證可以由sidecar專門完成，例如，通過在sidecar上終止所有的TLS並且在應用和sidecar之間使用未加密的通訊。如果需要執行額外的高階授權，則可以通過可信請求標頭將呼叫者身份傳遞給應用程式程式碼。一些簡單的授權形式，例如“只允許服務X訪問我的端點Y”，也可以完全轉移到sidecar過程中，並通過集中策略進行控制。這些策略甚至可以在執行時更新，而不會影響應用程式程式碼。

Gould：一旦使用了編排工具例如Kubernetes，傳統的網路分割方法認同就開始崩潰。通過服務網格，服務可以通過一致、安全的方式在資料中心中重新建立一致的身份，此外，還可以基於強大的加密基元而不是部署拓撲來實現。例如，Conduit可以提供證書頒發機構和/或與證書頒發機構整合，以自動分配服務的TLS證書，以便當兩個支援服務網格的服務進行通訊時，它們具有強大的對等密碼證明。一旦這些身份原語被建立起來，我們就可以用它們來構建訪問控制策略。

InfoQ：當前人們學習和部署服務網格的熟悉階段如何？學習曲線陡峭嗎？陡峭的部分在哪裡？

Klein：說實話，為時尚早。在大型微服務架構中成功部署服務網格是可能的，但仍需要相當多的網路和系統知識。正如我多次提到的，服務網格部署由“資料平面”和“控制平面”組成。資料平面觸及每個資料包並執行負載均衡、重試、超時等。控制平面通過為服務發現、路由表等提供配置來協調所有資料平面。像Envoy、HAProxy和NGINX這樣的資料平面是健壯的，完全可用於生產。但是，為組織開發和部署控制平面和相關配置實際上是最困難的部分。

Envoy是一個可用於大量多種部署型別的通用工具。這意味著Envoy擁有令人眼花繚亂的選項，對於不熟悉的人可能會非常恐懼。不幸的是，適應性往往與易用性相左。另一方面，更緊密地與組織的開發實踐和工具繫結的控制平面可能會有更少的選項，選項越多對於大多數開發人員來說更容易理解和使用。因此，隨著時間的推移，我認為隨著微服務架構在Kubernetes等工具上的標準化，服務網格將通過控制平面專案（如Envoy之上構建的Istio）變得更“開箱即用”。

Berg：與採用雲策略類似，服務網格具有豐富的功能和特性，但如果您一開始就嘗試使用其所有功能，您可能會覺得它難以琢磨。在使用Srevice Mesh的初期建議您只採用部分功能。例如，如果您想要檢視微服務的複雜性，請僅為使用服務網格中的遙測，而不是安全或路由。隨著需求的增長，從簡單採用到逐步接納服務網格。

Priyanka：根據我們從OpenTracing終端使用者社群獲悉的資訊，服務網格是一項受人歡迎的技術，它可以使微服務更加健壯。目前，人們需要花時間瞭解所有的選項，如果有更多的教育材料（如本文）就更好了。

Evenson：這實際上取決於服務網格。服務網格的功能之一是，您不必更改應用程式以支援服務網格。有些阻力是應用程式開發人員不知道如何修改基礎結構定義以部署服務網格的資料平面元件，以便它可以在所有資料通訊的路徑中。

Talwar：今天，像Istio這樣的服務網格可以在Kubernetes等平臺上無縫工作，但在其他平臺中使用它還存在困難。另一個關鍵點是讓使用者逐步嘗試Istio的各個部分，就像安全、監控或彈性一樣，而不需要增加了解Istio其他部分的認知負荷。我認為如果在這兩個領域投入更多工作將使Istio更易於消化和被更廣泛的使用。另一個問題是需要經過良好測試，和多效能的優化已經支援生產，這是Istio專案目前正在進行的工作。

Shkuro：在Kubernetes中部署Istio服務網格相當簡單，但對於許多不使用Kubernetes的組織來說，這有一點學習曲線。首先，組織中使用的部署系統需要支援將多個容器作為服務例項的邏輯單元（Kubernetes中的pod的概念）執行。另外，服務網格程式可以作為主機上的單個代理執行，這雖然可以解決路由和服務發現等問題，但卻使安全性和身份驗證等其他功能無法實現。從我與其他公司進行的一些非正式對話中，為服務網格執行控制平面可能是最難的部分。控制平面需要與系統架構中的其餘部分深度整合，例如，它需要了解服務部署以便控制服務發現，執行狀況檢查、負載均衡/故障轉移。 Istio專案在抽象控制平面功能方面取得重大進展。

Gould：我們一直在支援Linkerd生產近兩年。我們已經學到了很多陡峭學習曲線的知識，包括我們期望學習的一些東西，但是往往這些東西在回顧過程中顯而易見。一個令人驚訝的教訓是，雖然Linkerd在極高的規模上表現出色，但事實證明，許多使用者會從最強功能的簡化方法中受益匪淺。應該讓使用者很容易就開始使用服務網格。我們希望降低管理分散式服務的複雜性，而不是增加它。這種見解導致了我們最近在Conduit上的工作，如果https://conduit.io/getting-started/不能滿足您需要啟動和執行的所有功能，我想知道為什麼。

更一般地說，我認為採用服務網格的缺陷是一次嘗試做太多事情。服務網格的採用需要在其關鍵性和解決的問題範圍內增加。這是一種新的工具，我們見過的最成功的採用方式是漸進式的。我們的建議是儘可能保持簡單（但並不簡單）。

InfoQ：各位否談論下Sidecar設計模式以及使用Sidecar可以實現哪些平臺級別的功能？

Klein：正如我上面所討論的，sidecar代理是抽象應用程式網路的關鍵。我們認為localhost網路是可靠的。根據這個假設，應用程式只需要知道它的sidecar代理，並且代理可以處理其他任何事情（除了上下文傳播）。

Berg：Sidecar是客戶端代理，與每個應用程式（即容器）一起部署。與sidecar配合使用的服務會自動啟用帶網格的服務。它在概念上與父應用程式相連，並通過提供平臺功能補充應用程式。因此，sidecar提供了關鍵的網路控制點。有了這種設計模式，您的微服務可以將sidecar作為同一個微服務容器內的一組程式使用，也可以作為自身容器中的sidecar，以利用路由、負載均衡、彈性（如斷路和重試）深度監控和訪問控制。

Priyanka：Sidecar模式基本上是外掛或驅動程式模式，但是相對於平臺。通過從網路、度量、日誌記錄和其他具有標準介面的子元件中抽象出實現細節，運維人員可以更好地控制和靈活地制定其部署。

Evenson：Sidecar設計允許您操作Linux執行時環境，而無需更改應用程式程式碼。通常，將服務網格資料平面元件部署為sidecar，並修改Linux核心上該網路namespace的路由，以通過資料平面元件路由所有入口/出口。

Talwar：Sidecar模式是一種模式，其中協處理/容器映象位於應用程式旁邊，可以作為可信任的搭檔，可以獨立更新並由單獨的團隊管理，但與應用程式共享生命週期。平臺可以承擔的平臺功能包括日誌記錄、報告、身份驗證、配額策略檢查等。

Shkuro：行業內沒有關於什麼是Sidecar模式的嚴格定義。例如，谷歌的Brendan Burns認為我們在這裡討論的服務網格sidecar是Ambassador模式的一個例子，因為它只關心應用程式如何與其他地方進行通訊，而Microsoft Azure文件使用更慷慨的定義包括許多外圍任務，包括平臺抽象、代理通訊、配置、日誌記錄等。我個人更喜歡後一種定義，其中Ambassador模式是Sidecar模式的子類。

本質上，Sidecar模式建議從業務應用程式中提取常用功能，並將其封裝到在sidecar容器中執行的另一個程式中。這是一個眾所周知的分解原理。通過將常見的部分抽取到可重用的容器中，使應用程式免於重新實現這些功能，可能使用多種程式語言。這與將傳統的單體應用程式分成單獨的微服務類似，除了sidecar的生命週期與父服務的生命週期相同之外，我們主要將它們用於與基礎設施相關的功能。

Gould：從根本上說，sidecar只是另一個容器。這沒什麼神奇的。使用sidecar代理，我們能夠儘可能靠近應用程式來管理操作邏輯，而不需要在應用程式程式碼中管理。服務網格的全部要點是將您的應用程式與管理服務通訊的操作方面有效和可靠地分離。使用sidecar模式，我們可以為應用程式提供和驗證身份等功能，因為sidecar必須具有與其代理的服務相同的特權級別。這是sidecar與在每臺主機部署之間最大的不同。

關於小組成員

Matt Klein是Lyft的軟體工程師和Envoy的架構師。在過去15年裡，Matt一直致力於作業系統、虛擬化、分散式系統、網路以及使系統更易於使用。其中一些亮點包括領導Twitter的C++ L7邊緣代理的開發，並致力於亞馬遜EC2中的高效能運算和網路。

---

Dan Berg是IBM Cloud部門的傑出工程師。Daniel負責技術戰略以及IBM Cloud中提供的容器和微服務平臺的實現。在此職位上，Daniel對包括Docker和Kubernetes在內的容器技術有著深厚的知識，並且在構建和運營高可用的雲原生服務方面擁有豐富的經驗。Daniel也是Istio服務網格專案的核心貢獻者。

---

Priyanka Sharma是一位熱衷於構建開發人員產品並通過開源社群成長的企業家。她目前在LightStep擔任開源合作伙伴，並且是OpenTracing專案（CNCF專案）的一名貢獻者，為分散式跟蹤提供獨立於供應商的API。她擔任HeavyBit（一家開發人員產品的加速器）行業創業公司的顧問。關注她的Twitter@pritianka。

---

Lachlan Evenson是雲原生布道師。Lachlan花了近兩年半的時間與Kubernetes合作，並支援雲原生。他是開源軟體的信徒，並且是一名活躍的社群成員。Lachlan致力於幫助雲原生專案在Azure上執行。

---

Varun Talwar是Google Cloud的產品經理；同時他也是@grpcio和@IstioMesh的PM

---

Yuri Shkuro是Uber的一名工程師，致力於分散式追蹤、可靠性和效能。Yuri是OpenTracing標準（CNCF專案）的合著者，以及Jaeger的技術主管，這是一款來自Uber的開源分散式追蹤系統。

---

Oliver Gould是Buoyant的CTO和聯合創始人，負責開源服務網格專案Linkerd和Conduit的開源開發工作。在加入Buoyant之前，他是Twitter的一名基礎設施工程師，他是可觀測性、流量和配置與協調團隊的技術負責人。他是Linkerd的創造者，也是Finagle的核心貢獻人，Finagle是Twitter、Pinterest、Soundcloud和其他公司使用的RPC庫。