譯者 | 李睿

成都創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的桃城網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

審校 | 重樓

讀者成長計(jì)劃社群招募，咨詢小助手（微信號(hào)：CTOjishuzhan）

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

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

一、超越OpenTelemetry的可觀察性

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

1.跟蹤的工作原理

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

2.廣義場(chǎng)景傳播

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

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

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

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

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

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

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

二、使用OpenTelemetry的沙盒

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

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

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

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

1.請(qǐng)求路由

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

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

以一個(gè)簡(jiǎn)單的微服務(wù)應(yīng)用程序?yàn)槔粋€(gè)前端和后端，可以設(shè)置如下內(nèi)容：

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

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

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

2.狀態(tài)隔離

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

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

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

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

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

3.消息隊(duì)列

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

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

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

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

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

4.第三方API

現(xiàn)代微服務(wù)棧利用許多第三方API和外部服務(wù)來提供重要的功能，例如支付、集成等，這些功能可以通過外部API端點(diǎn)和Webhook與Kubernetes中的微服務(wù)進(jìn)行對(duì)接。在第三方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)請(qǐng)求路由到適當(dāng)?shù)纳澈泄ぷ髫?fù)載。

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

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

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

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

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

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

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

四、結(jié)論

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

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

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

網(wǎng)站標(biāo)題：如何在Kubernetes中使用OpenTelemetry的沙盒
分享URL：http://uogjgqi.cn/article/cogppse.html