馮磊，目前主要從事手機(jī)應(yīng)用平臺(tái)的構(gòu)建，任職新浪網(wǎng)技術(shù)中國(guó)研發(fā)中心技術(shù)保障部架構(gòu)師。5+年互聯(lián)網(wǎng)，移動(dòng)終端，游戲從業(yè)經(jīng)驗(yàn)。歷任軟件工程師，高級(jí)軟件工程師，技術(shù)經(jīng)理。

趙星宇，HttpDNS的合作者。目前就職于新浪微博，從事手機(jī)微博的基礎(chǔ)架構(gòu)開發(fā)，任android高級(jí)研發(fā)工程師職位。

HttpDNS是使用HTTP協(xié)議向DNS服務(wù)器的80端口進(jìn)行請(qǐng)求，代替?zhèn)鹘y(tǒng)的DNS協(xié)議向DNS服務(wù)器的53端口進(jìn)行請(qǐng)求,繞開了運(yùn)營(yíng)商的Local DNS，從而避免了使用運(yùn)營(yíng)商Local DNS造成的劫持和跨網(wǎng)問題。 (具體httpdns是什么？詳細(xì)閱讀見（【鵝廠網(wǎng)事】全局精確流量調(diào)度新思路-HttpDNS服務(wù)詳解）：http://mp.weixin.qq.com/s?__biz=MzA3ODgyNzcwMw==&mid=201837080&idx=1&sn=b2a152b84df1c7dbd294ea66037cf262&scene=2&from=timeline&isappinstalled=0&utm_source=tuicool)

鵝廠往事中提到

那么對(duì)于騰訊這樣的域名數(shù)量在10萬級(jí)別的互聯(lián)網(wǎng)公司來講，域名解析異常的情況到底有多嚴(yán)重呢？每天騰訊的分布式域名解析監(jiān)測(cè)系統(tǒng)在不停地對(duì)全國(guó)所有的重點(diǎn)LocalDNS進(jìn)行探測(cè)，騰訊域名在全國(guó)各地的日解析異常量是已經(jīng)超過了80萬條。這給騰訊的業(yè)務(wù)帶來了巨大的損失。為此騰訊建立了專業(yè)的團(tuán)隊(duì)與各個(gè)運(yùn)營(yíng)商進(jìn)行了深度溝通，但是由于各種原因，處理效率及效果均不能達(dá)到騰訊各業(yè)務(wù)部門的需求。除了和運(yùn)營(yíng)商進(jìn)行溝通，有沒有一種技術(shù)上的方案，能從根源上解決域名解析異常及用戶訪問跨網(wǎng)的問題呢？

HttpDNS主要解決三類問題：

1. LocalDNS劫持

2. 平均訪問延遲下降

3. 用戶連接失敗率下降

LocalDNS劫持: 由于HttpDNS是通過ip直接請(qǐng)求http獲取服務(wù)器A記錄地址，不存在向本地運(yùn)營(yíng)商詢問domain解析過程，所以從根本避免了劫持問題。 （對(duì)于http內(nèi)容tcp/ip層劫持，可以使用驗(yàn)證因子或者數(shù)據(jù)加密等方式來保證傳輸數(shù)據(jù)的可信度）

平均訪問延遲下降: 由于是ip直接訪問省掉了一次domain解析過程，（即使系統(tǒng)有緩存速度也會(huì)稍快一些‘毫秒級(jí)’）通過智能算法排序后找到最快節(jié)點(diǎn)進(jìn)行訪問。

用戶連接失敗率下降: 通過算法降低以往失敗率過高的服務(wù)器排序，通過時(shí)間近期訪問過的數(shù)據(jù)提高服務(wù)器排序，通過歷史訪問成功記錄提高服務(wù)器排序。如果ip(a)訪問錯(cuò)誤，在下一次返回ip(b)或者ip(c) 排序后的記錄。（LocalDNS很可能在一個(gè)ttl時(shí)間內(nèi)（或多個(gè)ttl）都是返回記錄

HttpDNSLib庫(kù)組成

HttpDNSLib庫(kù)主要由三個(gè)模塊組成，查詢模塊，緩存模塊，評(píng)估模塊。

查詢模塊：

1. 檢查本地是否有對(duì)應(yīng)的 domain 緩存

2. 如果沒有 則從本地LocalDNS獲取然后從httpdns更新domain記錄

3. 有數(shù)據(jù)則檢測(cè)是否過期 已過期則更新記錄返回 LocalDNS 記錄， 未過期則直接返回緩存層數(shù)據(jù)。

4. 從HttpDNS 接口查詢本次app開啟后使用過的domain 記錄定時(shí)訪問，更新內(nèi)存緩存，數(shù)據(jù)庫(kù)緩存等記錄

數(shù)據(jù)模塊：

1. 根據(jù)SP（或Wifi名）緩存域名信息

2. 更具SP（或Wifi名）緩存服務(wù)器ip信息、優(yōu)先級(jí)

3. 記錄服務(wù)器ip每次請(qǐng)求成功數(shù)、錯(cuò)誤數(shù)

4. 記錄服務(wù)器ip最后成功訪問時(shí)間、最后測(cè)速

5. 添加 內(nèi)存 -》數(shù)據(jù)庫(kù) 之間的緩存層

評(píng)估模塊：

1. 根據(jù)本地?cái)?shù)據(jù)，對(duì)一組IP排序

