活动营销系统迁移（未完待续）

背景

前世

前期点评和美团合并后，业务上为了快速接入美团外卖，双方采用了open-api的形式对接，考虑api对接的原因很多；

1. 公司级的内网没有打通，无法进行服务级别调用，只能走公网；
2. 双方都有对接第三方的open-api的成熟平台；
3. 双方服务化的形式不同，美团为thrift，点评为自研的pigeon(类似dubbo)，两种RPC协议没有打通。
4. 时间紧迫，不能等内网、协议等完全OK后再接入。

选用公网的同时也带来了一系列的缺点（16年5月份完成内网打通，当月接入内网）

1. 公网链路不稳定，受限于当地运营商、�网络提供商等。
2. 内部数据暴露在了公网，有数据泄露的风险。
3. 延时加剧，降低了单台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. 提供了类似于调用本地方法一样调用接口的功能，对代码无侵入；	需要搭建独立的注册中心以及监控系统，成本效大	�大型系统、模块依赖复杂

调研

业务调研

技术调研