開發和測試爭搶環境？是時候進行多環境建設了

在上一期文章裡，我們介紹了多環境下的應用配置管理問題，從這期開始，我們會分兩期文章詳細聊聊多環境建設的問題：就是我們到底需要哪些環境？這些環境都有什麼作用？環境建設的思路和方式是怎樣的？

今天我就結合自己的經驗和理解與你聊一聊持續交付中的線下多環境建設。

環境分類

通常，我們主要按照環境所起到的作用，將環境分為兩大類：

• 線下環境：測試驗收用。
• 線上環境：為使用者提供服務。

從建設角度來說，線下環境和線上環境，在網段上是要嚴格隔離的。這一點在做環境建設時就要確定網路規劃，同時在網路裝置或者虛擬網路的訪問策略上要嚴格限定兩個環境的互通，如果限制不嚴格，就極易引起線上故障，甚至是資訊保安問題。

如果你維護過這樣兩套環境，我想你一定在這方面有過深刻的感受，甚至是痛苦的經歷。

所以，從規劃上，線上環境和線下環境是兩套獨立的區域，所有的應用、基礎服務都是全套獨立部署的。但是線下環境所需的資源往往是要少於線上環境，畢竟只有負責開發測試的少數人使用，不會有線上流量進來。如下圖所示：

再往後，開發測試環境上，又會出現開發和測試的衝突和爭搶，因為從場景上，業務開發團隊可能要同時承擔多個並行專案的研發，而且可能會有多個業務開發團隊一起參與進來。

比如對於電商來說，到了年底，就集中會有“雙11”、“雙12”、“雙旦節”以及“年貨節”等等這樣的大型營銷專案，因為時間非常緊湊，所以就必須多專案並行。

這個時候，分解下來，對於我們的應用軟體來說，有可能是存在多個開發分支的。到了專案聯調和驗證環節，就必然會存在同一個應用有多個版本需要同時釋出和測試的情況，但是開發測試環境卻只有一個，這就必然導致雙方激烈的爭搶。

所以這個時候，就必須建立解決衝突的方案，開始建設線下的第三套環境：專案環境。

專案環境可能有多套，一個專案對應一套環境，但是無論從資源成本還是維護成本方面考慮，專案環境仍然不會像整合測試環境那樣形成一套完整的開發測試體系。

所以專案環境同開發測試環境一樣，仍然是以最小化為原則來建設，也就是說，在這個環境裡面，只部署同一專案中涉及變更的應用，而對於基礎服務和不涉及專案需求變更的應用不做重複建設。如果對專案環境中不存在的應用有依賴，那麼訪問整合測試環境中對應的應用就可以了。

在這裡，我們同樣以簡單的模型展示多個專案測試環境、開發測試環境與整合測試環境的關係：

不過，如果說隨專案的增加就需要分別建設對應的專案環境，那麼這對於開發、測試和運維來說都會有非常大的維護負擔。所以通常情況下，我們會嚴格限制建設專案環境的起步線。

比如只有公司級大促、公司戰略級的專案，或者超過一定人日的跨團隊專案，才允許建立獨立的專案環境。一般情況下，還是引導優先使用開發測試環境。

環境建設上的關鍵技術點

線下環境細分出整合測試環境、開發測試環境以及多個專案環境之後，帶來的最大的成本其實不在資源上，而是在管理和維護上，而且單單就線下維護的工作量來說，甚至要超過線上維護的工作。

複雜度和涉及到的技術點有以下四個方面。

網段規劃

• 第一是網段規劃。每個環境都要有獨立的網段，比如整個線下環境要獨立佔用一個B段，專案環境和開發測試環境相對較小，可以獨立佔用一個C段。雖然不需要做網路策略上的隔離，但是為了便於管理，如分配回收資源以及部署應用，還是要在邏輯上區分出來。同時，網段規劃也是為下面的單元化呼叫做準備。

服務化框架的單元化呼叫

• 第二是服務化框架的單元化呼叫。這一點需要服務化框架支援，比如上面我們提到的專案環境，到了聯調階段就需要一組應用單獨聯調，而不能跨專案環境呼叫。同時，對於專案中依賴的未變化的應用，就需要呼叫整合測試環境中穩定版本的應用。這個服務呼叫的基本規則就是基於上述網段的規劃來建立的，規則要放到服務化的註冊中心，也就是ConfgServer這個部件中儲存，同時需要服務化框架支援規則呼叫，優先支援本單元呼叫，本單元不存在可以呼叫整合測試環境單元。

環境的域名訪問策略