2. 處理用戶反饋回來的請(qǐng)求明細(xì)，入庫(kù)

3. 針對(duì)用戶反饋是失敗請(qǐng)求，進(jìn)行分析上報(bào)預(yù)警

4. 給HttpDns服務(wù)端智能分配A記錄提供數(shù)據(jù)依據(jù)

HttpDNS交互流程

HttpDNS交互流程圖：

從這張圖中可以看出來 整個(gè)業(yè)務(wù)的交互流程，用戶向查詢模塊傳入一個(gè)URL地址，然后查詢模塊會(huì)檢查緩存是否存在，不存在從httpdnsapi接口查詢， 然后經(jīng)過評(píng)估模塊返回。在用戶請(qǐng)求URL過程完畢時(shí)，需要將這次請(qǐng)求的結(jié)果反饋給 lib庫(kù)的評(píng)估模塊由評(píng)估模塊入庫(kù)記錄本次質(zhì)量數(shù)據(jù)。

HttpDns Lib庫(kù)交互流程：

這張圖就更深入的說了下 lib的工作原理。有兩條豎線講圖片分為了三個(gè)區(qū)域，分別是左部分、中間部分 和 右部分。

左部分是app主線程操作的事情，中間部分是app調(diào)用者線程中處理lib庫(kù)事件邏輯的事情，右面部分是新線程獨(dú)立處理事件的邏輯。

開始是里客戶端調(diào)用方，傳入一個(gè) url，獲取domain信息后由查詢模塊查詢domain記錄，查詢模塊會(huì)從內(nèi)存緩存層查詢，內(nèi)存緩存層沒有數(shù)據(jù)會(huì)，查詢數(shù)據(jù)庫(kù)，如果數(shù)據(jù)庫(kù)也沒有數(shù)據(jù)會(huì)請(qǐng)求本地 LocalDNS。從三個(gè)環(huán)節(jié)中任何一個(gè)環(huán)節(jié)拿到數(shù)據(jù)后， 都會(huì)進(jìn)入下一個(gè)環(huán)節(jié)，如果沒有拿到數(shù)據(jù)返回null結(jié)束。進(jìn)入評(píng)估模塊，根據(jù)五個(gè)插件進(jìn)行排序， 排序后返回?cái)?shù)據(jù)給客戶端。

lib模塊設(shè)定定時(shí)器，根據(jù)ttl過期時(shí)間來檢查domain是否需要更新。 定時(shí)器是獨(dú)立線程， 不會(huì)影響app主線程。 httpdns api請(qǐng)求數(shù)據(jù)， 先從自己配置的 httpdns api接口獲取數(shù)據(jù)，如果獲取不到會(huì)從 dnspod api接口獲取如果也獲取不到 直接從本地 localDNS獲取數(shù)據(jù)，（從本地localDNS獲取數(shù)據(jù)后期會(huì)改為發(fā)送UDP包封裝dns協(xié)議從公共dns服務(wù)器直接獲取，比如114dns等。dns服務(wù)器地址可自行設(shè)定。 ）獲取到數(shù)據(jù)后進(jìn)入測(cè)速模塊。 測(cè)速模塊最新版本可以配置兩種方式，一種是http空請(qǐng)求。 兩個(gè)http頭的交互，類似tcp首保耗時(shí)時(shí)間原理 ，用來測(cè)試鏈路最快。 另一種是ping命令，（icmp協(xié)議）來盡量最小化流量的消耗，考慮倒可能有的服務(wù)器禁ping就使用空http測(cè)速即可。 測(cè)速后將數(shù)據(jù)插入本地 cache 即可。

