API Gateway演进

问题

从PC时代向移动时代演进, 移动端大量沿用了过去的接口模型. 没有明确的区分内外部服务, 因为缺少统一出口, 逐渐发现了如下问题:

1. 客户端到微服务直接通信,强耦合;内部服务直接对外报漏;微服务重构或由java改go;适配各种端
2. 需要多次请求,客户端聚合数据,工作量巨大,延迟高;我们要前轻后重
3. 协议不利于统一,各个部门间有差异,需要端来兼容
4. 面向端的API适配,耦合到了内部服务
5. 多终端兼容逻辑复杂,每个服务都需要处理
6. 统一逻辑无法收敛,比如安全谁、限流

app-interface

新增了app-interface用于统一的协议出口,在服务内进行大量的数据组装,按照业务场景设计粗粒度的API:

1. 轻量交互:协议精简、聚合
2. 差异服务:数据裁剪以及聚合、针对终端定制化API;安卓需要a字段、ios不需要
3. 动态升级:原有系统兼容升级,更新服务而非协议
4. 沟通效率提升,协作模式深埋为移动业务+网关小组

BFF可以认为是一种适配服务,将后端的微服务进行适配(主要包括聚合裁剪和格式适配等逻辑),向无线端设备暴露友好和统一的API,方便无线设备接入访问后端服务

问题

最致命的一个问题是整个app-interface属于single point of failure,严重代码缺陷或者流量洪峰可能引发集群宕机.

1. 单个模块也会导致后续业务集成复杂度高,根据康威法则,单BFF和多团队之间就出现不匹配问题,团队间沟通协调成本高,交付效率低下
2. 很多跨横切面逻辑,比如安全认证、日志监控、限流熔断等.随着时间的推移,代码变得越来越复杂,技术债务越来越多

API Gateway

跨横切面(Cross-Cutting Concerns)的功能,需要协调更新框架升级发版(路由、认证、限流、安全),因此全部上浮,引入API Gateway,把业务集成度高的BFF层和通用功能服务层API Gateway进行了分层处理

在新的架构中,网关承担了重要的角色,它是解耦拆分和后续升级的利器.在网关的配合下,单块BFF实现了解耦拆分,各业务线团队可以独立开发和交付各自的微服务,研发效率大大提升.另外,把跨横切面逻辑从BFF剥离到网关上去以后,BFF的开发人员可以更加专注业务逻辑交付,实现了架构上的关注分离(Separation of Concerns).

我们的业务流量实际为 移动端-API Gateway- BFF - Microservices,在FE Web业务中, BFF可以是Node.js来做服务端渲染(SSR, Server-Side Rendering), 注意这里忽略了上游的CDN、4/7层负载均衡(SLB)

go-kratos

使用Go语言全新开发了go-kratos,核心考虑可控性、稳定性.控制面目前自定义实现,后续会对齐社区XDS协议,可以使用Istio或者kratos gateway UI进行治理.

BFF目前使用DSL编排View逻辑,当复杂场景无法描述时候可能想一个高级点的语言Typescript,更进一步我们想使用Control Flow Framework + Serverless/FaaS 易于交付的形式解决BFF的问题

API Gateway可用性设计

API Gateway从架构层面来说仍然是单点,类似之间我们SLB的故障.可用性最大的一环是涉及核心组件的变更流程管理,其他的可用性这里基本类似微服务

1. 隔离
2. 超时控制
3. 重试
4. 限流
5. 过载保护
6. 熔断
7. 降级
8. 负载均衡