背景
前世
前期点评和美团合并后，业务上为了快速接入美团外卖，双方采用了open-api的形式对接，考虑api对接的原因很多；
- 公司级的内网没有打通，无法进行服务级别调用，只能走公网；
- 双方都有对接第三方的open-api的成熟平台；
- 双方服务化的形式不同，美团为thrift，点评为自研的pigeon(类似dubbo)，两种RPC协议没有打通。
- 时间紧迫，不能等内网、协议等完全OK后再接入。
选用公网的同时也带来了一系列的缺点（16年5月份完成内网打通，当月接入内网）
- 公网链路不稳定，受限于当地运营商、�网络提供商等。
- 内部数据暴露在了公网，有数据泄露的风险。
- 延时加剧，降低了单台web服务的吞吐量，服务的SLA相关数据不容乐观。
今生
从公司合并到现在已一年多，很多基础设施以及中间件已趋于融合，内网打通、rpc协议打通、通用中间件统一（MQ，cache，SLB）以及很多基础服务都已两地部署。
为什么现有架构不可延续？
首先，美团外卖的open-api是直接提供给客户端以及h5调用，点评侧服务通过httpclient来调用美团的open-api显得层级关系概念有些紊乱。同时面向客户端及前端的api，但显然在架构上不在同一层级。
其次，无法定制化点评侧的业务逻辑，通过美团的open-api，很多点评独有的需求逻辑无法由点评侧完成，数据及逻辑都在美团的open-api侧。
再其次，从技术角度来看，http和服务化相比缺点更为突出
| item | 优点 | 缺点 | 场景 |
|---|---|---|---|
| HTTP | 简单、直接、开发方便。利用现成的http协议进行传输 | 每次通信都要像http一样去3次握手什么的，减少了网络开销 | 接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段 |
| pigeon服务 | 1. 长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销； 2. RPC框架一般都有注册中心，有丰富的监控管理；3. 发布、下线接口、动态扩展等；4. 提供了类似于调用本地方法一样调用接口的功能，对代码无侵入； | 需要搭建独立的注册中心以及监控系统，成本效大 | �大型系统、模块依赖复杂 |
