來源 | 公眾號(hào)：云效（ID: ali_yunxiao)

作者 | 林帆（花名金戟）

正式環(huán)境的穩(wěn)定性，除去軟件自身的質(zhì)量因素，主要與運(yùn)行的主機(jī)、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施相關(guān)，而測(cè)試環(huán)境的穩(wěn)定性則更多受到人為因素影響。由于頻繁的版本變更，以及部署未經(jīng)充分驗(yàn)證的代碼，測(cè)試環(huán)境出故障的情況屢見不鮮。本文介紹了阿里巴巴是如何管理測(cè)試環(huán)境的。

阿里的許多實(shí)踐看似簡(jiǎn)單，背后卻蘊(yùn)涵著許多思考，譬如測(cè)試環(huán)境的管理。

互聯(lián)網(wǎng)產(chǎn)品的服務(wù)通常是由 Web 應(yīng)用、中間件、數(shù)據(jù)庫(kù)和許多后臺(tái)業(yè)務(wù)程序組成的，一套運(yùn)行環(huán)境就是一個(gè)自成一體的小生態(tài)。最基本的運(yùn)行環(huán)境是線上環(huán)境，部署產(chǎn)品的正式發(fā)布版本，為用戶提供持續(xù)可靠的服務(wù)。

除此以外，還有許多不對(duì)外部用戶開放的運(yùn)行環(huán)境，用于產(chǎn)品團(tuán)隊(duì)日常的開發(fā)和驗(yàn)證，統(tǒng)稱為測(cè)試環(huán)境。正式環(huán)境的穩(wěn)定性，除去軟件自身的質(zhì)量因素，主要與運(yùn)行的主機(jī)、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施相關(guān)，而測(cè)試環(huán)境的穩(wěn)定性則更多受到人為因素影響。由于頻繁的版本變更，以及部署未經(jīng)充分驗(yàn)證的代碼，測(cè)試環(huán)境出故障的情況屢見不鮮。

良好的代碼提交習(xí)慣、適當(dāng)?shù)淖兏皺z查有助于減少故障的發(fā)生，但無法徹底杜絕后患。增加多套測(cè)試環(huán)境副本能夠有效控制故障的影響范圍，然而企業(yè)的資源終歸有限，降低測(cè)試環(huán)境成本和提高測(cè)試環(huán)境穩(wěn)定性成為了矛盾的兩面。

在這個(gè)領(lǐng)域里，獨(dú)具匠心的阿里研發(fā)效能團(tuán)隊(duì)設(shè)計(jì)了一種服務(wù)級(jí)復(fù)用的虛擬化技術(shù)，稱為“特性環(huán)境”，其巧妙的思路令人贊嘆。本文將圍繞測(cè)試環(huán)境管理的話題，聊聊這種具有阿里特色的工作方式。

測(cè)試環(huán)境管理的困局

測(cè)試環(huán)境的用途很廣泛，常見的測(cè)試環(huán)境譬如系統(tǒng)集成測(cè)試環(huán)境、用戶驗(yàn)收測(cè)試環(huán)境、預(yù)發(fā)布測(cè)試環(huán)境、灰度測(cè)試環(huán)境等，它們體現(xiàn)了產(chǎn)品的交付生命周期，也間接反映出整個(gè)團(tuán)隊(duì)的組織結(jié)構(gòu)。

小作坊型產(chǎn)品團(tuán)隊(duì)的測(cè)試環(huán)境管理起來十分簡(jiǎn)單，每個(gè)工程師本地就能啟動(dòng)全套軟件組件進(jìn)行調(diào)試，倘若不放心，再加上一個(gè)公共的集成測(cè)試環(huán)境也就足夠。

隨著產(chǎn)品規(guī)模擴(kuò)大，本地啟動(dòng)所有服務(wù)組件逐漸變得既費(fèi)時(shí)又費(fèi)事，工程師們只能在本地運(yùn)行一部分待調(diào)試的組件，然后利用公共測(cè)試環(huán)境上的其余組件組成完整系統(tǒng)。

