02微服务设计

API Gateway

在进行了SOA服务化架构演进后，将局势架构按照功能进行了垂直拆分，直接对外暴露一批微服务接口，但是却因为缺乏统一的出口面临一些困难：

• 客户端到微服务直接进行通信，导致强耦合出现—导致随着时间的推移，历史的API需要保留，需要维护历史的API接口
• 一个功能/页面需要多次请求，客户端聚合数据，工作量变得巨大、延迟变高。
• 多服务可能由多部门进行提供，部门之间的接口规范存在差异、协议不利于统一，需要端来兼容。
• 若每一个微服务都直接对外，意味着每一个微服务都需要考虑面向不同的移动端、web端来做API的适配和兼容(apid、安卓版…)。
• 多终端(各个版本的API)兼容逻辑复杂，每个服务都需要处理。
• 统一的逻辑无法进行收敛，例如安全认证、限流。只有对外暴露的"表面积"越少，安全性就越收敛。

因此可以在微服务与内网的SLB之间增加一个app-interface（BFF，Backend for Frontend）用于统一的协议出口，在服务内进行大量的dataset join(区别于以前面向资源的接口，面向用户场景的高效研发，有很多种数据源做返回，最终面向用户场景面向usecase)，按照业务场景设计粗粒度的API，给后续服务演进带来更多的优势：

• 轻量级的交互：协议精简、聚合。在面向不同的终端面向不同的网络环境，可能需要做一些协议的裁剪，可以节省流量。
• 差异服务：针对不同的终端要进行定制化的API，进行数据的裁剪和聚合，例如针对电视机、移动端接口是不同的，