譯者 | 李睿

審校 | 重樓

51CTO讀者成長計劃社群招募，咨詢小助手（微信號：CTOjishuzhan）

【資料圖】

OpenTelemetry項目于2019年推出，是之前就已經(jīng)存在的OpenTracing和OpenCensus這兩個項目的結(jié)合，其目標(biāo)是成為從基于分布式微服務(wù)的應(yīng)用程序中提取遙測數(shù)據(jù)的單一開放標(biāo)準(zhǔn)。該項目是一個規(guī)范、工具和庫的集合，旨在幫助以日志、度量和跟蹤的形式從應(yīng)用程序收集遙測數(shù)據(jù)，然后可以將其轉(zhuǎn)發(fā)到支持聚合、可視化和內(nèi)省這些數(shù)據(jù)的可觀察性工具。

本文將探索一個利用OpenTelemetry(縮寫為OTel)的新用例，特別是由OTel啟用的分布式場景傳播，以創(chuàng)建稱為“沙盒”的輕量級環(huán)境，然后可以用于以可擴(kuò)展的方式啟用各種形式的微服務(wù)測試。此外，還將研究哪種類型的應(yīng)用程序最自然地使用這個模型，以及它如何幫助用戶在開發(fā)生命周期的早期獲得高質(zhì)量的測試反饋。

一、超越OpenTelemetry的可觀察性

OTel的設(shè)計用例之一是跟蹤。跟蹤提供了對分布式系統(tǒng)如何處理用戶或應(yīng)用程序請求的理解，該分布式系統(tǒng)涉及許多獨(dú)立的組件。

1.跟蹤的工作原理

每個微服務(wù)在處理請求時，都會發(fā)出一些被稱為“span”的信息，其中包含一些關(guān)于它正在處理的請求的場景。而一旦所有這些span被發(fā)送到某個后端，它們就可以拼接在一起，告訴整個請求流，這被稱為“跟蹤”。跟蹤可用于了解特定請求發(fā)生了什么，也可用于在聚合場景中發(fā)現(xiàn)和處理可能影響某些請求子集的模式。這些關(guān)于請求通過由多個微服務(wù)組成的系統(tǒng)所經(jīng)過路徑的信息，可以有效地隔離和推斷生產(chǎn)問題發(fā)生時的根本原因。

2.廣義場景傳播

當(dāng)查看下面的圖表時，可以看到每個單獨(dú)的服務(wù)只發(fā)出它自己的“span”，這與它在本地處理請求的方式有關(guān)。因此，為了將屬于單個請求的范圍綁定到單個跟蹤中，需要在這些標(biāo)識請求本身的服務(wù)之間傳播某種形式的場景，這被稱為跟蹤場景。

OTel通過它的庫來實(shí)現(xiàn)這一點(diǎn)，它負(fù)責(zé)沿著同步/異步請求鏈在服務(wù)之間傳遞跟蹤標(biāo)識符。更重要的是，對于一些動態(tài)語言，它只需要放入相應(yīng)的OTel庫，該庫“自動檢測”字節(jié)代碼以透明地執(zhí)行分布式場景傳播。

這種沿請求流傳播場景片段的想法雖然起源于跟蹤，但并不是專門與跟蹤相關(guān)。

它是一種更通用的機(jī)制，可以利用它在微服務(wù)之間傳播更多與跟蹤相關(guān)的信息。有關(guān)Baggage規(guī)格的解釋明確地說明了這一點(diǎn)。

該規(guī)范定義了一個標(biāo)準(zhǔn)，用于表示和傳播一組與分布式請求或工作流執(zhí)行相關(guān)的應(yīng)用程序定義的屬性。這是獨(dú)立于跟蹤場景規(guī)范的。無論是否使用分布式跟蹤，都可以使用Baggage。

該規(guī)范標(biāo)準(zhǔn)化了應(yīng)用程序定義的屬性的表示和傳播。與其相反，跟蹤場景規(guī)范標(biāo)準(zhǔn)化了啟用分布式跟蹤場景所需元數(shù)據(jù)的表示和傳播。

現(xiàn)在開始利用這個機(jī)制來實(shí)現(xiàn)超越遙測和追蹤的用例。

二、使用OpenTelemetry的沙盒

沙盒是一種輕量級環(huán)境，可用于測試和驗證對堆棧中微服務(wù)子集的更改。沙盒與傳統(tǒng)環(huán)境的關(guān)鍵區(qū)別之一是，沙盒使用一組未更改的共享依賴項（其名稱為“基線”），以測試一些已經(jīng)更改的服務(wù)。

