API Gateway
在进行了SOA服务化架构演进后,将局势架构按照功能进行了垂直拆分,直接对外暴露一批微服务接口,但是却因为缺乏统一的出口面临一些困难:
- 客户端到微服务直接进行通信,导致强耦合出现—导致随着时间的推移,历史的API需要保留,需要维护历史的API接口
- 一个功能/页面需要多次请求,客户端聚合数据,工作量变得巨大、延迟变高。
- 多服务可能由多部门进行提供,部门之间的接口规范存在差异、协议不利于统一,需要端来兼容。
- 若每一个微服务都直接对外,意味着每一个微服务都需要考虑面向不同的移动端、web端来做API的适配和兼容(apid、安卓版…)。
- 多终端(各个版本的API)兼容逻辑复杂,每个服务都需要处理。
- 统一的逻辑无法进行收敛,例如安全认证、限流。只有对外暴露的"表面积"越少,安全性就越收敛。
因此可以在微服务与内网的SLB之间增加一个app-interface(BFF,Backend for Frontend)用于统一的协议出口,在服务内进行大量的dataset join(区别于以前面向资源的接口,面向用户场景的高效研发,有很多种数据源做返回,最终面向用户场景面向usecase),按照业务场景设计粗粒度的API,给后续服务演进带来更多的优势:
- 轻量级的交互:协议精简、聚合。在面向不同的终端面向不同的网络环境,可能需要做一些协议的裁剪,可以节省流量。
- 差异服务:针对不同的终端要进行定制化的API,进行数据的裁剪和聚合,例如针对电视机、移动端接口是不同的,