1、2018/7/24極客時間 | 持續(xù)交付36講09 測試環(huán)境要多少？從成本與效率說起2018-07-24 王瀟俊09 測試環(huán)境要多少？從成本與效率說起朗讀人：王瀟俊1005 | 4.63M在上一篇文章中，我給你分享了互聯(lián)網(wǎng)公司測試環(huán)境的常見結(jié)構(gòu)，以及對用戶來說什么樣的測試環(huán)境才是好用的。然而對測試環(huán)境來說，只是高效好用還不夠，還要考慮到成本問題。效率和成本永遠(yuǎn)是一對矛盾體。今天，我就從成本和效率出發(fā)，和你聊聊構(gòu)建測試環(huán)境時，還需要考慮的其他維度。測試環(huán)境的成本談到環(huán)境成本，你很自然地就會想到云計算，持續(xù)交付：發(fā)布可靠軟件的系統(tǒng)方法一書出版時，云計算還是一個時髦的概念，而 8 年后的今天，云技術(shù)

2、已經(jīng)非常成熟了。今天，部分傳統(tǒng)企業(yè)和互聯(lián)網(wǎng)企業(yè)都在選擇混合云架構(gòu)，而創(chuàng)業(yè)公司選擇公有云已經(jīng)有了點(diǎn)模式化的意味。公有云非常好地滿足了 DevOps 的“基礎(chǔ)設(shè)施即代碼”的理念，哪怕你完全不使用公有云，那在環(huán)境中整合開源的私有云技術(shù)依然能為你帶來不少便利。然而，云計算并非“銀彈”，我們上云后，在成本上，還是有很多值得去思考和做的事情。/column/article/114726/6尤其是當(dāng)環(huán)境數(shù)量增加時，你很容易就可以想到成本會增加，但是你可能并不明白要增加哪些方面的成本，以及會增加多少的問題。那么，接下來，我就跟你聊聊當(dāng)環(huán)境數(shù)量增加時，你需要考慮的

3、成本有哪些呢？首先是機(jī)器資源成本保證環(huán)境的獨(dú)立性，是你構(gòu)建更多套環(huán)境的一個主要原因。但是，一套獨(dú)立的、擁有完整鏈路的環(huán)境成本是非常高的。那么，以阿里云的價格為例，我來跟你一起算算這筆賬。假設(shè)一個只有 100 個應(yīng)用的微服務(wù)架構(gòu)環(huán)境，選取單應(yīng)用單機(jī) 2 核 4G 內(nèi)存的低配置實(shí)例方式進(jìn)行部署，單實(shí)例的年價格在 2000 元左右，100 個實(shí)例的話，一年的花費(fèi)就是 20 萬元左右。而這只是最保守的計算，隨著服務(wù)規(guī)模的增加，以及更多環(huán)境的需要，整體花費(fèi)上漲兩個數(shù)量級也是很正常的。這樣的問題在開發(fā)環(huán)境和集成環(huán)境的表現(xiàn)是最明顯的。為了保證這兩套環(huán)境的獨(dú)立性，你必然需要有很高的環(huán)境副本數(shù)。但無論如何，你都

4、不可能讓每一個開發(fā)和測試人員都擁有一套完整環(huán)境的硬件資源?？梢姡恳惶篆h(huán)境的機(jī)器資源成本都很大，而且隨著需求的增加成比例增長。其次是管理成本管理成本，包括維護(hù)環(huán)境的可用性，配置的管理成本，和測試數(shù)據(jù)的維護(hù)成本三個維度。1. 維護(hù)多套環(huán)境的第一要點(diǎn)是，維護(hù)環(huán)境的可用性。與云時代之前相比，容器技術(shù)已經(jīng)解決了很多問題。比如，服務(wù)器操作系統(tǒng)級別的依賴的標(biāo)準(zhǔn)化更容易了；當(dāng)出現(xiàn)硬件故障時，遷移和恢復(fù)服務(wù)也更加方便了。但是，容器技術(shù)并沒有解決故障定位的問題。微服務(wù)架構(gòu)下集群的節(jié)點(diǎn)數(shù)量多, 調(diào)用鏈復(fù)雜，你不再能確定到底是環(huán)境問題，還是程序本身的 Bug，也就導(dǎo)致定位故障更加困難了。所以，更多套環(huán)境就意味著更大

5、的集群規(guī)模，出現(xiàn)故障的幾率會隨之增加，而解決故障也會占用你更長的工作時間。2. 維護(hù)多套環(huán)境的另一大成本是，配置的管理成本。配置是環(huán)境管理中最核心的內(nèi)容，創(chuàng)建一套環(huán)境時，為了保證它真正的獨(dú)立可用，不僅要保證應(yīng)用可以成功運(yùn)行，還要保證應(yīng)用在基礎(chǔ)設(shè)施的配置是正確的。比如集成測試環(huán)境下部署了一個應(yīng)用的多個平行項(xiàng)目，就需要有辦法保證測試人員能訪問到正確的應(yīng)用。如果是 Web 應(yīng)用，你就要考慮把應(yīng)用綁定到不同的域名，這樣就會增加域名管理的成本； 如果是一個 service 應(yīng)用，你就要考慮到這些 service 不會被其他項(xiàng)目的、無關(guān)環(huán)境中的應(yīng)用調(diào)用到，同時也不會調(diào)用到其他錯誤的服務(wù)。每多一套環(huán)境，就會

