天天看點

移動端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      

 對應内部的架構也會是兩個樣子

移動端API架構 統一Proxy還是各自為政?

今天我們就來聊一下,僅僅從架構層面來說到底是有紅色Proxy部分好呢還是沒有好?

一般的初創公司,甚至到中型網際網路技術公司,很多人都在用分拆域名的方式來分拆業務,這樣做好處是什麼?

一般在一家創業公司驅使按域名分業務分拆後端API始于團隊和人員的發展,他們期望各業務負責人隻需要關注自己的業務,業務間沒有關聯關系,即便在最終産品上各業務會有先後依賴關系,如消息服務(msg service)依賴user service,也都是整體由用戶端來串邏輯,研發msg service的同學與user service的同學可以不用交流或者少交流,已到達各業務開發團隊齊頭并進的效果。出了問題呢,也能很快的定位是哪個api的service挂了,每個團隊維護好自己的服務, 幹好自己的事情. 

在這個階段的公司,這也是個不錯的方案能夠讓多個團隊齊頭并進.

但是對于大的網際網路公司,或者有技術追求的技術公司,這并不是最理想的方案,為什麼呢?

我們來看看按域名分拆業務帶來的問題:

1. 流量監控等方案需要在各個業務做

2. 安全性, 防攻擊等相關問題需要各個業務團隊完成

3. 不利于統一管理,需要給每個業務配備對應的運維人員(絕大部分這種架構的公司op也是這麼配備的)

4. 擴容 縮容 熔斷 等高可用相關的基礎方案難複用

這裡面最重要的是流量監控和容量規劃,在同一的proxy層做監控能夠讓人非常快速的知道系統故障時問題在哪,哪個服務的耗時增加了,哪個服務開始出現500了. 如終端報bug消息出不來了,到底是msg service還是user service的問題,一目了然;同時統一的擴容 縮容以及服務降級的關聯,都好做了,運維工程師的幸福生活由此展開.

當然,這并不是唯一的方式,使用分拆域名然後把各個監控資料彙集到一塊也能做,但是成本變高了.

部落格位址:Zealot Yin

歡迎轉載,轉載請注明出處[http://creator.cnblogs.com/]