丨測(cè)試環(huán)境要多少?gòu)某杀九c效率說起

模式化的意味。公有云非常好地滿足了DevOps的“基礎(chǔ)設(shè)施即代碼”的理念，哪怕你完然而，云計(jì)算并非“銀彈”，我們上云后，在成本上，還是有很多值得去思考和做的尤其是當(dāng)環(huán)境數(shù)量增加時(shí)，你很容易就可以想到成本會(huì)增加，但是你可能并不明白要增加哪些方面的成本，以及會(huì)增加多少的問題。那么，接下來，我就跟你聊聊當(dāng)環(huán)境數(shù)量增加時(shí)，你需要考慮的成本有哪些呢？首先是機(jī)器資源成那么，以阿里云的價(jià)格為例，我來跟你一起算算這筆賬。假設(shè)一個(gè)只有100個(gè)應(yīng)用的微服務(wù)架構(gòu)環(huán)境，選取單應(yīng)用單機(jī)2核4G內(nèi)存的低配置實(shí)例方式進(jìn)行部署，單實(shí)例的年價(jià)格在2000元左右，100個(gè)實(shí)例的話，一年的花費(fèi)就是20萬元左右。這樣的問題在開發(fā)環(huán)境和集成環(huán)境的表現(xiàn)是最明顯的。為了保證這兩套環(huán)境的獨(dú)立性，你必然需要有很高的環(huán)境副本數(shù)。但無論如何，你都不可能讓每一個(gè)開發(fā)和測(cè)試人員都擁有一套完整環(huán)境的硬件資源?？梢?，每一套環(huán)境的機(jī)器資源成本都很大，而且隨著需求的增加成比例增其次是管理成管理成本，包括環(huán)境的可用性，配置的管理成本，和測(cè)試數(shù)據(jù)的成本三個(gè)維度1.多套環(huán)境的第一要點(diǎn)是，環(huán)境的可用性但是，容器技術(shù)并沒有解決故障定位的問題。微服務(wù)架構(gòu)下集群的節(jié)點(diǎn)數(shù)量多,調(diào)用鏈復(fù)雜，你不再能確定到底是環(huán)境問題，還是程序本身的Bug，也就導(dǎo)致定位故障更加2.多套環(huán)境的另一大成本是，配置的管理成本配置是環(huán)境管理中最的內(nèi)容，創(chuàng)建一套環(huán)境時(shí)，為了保證它真正的獨(dú)立可用，不僅要保證應(yīng)用可以成功運(yùn)行，還要保證應(yīng)用在基礎(chǔ)設(shè)施的配置是正確的。比如集成測(cè)試環(huán)境下部署了一個(gè)應(yīng)用的多個(gè)平行項(xiàng)目，就需要有辦法保證測(cè)試人員能到正確的應(yīng)用。如果是Web應(yīng)用，你就要考慮把應(yīng)用綁定到不同的，這樣就會(huì)增加管理的成本；如果是一個(gè)service應(yīng)用，你就要考慮到這些service不會(huì)被其他項(xiàng)目的、無關(guān)環(huán)境每多一套環(huán)境，就會(huì)多一套這樣的配置，而且這些配置都需要在各類基礎(chǔ)設(shè)施中生3.多套環(huán)境的第三大成本是，測(cè)試數(shù)據(jù)的成本最后是流程成流程成本主要包括溝通成本和測(cè)試成本兩溝通成每增加一套環(huán)境，你都需要考慮團(tuán)隊(duì)成員如何在新環(huán)境上溝通協(xié)作。誰(shuí)在占用，何時(shí)退出這些信息，你都需要第一時(shí)間告知團(tuán)隊(duì)。當(dāng)環(huán)境的數(shù)量變得非常多以后，做好這些事的難度就很大了。測(cè)試成在開發(fā)環(huán)境，集成測(cè)試環(huán)境，驗(yàn)收測(cè)試環(huán)境，預(yù)發(fā)布環(huán)境，生產(chǎn)環(huán)境這樣的結(jié)構(gòu)下，核心功能的測(cè)試流程就至少會(huì)執(zhí)行五次。每引入一套新的環(huán)境，測(cè)試流程都會(huì)變得更加復(fù)雜?，F(xiàn)在你應(yīng)該已經(jīng)，因?yàn)樵黾右惶篆h(huán)境帶來的成本竟然有那么多。但是為了提高持續(xù)交付的效率，的多套環(huán)境又是必不可少的。那么，你究竟應(yīng)該怎樣去規(guī)劃和設(shè)計(jì)環(huán)境第一，公共與泳道第一個(gè)關(guān)鍵點(diǎn)是抽象公共環(huán)境，而其中的公共服務(wù)基本都屬于底層服務(wù)，相對(duì)比較穩(wěn)定，這是解耦環(huán)境的重中之重。比如我們經(jīng)常會(huì)將中間件，框架類服務(wù)，底層業(yè)務(wù)公共（賬戶，登陸，基本信息）服務(wù)部署在這套公共環(huán)境下。在公共環(huán)境的基礎(chǔ)上，可以通過泳道的方式相關(guān)測(cè)試應(yīng)用，利用LB和SOA中間件對(duì)路由功能的支持，在一個(gè)大的公共集成測(cè)試環(huán)境中出一個(gè)個(gè)獨(dú)立的功能測(cè)試環(huán)境，那么為了幫助你理解，我跟你一個(gè)具體的案例比如，你有一個(gè)新的下單流程需要測(cè)試。你可以將“下單web2.0”和“下單service2.0”出來，如圖中的“功能環(huán)境1”所示。被剝離出的“下單service2.0”只能被當(dāng)前環(huán)境內(nèi)的web務(wù)器調(diào)用。而“下單service2.0”所依賴調(diào)用的“支付service1.0”則于此同時(shí)，如圖中所示的“功能環(huán)境2”，可以同時(shí)支持“下單service3.0”這個(gè)并行版本與一個(gè)新版本的“支付service2.0”進(jìn)行聯(lián)調(diào)，此環(huán)境是不會(huì)調(diào)用公共環(huán)境中的“支付service1.0”的。通過這種方式，你就可以解決并行開發(fā)和并試的問題了第二，避免產(chǎn)生多套公共環(huán)從原則上講，集成環(huán)境中只要有一套公共環(huán)境就足夠了。但有時(shí)候，你會(huì)發(fā)現(xiàn)項(xiàng)目的范圍特別廣，依賴應(yīng)用或者影響應(yīng)用特別多，特別是一些底層服務(wù)的改動(dòng)或者重構(gòu)等。在這種情況下，如果把依賴它的所有服務(wù)都部署起來，就很有可能變成第二、第三套公共環(huán)境了。這種情況下，你可以通過mockservice來模擬大多數(shù)服務(wù)，這樣就可以達(dá)到測(cè)試環(huán)境的最小集合了。關(guān)于mockservice如何做，我會(huì)在后續(xù)的講解中，為你詳細(xì)解釋。第三，減輕配置的復(fù)雜而對(duì)于減輕環(huán)境配置的復(fù)雜度來說，你可以從以下兩個(gè)方面著制定一套統(tǒng)一配置的解決方要讓環(huán)境自己說話，有效減少配置比如，對(duì)于數(shù)據(jù)庫(kù)，對(duì)于不同的測(cè)試需求，我們可能會(huì)在公共的數(shù)據(jù)庫(kù)和獨(dú)立的數(shù)據(jù)庫(kù)之間進(jìn)行頻繁切換；又比如，我們可以在啟動(dòng)應(yīng)用時(shí)自動(dòng)配置正確的數(shù)據(jù)庫(kù)。那么無論有多少套環(huán)境，配置也不是一件難事。關(guān)于減輕配置的復(fù)雜度，我也會(huì)在專欄后續(xù)的講解中，給你詳細(xì)分析如何實(shí)我們究竟需要多少套環(huán)境，這個(gè)問題的答案應(yīng)該是這樣的：在大環(huán)境（開發(fā)、集成、驗(yàn)收）的數(shù)量上，你要考慮環(huán)境的用戶是誰(shuí)，環(huán)境的價(jià)值是什么。在環(huán)境的價(jià)值沒有有些公司就通過功能分支直接上線的分支策略，對(duì)每個(gè)分支，都創(chuàng)建一整套的功能測(cè)試環(huán)境，并在分支上線后快速釋放。以這樣的方式，精簡(jiǎn)了驗(yàn)收測(cè)試環(huán)境，即大環(huán)境的產(chǎn)生。但其代價(jià)是發(fā)布過程分支之間必須是串行的，即一個(gè)分支的上線會(huì)阻塞其他分支的上線。而在每個(gè)大環(huán)境的子環(huán)境上（也就是按照測(cè)試需求被剝離出來的功能環(huán)境），你必須保證它的副本數(shù)可以滿足用戶測(cè)試的需求。比如，在集成測(cè)試環(huán)境，只產(chǎn)生一套公共環(huán)境，并通過工具，支持的功能測(cè)試環(huán)境的快速建立和銷毀，讓環(huán)境可以按需分配。歡迎你給我留言 不得售賣。頁(yè)面已增加防盜追蹤，將依 上一 08|測(cè)試環(huán)境要多少？從現(xiàn)實(shí)需求說下一 10|讓環(huán)境自己說話，論環(huán)境自描述的重要精選留言李?yuàn)^ 3展旭 展展童飛 老師你好，請(qǐng)假一個(gè)問題，在