App域名容災方案

文 掘金號 wandyers @每日優鮮

著做權歸做者全部。商業轉載請聯繫本帳號得到受權，非商業轉載請註明每日優鮮大前端團隊以及原文地址。

注：本文爲系列文章，將分爲方案簡介，方案落地方案，具體方案剖析，技術實現細節等多篇文章，敬請期待。

背景

因部分地區App域名解析出現問題，致使部分B端App等（如下統一簡稱App）都出現網絡請求超時，找不到主機或異常錯誤，致使部分配送App沒法登陸、使用等問題，影響了部分To B業務。

目標

儘可能消除因外部網絡緣由（如外部DNS解析異常、域名不可達等）致使的App出現網絡異常的問題。 通過調研,咱們總結了下面的幾種方案來防止相似問題再次發生，對比以後，咱們最終也選擇了部分策略作爲咱們的分批落地方案（步驟後續會詳細講解）。 咱們的但願App達到避免DNS劫持，下降訪問延遲，下降用戶鏈接失敗率，提高用戶體驗度，SDK高可擴展度及可複用性。

方案簡介

如下的各類實現策略的簡介及簡單的優缺點對比。

方案詳細

本章節將對上面提到的策略作出詳細闡述，包括實現流程及部分重點細節。

1.系統DNS緩存策略

本策略即如今的實現策略，無需額外開發，使用域名進行請求，依賴系統DNS和網絡服務商的DNS解析等。再也不詳細說明。

2. 直連策略

直連方案實現較爲簡單，當使用域名訪問出現找不到主機，請求超時等異常時，直接切換至IP地址重試請求；且App在下次啓動以前，一直使用該IP進行網絡請求。

IP或域名優先級爲： LocalDNS（域名） > 內置固定IP。

流程圖以下圖所示：

本方案實現較爲簡單，在緊急時能夠做爲臨時過分方案。但不建議長期使用此策略，由於App內置的IP沒法實時動態更新，會增長將來的風險。

3. 配置文件策略

App首次啓動時（包含冷啓動），請求後端接口下發配置文件，數據格式可參照附錄必定義，並持久化緩存在App客戶端本地以供未來使用。

當App啓動時，從緩存讀取出來配置，並驗證有效期。如所有過時，則使用域名或系統內置的IP使用；如部分未過時或全未過時(其實大部分狀況下，即便IP過時，在必定時間段內仍是有效的)，則按照優先級次序使用IP地址直連請求；

IP或域名優先級爲： 配置文件IP > LocalDNS（域名）> 內置固定IP 。

此方案相比較直連方案，更加靈活，後臺可隨時更換IP地址而不影響生產環境客戶端。

但會出現當域名不可達時間段較長時，或者用戶在較長時間段內未打開App，而打開時正好域名不可達，致使緩存配置文件的所有失效，進而降級至直連方案。簡而言之，配置文件TTL時間閥值很差控制，不夠靈活。

由於每次App啓動都會請求配置文件並更新本地緩存，沒法根據每一個IP的TTL靈活的更新。

這種方案也會與項目耦合度較高，不利於擴展，各端都須要實現本身業務邏輯，與實際業務耦合度較高。

緩存文件或數據的安全性校驗也必不可少（此部分將在後續的分享中詳細闡述），防止被第三方惡意篡改致使出現異常。

參考流程以下圖所示：

如下兩種策略都是基於HttpDNS。HttpDNS是以Http或Https的方式向外提供域名解析的服務。與傳統的運營商的Local DNS相比，有如下幾點優點：

1、 防止出現DNS劫持

2、 可實現精準調度，讓客戶端接入最近的業務節點

3、 0ms解析延遲

4、 快速生效

5、 擴展性強

4.第三方HttpDNS策略

騰訊雲HttpDNS，阿里雲HttpDNS，DNSPod等廠家提供HttpDNS方案，客戶端接入方便，開發量較小，相對穩定。

但因爲依賴第三方服務，不能自定義一些依賴規則，好比分流等。且第三方服務也可能出現服務異常進而致使咱們的網絡狀態不可控。

拓撲圖以下圖所示【圖片參考於網絡】：

流程圖與自建HttpDNS方案類似，請參考"自建HttpDNS"章節流程圖。

5.自建HttpDNS策略

自建HttpDNS就是提供私有的DNS解析服務，以Http或Https的方式向外提供服務。嚴格來說，此方案不是降級策略，而是使用自建DNS替代系統DNS拿到直連IP進行網絡請求，而把系統級的緩存做爲最後的降級方案。

獨立域名或獨立IP提供HttpDNS域名解析服務，自研HttpDNS的SDK實現與服務器的通信；各端App接入SDK並完成Http DNS的解析工做，並根據域名拿到部分或所有可用的IP地址列表，再也不依賴現有域名訪問後臺服務，每次均採用IP的方式訪問服務。

拓撲圖以下圖所示【圖片參考於網絡】：

App在啓動時，須要按照如下流程完成SDK初始化，訪問業務接口時，直接使用IP訪問，下降延遲，避免DNS劫持等問題，也能方便的集成在其它App中。

IP或域名優先級爲：自建HttpDNS > LocalDNS（域名） > 內置固定IP 。

主要流程圖以下圖所示：

自定HttpDNS與配置文件策略的區別在於，第一提供SDK供多端快捷接入；第二能對單個IP的生命週期進行管理；第三SDK接入方不須要關心IP的管理，只要根據SDK返回的IP或域名（無有效IP時自動切換爲域名）進行網絡請求便可。

關注問題

1. 不管採用哪一種方案，都須要考慮Header中Host參數配置問題，Https的證書校驗問題，SNI等問題，App內嵌的網頁的網絡請求等問題。
2. 不管採用何種方案，都默認使用App內部固定的IP做爲最後的容災方案。
3. 相同優先級中存在多個IP有效時，採起輪詢或優先級的方案就行分流。

上面提到的問題，都將在後續的分享中說明相關實現方案。

建議方案

基於以上闡述，考慮App現狀，建議初始階段暫時採用直連策略（DS001）或配置文件策略(DS002)，在既能減小生產環境問題。App能正常訪問的前提下。

第二步根據實際狀況，建議儘快實現或接入第三方HttpDNS策略方案(DS003)或自建Http DNS方案(DS004)，並實現本身的SDK供多端使用，此方案在靈活性，擴展性，可維護性，可控制性上比其它方案更加有優點。

附錄

附錄一

[
	{
		"hostName":"a.test.cn", //域名
		"ips":[ // 域名對應的IP地址列表
			{
				"priority":1, // 優先級
				"ipAddr":"192.168.1.23", // ip地址
				"ttl":1568859453 // 超時時間
			},
			{
				"priority":1,
				"ipAddr":"192.168.1.23",
				" ttl":1568859453
			}
		]
	},
	{
		"hostName": "b.test.cn" ,
		"ips":[
			{
		    	"priority":1,
				"ipAddr":"192.168.1.23",
				" ttl":1568859453
			}
		]
	}
]
複製代碼