這個屬性使得沙盒資源的效率很高，并且設(shè)置起來也很快。反過來，這意味著用戶可以啟動一個沙盒來測試單個提交，或者對每個微服務(wù)的單個更改，這在具有中等規(guī)模(>20左右)的傳統(tǒng)微服務(wù)環(huán)境中變得成本高昂。

這種方法的另一個關(guān)鍵優(yōu)勢是，這些沙盒可以部署到現(xiàn)有的環(huán)境中，例如部署或生產(chǎn)環(huán)境中，以針對最新的依賴項測試更改，從而消除了過時依賴關(guān)系的問題，以及由于它們之間的差異而不得不在“更高”的環(huán)境中反復(fù)重新測試的問題。

以下將了解如何利用OTel中的分布式場景傳播在Kubernetes中創(chuàng)建沙盒。

1.請求路由

由于采用OTel庫和工具，一旦應(yīng)用程序能夠跨請求攜帶任意場景片段，現(xiàn)在就可以開始考慮使用它來隔離請求及其相互影響。

可以通過利用請求級多租戶來創(chuàng)建沙盒。這是通過為每個請求分配一個特定的“租戶”來完成的。租戶只是指與每個請求相關(guān)聯(lián)的標(biāo)識符，告訴系統(tǒng)如何處理和路由特定的請求。在下面的示例中，租賃由“租戶”標(biāo)頭（或者說L7協(xié)議元數(shù)據(jù)）指定，并具有一個值，該值標(biāo)識應(yīng)將其路由到服務(wù)的哪個特定測試版本。該租賃元數(shù)據(jù)使用OTel中的Baggage機(jī)制在服務(wù)之間傳遞，并在后臺使用HTTP/gRPC標(biāo)頭。

以一個簡單的微服務(wù)應(yīng)用程序為例，它包含一個前端和后端，可以設(shè)置如下內(nèi)容：

可以教會前端根據(jù)租約有條件地將正在發(fā)出的出站請求路由到后端。在Kubernetes中，做出路由決策是很簡單的，因為有幾種機(jī)制可以在應(yīng)用程序不參與決策的情況下處理它。例如，可以使用服務(wù)網(wǎng)格(如Istio)，這使得這種路由操作很容易在網(wǎng)格本身的規(guī)則中表示。創(chuàng)建一個Sidecar容器，利用特使或自定義代碼來攔截請求，并在每個微服務(wù)上透明地代理請求，這是非常簡單的。

上面創(chuàng)建的這個設(shè)置也可以擴(kuò)展到測試中的多個工作負(fù)載。這種設(shè)置可以很容易地在現(xiàn)有的登臺和生產(chǎn)集群中進(jìn)行設(shè)置，只需很少的工作。登臺和生產(chǎn)通常已經(jīng)有一個持續(xù)部署(CD)流程，用于更新服務(wù)的穩(wěn)定版本(基線)，并且在同一集群中部署這些沙盒們能夠在不測試這些依賴關(guān)系時重用它們。

只需使用上面所示的請求隔離，這個沙盒就可以用于測試對無狀態(tài)服務(wù)的更改、運(yùn)行API測試等。但是它仍然有局限性，因為還沒有解決隔離可能產(chǎn)生副作用的數(shù)據(jù)突變、通過消息隊列隔離異步工作流或調(diào)用第三方API的問題。以下將解決這些問題，使沙盒更加健壯，并能夠在微服務(wù)環(huán)境中支持更多類型的測試。

2.狀態(tài)隔離

使用這種方法在更多用例中執(zhí)行更復(fù)雜的測試的一個重要步驟是解決狀態(tài)隔離問題。在這里需要注意的一點(diǎn)是，并不是每個涉及微服務(wù)測試的用例都需要額外的狀態(tài)隔離。例如，在人工或使用自動化為特定流運(yùn)行API或E2E測試時，如果在特定流中，能夠創(chuàng)建和清理在測試中使用的實(shí)體，那么已經(jīng)實(shí)現(xiàn)了氣密測試，而實(shí)際上不需要額外的狀態(tài)隔離。

但是，在有些情況下需要額外的隔離，例如在數(shù)據(jù)存儲上執(zhí)行DDL更改，或者如果可能執(zhí)行一些有副作用的突變。在這些情況下，可能希望部署可能受到影響的數(shù)據(jù)存儲的隔離版本，并使沙盒工作負(fù)載使用它們，而不是基線環(huán)境使用的數(shù)據(jù)存儲。