代碼結(jié)構(gòu)

工程代碼一共有八個(gè)主要package包，分別是cache、httpdns、log、model、query、score、speedtest、networktype。

cache包數(shù)據(jù)緩存層

IDnsCache是該包的對(duì)外主要接口。DnsCacheManager 實(shí)現(xiàn)該接口，封裝了管理該包的所有邏輯調(diào)度，ConcurrentHashMap是內(nèi)存緩存層的介質(zhì)，當(dāng)初使用過非線程安全的hashMap遇到了很多線程鎖的問題，沒有更好的辦法自己控制鎖管理，就替換成線程安全的concurrenthashmap對(duì)象了。DBConstants 設(shè)定了數(shù)據(jù)庫(kù)名字表名字以及表字段，包含全部sql語句。 DNSCacheDatabaseHelper 用來操作數(shù)據(jù)庫(kù)，所有和數(shù)據(jù)庫(kù)交互的邏輯都在該類。

networktype包用來監(jiān)控網(wǎng)絡(luò)變化和檢測(cè)當(dāng)前網(wǎng)絡(luò)狀態(tài)

Constants 設(shè)定了網(wǎng)絡(luò)狀態(tài)的相關(guān)常量。 NetworkManager類也是這個(gè)包的主入口類所有網(wǎng)絡(luò)狀態(tài)的獲取都是通過這個(gè)類來獲取。 NetworkStateReceiver用來注冊(cè)網(wǎng)絡(luò)廣播來接受網(wǎng)絡(luò)發(fā)生變化的事件 。

httpdns包封裝了所有HttpDNS api交互請(qǐng)求

IHttpDNS接口定義了該包和外部交互的所有數(shù)據(jù)格式，HttpDnsManager 實(shí)現(xiàn)了IHttpDNS接口。 HttpDnsConfig定義了使用到的常量配置， 以及dns api接口的開關(guān)，和順序。 requests包里INetworkRequests接口輕量級(jí)的定義了 網(wǎng)絡(luò)請(qǐng)求的實(shí)現(xiàn)， 目前使用ApacheHttp實(shí)現(xiàn)的該接口，如果用戶有需求更換網(wǎng)絡(luò)實(shí)現(xiàn)方式實(shí)現(xiàn)INetworkRequests 接口即可。 IJsonParser 接口定義了 httpdns api返回?cái)?shù)據(jù)解析json的方式， 目前使用 android jsonObject實(shí)現(xiàn)。 如果需要擴(kuò)展直接實(shí)現(xiàn)該接口即可。

log包實(shí)現(xiàn)了記錄dnscachelib庫(kù)記錄日志倒文件的工具類

IDnsLog約定了寫log和獲取log的方法。 HttpDnsLogManager實(shí)現(xiàn)該接口，并管理log模塊。該模塊還有一個(gè)寫文件的工具類。

model包封裝了全部數(shù)據(jù)交互模型

DomainModel對(duì)應(yīng)數(shù)據(jù)庫(kù)domain表， IpModel對(duì)應(yīng)數(shù)據(jù)庫(kù)ip表。 HttpDnsPack是獲取httpdns api接口數(shù)據(jù)的模型 。 ConnectFailModel用來記錄所有異常錯(cuò)誤。

query包是查詢模塊的入口

IQuery定義了該包對(duì)外的協(xié)議接口。 QueryManager實(shí)現(xiàn)該接口封裝了所有查詢相關(guān)操作。

Score包也是前面說的評(píng)估模塊

IScore定義該包對(duì)外實(shí)現(xiàn)的接口，ScoreManager實(shí)現(xiàn)該接口。 PlugInManager用來管理所有評(píng)估插件。 所有的評(píng)估插件均實(shí)現(xiàn) IPlugIn接口協(xié)議，規(guī)定輸入輸出。使用者可以自行添加評(píng)估插件。

