移動端API架構 統一Proxy仍是各自爲政?

今天首先回答上一篇的問題：

爲何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的問題，一目瞭然；同時統一的擴容 縮容以及服務降級的聯動，都好作了，運維工程師的幸福生活由此展開.

固然,這並非惟一的方式，使用分拆域名而後把各個監控數據聚集到一塊也能作，可是成本變高了.