人們可以看到，在實(shí)踐中，盡可能地使用邏輯隔離而不是基礎(chǔ)設(shè)施隔離要有效得多。例如，在像MySQL和PostgreSQL這樣的數(shù)據(jù)庫以及大多數(shù)托管云計算數(shù)據(jù)庫中，數(shù)據(jù)基礎(chǔ)設(shè)施本身提供了一個內(nèi)置的邏輯隔離概念。這種邏輯隔離的選擇使沙盒保持輕量級、資源高效，并且仍然能夠在幾秒鐘內(nèi)啟動，而這對于大多數(shù)情況來說已經(jīng)足夠了。當(dāng)然，如果有必要，總是可以啟動新的物理基礎(chǔ)設(shè)施來與沙盒相關(guān)聯(lián)，但在實(shí)踐中發(fā)現(xiàn)這種需求非常罕見。

建立基礎(chǔ)設(shè)施只是解決方案的一部分；播種數(shù)據(jù)是關(guān)鍵，必須在環(huán)境啟動時/之前執(zhí)行?？梢詫⑺羞@些短暫數(shù)據(jù)存儲的生命周期與環(huán)境本身的生命周期聯(lián)系起來，也可以選擇設(shè)置和維護(hù)預(yù)先預(yù)熱的數(shù)據(jù)存儲，這些數(shù)據(jù)存儲是根據(jù)需要提供給服務(wù)的測試版本的。后一種使用預(yù)熱測試數(shù)據(jù)存儲的方法可以幫助準(zhǔn)備好高質(zhì)量的數(shù)據(jù)，并且在實(shí)踐中，即使對于大型微服務(wù)堆棧，需要保留的此類測試數(shù)據(jù)存儲數(shù)量也不是特別多。一些沙盒方法的高級用戶更進(jìn)一步，實(shí)現(xiàn)了將租賃與特定類型的數(shù)據(jù)集相關(guān)聯(lián)的機(jī)制，例如在Uber關(guān)于SLATE的博客文章中。

使用短暫的隔離數(shù)據(jù)存儲，可以提供高質(zhì)量的數(shù)據(jù)進(jìn)行開發(fā)/測試，同時確保在環(huán)境之外沒有可見的副作用。使用邏輯隔離的想法特別有助于擴(kuò)展沙盒的數(shù)量，同時將額外的基礎(chǔ)設(shè)施或運(yùn)營成本降至最低。與環(huán)境選擇最高隔離級別作為默認(rèn)隔離級別的流行概念相反，可以根據(jù)應(yīng)用程序的用例和性質(zhì)為沙盒選擇最合適的隔離類型。

3.消息隊列

消息隊列在現(xiàn)代微服務(wù)堆棧中無處不在，當(dāng)涉及到這些沙盒時，它提出了一個有趣的挑戰(zhàn)?？紤]到消息隊列，消息隊列的大多數(shù)(如果不是全部)實(shí)現(xiàn)允許在消息中設(shè)置一些報頭/元數(shù)據(jù)。這意味著消息本身包含一些關(guān)于它們來自哪里的請求/流的標(biāo)識的信息，這提供了一些關(guān)于如何進(jìn)行消息路由的想法。

對于消息隊列，通常也首選邏輯隔離，而不是物理隔離。因此，如果Kafka是消息隊列，更愿意設(shè)置單獨(dú)的主題，而不是建立新的孤立的Kafka集群。

雖然這個解決方案保證有效，但實(shí)際上，在大型微服務(wù)環(huán)境中有許多生產(chǎn)者和消費(fèi)者，這使得它不太理想，這是因為它可能最終要求孤立地支持每個微服務(wù)。一種更清潔的隔離方法是教會消費(fèi)者更有選擇性地以“租戶意識”的方式消費(fèi)。

這種讓使用者能夠感知租戶的方法需要在應(yīng)用程序?qū)舆M(jìn)行一些更改。該功能可以很容易地封裝到一個“消息路由器”庫中，可以與使用者客戶端一起使用。這個庫將根據(jù)使用者服務(wù)的標(biāo)識(它是基線嗎?它屬于哪個沙盒?)和包含租賃信息的消息元數(shù)據(jù)。這個庫需要了解集群中不同沙盒的狀態(tài)信息，以便在每個使用者中做出決策，這要求它與運(yùn)行在Kubernetes集群中的某些路由控制器(或服務(wù)網(wǎng)格)進(jìn)行對接。

這種方法解決了一個長期存在的問題，即消息隊列在微服務(wù)堆棧中難以測試，它為具有租戶意識的消費(fèi)者提供了一種多路復(fù)用不同流的干凈方式，并且不需要額外的基礎(chǔ)設(shè)施設(shè)置，這使得它的設(shè)置非?？?。

4.第三方API

