今天首先回答上一篇的問題：
為什麼APP通過運營商接入網路,連通率會那麼差？
1. 域名快取問題
運營商的localdns會快取域名的解析結果，不向權威DNS遞迴查詢解析
為什麼要這麼幹呢？
1）運營商之間的跨網流量結算費用比較貴（他們內部技術團隊的KPI），為了最大化的在本網消耗（內部結算好算），減少跨網結算，所以會把IP地址解析到自己的內容快取IP地址
2) 推送廣告，有利可圖。把內容快取替換為第三方聯盟廣告.
2. 解析轉發問題
部分小運營商圖省事，不進行域名的遞迴解析，而是把解析請求轉發到其他運營商的LocalDNS上,導致排程出現問題，跨網排程，最後影響的就是耗時，當耗時足夠大時，連通性就沒法保障了
3. LocalDNS遞迴出口NAT導致排程不準
LocalDNS遞迴出口NAT指的是運營商的LocalDNS按照標準的DNS協議進行遞迴，但是因為在網路上存在多出口且配置了目標路由NAT，結果導致LocalDNS最終進行遞迴解析的時候的出口IP就有概率不為本網的IP地址，跨網的影響如上
所以基於以上的原因，APP端對伺服器端API的連通性就會損失個5%左右.
解決方案請見上文<移動端API介面優化的術和結果>
今天來講另一個話題：
移動端API架構 是該統一Proxy還是各自為政?
我經歷過幾家公司，有把所有的service放到一個域名下的，也有按業務的不同來拆分為不同域名服務的
如： api.baidu.com/msg api.baidu.com/user api.baidu.com/search 也有如： msg.baidu.com user.baidu.com search.baidu.com
對應內部的架構也會是兩個樣子
今天我們就來聊一下，僅僅從架構層面來說到底是有紅色Proxy部分好呢還是沒有好？
一般的初創公司,甚至到中型網際網路技術公司，很多人都在用分拆域名的方式來分拆業務，這樣做好處是什麼？
一般在一家創業公司驅使按域名分業務分拆後端API始於團隊和人員的發展，他們期望各業務負責人只需要關注自己的業務，業務間沒有關聯關係，即便在最終產品上各業務會有先後依賴關係，如訊息服務(msg service)依賴user service，也都是整體由客戶端來串邏輯，研發msg service的同學與user service的同學可以不用交流或者少交流，已到達各業務開發團隊齊頭並進的效果。出了問題呢，也能很快的定位是哪個api的service掛了，每個團隊維護好自己的服務, 幹好自己的事情.
在這個階段的公司，這也是個不錯的方案能夠讓多個團隊齊頭並進.
但是對於大的網際網路公司，或者有技術追求的技術公司，這並不是最理想的方案，為什麼呢？
我們來看看按域名分拆業務帶來的問題：
1. 流量監控等方案需要在各個業務做
2. 安全性, 防攻擊等相關問題需要各個業務團隊完成
3. 不利於統一管理，需要給每個業務配備對應的運維人員（絕大部分這種架構的公司op也是這麼配備的）
4. 擴容 縮容 熔斷 等高可用相關的基礎方案難複用
這裡面最重要的是流量監控和容量規劃，在同一的proxy層做監控能夠讓人非常快速的知道系統故障時問題在哪，哪個服務的耗時增加了，哪個服務開始出現500了. 如終端報bug訊息出不來了，到底是msg service還是user service的問題，一目瞭然；同時統一的擴容 縮容以及服務降級的聯動，都好做了，運維工程師的幸福生活由此展開.
當然,這並不是唯一的方式，使用分拆域名然後把各個監控資料彙集到一塊也能做，但是成本變高了.