測試環境對於任何一個軟體公司來講，都是核心基礎元件之一。轉轉的測試環境伴隨著轉轉的發展也從單一的幾套環境發展成現在的任意的docker動態環境+docker穩定環境環境體系。期間環境系統不斷的演進，去適應轉轉叢集擴張、新業務的擴充套件，走了一些彎路，但最終我們將系統升級到了我們認為的終極方案。下面我們介紹一下轉轉環境的演進和最終的解決方案。

1 測試環境演進

1.1 單體環境

轉轉在2017年成立之初，5臺64G記憶體的機器，搭建5個完整的測試環境。就滿足了轉轉的日常所需。一臺分給開發，幾臺分給測試。通過溝通協調就能解決多分支並行開發下衝突問題。

1.2動態環境+穩定環境

隨著微服務化的進行，轉轉的服務數量是急速擴充的。分支並行開發增多，共用環境造成的互相影響也逐漸增多。單體環境已經不能滿足我們的需求。新的組織形式被提了出來。動態環境部署修改的服務和一些必要服務。穩定環境部署和線上一致的服務。同時我們開發了一個環境平臺去管理環境的申請到回收的整個生命週期。階段性的滿足了我們訴求。存在問題：請求進入到穩定環境之後，呼叫將會在穩定環境中，無法呼叫到動態環境的服務。導致被測服務之前的所有服務、mq的生產方都要部署到當前測試機上，即使這些服務沒有任何變化，隨著叢集規模的繼續擴大，對資源的消耗飛速增加。

1.3 動態環境+穩定環境（ip路由）

對於上面的問題，我們期望能做成請求的流量是動態環境下優先，如果沒有的情況下再請求到穩定環境上，這樣測試機上只部署發生了變化的服務和入口服務（必需）就可以了。隨後和架構運維一起實現了ip路由的功能，就是將ip作為泳道名稱向下傳遞。這個方案上線後，資源使用量下降30%左右。在2019年上線後的兩年內，轉轉經歷了和找靚機合併，晶片供應緊張導致機器長時間無法採購到，在這個背景下，保證了轉轉環境的應用。但是問題也日益的凸顯。

2 環境使用中的問題

從大的方面來講：系統穩定性，資源成本，使用效率三個方面互相制衡。在成本（包括採購困難）這個限制下，舊機器無法淘汰導致穩定性問題。資源不足，現存的測試機使用率就降不下來，穩定環境就無法保持記憶體30%空閒率的下限，穩定性就會成問題。測試環境就需要嚴格的回收策略，導致使用者的使用體驗和使用效率下降，如：到期回收和資源空閒回收，肯定會導致部分使用中的環境被回收掉，尤其是大的記憶體環境，對應大的專案，恢復起來慢，影響也大。已有的架構下不能做到三者兼得，或者說不能做到我們希望的妥協。具體的問題如下：

2.1 資源的不足

業務的增長和叢集數量的增長，疊加伺服器採購不到的情況，機器資源很緊張。測試資源池3.8T, 高峰佔用率80%。剩餘資源散落在20幾臺物理機上，導致超過40G記憶體的機器都是比較難申請的。

2.2 資源的浪費

在機器資源不足的情況下，還存在機器資源浪費的情況，現有的方案，機器申請下來記憶體是固定的，不能自動的擴容和縮容，隨著環境中被測服務的逐漸上線，最新版本會被同步到穩定環境中，動態環境和穩定環境中重複的服務會越來越多。但是無法將測試資源回收到資源池之中。

2.3 穩定性問題

機器的穩定性

眾所周知，測試環境的機器基本都是線上過保的機器，年齡不一，但是一般比較大，損壞是常有的事情，我們高峰期一個月損壞了5臺物理機。對業務產生直接影響。

部署過程簡要介紹

先簡單介紹下機器啟動部署過程：

系統的穩定性
- 整個初始化部署，流程7-8步，各個環境都可能出現問題，日常穩定性不足。
- 在上面3個方案的歷史迭代中，積累了大量的歷史包袱。每次部署都要要對測試配置檔案中的資料庫、redis、mq、zk等配置進行替換，易出錯，不易維護，工程規範化不足。
- 在環境的構成中，環境中每次新增刪除服務，都要重新計算nginx和host，依賴長，容易出錯。
- 日常使用中，記憶體不足的情況下，無法自動擴容，只能重新申請環境，時間成本高。
- Kvm資源方案生態差，維護成本高。

以上這些過程中的問題，每週會有25個左右環境問題反饋，我們每週都需要8h左右的運維時間。為了解決上面的問題，我們開發了系統錯誤分析工具，虛擬機器重啟工具、機器資源報警工具、機器存活監控、穩定環境整體遷移工具等眾多管理員工具幫助使用者和我們解決日常問題。整體來講日常的維護成本是很高的。使用者用著有很多問題，也很不爽。