現(xiàn)代微服務(wù)棧利用許多第三方API和外部服務(wù)來提供重要的功能，例如支付、集成等，這些功能可以通過外部API端點(diǎn)和Webhook與Kubernetes中的微服務(wù)進(jìn)行對接。在第三方API中，傳播租戶信息的方法因系統(tǒng)而異。

在許多情況下，這些API只是“即發(fā)即棄”，或者具有由應(yīng)用程序本身控制的副作用，在這種情況下，可能不需要通過外部系統(tǒng)進(jìn)行租賃傳播。

在需要外部系統(tǒng)回調(diào)或Webhook在微服務(wù)中執(zhí)行一些額外處理的系統(tǒng)中，HTTP回調(diào)URL中的查詢參數(shù)可以用于傳播租賃信息。Kubernetes集群內(nèi)部的路由機(jī)制將查找包含租賃信息的特定查詢字符串，并使用該查詢字符串將這些回調(diào)請求路由到適當(dāng)?shù)纳澈泄ぷ髫?fù)載。

在實(shí)踐中，這種機(jī)制通常需要對應(yīng)用層進(jìn)行一些較小的修改。微服務(wù)還必須知道它自己的租期。也就是說，擁有關(guān)于它所屬的沙盒的信息，這樣它就可以在回調(diào)時設(shè)置適當(dāng)?shù)淖馄谠獢?shù)據(jù)。

三、在實(shí)踐中實(shí)現(xiàn)沙盒

沙盒方法已經(jīng)在Lyft、Uber和Doordash的數(shù)百個微服務(wù)中大規(guī)模實(shí)現(xiàn)，這允許一個非常有效和可擴(kuò)展的機(jī)制來快速測試和迭代。用戶在與企業(yè)合作中吸取了一些經(jīng)驗教訓(xùn)，可以幫助他們在自己的基礎(chǔ)設(shè)施中采用沙盒。

在實(shí)踐中，對于想要開始采用這種方法的用戶，驗證的最簡單的方法是首先將沙盒集成到一些微服務(wù)的持續(xù)集成（CI）流程中。這些沙盒可以在現(xiàn)有的登臺環(huán)境中創(chuàng)建，這只需要很少的額外設(shè)置，并消除了與共享登臺環(huán)境相關(guān)的瓶頸。從這一點(diǎn)開始，隨著OTel在企業(yè)內(nèi)的采用和場景傳播中的空白被填補(bǔ)，很容易擴(kuò)展沙盒，以在不同微服務(wù)之間進(jìn)行變更的預(yù)合并測試、端到端測試和性能測試。隨著采用率的增長，隨著越來越多的用例可以更快、更容易地使用沙盒解決，對額外測試環(huán)境或staging環(huán)境的需求急劇下降是很典型的。

此外還發(fā)現(xiàn)，服務(wù)之間的合并前測試，例如將屬于不同服務(wù)的測試沙盒放在一起，并通過它們運(yùn)行流量，在開發(fā)生命周期中非常有用，并且在開發(fā)迭代和反饋方面比目前常見的合并后測試要快得多。

在生產(chǎn)環(huán)境中使用沙盒進(jìn)行測試是終極目標(biāo)，它最終能夠完全消除分段。一旦租賃控制和數(shù)據(jù)隔離機(jī)制在組織內(nèi)足夠成熟，這最終是可能的，但對于希望使用沙盒的組織來說，這通常不是最佳的起點(diǎn)。

雖然大多數(shù)微服務(wù)通信模式都很適合這個范例，但也有一些模式是困難的，例如，測試Kubernetes基礎(chǔ)設(shè)施組件或在自定義協(xié)議上使用低級網(wǎng)絡(luò)的組件。對于這些情況，更傳統(tǒng)的設(shè)置環(huán)境的方式或不同的隔離方法可能比使用沙盒更合適。

四、結(jié)論

本文探索了沙盒的范例，沙盒是一種利用請求級隔離來提供可擴(kuò)展的微服務(wù)測試輕量級環(huán)境。還研究了在內(nèi)部實(shí)現(xiàn)有效沙盒解決方案的不同技術(shù)，例如使用OTel傳播場景、請求路由、狀態(tài)隔離以及處理消息隊列和第三方API。最后還研究了對于希望在內(nèi)部實(shí)現(xiàn)沙盒的組織的一些實(shí)際考慮。

沙盒方法已經(jīng)在一些行業(yè)中被有效地使用，以幫助加快和改進(jìn)開發(fā)生命周期。Signadot正在構(gòu)建一個Kubernetes原生解決方案，使創(chuàng)建和部署沙盒變得容易，能夠幫助實(shí)現(xiàn)這一點(diǎn)。

原文鏈接：https://dzone.com/articles/sandboxes-in-kubernetes-using-opentelemetry

關(guān)鍵詞：