speedtest包實(shí)現(xiàn)測(cè)速邏輯

ISpeedtest規(guī)定該包對(duì)外的接口協(xié)議， SpeedtestManager實(shí)現(xiàn)ISpeedtest接口。 封裝了測(cè)速相關(guān)邏輯， 包括空http請(qǐng)求，以及ping命令測(cè)速。

另外場(chǎng)景包種有幾個(gè)類簡(jiǎn)單介紹下。 DNSCache類是lib的主入口類，用戶的所有操作均調(diào)用該入口類，該類是單利類直接獲取實(shí)例調(diào)用即可，也是主場(chǎng)景。

由于內(nèi)部model數(shù)據(jù)過于復(fù)雜，為用戶專門封裝DomainInfo模型。 該類僅返回用戶使用的相關(guān)數(shù)據(jù)。

DNSCacheConfig 是httpdns庫(kù)的全局配置文件， 可以直接修改該文件，也可以外部調(diào)用方法設(shè)置參數(shù) 。 該文件還封裝了云端動(dòng)態(tài)更新緩存配置。

代碼結(jié)構(gòu)如下圖所示：

在編寫該庫(kù)的時(shí)候遇到最頭疼的問題可能就是多線程同時(shí)訪問導(dǎo)致遇到的數(shù)據(jù)異常錯(cuò)誤。比如用戶訪問 api.weibo.cn 域名該域名目前數(shù)據(jù)庫(kù)中沒有緩存，內(nèi)存中也沒有緩存。在同時(shí)有多個(gè)請(qǐng)求以來來獲取該域名的ip的時(shí)候， 因?yàn)闆]有數(shù)據(jù)會(huì)去請(qǐng)求api接口獲取數(shù)據(jù)， 導(dǎo)致同時(shí)開啟多個(gè)線程訪問數(shù)據(jù)。 解決辦法在請(qǐng)求api接口前增加正在請(qǐng)求隊(duì)列，

任何需要請(qǐng)求數(shù)據(jù)的domain都先要在該隊(duì)列檢測(cè)是否有請(qǐng)求存在如果沒有在繼續(xù)進(jìn)入后面流程如果有則丟掉本次請(qǐng)求指令。 另外在操作數(shù)據(jù)庫(kù)的時(shí)候使用了 對(duì)象鎖和 synchronized 方法鎖， 導(dǎo)致了程序有鎖死的情況，后改成全部使用對(duì)象鎖就解決了該問題。全程的調(diào)試數(shù)據(jù)也是最頭疼的環(huán)節(jié)，后直接編寫測(cè)試程序，時(shí)時(shí)調(diào)試所有環(huán)節(jié)的數(shù)據(jù)（看到時(shí)時(shí)數(shù)據(jù)后發(fā)現(xiàn)了很多程序的bug，后都一一解決）。

以上為馮老師的分享，接下來是星宇跟大家分享下項(xiàng)目從研發(fā)倒現(xiàn)在所遇到的一些主要問題和大家有疑問的點(diǎn)。

開發(fā)過程中，常見的一些問題

1、手機(jī)網(wǎng)絡(luò)從3G 切換到 Wifi下處理了什么？

NetworkStateReceiver類來監(jiān)聽網(wǎng)絡(luò)是否發(fā)生變化，在網(wǎng)絡(luò)有變化的時(shí)候，會(huì)刷新 NetworkManager類中的網(wǎng)絡(luò)環(huán)境，在客戶端內(nèi)如果是手機(jī)網(wǎng)絡(luò)可以知道網(wǎng)絡(luò)類型（2G、3G、4G）也可以知道當(dāng)前SP（移動(dòng)、聯(lián)通、電信），如果是Wifi網(wǎng)絡(luò)環(huán)境可以知道SSID（wifi名字）在刷新網(wǎng)絡(luò)環(huán)境后，會(huì)重新查詢緩存內(nèi)是否有當(dāng)前鏈路下的最優(yōu)A記錄，如果沒有則從LocalDNS獲取第一次，然后馬上更新httpdns記錄。

2、網(wǎng)絡(luò)發(fā)生變化后，返回的A記錄還一樣么？