3 解決方案：動態環境+穩定環境（標籤路由）

3.1 解決方案

系統底層架構修改

由於以上的問題，我們和架構運維重新設計了環境平臺的方案。我們最終採用了docker + 穩定環境的方案。ip路由變成了標籤路由，一個環境不再是一臺機器上部署多個服務，而是一個環境下，多個docker組成，多個ip組成，如下：環境yyy由服務B和D組成，ip分別為192.168.5.1和192.168.6.1。這樣映象初始化、agent初始化過程被幹掉。環境的大小限制不再是一個宿主機大小決定，極限情況下一個環境可以包含轉轉所有的服務。單個環境容量不再是問題。通過k8s的特性，部署時會新啟動一個節點，並且新節點啟動成功之後，下線舊節點。保證了服務在部署過程中，服務不中斷。

工程規範化

推動rd升級服務，將測試配置修改為正常的配置，從而下掉平臺的配置替換。

nginx中心化

去掉每個環境上的nginx，消滅ng部署生成過程的問題。通過系統聯動使用運維的中心化nginx。

host配置

推動刪除不必要的公共host，在服務升級的過程中推動RPC的host呼叫方式升級為服務管理平臺，剩餘公共host採用內部dns能力進行解決。

新問題

在制定新方案的過程中，一個目標是解決之前的依賴問題，一個就是儘量減少新方案帶來的使用方式上變動，減少使用者使用成本。環境docker化之後最大的影響是什麼呢？一、ip變成了標籤，不再是唯一ip。

二、服務每部署一次，ip變一次。

ip沒了，那麼入口host怎麼配置？ip變了，那麼如何登入到機器上？如何檢視歷史日誌？如何進行單元測試？解決方案：

轉轉之前有泛域名解析的能力,如app.zhuanzhuan.com帶標籤可以寫為app-${tag}.zhuanzhuan.com。
請求whistle配置中增加：192.xxx.xxx.xxx app.zhuanspirit.com excludeFilter://*/api reqHeaders://(Global-Route-Tag:test1234)。注：192.xxx.xxx.xxx為中心化nginx。
增加webshell 解決ip變動帶來的登入成本增加。
增加歷史日誌查詢功能，解決ip銷燬後歷史日誌查詢問題。
增加本地化標籤路由的功能，解決單元測試每次輸入ip的問題。變成標籤設定。注：在後面的docker推廣過程中，我們發現方案中，我們漏掉了遠端debug場景下，ip變動的問題。最後通過開發了一個idea外掛和環境平臺聯動解決。
新的運營方式

新的技術方案中，資源的最小管理節點由之前的一個kvm變為標籤中的一個服務。在測試服務上線之後，環境平臺會自動同步最新程式碼到穩定環境，之後將測試標籤中剛剛上線的服務刪除，回收資源。從而避免資源的浪費。

成果

部署過程縮減為：服務映象啟動 + ng配置同步。步驟極大的縮減。穩定性、效率提高。在宿主機掛掉的情況下，k8s自動排程到新的節點。進一步保證穩定性。資源成本、穩定性和使用效率三方的制衡被打破。三方面充分的得到了提高。目前：

使用者問題：減少95%，並且大專案測試中，環境問題消失了。
申請時間：由28分鐘到5分鐘以內。
資源佔用：3200G到1200G。

總結

在制定了這個方案之後，轉轉在架構、運維和工程效率三個部門互相配合情況下，1個月內完成開發，3個月內完成了服務升級。1年內完成了整體功能的推廣。取得了豐碩的成果。
docker化之後，改變了整個環境的使用生態。現在，要用一個測試環境，申請則立即可用。過程中不再有任何心力消耗，不再有中斷。並且資源管理的最小節點變為一個服務。環境系統的底層技術架構在我們看來處於業內目前的最優的方案，在系統、使用者層面上做到了資源，效能和效率三者的整體性提升和平衡。整個系統是相對成熟的，可以預見的是，在未來很長一段時間內系統不需要再進行系統結構上的升級。

更多技術實現細節

關於作者

陳秋，轉轉工程效率負責人，主要負責配置管理和devops體系建設。歡迎大家留言、交流互相學習。

轉轉研發中心及業界小夥伴們的技術學習交流平臺，定期分享一線的實戰經驗及業界前沿的技術話題。

關注公眾號「轉轉技術」（綜合性）、「大轉轉FE」（專注於FE）、「轉轉QA」（專注於QA），更多幹貨實踐，歡迎交流分享~

轉轉測試環境docker化實踐