背景
前世
前期點(diǎn)評(píng)和美團(tuán)合并后，業(yè)務(wù)上為了快速接入美團(tuán)外賣，雙方采用了open-api的形式對(duì)接，考慮api對(duì)接的原因很多；
- 公司級(jí)的內(nèi)網(wǎng)沒有打通，無法進(jìn)行服務(wù)級(jí)別調(diào)用，只能走公網(wǎng)；
- 雙方都有對(duì)接第三方的open-api的成熟平臺(tái)；
- 雙方服務(wù)化的形式不同，美團(tuán)為thrift，點(diǎn)評(píng)為自研的pigeon(類似dubbo)，兩種RPC協(xié)議沒有打通。
- 時(shí)間緊迫，不能等內(nèi)網(wǎng)、協(xié)議等完全OK后再接入。
選用公網(wǎng)的同時(shí)也帶來了一系列的缺點(diǎn)（16年5月份完成內(nèi)網(wǎng)打通，當(dāng)月接入內(nèi)網(wǎng)）
- 公網(wǎng)鏈路不穩(wěn)定，受限于當(dāng)?shù)剡\(yùn)營(yíng)商、?網(wǎng)絡(luò)提供商等。
- 內(nèi)部數(shù)據(jù)暴露在了公網(wǎng)，有數(shù)據(jù)泄露的風(fēng)險(xiǎn)。
- 延時(shí)加劇，降低了單臺(tái)web服務(wù)的吞吐量，服務(wù)的SLA相關(guān)數(shù)據(jù)不容樂觀。
今生
從公司合并到現(xiàn)在已一年多，很多基礎(chǔ)設(shè)施以及中間件已趨于融合，內(nèi)網(wǎng)打通、rpc協(xié)議打通、通用中間件統(tǒng)一（MQ，cache，SLB）以及很多基礎(chǔ)服務(wù)都已兩地部署。
為什么現(xiàn)有架構(gòu)不可延續(xù)？
首先，美團(tuán)外賣的open-api是直接提供給客戶端以及h5調(diào)用，點(diǎn)評(píng)側(cè)服務(wù)通過httpclient來調(diào)用美團(tuán)的open-api顯得層級(jí)關(guān)系概念有些紊亂。同時(shí)面向客戶端及前端的api，但顯然在架構(gòu)上不在同一層級(jí)。
其次，無法定制化點(diǎn)評(píng)側(cè)的業(yè)務(wù)邏輯，通過美團(tuán)的open-api，很多點(diǎn)評(píng)獨(dú)有的需求邏輯無法由點(diǎn)評(píng)側(cè)完成，數(shù)據(jù)及邏輯都在美團(tuán)的open-api側(cè)。
再其次，從技術(shù)角度來看，http和服務(wù)化相比缺點(diǎn)更為突出
| item | 優(yōu)點(diǎn) | 缺點(diǎn) | 場(chǎng)景 |
|---|---|---|---|
| HTTP | 簡(jiǎn)單、直接、開發(fā)方便。利用現(xiàn)成的http協(xié)議進(jìn)行傳輸 | 每次通信都要像http一樣去3次握手什么的，減少了網(wǎng)絡(luò)開銷 | 接口不多、系統(tǒng)與系統(tǒng)交互較少的情況下，解決信息孤島初期常使用的一種通信手段 |
| pigeon服務(wù) | 1. 長(zhǎng)鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網(wǎng)絡(luò)開銷； 2. RPC框架一般都有注冊(cè)中心，有豐富的監(jiān)控管理；3. 發(fā)布、下線接口、動(dòng)態(tài)擴(kuò)展等；4. 提供了類似于調(diào)用本地方法一樣調(diào)用接口的功能，對(duì)代碼無侵入； | 需要搭建獨(dú)立的注冊(cè)中心以及監(jiān)控系統(tǒng)，成本效大 | ?大型系統(tǒng)、模塊依賴復(fù)雜 |