• 第三是環境的域名訪問策略。這麼多的環境，內外部DNS域名是保持一套還是多套，比如訪問蘑菇街主頁（www.mogujie.com），首頁域名就一個，但是怎麼能確保訪問到我們所期望的環境上呢。這裡有幾種方式：

  • 第一種，DNS服務保持一套，域名，特別是外部域名多套，每個環境分別配置一個不同的域名，比如開發測試環境，dev.mogujie.com。但是如果這樣，下層的二級域名和二級目錄等等都要跟著變動，而且對於專案環境來說，數量不固定，每次都換一個也不方便記憶和管理，所以這個方案基本不可行。

  • 第二種，DNS服務保持一套，域名保持一套，但是做域名的hosts繫結，也就是自己來設定要訪問域名所對應的環境。這樣一來，如果相對固定的開發測試環境和整合測試環境所對應的hosts相對固定，那麼只需要繫結一次就可以通用。但是專案環境始終在不斷的變化中，繫結規則可能隨時在變化，所以這種方案的複雜度在於對hosts配置的管理上。

  • 第三種，DNS服務多套，也就是不同的環境中配置獨立的DNS服務，這樣可以減少繁瑣的hosts繫結，但是也會提高多套DNS服務管理上的複雜度，而且對於專案環境有可能依賴整合測試環境中的服務，這時仍然會涉及本地DNS服務的hosts繫結。

  • 第四種，對於公網域名，可以直接通過無線路由劫持的方式訪問，可以在無線路由器上配置多個接入點，這樣一來，連線不同的接入點，就會自動對應到不同環境的域名IP地址上去。

    通常，對於公網域名來說，如果具備穩定的環境，如整合測試環境，直接通過第四種劫持方式指定到對應環境中去，這樣最方便，這種方案在後續線上多環境建設中還會使用。

    對於內部域名，則有多種方案，沒有優劣，主要看場景和管理成本。我們選擇的是第二種，即繫結hosts的方式。每個環境會對應一套hosts配置，當選擇不同環境進行聯調或訪問時，就將hosts配置下發到對應部署應用的主機上。

    在這裡，我們仍然以模型展示第二、四種方案和多種線下環境之間的執行邏輯：

但是，無論採取哪種方式，我們可以看到，這個管理過程仍然是比較複雜繁瑣的，必須要非常仔細地規劃和部署，同時還需要配套的自動化工具支援，否則靠人管理是不現實的，所以最後一點就是自動化的配套。

自動化管理

• 第四是自動化管理。按照我們之前分享的管理模式，這裡雖然有這麼多的線下環境，但我還是會把它們以應用為核心給管理起來，即應用的開發測試環境，應用的整合測試環境，應用的專案環境。這樣一來，上面提到的不同環境的網段資訊、配置資訊、資源分配回收以及軟體部署釋出，都能夠以應用為出發點去做，這一點我們在後面的文章會詳細分享。

總結

最後，不知道你有沒有感受到，單單一個線下環境就要如此複雜和繁瑣，整個持續交付體系建設是多麼的有挑戰性，就可想而知了。

我們對線下環境稍微做個總結：

• 整合測試環境，主要供測試使用，這個環境會最大程度與線上版本保持同步。作為對應用的功能、需求、業務流程等在正式釋出上線進行驗證的主要環境，整合測試環境的穩定性和可測試需要加強保障，進行全套建設。同時，作為整個線下環境的中心節點，也要為開發測試環境和專案環境提供部分依賴服務。
• 開發測試環境，主要供開發人員使用，針對偏日常的需求開發、聯調和功能驗證，以最小化原則進行建設，但是一般情況下不對資源進行回收。
• 專案環境，供開發和測試共同使用，針對多團隊多人員協作的專案型場景，可以同時存在多個專案環境，在這個環境中針對專案需求進行獨立開發、聯調和驗證。測試也需要提前介入這個環境進行基本功能的驗收，並遵循最小化的建設原則，但是要有生命週期，即專案啟動時分配資源，專案結束回收資源，不能無限期佔用。

最後，在實際操作中，仍然會很多細節問題，這些問題會跟業務場景有關，針對這些場景又有可能有不同的建設要求，比如訊息的消費問題會涉及全業務流程驗證等等。

所以，留幾個問題給你思考：線上下環境的建設過程中，你通常會遇到哪些問題？會有哪些獨立環境？或者你有什麼更好的經驗和建議分享？

精選提問

1. 老師這個線下多專案環境按最小化部署我不太理解啊，比如一個a應用部署了兩個開發環境，但是如果依賴的dubbo都是一套的話這個呼叫如何分離呢？

   服務化框架要支援本單元（環境）呼叫優先，在框架能力強要做一些改造。不然就會出現你說的問題