與此同時(shí)，團(tuán)隊(duì)規(guī)模的擴(kuò)張，使得每個(gè)團(tuán)隊(duì)成員的職責(zé)進(jìn)一步細(xì)分，新的子團(tuán)隊(duì)被劃分出來，這意味著項(xiàng)目的溝通成本增加，公共測(cè)試環(huán)境的穩(wěn)定性開始變得難以控制。在這個(gè)過程中，測(cè)試環(huán)境管理復(fù)雜性帶來的影響，不僅體現(xiàn)在服務(wù)聯(lián)調(diào)變得繁瑣，更直接反映在交付流程和資源成本的變化上。

在交付流程方面，一個(gè)顯著的變化是測(cè)試環(huán)境種類增多。出于不同的用途和目的，工程師們?cè)O(shè)計(jì)出了各式各樣的專用測(cè)試環(huán)境。這些測(cè)試環(huán)境的組合形成了各個(gè)企業(yè)獨(dú)具特色的交付流程。下圖展示了一種用于大型項(xiàng)目的復(fù)雜交付流程。

從單獨(dú)服務(wù)的角度來看，環(huán)境與環(huán)境之間是由流水線相連的，再加上自動(dòng)化測(cè)試或手工審批操作組成關(guān)卡，實(shí)現(xiàn)環(huán)境之間的傳遞。通常越高級(jí)別環(huán)境的部署頻率越低，因此相對(duì)穩(wěn)定性也越高。與之相反，在級(jí)別較低的環(huán)境上，就隨時(shí)可能存在新的部署，會(huì)打擾正在使用該環(huán)境的其他人。有時(shí)為了復(fù)現(xiàn)某些特殊的問題場(chǎng)景，一些開發(fā)者不得不直接登錄到服務(wù)器上面去“搞事情”，進(jìn)一步影響環(huán)境的穩(wěn)定性和可用性。

面對(duì)隨時(shí)可能崩潰的測(cè)試環(huán)境，小企業(yè)會(huì)試著去“堵”：約束服務(wù)變更時(shí)間、設(shè)立嚴(yán)格的變更規(guī)范，大企業(yè)則善于用“疏”：增加測(cè)試環(huán)境副本，隔離故障影響范圍。顯然，不堪重負(fù)的測(cè)試環(huán)境一定越“堵”越“漏”，千年以前大禹治水的故事早就揭示了的道理，刻意的管控拯救不了脆弱的測(cè)試環(huán)境。

近年來，DevOps 文化的興起，端到端解放了開發(fā)者的雙手，這對(duì)于測(cè)試環(huán)境的管理而言卻是一把雙刃劍。一方面，DevOps 鼓勵(lì)開發(fā)人員參與運(yùn)維，了解產(chǎn)品的完整生命周期，有助于減少不必要的低級(jí)運(yùn)維事故；另一方面，DevOps 讓更多的手伸向測(cè)試環(huán)境，更多的變更、更多的 Hotfix 出現(xiàn)了。這些實(shí)踐從全局來看利大于弊，然而并不能緩解測(cè)試環(huán)境的動(dòng)蕩。單純的流程疏通同樣拯救不了脆弱的測(cè)試環(huán)境。

那么該投入的還得投入。將不同團(tuán)隊(duì)所用的低級(jí)別測(cè)試環(huán)境各自獨(dú)立，此時(shí)每個(gè)團(tuán)隊(duì)看到的都是線性流水線，從整體上觀察，則會(huì)程現(xiàn)出河流匯聚的形狀。

由此推廣，理想情況下，每位開發(fā)者都應(yīng)該得到獨(dú)占且穩(wěn)定的測(cè)試環(huán)境，各自不受干擾的完成工作。然而由于成本因素，現(xiàn)實(shí)中在團(tuán)隊(duì)內(nèi)往往只能共享有限的測(cè)試資源，不同成員在測(cè)試環(huán)境相互干擾成為影響軟件開發(fā)質(zhì)量的隱患。增加測(cè)試環(huán)境副本數(shù)本質(zhì)上是一種提高成本換取效率的方法，然而許多試圖在成本和效率之間尋找最優(yōu)平衡的探索者們，似乎都在同一條不歸路上越行越遠(yuǎn)。

