筆記。 翻譯。：本文作者（Luc Perkins）是 CNCF 的開發者倡導者，CNCF 是 Linkerd、SMI（服務網格介面）和 Kuma 等開源專案的發源地（順便問一下，你有沒有想過為什麼 Istio 不在這個名單上？..）。為了讓 DevOps 社區更好地理解流行炒作的“服務網格”，他列出了此類解決方案提供的 16 種典型功能。
今天 ― 軟體工程中最熱門的話題之一（理所當然！）。我認為這項技術非常有前景，我夢想看到它被廣泛採用（當然，當它有意義的時候）。然而，對大多數人來說，它仍然籠罩在一層神秘的氣氛中。此外，即使是那些 我很了解他 有了它，往往很難闡明它的優點以及它到底是什麼（包括卑微的僕人）。在本文中，我將嘗試透過列出各種情況來糾正這種情況 使用場景 “服務網格”*。
* 注意：翻譯：從本文開始，此翻譯（「服務網格」）將用於仍為新的術語「服務網格」。
但首先我想發表幾點評論：
- 我從未使用過服務網格，也沒有在為自己教育而進行的專案之外使用過它們。另一方面，我在 2015 年為 Twitter 的內部服務網格編寫了大量文件（當時它甚至不被稱為「服務網格」），並為以下網站和文件做出了貢獻： ，因此它有一定的意義。
- 我的清單是大概的且不完整。當然，還有一些我不知道的用例，而且隨著技術的發展和普及，新的用例可能會隨著時間的推移而出現。
- 同時，並非所有現有的服務網格實作都支援所有列出的用例。因此，我的陳述（例如“服務網格可以…”）應該讀作“一些，甚至可能是所有流行的服務網格實現都可以…”。
- 範例的順序並不重要。
簡短清單：
- 服務發現；
- 加密;
- 身份驗證和授權；
- 負載平衡；
- 斷路器；
- 自動縮放；
- 金絲雀部署；
- 藍綠部署；
- 健康檢查；
- 減載；
- 流量鏡像；
- 絕緣;
- 請求速率限制、重試和超時；
- 遙測;
- 審計;
- 可視化。
1. 服務發現
TL;DR：使用簡單名稱連接到網路上的其他服務。
服務應該能夠使用適當的名稱自動“找到”彼此 - 例如， service.api.production, pets/staging 或 cassandra。雲端環境具有彈性，多個服務實例可以隱藏在一個名稱後面。顯然，在這種情況下，對所有 IP 位址進行硬編碼在物理上是不可能的。
另外，當一個服務發現另一個服務時，它應該能夠向該服務發送請求，而不必擔心它們最終會到達其死亡實例的輸入。換句話說，服務網格必須監控所有服務實例的健康狀況，並盡可能保持主機清單的最新狀態。
每個服務網格以不同的方式實現服務發現機制。目前，最常見的方式是委託給 DNS Kubernetes 等外部程序。過去，我們為此在 Twitter 上使用了一個名稱系統。 。此外，服務網格技術可以引入自訂命名機制（儘管我還沒有遇到任何具有此類功能的 SM 實作）。
2.加密
TL;DR：擺脫服務之間的未加密流量並使流程自動化和可擴展。
很高興知道攻擊者無法進入您的內部網路。防火牆在這方面發揮了很好的作用。但是如果駭客真的入侵了會發生什麼事呢？他能對服務內流量為所欲為嗎？希望這種事不會發生。為了防止這種情況發生，應該實施零信任網絡，其中服務之間的所有流量都經過加密。大多數現代服務網格透過相互 （相互 TLS，mTLS）。在某些情況下，mTLS 可以在整個雲層和星團中發揮作用（我認為將來有一天行星際通訊也會以類似的方式安排）。
當然，對於 mTLS 服務網格 選修的。每個服務都可以處理自己的 TLS，但這意味著需要找到一種方法來產生憑證、在服務主機之間分發它們，並在應用程式中包含從檔案載入這些憑證的程式碼。是的，並且不要忘記定期更新這些憑證。服務網格使用以下系統實現 mTLS 自動化 ，進而自動化頒發和輪換證書的過程。
3. 身份驗證和授權
TL;DR：確定誰發起請求，並定義在請求到達服務之前他們可以做什麼。
服務人員通常會想知道， 誰 發出請求（身份驗證），並利用此資訊決定 該 該主體被允許做（授權）。在這種情況下，代名詞“who”可能隱藏：
- 其他服務。這稱為“身份驗證” 皮爾阿例如，服務
web想要存取該服務db。服務網格通常使用 mTLS 解決這些類型的問題，並使用憑證充當必要的識別碼。 - 一些人類用戶。這稱為“身份驗證” 請求例如，用戶
haxor69想買一個新燈。服務網格提供各種機制，例如： .我們中的許多人都必須在應用程式程式碼中這樣做。收到請求後，我們會查看表格
users，找到使用者並比對密碼，然後檢查該列permissions等等。對於服務網格來說，這甚至在請求到達服務之前就發生了。
一旦我們確定了請求來自何處，我們就需要確定該主體被允許做什麼。有些服務網格允許你以 YAML 檔案或命令列的方式設定基本策略（關於誰可以做什麼），而有些服務網格則提供與以下框架的整合： 。最終目標是讓您的服務接受任何請求，並確信該請求來自可信任來源。 и 此操作是允許的。
4. 負載平衡
TL;DR：根據特定模式在服務實例之間分配負載。
服務部分的「服務」通常由許多相同的副本組成。例如，今天的服務 cache 共有 5 份，明天可能會增加到 11 份。請求發送至 cache，必須按照特定目的進行分配。例如，最小化延遲或最大化獲得工作實例的機率。最常用的演算法是Round-robin演算法，但還有很多其他演算法，例如加權方法。 （加權） 查詢（您可以選擇首選目標）、響鈴 （戒指） 雜湊（對上游主機使用一致性雜湊）或最少查詢方法（優先考慮查詢最少的實例）。
經典負載平衡器具有其他功能，例如 HTTP 快取和 DDoS 保護，但它們與東西向流量（服務網格的典型應用）不太相關。雖然沒有必要使用服務網格進行負載平衡，但它確實允許您從集中控制平面定義和控制每個服務的負載平衡策略，從而無需在網路堆疊中運行和配置單獨的負載平衡器。
5. 熔斷
TL;DR：停止有問題的服務的流量並在最壞的情況下控制損害。
如果由於某種原因服務無法處理流量，則服務網格提供了幾種解決此問題的選項（其他選項將在相關部分討論）。熔斷是斷開服務與流量的最嚴重的選擇。然而，這本身並沒有任何意義——需要一個備用計劃。可提供背壓。 () 對於發出請求的服務（只需記住為此設置服務網格！），或者，例如，將狀態頁面塗成紅色，並使用“下落的鯨魚”（“Twitter 已關閉”）將用戶重定向到頁面的下一個版本。
服務格不僅能讓你確定， 什麼時候 隨後將關閉 該 接下來將會是。在這種情況下，「何時」可以包含指定參數的任意組合：一定時期內的請求總數、並行連線數、待處理的請求、活動重試等。
您可能不想過度使用斷路功能，但最好知道在緊急情況下有一個備用計劃。
6.自動縮放
TL;DR：根據指定的標準增加或減少服務實例的數量。
服務網格不是調度程序，因此它們不會 執行 獨立擴展。然而，它們可以為規劃者提供決策資訊。由於服務網格可以存取服務之間的所有流量，因此它們擁有有關正在發生的事情的大量資訊：哪些服務遇到問題、哪些服務未充分利用（其分配的容量被浪費）等等。
例如，Kubernetes 根據 pod 的 CPU 和記憶體使用情況來擴充服務。 （請參閱我們的報告““ - 大約。 譯）但如果您決定根據任何其他指標（在我們的例子中是與流量相關的指標）進行擴展，那麼您將需要一個專用指標。管理 示範如何使用 , и ，但其過程本身卻相當複雜。我們希望服務網格能夠簡化這個過程，允許我們簡單地指定條件，例如「增加服務實例的數量 auth，如果一分鐘內等待執行的請求數超過閾值。 」
7. 金絲雀部署
TL;DR：在部分使用者身上測試服務的新功能或新版本。
假設您正在開發一款 SaaS 產品，並計劃推出一個很酷的新版本。您在階段性地測試了它並且它運行得很好。然而，人們對於它在現實生活中的行為仍然存在一些擔憂。換句話說，有必要在真實任務上測試新版本，而不會危及用戶的信任。金絲雀部署非常適合這種情況。它們允許您向一部分用戶演示新功能。這個子集可能由最忠實的用戶組成，或是使用產品免費版本的用戶，或是自願成為「白老鼠」的用戶。
服務網格透過允許您指定確定誰可以看到哪個版本的應用程式的標準並相應地路由流量來實現這一點。同時，服務本身沒有任何變化。該服務的 1.0 版本假定所有請求都來自應該看到它的用戶，而 1.1 版本也對其用戶做出同樣的假設。同時，你可以改變新舊版本之間的流量百分比，如果新版本運行穩定並且你的「實驗鼠」同意的話，將越來越多的用戶重定向到新版本。
8.藍綠部署
TL;DR：推出一項很酷的新功能，但要準備好立即恢復它。
意 推出新的「藍色」服務，與舊的「綠色」服務同時推出。如果一切順利，且新服務效果良好，那麼舊服務就可以逐步關閉。 （唉，有一天，這項新的「藍色」服務也會像「綠色」服務一樣消失…）藍綠部署與金絲雀部署的不同之處在於，新功能涵蓋 一下子 使用者（不是部分）；這裡的重點是，如果出現問題，要準備好一個「備用避風港」。
服務網格提供了一種非常方便的方法來測試「藍色」服務，並在出現問題時立即切換到正常運行的「綠色」服務。更不用說他們還提供了大量有關“藍色”運行的信息（請參閱下面的“遙測”部分），這有助於了解它是否已準備好全面運行。
筆記。 翻譯。：您可以在 Kubernetes 中閱讀有關不同部署策略（包括提到的金絲雀、藍綠和其他）的更多信息 .
9. 健康檢查
TL;DR：監控哪些服務實例是健康的，並對不再健康的服務實例做出回應。
健康檢查 （健康檢查） 幫助決定服務實例是否已準備好接收和處理流量。例如，對於 HTTP 服務，健康檢查可能看起來像是對端點的 GET 請求 /health。回答 200 OK 將意味著該實例是健康的，任何其他的 - 它尚未準備好接收流量。服務網格可讓您指定執行健康檢查的方式和執行頻率。然後，這些資訊可用於其他目的，例如負載平衡和斷路。
因此，健康檢查不僅僅是一個用例，而且通常用於實現其他目標。此外，根據健康檢查的結果，可能需要外部（相對於其他服務網格目標）操作：例如，更新狀態頁面、在 GitHub 上建立問題或填寫 JIRA 票證。服務網格提供了一個方便的機制來自動化所有這些。
10. 減載
TL;DR：為了因應使用量的暫時激增而重新路由流量。
如果某項服務的流量過大，你可以暫時將部分流量重新導向到另一個位置（即「丟棄」或「傾倒」） （棚） 讓他在那裡）。例如，到備份服務或資料中心，或到永久服務或資料中心。 話題。因此，服務將繼續處理一些請求，而不是崩潰並停止處理所有請求。削減負載比切斷電路好，但仍然不建議過度使用。它有助於防止可能導致下游服務崩潰的級聯故障。
11. 流量並行化/鏡像
TL;DR：一次將一個請求傳送到多個地方。
有時需要同時向多個服務發送一個請求（或多個請求）。一個典型的例子是將部分生產流量傳送到暫存服務。主生產 Web 伺服器向下游服務發送請求 products.production 並且只對他一個人這樣。服務網格智慧地複製此請求並將其發送到 products.staging，網頁伺服器對此一無所知。
另一個可以在流量並行化之上實現的服務網格的相關用例是 。它涉及向服務的不同版本發送相同的請求並檢查所有版本的行為是否相同。我還沒有遇到像這樣整合回歸測試系統的服務網格實現 ，但這個想法本身看起來很有希望。
12.絕緣
TL;DR：將您的服務網格分解為微型網路。
也稱為 分割隔離是將服務網格劃分為邏輯上獨立的、彼此不了解的段落的藝術。隔離有點像是建立虛擬專用網路。關鍵的區別在於，您仍然可以享受服務網格的所有好處（如服務發現），但同時又增加了安全性。例如，如果攻擊者設法滲透到其中一個子網路中的服務，他將無法看到其他子網路中正在運行的服務或攔截其流量。
此外，這些好處也可能是組織方面的。您可能希望根據公司結構將服務劃分為子網，並讓開發人員從必須考慮整個服務網格的認知負擔中解放出來。
13. 請求速率限制、重試和逾時
TL;DR：不再需要在程式碼庫中包含耗時的請求管理任務。
所有這些都可以被視為單獨的用例，但我決定將它們組合在一起，因為它們有一個共同的特點：它們卸載了通常由應用程式庫處理的請求生命週期管理任務。如果你正在開發 Ruby on Rails Web 伺服器（未與服務網格整合），該伺服器透過以下方式向後端服務發出請求 ，如果 N 個請求失敗，應用程式必須自行決定要做什麼。您還必須弄清楚這些服務可以處理的流量，並使用特殊程式庫對這些參數進行硬編碼。此外，應用程式必須決定何時放棄並讓請求浪費（超時）。為了改變上述任何參數，必須停止、重新設定並重新啟動 Web 伺服器。
將這些問題委託給服務網格不僅意味著服務開發人員不必考慮它們，而且可以以更全面的方式看待它們。如果您有一個複雜的服務鏈，例如 A –> B –> C –> D –> E，您需要考慮請求的整個生命週期。如果任務是延長服務 C 中的逾時時間，那麼一次性完成而不是分部分完成是有意義的：透過更新服務代碼並等待拉取請求被接受並且 CI 系統部署更新的服務。
14.遙測
TL;DR：從服務中收集所有必要的（和不太必要的）資訊。
遙測是一個通用術語，包括指標、分散式追蹤和日誌記錄。服務網格提供收集和處理所有三種類型資料的機制。這時事情就變得有點模糊了，因為可能的選項數量太多了。有一個指標收集工具 以及其他可用於收集日誌的工具 , , 等等 （例如，ClickHouse 與我們的 對於 K8s – 大約翻譯），對於分散式跟踪，有 等等。每個服務網格可能支援某些工具而不支援其他工具。看看這個項目是否能 提供一些收斂。
在這種情況下，服務網格技術的優勢在於，Sidecar 容器原則上可以從其服務中收集上述所有資料。換句話說，您可以使用單一的遙測收集系統，並且服務網格可以透過多種方式處理所有這些資訊。例如：
- CLI 中某個服務的尾部日誌；
- 從服務網格儀表板追蹤請求量；
- 收集分散式追蹤並將其轉發到像 Jaeger 這樣的系統。
請注意，主觀判斷： 一般來說，遙測是強服務網格介入不理想的領域。收集基本資訊和追蹤一些“黃金指標”，如命中率和延遲是很好的，但我們希望我們不會看到試圖取代專門系統的弗蘭肯斯坦堆疊出現，其中一些系統已經很成熟和很好理解。
15. 審計
TL;DR：忘記歷史教訓的人注定會重蹈覆轍。
審計是觀察系統中重要事件的藝術。對於服務網格來說，這可能意味著追蹤誰對特定服務的特定端點發出了請求，或者上個月某個安全相關事件發生了多少次。
顯然，審計與遙測密切相關。不同之處在於，遙測通常與效能和技術適用性等方面相關，而審計可能涉及嚴格技術領域之外的法律和其他問題（例如 GDPR 合規性）。
16. 可視化
TL;DR：奇怪介面的來源－React.js 萬歲。
可能有更合適的術語，但我不知道。我只是指服務網格或其某些組件的圖形表示。這些視覺化可以包括平均延遲、sidecar 容器配置資訊、健康檢查結果和警報等指標。
在服務導向的環境中工作涉及的認知負荷比「巨石陛下」要高得多。因此，應該不惜一切代價，減輕認知壓力。服務網格的簡單圖形介面，只需單擊按鈕即可獲得所需的結果，這對於這項技術的發展至關重要。
未被列入名單
我原本打算在列表中包含更多用例，但後來決定不這樣做。以下是我做出這項決定的原因：
- 多數據中心。在我看來，這與其說是一個用例，不如說是服務網格或某些功能集（如服務發現）的狹隘而具體的應用。
- 入口和出口。這是一個相關領域，但我將自己（也許是人為的）限制在「東西向交通」用例上。入口和出口值得單獨寫一篇文章。
結論
目前就這些了！再次強調，此列表是有條件的，並且很可能是不完整的。如果你覺得我遺漏了什麼或犯了錯誤，請透過 Twitter 聯絡我（）。請遵守禮儀規則。
譯者PS
文章的主要插圖是根據文章中的一張圖片“「（作者：Gregory MacKinnon）。它展示了應用程式（綠色）中的某些功能如何遷移到提供它們之間連接的服務網格（藍色）。
另請閱讀我們的博客：
- «“;
- «“;
- «“。
來源： www.habr.com
