【以下為分享實錄，有刪節】
測試環境管理之困
互聯網產品的服務通常是由 Web 應用、中間件、數據庫和許多後臺業務程序組成，一套運行環境就是一個自成一體的小生態。部署軟件產品的正式發佈版本，為用戶提供持續可靠的服務的環境為“正式環境”，而開發者用於日常的開發和驗證的運行環境，就是我們說的“測試環境”，它是包含完成軟件測試工作所必需的計算機硬件、軟件、網絡設備、歷史數據的總稱。
我們為什麼要關注“測試環境”呢？因為測試環境出故障的機率非常高，大大影響軟件研發的效率，這主要是由於由於頻繁的版本變更，以及部署未經充分驗證的代碼等因素引起的。此外測試環境也是開發者使用最頻繁的一種環境，數據表明，測試和聯調任務通常佔開發者日常工作時間的50%以上，穩定而易用的測試環境能夠極大提高開發者的工作效率和幸福感。
理想的測試環境是怎樣的？我們認為理想的測試環境需要做到以下幾點：
一、本地直連，雙向訪問互通。開發者的大部分工作是在本地（自己的電腦）中完成的，然後通過測試環境驗證所做的工作是否符合預期。如果“本地”和“測試環境”之間，不能夠互通的話，開發者要驗證自己開發的軟件功能就會變得十分困難。
二、獨佔式隨意使用，可重啟，可調試，可斷點。當團隊有多名開發者進行多人並行開發的時候，如果共用一套測試環境就會出現相互干擾的情況。比如當我正在重啟測試環境的時候，就可能影響到其它開發者的測試工作。因而理想的測試環境應該是“獨佔式”的，你使用你的環境，我使用我的環境，彼此不干擾。
三、多人隨意組合協作，多服務聯調不串流量。當多位開發者在同一個項目上進行合作的時候，開發者之間又是希望互通的。比如我的一個請求，希望調用對方本地的一個服務。同樣對方也可以調用我本地的服務。同時，又希望非項目內的開發者的請求不要進來，即做到多服務聯調不串流量。
四、多個依賴服務版本同時在線，想測哪個隨時切換。當進行大版本更新的時候，我們可能既要測試新版本的兼容性，又要測試老版本的兼容性， 這就要求多個依賴服務版本同時在線，並且可以隨時切換。
簡單總結一下，理想的測試環境應該是：自由連接、隨時可用、互訪可控。
那麼現實中的測試環境又是怎樣的呢？所謂“理想很豐滿，現實很骨感”，在一線工作的開發者可能會發現，真實的測試環境並非這麼理想。
一、在中小企業，本地的開發機往往是不具有公網IP的機器，大多會使用內網IP地址，這樣測試環境要回到本地環境時候是不通的。特別是在 在Kubernetes集群中，每個Pod都會被賦予一個Cluster IP，Cluster IP是一個在Kubernetes集群中特有的內網IP，我們在本地訪問Cluster IP也是調不通的。這就造成了本地/集群雙向均不通。
二、在中小企業，測試環境通常是共用的，這就會造成前文提到的相互干擾、調用和消息互串等問題。
三、如果開發者想獨立拉起一套專用測試環境，不僅費時費力，而且資源成本也是難以招架的。
總之，現實中的測試環境：無法直連、穩定性差、流量混雜。
阿里巴巴的測試環境實踐
以上提到的測試環境管理之困，總結一下主要有兩點：一是本地和集群之間網絡互通的問題；一個是多人協作開發時，路由的可訪問性控制問題，比如誰和誰相連，誰和誰不相連，怎樣做到相互間不干擾這些問題。
在阿里巴巴內部，我們主要通過兩個機制來解決以上痛點：扁平的內網IP和項目環境。
扁平的內網IP主要是基於CNI(Conteinre Network Interface) 機制改造Kubernetes的IP邏輯實現的，可以使集群中的每個Pod分配到的IP與本地機器分配到IP處於一個大的網絡環境下，這樣就可以解決本地環境和集群之間互通的問題。但是這種方式實施起來比較複雜，而且通用性不高，因為每個企業內部的網絡情況都不同，本次分享對這個方法不做詳細的展開。
下面我們重點講解“項目環境”。項目環境是基於RPC、消息中間件的虛擬環境，從表面上看，每個項目環境都是一套獨立完整的測試環境，由一系列服務組成集群，而實際上，除了個別當前使用者想要測試的服務，其餘服務都是通過路由系統和消息中間件虛擬出來的，指向公共基礎環境的相應服務。
如上圖所示，在某個開發項目中，我們有公共基礎環境和三個獨立的項目環境（項目環境）。服務A、服務B、服務C、服務D共同組成了完整的公共基礎環境，在項目環境-2中只部署了“服務C”，但對於項目環境-2的使用者而言，他可以通過路由調用公共基礎環境中的其它服務，因此他會認為項目環境-2就是一個完整的獨立的測試環境。同樣的道理，對於開發者而言，他們認為項目環境-1和項目環境-3也同樣是完整的獨立的測試環境。
我們創建一套“項目環境”肯定是比創建一套包含所有服務的測試環境的成本要低。本質上是基於消息路由的控制，實現集群中部分服務的複用。在這種機制下，許多外表龐大的獨立測試環境實際只需要消耗極小的額外基礎設施資源，即使給每個開發者配備一套專用的測試環境都是可行的。
為進一步提升測試效率，我們又搗鼓出一種開腦洞的玩法：將本地開發機加入項目環境。在阿里巴巴集團內部，由於開發機和測試環境都使用內網IP地址，稍加變通其實不難將特定的測試環境請求直接路由到開發機。這意味著，使用項目環境的開發者，在進行一項測試時，其服務調用鏈路上的服務，既可以來自公共基礎環境，也可以來自項目環境，甚至來自本地環境。現在，調試集群中的服務變得非常簡單，再也不用等待漫長的流水線構建，就像整個測試環境都運行在本地一樣。
通過以上介紹的阿里巴巴關於測試環境的解決方案，能給開發者帶來怎樣的測試體驗呢？
- 開發者會覺得自己坐擁整個服務集群，所有測試服務IP地址都可以由本地直接訪問，隨時進行斷點、單步調試、重新部署服務等操作，而絲毫不會影響到其他人；
- 當多人協作研發軟件時，每位開發者同一時刻只能屬於同一個隔離域，同一個隔離域裡面的服務相互可見，並且當出現服務調用的時候，會優先調用隔離域裡面的服務。不同隔離域裡面的服務相互之間不可見，是互不影響的；
- 由於我們是通過“染色”（打標籤）的方式實現的隔離，這種隔離方式非常的靈活，假如某位開發者前面在跟第一個項目進行聯調，調試結束後，他想把該服務放入第二個項目中進行調試，他只需要把自己的服務從一個項目環境退出，進入另一個項目環境即可，實現靈活組隊協作。
總結
我們將測試環境管理遇到的問題歸納為兩個主要問題，第一個是本地與集群互通互聯的問題。在阿里巴巴集團內部主要通過基於CNI機制改造Kubernetes的IP邏輯實現的“扁平化的內網IP”這個方法來解決，這種方式更適合大型集團企業。對外，我們也推出了一個更輕量的開發解決方案，主要通過kt-connect這個工具實現，kt-connect是開源免費的，由阿里雲·雲效提供技術支持，在下一節的分享中我們會詳細介紹該工具的使用。
第二個問題，是關於路由的控制，在阿里巴巴內部我們是通過“項目環境”與“隔離域”實現的。對外我們也推出了一個開源解決方案，主要通過kt-connect和kt-virtual-environment這兩個開源工具來實現，具體方案會在本系列分享的第三節內容中講述。
【下期預告】
【直播日期】4月22日 16:00
【直播主題】單人開發場景下的測試環境實踐
【直播講師】鄭雲龍 阿里巴巴技術專家
【觀看方式】雲效開發者交流群直播（釘釘群號：群號：23362009）
【關於雲效】
雲效，企業級一站式DevOps平臺，源於阿里巴巴先進的研發理念和工程實踐，致力於成為數字企業的研發效能引擎！雲效提供從“需求 ->開發->測試->發佈->運維->運營”端到端的在線協同服務和研發工具，通過人工智能、雲原生技術的應用助力開發者提升研發效能，持續交付有效價值。