由于客觀的規(guī)模和體量，上述這些測(cè)試環(huán)境管理的麻煩事兒，阿里的產(chǎn)品團(tuán)隊(duì)都無法幸免。

?首先是測(cè)試環(huán)境種類的管理

在阿里內(nèi)部，同樣有十分豐富的測(cè)試環(huán)境區(qū)分。各種測(cè)試環(huán)境的命名與其作用息息相關(guān)，雖然業(yè)界有些常用的名稱，但都未形成權(quán)威的標(biāo)準(zhǔn)。實(shí)際上，環(huán)境的名稱只是一種形式，關(guān)鍵還在于各種測(cè)試環(huán)境應(yīng)當(dāng)分別適配于特定應(yīng)用場(chǎng)景，且場(chǎng)景之間應(yīng)當(dāng)或多或少存在一些差異。

這種差異有些在于運(yùn)行的服務(wù)種類，譬如性能測(cè)試環(huán)境很可能只需要運(yùn)行與壓力測(cè)試相關(guān)的那部分訪問量最大的關(guān)鍵業(yè)務(wù)服務(wù)，其他服務(wù)運(yùn)行了也是浪費(fèi)資源。有些差異在于接入數(shù)據(jù)的來源，譬如開發(fā)自測(cè)的環(huán)境的數(shù)據(jù)源與正式環(huán)境肯定不一樣，這樣測(cè)試使用的假數(shù)據(jù)就不會(huì)污染線上用戶的請(qǐng)求；預(yù)發(fā)布環(huán)境（或用戶驗(yàn)收測(cè)試環(huán)境）會(huì)用與正式環(huán)境一致的數(shù)據(jù)源（或正式數(shù)據(jù)源的拷貝），以便反映新功能在真實(shí)數(shù)據(jù)上運(yùn)行的情況；自動(dòng)化測(cè)試相關(guān)的環(huán)境會(huì)有單獨(dú)的一套測(cè)試數(shù)據(jù)庫(kù)，以避測(cè)試運(yùn)行過程中受到其他人為操作的干擾。

還有些差異在于使用者的不同，譬如灰度和預(yù)發(fā)布環(huán)境都使用正式的數(shù)據(jù)源，但灰度環(huán)境的使用者是一小撮真實(shí)的外部用戶，而預(yù)發(fā)布環(huán)境的使用者都是內(nèi)部人員。總之，沒必要為一個(gè)不存在業(yè)務(wù)特殊性的測(cè)試場(chǎng)景專門發(fā)明一種測(cè)試環(huán)境。

在集團(tuán)層面，阿里對(duì)流水線形式的約束相對(duì)寬松。客觀的講，只有在一線的開發(fā)團(tuán)隊(duì)知道最適合團(tuán)隊(duì)的交付流程應(yīng)該是什么樣子。阿里的開發(fā)平臺(tái)只是規(guī)范了一些推薦的流水線模板，開發(fā)者可在此基礎(chǔ)上進(jìn)行發(fā)揮。列舉幾個(gè)典型的模板例子：

這里出現(xiàn)了幾種外界不太常見的環(huán)境類型名稱，稍后會(huì)詳細(xì)介紹。

?其次是測(cè)試環(huán)境成本的管理

成本管理的問題十分棘手且十分值得深究。與測(cè)試環(huán)境相關(guān)的成本主要包括管理環(huán)境所需的“人工成本”和購(gòu)買基礎(chǔ)設(shè)施所需的“資產(chǎn)成本”。通過自動(dòng)化以及自服務(wù)化的工具可以有效降低人工相關(guān)的成本，自動(dòng)化又是個(gè)很大的話題，宜另起一篇文章討論，此處暫且收住。