數(shù)據(jù)庫(kù)中緩存的數(shù)據(jù)，是根據(jù)當(dāng)前sp來緩存的，也就是說當(dāng)自身網(wǎng)絡(luò)環(huán)境變化后，返回的a記錄是不一樣的 。手機(jī)網(wǎng)絡(luò)下會(huì)根據(jù)當(dāng)前sp來緩存 a記錄服務(wù)器ip，如果是wifi網(wǎng)絡(luò)環(huán)境下 根據(jù)當(dāng)前ssid來緩存a記錄，因?yàn)閣ifi環(huán)境下庫(kù)自己沒有辦法明確判斷出自己的運(yùn)營(yíng)商，但相同的ssid不會(huì)發(fā)生頻繁的網(wǎng)絡(luò)運(yùn)營(yíng)商變化。 所以在wifi下請(qǐng)求回來的a記錄直接關(guān)聯(lián)ssid名字即可，即使wifi sp發(fā)生變化，最多延遲一個(gè)ttl時(shí)間就更新成最新的a記錄了。

3、怎樣進(jìn)行測(cè)速？

在從HttpDNS獲取回來a記錄的時(shí)候進(jìn)行測(cè)速，測(cè)速的方式有兩種： ping和空的http請(qǐng)求?？紤]倒有些服務(wù)器不支持ping來進(jìn)行鏈路質(zhì)量評(píng)判，可以使用空的http請(qǐng)求，僅僅是兩個(gè)http頭的流量開銷，而ping的方式流量開銷就更小了。 這個(gè)功能可以在庫(kù)中自己配置。這里的測(cè)速其實(shí)是模擬首保接收的時(shí)間來做的， 同時(shí)對(duì)于流量控制嚴(yán)格的可以在庫(kù)中配置測(cè)速頻繁度，比如一臺(tái)服務(wù)器在5分鐘內(nèi)有過測(cè)速記錄則不進(jìn)行測(cè)速。

4、域名ttl剛剛過期，庫(kù)還沒有從HttpDNS拉取回來數(shù)據(jù)怎么辦？

ttl過期的前10秒去請(qǐng)求數(shù)據(jù)，在ttl過期后的10秒內(nèi)庫(kù)也認(rèn)為當(dāng)前a記錄是有效的，會(huì)給你直接返回。

5、lib庫(kù)目前只能使用 dnspod 服務(wù)商么？ 支持dnspod 企業(yè)版本么？

目前庫(kù)可以支持自定義的 HttpDNS api接口， 只需要實(shí)現(xiàn)IHttpDns接口類即可，在配置了dnspod企業(yè)key和id 的時(shí)候自動(dòng)啟用企業(yè)版本加密傳輸，支持企業(yè)版本。

6、使用這個(gè)庫(kù)會(huì)不會(huì)降低應(yīng)用請(qǐng)求網(wǎng)絡(luò)的訪問速度？

從目前的測(cè)試數(shù)據(jù)來看是不會(huì)的，HttpDNS庫(kù)返回a記錄的時(shí)間平均在5毫秒以內(nèi)，有時(shí)會(huì)出現(xiàn)內(nèi)存緩存中沒有該域名記錄，數(shù)據(jù)庫(kù)中也沒有的時(shí)候會(huì)從LocalDNS獲取a記錄，時(shí)間會(huì)稍長(zhǎng)一些

一旦從LocalDNS獲取后，會(huì)緩存倒內(nèi)存中，在HttpDNS獲取數(shù)據(jù)后會(huì)更新內(nèi)存中得domain記錄。 從庫(kù)中獲取a記錄會(huì)比從LocalDNS獲取a記錄快一些。 在訪問網(wǎng)絡(luò)的時(shí)候由于是使用ip直鏈，可以起到一些加速效果，lib庫(kù)獲取domainA記錄 + ip直接訪問服務(wù)器 耗時(shí)小于 直接域名請(qǐng)求服務(wù)器。相關(guān)數(shù)據(jù)圖片

下面給出一個(gè)測(cè)試系統(tǒng)的截圖

7、lib庫(kù)里面訪問網(wǎng)絡(luò)使用的是哪個(gè)網(wǎng)絡(luò)庫(kù)？ json庫(kù)用的是哪個(gè)？

