前言
此文摘自2011年3月22日郵件分享
現狀
平時開發,測試,功能預演階段,為了能夠正常訪問應用,需要做Hosts綁定.隨著應用數量的不斷增多,綁定量也是急劇上升.例如最近工作平臺三期項目,需要綁定的環境多達44個.一旦有變動,需要通知所有人員做本地Hosts的調整,維護成本那是相當地大.
用一張圖,來描述下目前我們的方案:
如果站在面向對象編程的角度,來思考這張圖,我們會發現.
1. 利用客戶端本地Hosts綁定來實現,并且客戶端數量不可控—利用客戶端解決需求,但客戶端維護不在可控范圍內
2. Hosts綁定是非常不穩定的—需求易變
這樣的設計,違反了”封裝變化”的設計原則,故一旦有變動,維護成本非常大.
新方案思路
按照”封裝變化”的設計原則,我們就應該把”域名綁定”這個易變需求,進行統一管理.
看上圖,我們會發現,DNS的職責就是做域名解析的,并且DNS管理比較可控.
于是第一反應,我們可以使用內部域名解析服務器來綁定這些域名.
但是問題又來了,DNS來做測試環境域名解析,太重量級了.同一個域名,對應測試服務器IP有多個,綁定哪一個好呢?并且域名對應IP不斷變化,IT DNS負責人不被我們累死啊?
既然DNS上做文章不可行,又需要統一管理的地方,那么我們只能再抽象出一個新的概念來.
同樣,我們利用一張圖,來描述下整體架構.
與上圖相對,此圖多了一個”代理服務器”的概念,即Hosts綁定動作在此概念上完成.
流程如下:
1. 客戶端瀏覽器設置代理服務器,將所有請求發送到代理服務器上
2. 代理服務器檢查本地Hosts綁定,如綁定則直接解析,反之進入流程3
3. 代理服務器通過內部域名服務器解析域名
4. 代理服務器發送請求到測試服務器上,并且將響應內容返回給客戶端
具體嘗試性實施方案如下(在XX項目過程中有成功案例)
1. 利用squid搭建代理服務器 (代理地址: 10.20.131.207:3128)
備注:
Squid配置介紹見附錄I
2. 瀏覽器配置代理
全局代理: 代理服務器上,直接填寫 10.20.131.207 3128
局部代理: 通過pac實現,選擇”使用自動配置腳本”,腳本格式內容如下:
備注:
Pac腳本詳細介紹見附錄II
為了防止將配置工作帶給PD,銷售等,我們可以使用配置好的綠色瀏覽器提供直接使用.
推薦一款:GreenBrowser: http://www.morequick.com/indexen.htm
IE具體配置,見下圖:
Firefox同樣支持代理和pac腳本
Chrome需要安裝proxy switchy插件來支持.
改進方案思路
上述的方案中,有兩個比較大的缺陷
1. 代理服務器沒有多實例概念
代理服務器通過hosts綁定.hosts是全局性的,意味著一臺代理服務器只能服務一組需求.而事實上,我們不同的項目需要的綁定都是不一樣的.
2. 特性化需求不能滿足
綁定全在代理服務器上做了,客戶端本地個性化需求無法支持
所以,我理想中整體架構是這樣的,見圖:
1. 優先查看本地hosts文件
2. 代理服務器支持多實例部署,不同實例有不同的hosts綁定配置.
目前具體實現方案,還在構思中.歡迎大家提供實現方案思路.
附錄I
Squid權威指南(中文版): http://home.arcor.de/pangj/squid/chap01.html
附錄II
Pac介紹: http://en.wikipedia.org/wiki/Proxy_auto-config
Pac函數介紹: http://findproxyforurl.com/pac_functions_explained.html