資產(chǎn)購(gòu)買成本的降低依賴技術(shù)的改良和進(jìn)步（排除規(guī)模化采購(gòu)帶來的價(jià)格變化因素），而基礎(chǔ)設(shè)施技術(shù)的發(fā)展史包括兩大領(lǐng)域：硬件和軟件。硬件發(fā)展帶來的成本大幅下降，通常來自于新的材料、新的生產(chǎn)工藝、以及新的硬件設(shè)計(jì)思路；軟件發(fā)展帶來的基礎(chǔ)設(shè)施成本大幅下降，目前看來，大多來自于虛擬化（即資源隔離復(fù)用）技術(shù)的突破。

最早的虛擬化技術(shù)是虛擬機(jī)，早在 20 世紀(jì) 50 年代，IBM 就開始利用這種硬件級(jí)的虛擬化方法獲得成倍的資源利用率提升。虛擬機(jī)上的不同隔離環(huán)境之間各自運(yùn)行完整操作系統(tǒng)，具有很好的隔離性，通用性強(qiáng)，但對(duì)于運(yùn)行業(yè)務(wù)服務(wù)的場(chǎng)景，顯得略為笨重。2000 年后，KVM、XEN 等開源項(xiàng)目使得硬件級(jí)虛擬化廣泛普及。

與此同時(shí)，另一種更輕量的虛擬化技術(shù)出現(xiàn)了，以 OpenVZ、LXC 為代表的早期容器技術(shù)，實(shí)現(xiàn)了建立于操作系統(tǒng)內(nèi)核之上的運(yùn)行環(huán)境虛擬化，減少了獨(dú)立操作系統(tǒng)的資源消耗，以犧牲一定隔離性為代價(jià)，獲得更高的資源利用率。

之后誕生的 Docker 以其鏡像封裝和單進(jìn)程容器的理念，將這種內(nèi)核級(jí)虛擬化技術(shù)推上百萬人追捧的高度。阿里緊隨技術(shù)前進(jìn)的步伐，早早的就用上了虛擬機(jī)和容器，在 2017 年雙十一時(shí)，在線業(yè)務(wù)服務(wù)的容器化比例已經(jīng)達(dá)到 100%。然而，接下來的挑戰(zhàn)是，基礎(chǔ)設(shè)施資源利用率還能做得更高嗎？

甩掉了虛擬機(jī)的硬件指令轉(zhuǎn)換和操作系統(tǒng)開銷，運(yùn)行在容器中的程序與普通程序之間只有一層薄薄的內(nèi)核 Namespace 隔離，完全沒有運(yùn)行時(shí)性能損耗，虛擬化在這個(gè)方向上似乎已經(jīng)發(fā)展到了極限。唯一的可能是，拋開通用場(chǎng)景，專注到測(cè)試環(huán)境管理的特定場(chǎng)景上，繼續(xù)尋找突破。終于，阿里在這個(gè)領(lǐng)域里發(fā)現(xiàn)了新的寶藏：服務(wù)級(jí)虛擬化。

所謂服務(wù)級(jí)虛擬化，本質(zhì)上是基于消息路由的控制，實(shí)現(xiàn)集群中部分服務(wù)的復(fù)用。在服務(wù)級(jí)虛擬化方式下，許多外表龐大的獨(dú)立測(cè)試環(huán)境實(shí)際只需要消耗極小的額外基礎(chǔ)設(shè)施資源，即使給每個(gè)開發(fā)者配備一套專用的測(cè)試環(huán)境集群都不再是吹牛。

具體來說，在阿里的交付流程上，包含兩種特殊類型的測(cè)試環(huán)境：“公共基礎(chǔ)環(huán)境”和“特性環(huán)境”，它們形成了具有阿里特色的測(cè)試環(huán)境使用方法。公共基礎(chǔ)環(huán)境是一個(gè)全套的服務(wù)運(yùn)行環(huán)境，它通常運(yùn)行一個(gè)相對(duì)穩(wěn)定的服務(wù)版本，也有些團(tuán)隊(duì)將始終部署各服務(wù)的最新版本的低級(jí)別環(huán)境（稱為“日常環(huán)境”）作為公共基礎(chǔ)環(huán)境。

