移動端API架構(gòu) 統(tǒng)一Proxy還是各自為政? - 大熊先生|互聯(lián)網(wǎng)后端技術(shù) - 博客園http://www.cnblogs.com/Creator/p/5506095.html
我經(jīng)歷過幾家公司帅刊，有把所有的service放到一個域名下的挨稿，也有按業(yè)務(wù)的不同來拆分為不同域名服務(wù)的
api.baidu.com/msg
api.baidu.com/user
api.baidu.com/search
也有如：
msg.baidu.com
user.baidu.com
search.baidu.com
對應(yīng)內(nèi)部的架構(gòu)也會是兩個樣子
一般的初創(chuàng)公司,甚至到中型互聯(lián)網(wǎng)技術(shù)公司，很多人都在用分拆域名的方式來分拆業(yè)務(wù)锦秒，這樣做好處是什么？
一般在一家創(chuàng)業(yè)公司驅(qū)使按域名分業(yè)務(wù)分拆后端API始于團隊和人員的發(fā)展爸黄，他們期望各業(yè)務(wù)負責(zé)人只需要關(guān)注自己的業(yè)務(wù)雾鬼，業(yè)務(wù)間沒有關(guān)聯(lián)關(guān)系媚值，即便在最終產(chǎn)品上各業(yè)務(wù)會有先后依賴關(guān)系，如消息服務(wù)(msg service)依賴user service，也都是整體由客戶端來串邏輯靴拱，研發(fā)msg service的同學(xué)與user service的同學(xué)可以不用交流或者少交流垃喊，已到達各業(yè)務(wù)開發(fā)團隊齊頭并進的效果。出了問題呢袜炕，也能很快的定位是哪個api的service掛了本谜，每個團隊維護好自己的服務(wù), 干好自己的事情.
在這個階段的公司，這也是個不錯的方案能夠讓多個團隊齊頭并進.
但是對于大的互聯(lián)網(wǎng)公司偎窘，或者有技術(shù)追求的技術(shù)公司乌助，這并不是最理想的方案，為什么呢陌知？
我們來看看按域名分拆業(yè)務(wù)帶來的問題：
- 流量監(jiān)控等方案需要在各個業(yè)務(wù)做
- 安全性, 防攻擊等相關(guān)問題需要各個業(yè)務(wù)團隊完成
- 不利于統(tǒng)一管理他托，需要給每個業(yè)務(wù)配備對應(yīng)的運維人員（絕大部分這種架構(gòu)的公司op也是這么配備的）
- 擴容 縮容 熔斷 等高可用相關(guān)的基礎(chǔ)方案難復(fù)用
這里面最重要的是流量監(jiān)控和容量規(guī)劃，在同一的proxy層做監(jiān)控能夠讓人非常快速的知道系統(tǒng)故障時問題在哪仆葡，哪個服務(wù)的耗時增加了赏参，哪個服務(wù)開始出現(xiàn)500了. 如終端報bug消息出不來了，到底是msg service還是user service的問題沿盅，一目了然把篓；同時統(tǒng)一的擴容 縮容以及服務(wù)降級的聯(lián)動，都好做了嗡呼，運維工程師的幸福生活由此展開.
當(dāng)然,這并不是唯一的方式纸俭，使用分拆域名然后把各個監(jiān)控數(shù)據(jù)匯集到一塊也能做，但是成本變高了.