考慮到該庫(kù)的輕量級(jí)，使用的是android系統(tǒng)的org.apache.http.client.HttpClient庫(kù)訪問網(wǎng)絡(luò)，如果需要切換到工程在使用的網(wǎng)絡(luò)庫(kù)可以實(shí)現(xiàn) INetworkRequests 接口即可切換網(wǎng)絡(luò)庫(kù)。 json解析使用的也是android系統(tǒng)自帶的org.json.JSONObject 如有需求切換json解析庫(kù)，可直接實(shí)現(xiàn)IJsonParser接口即可切換。

8、使用該網(wǎng)絡(luò)庫(kù)會(huì)給我的app帶來多大的體積增加？

目前該lib庫(kù)沒有引用任何外部的庫(kù)文件。一切本著使用系統(tǒng)自身的api為原則，來保證庫(kù)的輕量級(jí)，和兼容性。 目前l(fā)ib庫(kù)打包后70多k，代碼在5千行左右。 測(cè)試工程代碼在6千行左右。

9、lib庫(kù)的配置必須要通過修改源代碼的方式來進(jìn)行配置么？

任何參數(shù)都可以在庫(kù)調(diào)用方配置，DNSCacheConfig 類是整個(gè)庫(kù)的配置文件。 并且支持云端動(dòng)態(tài)更新配置 需要實(shí)現(xiàn)DNSCacheConfig.ConfigText_API 更新地址。 具體配置api接口請(qǐng)參考 dome工程中設(shè)置庫(kù)的方式。

10、緩存domain記錄是存儲(chǔ)成文件還是數(shù)據(jù)庫(kù)，或者android內(nèi)部的一些存儲(chǔ)方式？

lib緩存數(shù)據(jù)是通過數(shù)據(jù)庫(kù)存儲(chǔ)的。SQLiteDatabase， 具體的表接口和sql語句請(qǐng)參考 DBConstants 類文件。

11、 評(píng)估模塊有什么功能？

評(píng)估模塊目前由五個(gè)插件組成， 速度插件、推薦優(yōu)先級(jí)插件、歷史成功次數(shù)插件、歷史錯(cuò)誤數(shù)插件、最近一次成功時(shí)間插件 。 每一個(gè)a記錄服務(wù)器ip，都會(huì)經(jīng)過這五個(gè)插件進(jìn)行評(píng)估排序后返回給使用者。 所有插件評(píng)估分值比重可以配置， 根據(jù)自己的需求以及不同的使用場(chǎng)景，調(diào)整出最合理的權(quán)重分配。

下面給出評(píng)估模塊算法細(xì)節(jié)圖

12、速度插件具體算法？

比如速度插件評(píng)分體系， 滿分100分， 那么有3個(gè)服務(wù)器ip， 1號(hào)服務(wù)器http請(qǐng)求耗時(shí)10毫秒， 2號(hào)服務(wù)器20毫秒， 3號(hào)服務(wù)器30毫秒。 那么經(jīng)過插件計(jì)算后 1號(hào)服務(wù)器100分， 2號(hào)服務(wù)器50分， 3號(hào)服務(wù)器25分。

13、優(yōu)先級(jí)插件又是什么？

如果是自定義的服務(wù)器，可以返回服務(wù)器優(yōu)先級(jí)字段，該的字段代表推薦使用該服務(wù)器的權(quán)重， 比如該字段服務(wù)端可以和監(jiān)控系統(tǒng)結(jié)合起來，甚至是用來分流。 相應(yīng)的權(quán)重值， 也會(huì)算出來不同的分值。

14、歷史成功次數(shù)插件是什么？ 歷史錯(cuò)誤次數(shù)插件是什么？

在當(dāng)前sp當(dāng)前鏈路下， 會(huì)記錄訪問過的該服務(wù)器ip的成功次數(shù)， 成功次數(shù)越多認(rèn)為該服務(wù)器相對(duì)穩(wěn)定。 會(huì)在排序的時(shí)候根據(jù)權(quán)重比值進(jìn)行影響最終排序結(jié)果， 該插件權(quán)重不建議過高。 同理歷史錯(cuò)誤插件也是記錄當(dāng)前鏈路下服務(wù)器出過錯(cuò)誤的次數(shù)，次數(shù)越高認(rèn)為越不穩(wěn)定。 排序盡量靠后。 同樣該插件權(quán)重不建議過高。