特性環(huán)境是這套方法中最有意思的地方，它是虛擬的環(huán)境。從表面上看，每個(gè)特性環(huán)境都是一套獨(dú)立完整的測(cè)試環(huán)境，由一系列服務(wù)組成集群，而實(shí)際上，除了個(gè)別當(dāng)前使用者想要測(cè)試的服務(wù)，其余服務(wù)都是通過路由系統(tǒng)和消息中間件虛擬出來的，指向公共基礎(chǔ)環(huán)境的相應(yīng)服務(wù)。由于在阿里通常的開發(fā)流程中，開發(fā)任務(wù)需要經(jīng)過特性分支、發(fā)布分支和諸多相關(guān)環(huán)節(jié)最后發(fā)布上線，大多數(shù)環(huán)境都從發(fā)布分支部署，唯獨(dú)這種開發(fā)者自用的虛擬環(huán)境部署來自代碼特性分支的版本，故可稱為“特性環(huán)境”（阿里內(nèi)部叫“項(xiàng)目環(huán)境”）。

舉個(gè)具體例子，某交易系統(tǒng)的完整部署需要由鑒權(quán)服務(wù)、交易服務(wù)、訂單服務(wù)、結(jié)算服務(wù)等十幾種小系統(tǒng)以及相應(yīng)的數(shù)據(jù)庫(kù)、緩存池、消息中間件等組成，那么它的公共基礎(chǔ)環(huán)境就是這樣一套具備所有服務(wù)和周邊組件的完整環(huán)境。假設(shè)此時(shí)有兩套特性環(huán)境在運(yùn)行，一套只啟動(dòng)了交易服務(wù)，另一套啟動(dòng)了交易服務(wù)、訂單服務(wù)和結(jié)算服務(wù)。對(duì)于第一套特性環(huán)境的使用者而言，雖然除交易服務(wù)外的所有服務(wù)實(shí)際上都由公共基礎(chǔ)環(huán)境代理，但在使用時(shí)就像是自己獨(dú)占一整套完整環(huán)境：可以隨意部署和更新環(huán)境中交易服務(wù)的版本，并對(duì)它進(jìn)行調(diào)試，不用擔(dān)心會(huì)影響其他用戶。對(duì)于第二套特性環(huán)境的使用者，則可以對(duì)部署在該環(huán)境中的三個(gè)服務(wù)進(jìn)行聯(lián)調(diào)和驗(yàn)證，倘若在場(chǎng)景中使用到了鑒權(quán)服務(wù)，則由公共基礎(chǔ)環(huán)境的鑒權(quán)服務(wù)來響應(yīng)。

咋看起來，這不就是動(dòng)態(tài)修改域名對(duì)應(yīng)的路由地址、或者消息主題對(duì)應(yīng)的投遞地址么？實(shí)事并沒那么簡(jiǎn)單，因?yàn)椴荒転榱四硞€(gè)特性環(huán)境而修改公共基礎(chǔ)環(huán)境的路由，所以單靠正統(tǒng)路由機(jī)制只能實(shí)現(xiàn)單向目標(biāo)控制，即特性環(huán)境里的服務(wù)主動(dòng)發(fā)起調(diào)用能夠正確路由，若請(qǐng)求的發(fā)起方在公共基礎(chǔ)環(huán)境上，就無法知道該將請(qǐng)求發(fā)給哪個(gè)特性環(huán)境了。對(duì)于 HTTP 類型的請(qǐng)求甚至很難處理回調(diào)的情況，當(dāng)處于公共基礎(chǔ)環(huán)境的服務(wù)進(jìn)行回調(diào)時(shí)，域名解析會(huì)將目標(biāo)指向公共基礎(chǔ)環(huán)境上的同名服務(wù)。

