在項目的開發過程中,為了保證軟件質量,服務端軟件會被部署到多種環境中,目的是隔離開發、測試、正式環境。
按照我們公司目前的架構,服務端軟件會經歷 “聯調環境” -> "測試環境" -> "正式環境" 的環境切換。
1. 聯調環境,部署在本地服務器上,主要是用來給 APP 開發人員對接調試
2. 測試環境,部署在線上服務器的測試環境,主要是用來給測試人員進行功能測試
3. 正式環境,提供給正式用戶使用
以前我們公司的方式是,在同一份代碼的基礎上,打不同環境的安裝包出來,但這種方式很容易出錯,例如,QA 使用一個正式環境的包進行測試,發現數據不正確,然后向開發人員進行反饋,最后幾經周折才發現是用錯了安裝包。
二、任務需求
當 APP 打好包之后,在不同的環境下,訪問同一接口的時候,APP 將自動請求相關環境下的服務:
1. 在聯調環境中,APP 將自動請求聯調服務器,api.local.odirus.me
2. 在測試環境中,APP 將自動請求測試服務器,api.test.odirus.me
3. 在正式環境中,APP 將訪問正式服務器, api.online.odirus.me
三、解決方案
我們進行了第一次嘗試,使用記錄的方式,大致流程如下:
購買兩台極路由,安裝 Hosts 插件;在內網部署兩台 Linux 服務器,安裝 Nginx 軟件。
1. 在第一台路由器 router-a 上修改記錄: api.online.odirus.me -> nginx-1 服務器的 IP ,並且在 nginx-1 上做好 HTTP 轉發規則:api.online.odirus.me -> api.local.odirus.me
2. 在第二台路由器 router-b 上修改記錄: api.online.odirus.me -> nginx-2 服務器的 IP,並且在 nginx-2 上做好 HTTP 轉發規則:api.online.odirus.me -> api.test.local.me
在使用APP的過程中,當設備連接 router-a 時,訪問的接口服務將自動切換為 api.local.odirus.me;當設備連接 router-b 時,訪問的接口服務獎自動切換為 api.test.local.me
這種方案,看似很美好,不過在實際工作過程中,會遇到很多詭異的問題,例如設備連接 router-a 的時候,APP 最終還是請求的 api.online.odirus.me 線上服務,所以極路由的 Hosts 插件還是不太穩定。
四、改進后的解決方案
經過摸索,我們認為自建 DNS 服務器將會更加穩定,大致流程如下:
在內網部署兩台服務器,分別都安裝 Nginx、dnsmasq,對應的IP、Nginx、dnsmasq 分別稱為 server-1-ip, server-2-ip;server-1-nginx, server-2-nginx;server-1-dns, server-2-dns
1. 在第一台服務器上,設置 dnsmasq 的域名配置為 api.online.odirus.me -> server-1-ip,並且在 nginx-1 上做好 HTTP 轉發規則:api.online.odirus.me -> api.local.odirus.me
2. 在第二胎服務器上,設置 dnsmasq 的域名配置為 api.online.odirus.me -> server-2-ip,並且在 nginx-2 上做好 HTTP 轉發規則: api.online.odirus.me -> api.test.odirus.me
在使用APP的過程中,當設備的 dns 修改為 server-1-dns 時,訪問的接口服務將自動切換為 api.local.odirus.me;當設備的 dns 修改為 server-2-dns 時,訪問的接口服務獎自動切換為 api.test.local.me