15、最后一次成功時(shí)間？

如果該服務(wù)器在 很近的時(shí)間內(nèi)訪問過，那么評(píng)估系統(tǒng)則認(rèn)為他鏈路是通的，則會(huì)給一個(gè)分值， 越接近現(xiàn)在的時(shí)間的服務(wù)器 分值越高。 24小時(shí)以前訪問的分值為0 。

16、評(píng)估插件就這五個(gè)嗎？

該五個(gè)插件屬于拋磚引玉， 可以自定義插件 只需要實(shí)現(xiàn) IPlugIn 接口即可。 所有的插件啟用和停止都在 配置文件中可以修改，以及配置每個(gè)插件的權(quán)重比。

17、智能評(píng)估一定會(huì)帶來好的效果嗎？

首先httpdns返回的a記錄已經(jīng)是 經(jīng)過當(dāng)前地域和當(dāng)前sp返回的最優(yōu)記錄結(jié)果集， 至少不會(huì)降低效率。

18、我可以不使用智能評(píng)估模塊么？

可以的在配置文件中關(guān)掉智能評(píng)估即可，具體代碼參照demo即可。 關(guān)掉智能評(píng)估模塊后，會(huì)在多個(gè)a記錄中隨機(jī)排序返回。

19、該Lib庫(kù)塊兼容性如何？

使用testin兼容性測(cè)試 測(cè)試兼容性結(jié)果：99.49%。 Android平臺(tái)全部由java代碼開發(fā)，沒有使用任何特殊特性，覆蓋全部系統(tǒng)版本。

最后附幾張測(cè)試工程效果圖：

• 模擬了客戶端訪問http請(qǐng)求，分別標(biāo)識(shí)了每個(gè)任務(wù)的詳細(xì)信息。

  
  
  

• 這個(gè)頁面全都是數(shù)據(jù)庫(kù)相關(guān)配置，在代碼中可以直接找到具體設(shè)置庫(kù)文件的接口。

  
  
  

• 數(shù)據(jù)報(bào)表入口，包含全部任務(wù)加速效果延遲效果數(shù)據(jù)記錄， lib庫(kù)耗時(shí)走向，每個(gè)ip直接訪問請(qǐng)求和domain訪問請(qǐng)求速度對(duì)比， 統(tǒng)計(jì)了服務(wù)器平局速度。

  
  
  
  

• 

• 

• 緩存數(shù)據(jù)標(biāo)簽中包含了 當(dāng)前庫(kù)的所有狀態(tài)， 能實(shí)時(shí)的看到內(nèi)存緩存層的所有數(shù)據(jù)狀態(tài)，包括數(shù)據(jù)庫(kù)中得所有數(shù)據(jù)狀態(tài)。 每秒鐘刷新一次。 在這里可以清空緩存層數(shù)據(jù)、數(shù)據(jù)層數(shù)據(jù)、已經(jīng)當(dāng)前測(cè)試工程的數(shù)據(jù)。 在這里你可以清楚的看到 ip 和 domain的對(duì)應(yīng)關(guān)系， 以及數(shù)據(jù)庫(kù)表中 每項(xiàng)的關(guān)系。 和所有的domain 以及 ip 的狀態(tài)。

  
  
  

全部代碼 均已開源 https://github.com/SinaMSRE/HTTPDNSLib ， 包括測(cè)試工程 也開源了 設(shè)計(jì)文檔 和 流程圖都在 git 上有。 測(cè)試工程的 ui psd 貌似也在git上

Q&A

Q1、每次請(qǐng)求url都需要去ping么？

不需要每次都ping的， 測(cè)試鏈路是否通暢 會(huì)在 從 httpdns api接口獲取數(shù)據(jù)后， 在測(cè)試鏈路是否通暢， 每次請(qǐng)求 httpdns api間隔是一個(gè) domain 設(shè)置的 ttl時(shí)間

ping 直發(fā)一個(gè)包， 最小化的減少 流量開銷。

檢測(cè)鏈路 如果配置成 http 空的請(qǐng)求， 也是同理 在 httpdns api請(qǐng)求結(jié)束后， 才會(huì)檢測(cè)鏈路是否暢通。