如何才能實(shí)現(xiàn)數(shù)據(jù)雙向的正確路由和投遞呢？不妨先回到這個(gè)問題的本質(zhì)上來：請(qǐng)求應(yīng)該進(jìn)入哪個(gè)特性環(huán)境，是與請(qǐng)求的發(fā)起人相關(guān)的。因此實(shí)現(xiàn)雙向綁定的關(guān)鍵在于，識(shí)別請(qǐng)求發(fā)起人所處的特性環(huán)境和進(jìn)行端到端的路由控制。這個(gè)過程與“灰度發(fā)布”很有幾分相似，可采用類似的思路解決。

得益于阿里在中間件領(lǐng)域的技術(shù)積累，和鷹眼等路由追蹤工具的廣泛使用，識(shí)別請(qǐng)求發(fā)起人和追溯回調(diào)鏈路都不算難事。如此一來，路由控制也就水到渠成了。當(dāng)使用特性環(huán)境時(shí)，用戶需要“加入”到該環(huán)境，這個(gè)操作會(huì)將用戶標(biāo)識(shí)（如 IP 地址或用戶 ID）與指定的特性環(huán)境關(guān)聯(lián)起來，每個(gè)用戶只能同時(shí)屬于一個(gè)特性環(huán)境。當(dāng)數(shù)據(jù)請(qǐng)求經(jīng)過路由中間件（消息隊(duì)列、消息網(wǎng)關(guān)、HTTP 網(wǎng)關(guān)等），一旦識(shí)別到請(qǐng)求的發(fā)起人當(dāng)前處在特性環(huán)境中，就會(huì)嘗試把請(qǐng)求路由給該環(huán)境中的服務(wù)，若該環(huán)境沒有與目標(biāo)一致的服務(wù)，才路由或投遞到公共基礎(chǔ)環(huán)境上。

特性環(huán)境并不是孤立存在的，它可以建立在容器技術(shù)之上，從而獲得更大的靈活性。正如將容器建立在虛擬機(jī)之上得到基礎(chǔ)設(shè)施獲取的便利性一樣，在特性環(huán)境中，通過容器快速而動(dòng)態(tài)的部署服務(wù)，意味著用戶可以隨時(shí)向特性環(huán)境中增加一個(gè)需要修改或調(diào)試的服務(wù)，也可以將環(huán)境中的某個(gè)服務(wù)隨時(shí)銷毀，讓公共基礎(chǔ)環(huán)境的自動(dòng)接替它。

?還有一個(gè)問題是服務(wù)集群調(diào)試

配合 AoneFlow 的特性分支工作方式，倘若將幾個(gè)服務(wù)的不同特性分支部署到同一個(gè)特性環(huán)境，就可以進(jìn)行多特性的即時(shí)聯(lián)調(diào)，從而將特性環(huán)境用于集成測(cè)試。不過，即使特性環(huán)境的創(chuàng)建成本很低，畢竟服務(wù)是部署在測(cè)試集群上的。這意味著每次修改代碼都需要等待流水線的構(gòu)建和部署，節(jié)約了空間開銷，卻沒有縮短時(shí)間開銷。

為了進(jìn)一步的降低成本、提高效率，阿里團(tuán)隊(duì)又搗鼓出了一種開腦洞的玩法：將本地開發(fā)機(jī)加入特性環(huán)境。在集團(tuán)內(nèi)部，由于開發(fā)機(jī)和測(cè)試環(huán)境都使用內(nèi)網(wǎng) IP 地址，稍加變通其實(shí)不難將特定的測(cè)試環(huán)境請(qǐng)求直接路由到開發(fā)機(jī)。這意味著，在特性環(huán)境的用戶即使訪問一個(gè)實(shí)際來自公共基礎(chǔ)環(huán)境的服務(wù)，在后續(xù)處理鏈路上的一部分服務(wù)也可以來自特性環(huán)境，甚至來自本地環(huán)境。現(xiàn)在，調(diào)試集群中的服務(wù)變得非常簡(jiǎn)單，再也不用等待漫長(zhǎng)的流水線構(gòu)建，就像整個(gè)測(cè)試環(huán)境都運(yùn)行在本地一樣。

DIY 體驗(yàn)特性環(huán)境

