\\\\\
隨著越來越多的公司採用微服務架構，istio、linkerd和cilium等服務網格也越來越受關注。服務網格提供了非常有吸引力的特性：全堆疊可觀測性、透明的安全性、系統彈性等。但是，服務網格真的是雲原生應用程式的正確解決方案嗎？本文將討論服務網格在什麼情況下是有意義的，以及什麼時候不應該使用服務網格。
\\\\
在當今世界，上市時間是一項基本的競爭優勢。快速響應市場和客戶反饋對於建立乙個成功的業務來說至關重要。微服務是加速軟體敏捷性和速度工作流的乙個強大正規化。不同的開發團隊同時開發應用程式的不同部分，所以決策是分散的。
\\ 分散的決策導致了兩個重要的後果。首先，軟體團隊可以在架構、發布、測試等方面做出區域性最優決策，而不依賴全域性的最優標準。這種決策最常見的例子是版本發布：每個團隊都有自己的發布路線，而不是一起發布乙個單體應用。其次，可以更快地做出決策，因為軟體團隊與集中式部門（如運營、架構等）之間的溝通成本降低了。
\\\\
採用微服務對組織、流程和架構有著深遠的影響。在本文中，我們將重點介紹關鍵的架構變化之——微服務是分布式系統。在基於微服務的應用程式中，業務邏輯分布在通過網路相互通訊的多個服務之間。分布式系統有更多的故障模式，正如「分布式計算的謬誤」這篇文章裡所強調的那樣。
\\ 鑑於這些故障模式，建立乙個防止小問題成為大故障的架構和流程至關重要。在快速發展過程中，故障是不可避免的。例如，在更新服務時會引入bug，服務在高負載下會崩潰，等等。
\\ 隨著應用程式複雜性的增長，對故障管理的需求也日益迫切。如果應用程式是由少數微服務組成的，故障往往更容易隔離和排除。隨著應用程式增長到數十個或數百個微服務，並且分布在不同的地理位置，那麼故障管理系統需要與應用程式一起擴充套件。
\\\\
故障管理有三種基本策略：主動測試、緩解症狀和快速響應。
\\主動測試。實現用於測試應用程式和服務的流程和系統，以便盡早識別出故障。這裡也包括傳統的「質量保證」（qa），儘管傳統的測試團隊更專注於預發布測試，但現在他們的工作也包括進行生產環境的測試。\\t
緩解症狀。實施策略，以減少故障的影響。例如，在多個服務例項之間進行負載均衡，這樣可以確保如果單個例項發生故障，整體服務仍然可用。\\t
快速反應。實現可以快速識別和解決故障的流程和系統。\
\\ 當服務發生故障時，會對其上游和下游服務產生影響。正確管理服務之間的通訊可以大大緩解故障所帶來的影響。這個時候，服務網格就可以派上用場。
\\ 服務網格負責管理服務級別（即layer 7）的通訊。服務網格提供了強大的原語，可以用於實現上述的三種故障管理策略。可以使用服務網格來實現：
\\動態路由，用於不同的發布和測試策略，如金絲雀路由、流量影子或藍/綠部署。\\t
彈性，通過斷路器和速率限定等策略減輕故障的影響。\\t
可觀測性，通過收集指標並將上下文（例如跟蹤資料）新增到服務間通訊中來幫助改進響應時間。\
服務網格以一種對應用程式開發人員來說基本透明的方式新增這些特性。但是，我們很快會看到，這種透明度有一些微妙之處。
\\\\
要想知道服務網格對你和你的組織來說是否有意義，首先要問自己兩個問題。
\\ 你的服務拓撲有多複雜？\\t
你如何將服務網格整合到軟體開發生命週期中？\
\\ 通常情況下，組織會從單個與現有單體應用程式相連的微服務開始。在這種情況下，服務網格的好處是有限的。如果微服務發生故障，要定位故障很簡單。單個微服務的故障影響範圍是很限制的。還可以通過現有的基礎設施（如kubernetes或api閘道器）來完成增量發布。
\\ 但是，隨著服務拓撲複雜度的增加，服務網格的好處開始漸顯。需要考慮到的關鍵約束是服務呼叫鏈的深度。如果你的拓撲很淺，也就是說單體應用直接呼叫十幾個微服務，那麼這個時候服務網格的好處仍然相當有限。隨著引入更多的服務間通訊，其中服務a呼叫服務b，服務b再呼叫服務c，這個時候服務網格變得更加重要。
\\\\
服務網格對執行在網格上的服務來說是透明的。可以把服務網格看成是乙個特性更豐富的l7網路。要讓乙個服務在服務網格上執行，不需要做出**變更。
\\ 但是，部署服務網格並不會自動改進軟體開發速度和敏捷性。你必須將服務網格整合到開發過程中。我們將在下一節更詳細地**這一點。
\\\\
服務網格為故障管理提供了強大的原語，不過也存在一些服務網格的替代方案。在本節中，我們將介紹各種故障管理策略，並討論如何將這些策略應用於sdlc。
\\\\
微服務應用程式的測試策略應盡可能真實。鑑於多服務應用程式的複雜性，現代測試策略更強調在生產環境進行測試（或使用生產資料）。
\\ 服務網格通過控制流向服務的l7流量，可以實現在生產環境中進行測試。例如，服務網格可將1％的流量路由到服務的v1.1，將99％的流量路由到v1.0（金絲雀部署）。這些可以通過宣告式路由規則（例如linkerd dtab或istio路由規則）進行配置。
\\ 服務網格並不是主動測試的唯一方法，還有其他補充策略，包括使用容器排程程式（如kubernetes）進行滾動更新、使用可以進行金絲雀部署的api閘道器或混沌工程。
\\ 有了這些策略，那麼應該由誰來管理測試工作流？。在服務網格中，路由規則可以由管理服務網格的團隊一併集中式管理。然而，這種方式不可擴充套件，因為個別服務開發者可能想要控制何時以及如何推出新版本服務。因此，如果由服務開發者來管理路由規則，那麼你該如何告訴他們可以做什麼以及不可以做什麼？如何管理衝突的路由規則？
\\\\
由於各種原因，服務可能會出現故障：**錯誤、資源不足、硬體故障。限制故障服務的影響範圍至關重要，至少整體應用程式仍能繼續執行，儘管處於降級狀態。
\\ 服務網格通過彈性模式來減輕故障的影響，例如負載均衡、斷路器和服務間通訊的速率限定。舉個栗子，負載較重的服務可能會受到速率限定，這樣可以繼續處理一些響應，而不會導致整個服務在負載重壓下崩潰。
\\ 其他緩解失敗的策略包括使用智慧型rpc庫（例如hystrix）或依賴容器排程程式。kubernetes之類的容器排程器支援健康檢查、自動擴充套件和動態路由。
\\ 這些緩解策略在針對特定服務進行適當配置時最為有效。例如，不同的服務可以處理不同的請求量，因此需要不同的速率限定。如何制定速率限定等策略？netflix已經實現了一些自動配置演算法來設定這些值。還有就是將這些功能暴露給服務開發者，讓他們做出正確的配置。
\\\\
故障是不可避免的。實現可觀測性——監控、警報/視覺化、分布式跟蹤和日誌——對於最大限度縮短故障響應時間來說至關重要。
\\ 服務網格自動收集服務間通訊的詳細指標，包括吞吐量、延遲和可用性方面的資料。另外，服務網格可以注入必要的頭部資訊以支援分布式跟蹤。請注意，這些頭部資訊仍然需要由服務本身進行傳播。
\\ 其他收集指標的方法包括使用監控**、通過statsd收集指標以及通過庫（例如jaeger增強庫）來實現跟蹤。
\\ 可觀測性的乙個重要組成部分是向服務開發者暴露警報和視覺化。收集指標只是第一步，讓服務開發者建立適合於給定服務的警報和視覺化對於可觀測性閉環來說非常重要。
\\\\
服務網格的部署機制很簡單。但是，正如之前的討論想要表明的那樣，將服務網格應用於工作流會更複雜。成功採用服務網格的關鍵在於認識到網格會影響你的開發流程，並做好將網格整合到這些流程中的準備。並不存在一種完全正確的方法用於將網格整合到流程中，新的最佳實踐仍在不斷出現。
是幾家高科技創業公司的參與者。此前，richard是duo security的產品與戰略副總裁。在加入duo之前，richard曾擔任rapid7戰略與企業發展副總裁。他還領導建立了rapid7的產品管理部門。richard還在red hat的銷售、市場營銷和工程領域擔任多個領導職務。
\\檢視英文原文：service mesh: promise or peril?
Istio 服務網格
istio是乙個完全開源的服務網格，作為透明的一層接入到現有的分布式應用程式裡。它也是乙個平台，擁有可以整合任何日誌 遙測和策略系統的 api 介面。istio 多樣化的特性使您能夠成功且高效地執行分布式微服務架構，並提供保護 連線和監控微服務的統一方法。服務網格用來描述組成這些應用程式的微服務網路...
服務網格 Istio和AWS App Mesh
在談論它之前，讓我們先看一下網格到底是什麼 服務網格是微服務體系結構的基礎結構層。它處理服務之間的通訊問題，使該通訊更加可見 或 可觀察 且易於管理。更具體地說，它可以處理諸如服務發現，路由和負載平衡，安全性 例如，加密，tls，身份驗證，授權 之類的事情，並提供錯誤處理 例如重試和斷路 上面提到的...
服務網格 Istio和AWS App Mesh
在談論它之前，讓我們先看一下網格到底是什麼 服務網格是微服務體系結構的基礎結構層。它處理服務之間的通訊問題，使該通訊更加可見 或 可觀察 且易於管理。更具體地說，它可以處理諸如服務發現，路由和負載平衡，安全性 例如，加密，tls，身份驗證，授權 之類的事情，並提供錯誤處理 例如重試和斷路 上面提到的...