6、多一套這樣的配置，而且這些配置都需要在各類基礎(chǔ)設(shè)施中生效。3. 維護(hù)多套環(huán)境的第三大成本是，測試數(shù)據(jù)的維護(hù)成本。測試數(shù)據(jù)也是環(huán)境中極為重要的一個組成部分。當(dāng)并行環(huán)境的數(shù)量變多后，數(shù)據(jù)的維護(hù)同樣是讓人頭疼的問題。為了保證環(huán)境的真，哪些環(huán)境共用一套數(shù)據(jù)庫，以及測試數(shù)據(jù)的更新在多套環(huán)境中怎么執(zhí)行等等，都需要非常高的管理成本。最后是流程成本流程成本主要包括溝通成本和測試成本兩個方面。1. 溝通成本每增加一套環(huán)境，你都需要考慮團(tuán)隊(duì)成員如何在新環(huán)境上溝通協(xié)作。誰在占用，何時退出這些信息，你都需要第一時間告知團(tuán)隊(duì)。當(dāng)環(huán)境的數(shù)量變得非常多以后，做好這些事的難度就很大了。2. 測試成本在開發(fā)環(huán)境，集成測試環(huán)境，

7、驗(yàn)收測試環(huán)境，預(yù)發(fā)布環(huán)境，生產(chǎn)環(huán)境這樣的結(jié)構(gòu)下，核心功能的測試流程就至少會執(zhí)行五次。每引入一套新的環(huán)境，測試流程都會變得更加復(fù)雜。如何調(diào)解效率和成本的矛盾？現(xiàn)在你應(yīng)該已經(jīng)意識到，因?yàn)樵黾右惶篆h(huán)境帶來的成本竟然有那么多。但是為了提高持續(xù)交付的效率，隔離的多套環(huán)境又是必不可少的。那么，你究竟應(yīng)該怎樣去規(guī)劃和設(shè)計環(huán)境呢？ 第一，公共與泳道的第一個關(guān)鍵點(diǎn)是抽象公共環(huán)境，而其中的公共服務(wù)基本都屬于底層服務(wù)，相對比較穩(wěn)定，這是解耦環(huán)境的重中之重。 比如我們經(jīng)常會將中間件，框架類服務(wù)，底層業(yè)務(wù)公共（賬戶，登陸，基本信息）服務(wù)部署在這套公共環(huán)境下。在公共環(huán)境的基礎(chǔ)上，可以通過泳道的方式隔離相關(guān)測試應(yīng)用，利用

8、LB 和 SOA 中間件對路由功能的支持，在一個大的公共集成測試環(huán)境中隔離出一個個獨(dú)立的功能測試環(huán)境，那么增加的機(jī)器成本就僅與被并行的項(xiàng)目多少有關(guān)系了。為了幫助你理解，我給你分享一個具體的案例。境內(nèi)的 web 服務(wù)器調(diào)用。而“下單 service 2.0”所依賴調(diào)用的“支付 service 1.0”則放在公共環(huán)境中。于此同時，如圖中所示的“功能環(huán)境 2”，可以同時支持“下單 service 3.0”這個并行版本與一個新版本的“支付 service 2.0”進(jìn)行聯(lián)調(diào)，此環(huán)境是不會調(diào)用公共環(huán)境中的“支付 service 1.0”的。通過這種方式，你就可以解決并行開發(fā)和并行測試的問題了。第二，避免產(chǎn)

9、生多套公共環(huán)境從原則上講，集成環(huán)境中只要有一套公共環(huán)境就足夠了。但有時候，你會發(fā)現(xiàn)項(xiàng)目的范圍特別廣，依賴應(yīng)用或者影響應(yīng)用特別多，特別是一些底層服務(wù)的改動或者重構(gòu)等。在這種情況下，如果把依賴它的所有服務(wù)都部署起來，就很有可能變成第二、第三套公共環(huán)境了。這種情況下，你可以通過 mock service 來模擬大多數(shù)服務(wù)，這樣就可以達(dá)到測試環(huán)境的最小集合了。關(guān)于 mock service 如何做，我會在后續(xù)的講解中，為你詳細(xì)解釋。第三，減輕配置的復(fù)雜度而對于減輕環(huán)境配置的復(fù)雜度來說，你可以從以下兩個方面著手：1. 制定一套統(tǒng)一配置的解決方案；2. 要讓環(huán)境自己說話，有效減少配置項(xiàng)。比如，對于數(shù)據(jù)庫，

10、對于不同的測試需求，我們可能會在公共的數(shù)據(jù)庫和獨(dú)立的數(shù)據(jù)庫之間進(jìn)行頻繁切換；又比如，我們可以在啟動應(yīng)用時自動配置正確的數(shù)據(jù)庫。那么無論有多少套環(huán)境，配置也不是一件難事。關(guān)于減輕配置的復(fù)雜度，我也會在專欄后續(xù)的講解中，給你詳細(xì)分析如何實(shí)現(xiàn)?？偨Y(jié)我們究竟需要多少套環(huán)境，這個問題的答案應(yīng)該是這樣的：在大環(huán)境（開發(fā)、集成、驗(yàn)收）的數(shù)量上，你要考慮環(huán)境的核心用戶是誰，環(huán)境的核心價值是什么。在環(huán)境的核心價值沒有沖突時， 盡量減少大環(huán)境的數(shù)量。有些公司就通過功能分支直接上線的分支策略，對每個分支， 都創(chuàng)建一整套的功能測試環(huán)境， 并在分支上線后快速釋放。以這樣的方式，精簡了驗(yàn)收測試環(huán)境，即大環(huán)境的產(chǎn)生。但其代價是發(fā)布過程分支之間必須是串行的，即一個分支的上線會阻塞其他分支的上線。而在每個大環(huán)境的子環(huán)境上（也就是按照測試需求被剝離出來的功能環(huán)境），你必須保證它的副本數(shù)可以滿足用戶測試的隔離需求。比如，在集成測試環(huán)境，只產(chǎn)生一套公共環(huán)境，并