覺得服務(wù)級(jí)虛擬化太小眾，離普通開發(fā)者很遠(yuǎn)？實(shí)事并非如此，我們現(xiàn)在就可以動(dòng)手 DIY 個(gè)體驗(yàn)版的特性環(huán)境來玩。

阿里的特性環(huán)境實(shí)現(xiàn)了包括 HTTP 調(diào)用、RPC 調(diào)用、消息隊(duì)列、消息通知等各類常用服務(wù)通信方式的雙向路由服務(wù)級(jí)虛擬化。要完成這樣的功能齊全的測(cè)試環(huán)境有點(diǎn)費(fèi)勁，從通用性角度考慮，咱不妨從最符合大眾口味的 HTTP 協(xié)議開始，做個(gè)支持單向路由的簡(jiǎn)易款。

為了便于管理環(huán)境，最好得有一個(gè)能跑容器的集群，在開源社區(qū)里，功能齊全的 Kubernetes 是個(gè)不錯(cuò)的選擇。在 Kubernetes 中有些與路由控制有關(guān)的概念，它們都以資源對(duì)象的形式展現(xiàn)給用戶。

簡(jiǎn)單介紹一下，Namespace 對(duì)象能隔離服務(wù)的路由域（與容器隔離使用的內(nèi)核 Namespace 不是一個(gè)東西，勿混淆），Service 對(duì)象用來指定服務(wù)的路由目標(biāo)和名稱，Deployment 對(duì)象對(duì)應(yīng)真實(shí)部署的服務(wù)。類型是 ClusterIP（以及 NodePort 和 LoadBalancer 類型，暫且忽略它們）的 Service 對(duì)象可路由相同 Namespace 內(nèi)的一個(gè)真實(shí)服務(wù)，類型是 ExternalName 的 Service 對(duì)象則可作為外部服務(wù)在當(dāng)前 Namespace 的路由代理。這些資源對(duì)象的管理都可以使用 YAML 格式的文件來描述，大致了解完這些，就可以開始動(dòng)工了。

基礎(chǔ)設(shè)施和 Kubernetes 集群搭建的過程略過，下面直接進(jìn)正題。先得準(zhǔn)備路由兜底的公共基礎(chǔ)環(huán)境，這是一個(gè)全量測(cè)試環(huán)境，包括被測(cè)系統(tǒng)里的所有服務(wù)和其他基礎(chǔ)設(shè)施。暫不考慮對(duì)外訪問，公共基礎(chǔ)環(huán)境中的所有服務(wù)相應(yīng)的 Service 對(duì)象都可以使用 ClusterIP 類型，假設(shè)它們對(duì)應(yīng)的 Namespace 名稱為 pub-base-env。這樣一來，Kubernetes 會(huì)為此環(huán)境中的每個(gè)服務(wù)自動(dòng)賦予 Namespace 內(nèi)可用的域名“服務(wù)名.svc.cluster”和集群全局域名“服務(wù)名.pub-base-env.svc.cluster”。有了兜底的保障后，就可以開始創(chuàng)建特性環(huán)境了，最簡(jiǎn)單的特性環(huán)境可以只包含一個(gè)真實(shí)服務(wù)（例如 trade-service），其余服務(wù)全部用 ExternalName 類型的 Service 對(duì)象代理到公共基礎(chǔ)環(huán)境上。假設(shè)它使用名稱為 feature-env-1 的 Namespace，其描述的 YAML 如下（省略了非關(guān)鍵字段的信息）：

kind: Namespace metadata:name: feature-env-1 --- kind: Service metadata:name: trade-servicenamespace: feature-env-1 spec:type: ClusterIP... --- kind: Deployment metadata:name: trade-servicenamespace: feature-env-1 spec:... --- kind: Service metadata:name: order-servicenamespace: feature-env-1 spec:type: ExternalNameexternalName: order-service.pub-base-env.svc.cluster... --- kind: Service ...