Q2、前面提到的并發(fā)請(qǐng)求，被丟棄的請(qǐng)求是怎么處理的

并發(fā)請(qǐng)求是說 客戶端請(qǐng)求 HttpDNS lib庫(kù) ，同時(shí)發(fā) api.weibo.cn 的請(qǐng)求么？

因?yàn)?去問 HttpDNS api接口的時(shí)候 ， 只需要有一個(gè)請(qǐng)求去問就可以了， 去問 HttpDNS api的時(shí)候 已經(jīng)切換到 非客戶端主線程， 在客戶端調(diào)用的主線程中 如果沒有緩存數(shù)據(jù) 就從 本地獲取 dns 的a記錄返回了。 所以直接丟棄這個(gè)訪問 HttpDNS api的請(qǐng)求即可， 不會(huì)影響到其他流程邏輯。

Q3、南北網(wǎng)絡(luò)之間請(qǐng)求有特別處理么？

南方電信，北方網(wǎng)通，運(yùn)營(yíng)商ip不一樣

首先 HttpDNS 返回的a記錄會(huì)根據(jù)你的出口ip 來從權(quán)威的 dns 服務(wù)器問出來結(jié)果。 如果你是南方的ip 肯定給你的a記錄 也是南方的， httpdns 返回的記錄理論應(yīng)該是和 傳統(tǒng)的 dns 返回的 a 記錄是一樣的。 而去問 httpdns 的api 地址 是 bgp的機(jī)房。 所以 也是 兼容多鏈路 多地域。有遇見過 傳統(tǒng) dns 出口可能是 電信的， 但業(yè)務(wù)訪問的 ip 出口是聯(lián)通的情況。 所以 HttpDNS 訪問 a記錄 也能避免這類一部分錯(cuò)誤。

Q4、用dnspod是用的他的接口么？如果dnspod上是配置的是cname，會(huì)遞歸解析出最終的ip緩存下來么？

會(huì)的。 這個(gè)依賴dnspod的返回結(jié)果， 同時(shí)也支持 cname 的返回結(jié)果。

比如 圖片使用 cdn 如果返回的是 cname 結(jié)果。 那么數(shù)據(jù)庫(kù)中記錄的也是 cname 結(jié)果。 通過 cname 家 host 頭來訪問也是可以的。

Q5、數(shù)據(jù)庫(kù)中記錄的是cname，還是cname解析出的ip？

數(shù)據(jù)庫(kù)中記錄的是 cname ， 并不是ip 。

因?yàn)闇y(cè)試過， 從一棟大樓走到另外一個(gè)大樓 里面 訪問的最終ip可能都不相同。 所以如果返回的是cname 則直接存儲(chǔ)cname 。 網(wǎng)絡(luò)環(huán)境發(fā)生變化， 會(huì)重新拉取， 不會(huì)使用緩存的cname 。

Q6、那cname的情況下，httpdns就起不到實(shí)際的作用了？

不會(huì)的， 一般劫持的都是 業(yè)務(wù)的主要域名， 而cname域名的劫持相對(duì)較少， 從我們公司的業(yè)務(wù)來看啊。 而且 dnspod 返回cname 的情況 我目前還沒看到。 都是解析倒ip 。 而我們自己做的 httpdns 服務(wù)器， 第一期目前會(huì)解析倒 cname 的節(jié)點(diǎn)。 跨域的ip解析 還沒做 會(huì)放到二期。

Q7、我們遇到的問題是主域名解析沒問題，cname的域名是amazon aws的域名，經(jīng)常莫名其妙解析不通，懷疑是運(yùn)營(yíng)商搞鬼。當(dāng)時(shí)也想自己做這個(gè)httpdns，但發(fā)現(xiàn)很麻煩，小廠沒人力搞這個(gè)事情。

有這個(gè)可能，我覺得可以把你們的domain放到dnspod里面試下解析出來的是不是cname如果是直接的ip應(yīng)該沒問題。后期我們有計(jì)劃加上udp直接發(fā)送dns協(xié)議包到公共的dns服務(wù)器節(jié)點(diǎn)來獲取數(shù)據(jù)，也支持設(shè)置自己家的權(quán)威dns服務(wù)器。