丨測試環(huán)境要多少從成本與效率說起

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