注意其中的 order-service 服務(wù)，它在當(dāng)前特性環(huán)境 Namespace 中可以使用局部域名 order-service.svc.cluster 訪問，請(qǐng)求會(huì)路由到它配置的全局域名 order-service.pub-base-env.svc.cluster，即公共基礎(chǔ)環(huán)境的同名服務(wù)上處理。處于該 Namespace 中的其它服務(wù)感知不到這個(gè)差異，而是會(huì)覺得這個(gè) Namespace 中部署了所有相關(guān)的服務(wù)。

若在特性的開發(fā)過程中，開發(fā)者對(duì) order-service 服務(wù)也進(jìn)行了修改，此時(shí)應(yīng)該將修改過的服務(wù)版本添加到環(huán)境里來。只需修改 order-service 的 Service 對(duì)象屬性（使用 Kubernetes 的 patch 操作），將其改為 ClusterIP 類型，同時(shí)在當(dāng)前 Namespace 中創(chuàng)建一個(gè) Deployment 對(duì)象與之關(guān)聯(lián)即可。

由于修改 Service 對(duì)象只對(duì)相應(yīng) Namespace（即相應(yīng)的特性環(huán)境）內(nèi)的服務(wù)有效，無法影響從公共基礎(chǔ)環(huán)境回調(diào)的請(qǐng)求，因此路由是單向的。在這種情況下，特性環(huán)境中必須包含待測(cè)調(diào)用鏈路的入口服務(wù)和包含回調(diào)操作的服務(wù)。例如待測(cè)的特性是由界面操作發(fā)起的，提供用戶界面的服務(wù)就是入口服務(wù)。即使該服務(wù)沒有修改，也應(yīng)該在特性環(huán)境中部署它的主線版本。

通過這種機(jī)制也不難實(shí)現(xiàn)把集群服務(wù)局部替換成本地服務(wù)進(jìn)行調(diào)試開發(fā)的功能，倘若集群和本地主機(jī)都在內(nèi)網(wǎng)，將 ExternalName 類型的 Service 對(duì)象指向本地的 IP 地址和服務(wù)端口就可以了。否則需要為本地服務(wù)增加公網(wǎng)路由，通過動(dòng)態(tài)域名解析來實(shí)現(xiàn)。

與此同時(shí)，云效也正在逐步完善基于 Kubernetes 的特性環(huán)境解決方案，屆時(shí)將會(huì)提供更加全面的路由隔離支持。值得一提的是，由于公有云的特殊性，在聯(lián)調(diào)時(shí)將本地主機(jī)加入云上集群是個(gè)必須克服的難題。為此云效實(shí)現(xiàn)了通過隧道網(wǎng)絡(luò) +kube-proxy 自身路由能力，將本地局域網(wǎng)主機(jī)（無需公網(wǎng) IP 地址）加入到不在同一內(nèi)網(wǎng) Kubernetes 集群進(jìn)行聯(lián)調(diào)的方式。其中的技術(shù)細(xì)節(jié)也將在近期的云效公眾號(hào)向大家揭曉，敬請(qǐng)留意。

? ?小結(jié)? ?

當(dāng)許多人還在等待，在虛擬機(jī)和容器之后，下一輪虛擬化技術(shù)的風(fēng)口何時(shí)到來的時(shí)候，阿里已經(jīng)給出了一種答案。創(chuàng)業(yè)者的心態(tài)讓阿里人懂得，能省必須省。其實(shí)，限制創(chuàng)新的往往不是技術(shù)而是想象力，服務(wù)級(jí)虛擬化的理念突破了人們對(duì)環(huán)境副本的傳統(tǒng)認(rèn)知，以獨(dú)特的角度化解了測(cè)試環(huán)境成本與穩(wěn)定性的矛盾。

作為一種頗具特色的技術(shù)載體，特性環(huán)境的價(jià)值不僅僅在于輕量的測(cè)試環(huán)境管理體驗(yàn)，更在于為每位開發(fā)人員帶來流暢的工作方式，實(shí)則是“簡(jiǎn)約而不簡(jiǎn)單”。

總結(jié)

以上是生活随笔為你收集整理的阿里巴巴是如何管理测试环境的？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。