最近在客戶現場出差，見證了不少有趣的線上事故，下面要講的就是其中之一。
一段時間以來，某個微服務在生產環境的response的延遲陡然增加了幾百毫秒，而部署的代碼并不是造成延遲原因。從Newrelic的監控可以發現，該API的延遲增大的主要原因是它依賴的一個服務響應時間增大了。
我們暫且把這個外部的服務稱為service.mycompany.com，這個服務分別部署在澳洲和歐洲的兩個數據中心，入口處是Akamai，做負載均衡，盡可能的按照訪問來源去分發請求。
該微服務部署在AWS悉尼的數據中心，所以理論上來講，當它請求service.mycompany.com時，Akamai應該返回的是位于悉尼的edge節點的IP，同時其訪問的origin服務器也應該位于悉尼。但是通過在該微服務的服務器debug，發現ping值以及traceroute的值都比較高，辦公室訪問卻都一切正常。當時懷疑是Akamai的GEOIP判斷出了問題，把來自亞馬遜悉尼的請求當成了來自美國的IP的請求，于是用部署于歐洲的數據中心的服務處理請求。和基礎設施部門管理網絡的人討論，再次調查后結論類似。
問題出在這個AWS賬戶下的VPC的DHCP options的配置。因為是比較早期使用的share的AWS賬戶，所以下面的網絡配置比較復雜，配置有Direct Connect 連往其他數據中心，以及很多VPC Peering。不知道因為什么原因，這個微服務部署的Cloudformation template里面選擇了包含google DNS 8.8.8.8和8.8.8.4的DHCP Options。我們都知道對于在Akamai上注冊的服務service.mycompany.com來說，如:
~> host service.mycompany.com
service.mycompany.com is an alias for mycompany.generic.edgekey.net.
mycompany.generic.edgekey.net is an alias for e8888.g.akamaiedge.net.
e8888.g.akamaiedge.net has address 104.116.190.24
第一次DNS請求返回的記錄是CName，之后進一步返回Akamai動態DNS的CName，也就是edge server的CName，之后再根據DNS服務器返回對應的edge服務器的IP地址，如果查詢的是Google的DNS，那么它會返回美國的edge服務器地址……。我們可以測試下:
~> dig @8.8.8.8 service.mycompany.com
; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 service.mycompany.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44304
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;service.mycompany.com. IN A
;; ANSWER SECTION:
service.mycompany.com. 86399 IN CNAME mycompany.generic.edgekey.net.
mycompany.generic.edgekey.net. 263 IN CNAME e8888.g.akamaiedge.net.
e8888.g.akamaiedge.net. 19 IN A 23.53.156.156
;; Query time: 603 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Nov 15 22:15:52 2016
;; MSG SIZE rcvd: 130
查詢下IP地址信息，
~> whois 23.53.156.156 | grep Country
Country: US
所以，這個微服務的請求先到Akamai美國的edge服務器，之后很有可能請求被發送到了歐洲的origin服務器，這個延遲不增加才??了……。
解決的辦法很簡單，更新配置，DHCP Options選擇Amazon提供的DNS就可以了，響應時間就降下去了。
這個事情給我們的教訓就是，不管怎么樣都不能崇洋媚外，雖然澳洲一直follow美國，但是DNS還是得用自己的。
