周佳辉-B站大规模 API Gateway 的设计与最佳实践.pdf

《周佳辉-B站大规模 API Gateway 的设计与最佳实践.pdf》由会员分享，可在线阅读，更多相关《周佳辉-B站大规模 API Gateway 的设计与最佳实践.pdf（33页珍藏版）》请在三个皮匠报告上搜索。

1、b 站大规模 API 网关的设计与最佳实践主讲人：周佳辉领域驱动设计启发下的AI视觉分析引擎构建主讲人：戴 昊演讲嘉宾介绍周佳辉 哔哩哔哩资深开发工程师2017 年加入 B 站，先后从事账号、网关、基础框架等开发工作开源社区爱好者安全技术爱好者云计算行业活跃用户始终以简单为核心设计理念追求极致简单有效的后端架构目录CONTENTSAPI 网关的历史背景123新一代 API 网关的设计与使用真实流量下的API 网关4API 网关与 API 标准化API 网关的历史背景1说在全站 PHP 岌岌可危之时第一次微服务化重构-SOA这是 b 站的第一次向微服务架构演进按垂直功能进行拆分这些微服务对外暴露

2、接口但因缺乏统一出口，也遇到了不少困难：客户端直接调用微服务，强耦合需要多次请求，客户端聚合数据，工作量巨大协议不利于统一，各个部门间有不少差异面向“端”的 API 适配，耦合到了内部服务多终端兼容逻辑复杂，每个服务都需要处理统一逻辑无法收敛，比如安全认证、限流网关演进 BFF 1.0我们新增了一个 app-interface 用于统一的协议出口，在服务内进行大量的 dataset join，按照业务场景来设计粗粒度的 API，给后续服务的演进带来的很多优势：轻量交互：协议精简、聚合；差异服务：数据裁剪以及聚合、针对终端定制化 API动态升级：原有系统兼容升级，更新服务而非协议沟通效率提升：协

3、作模式演进为移动业务+网关小组BFF 可以认为是一种适配服务，将后端的微服务进行适配，主要包括聚合裁剪和格式适配等逻辑，向无线端设备暴露友好和统一的 API。网关演进 BFF 2.0BFF 1.0 最致命的问题是整个 app-interface 属于 single point of failure，严重代码缺陷或者流量洪峰可能引发集群宕机。单个模块也会导致后续业务集成复杂度高，根据康威法则，单块的 BFF 和多团队之间就出现不匹配问题，团队之间沟通协调成本高，交付效率低下很多跨横切面逻辑，比如安全认证，日志监控，限流熔断等。随着时间的推移，代码变得越来越复杂，技术债越堆越多网关演进 API G

4、ateway将跨横切面（Cross-Cutting Concerns）的功能（路由、认证、限流、安全）全部上移，引入了 API Gateway。将重业务逻辑的 BFF 层和通用服务层 API Gateway 进行分离。API 网关和 BFF 配合，解耦了客户端和微服务，各业务团队可以独立开发交付新功能，研发效率大大提升。另外，把跨横切面逻辑从 BFF 剥离至 API 网关后，BFF 的开发人员可以更加专注业务逻辑交付，实现架构上关注分离（Separation of Concerns）。我们业务流量实际为：客户端-API Gateway-BFF-Microservices。在 FE Web 业务

5、中，BFF 可以是 Node.js 来做服务端渲染（Server-Side Rendering），注意这里忽略了上游的 CDN、4/7层负载均衡（SLB）。新一代 API 网关的设计与使用2目录CONTENTSAPI 网关的设计目标API 元信息管理统一管理、生命周期、文档、调试、IDL、OpenAPI、SDK流量调度路由、调度、多活、染色灰度、流量复制隔离保护限流、熔断、降级、缓存访问控制统一鉴权、跨域、风控可观测性QPS、Latency、SLA、日志、统一运维视角API 网关的技术选型Nginx/OpenRestyEnvoy+XDS自研 Go核心优势社区支持比较丰富云原生方案主导可灵活集成

6、内部系统Trace 能力通过开发通过日志实现支持支持扩展方式通过模块或 LuaXDS 或 C+直接利用 kratos 框架内部开发者多监控原生指标比较少需要开发原生指标比较少需要开发可按需开发健康检查原生功能较弱支持支持LB 算法WRR，HashP2C、LRP2C、WRRAPI 网关的整体架构API 网关的部署现状40+40+集群集群230+230+接口分组接口分组8300+8300+接口接口日调用量日调用量1010万亿万亿+API 生命周期管理API 网关的配置管理配置是 API 网关的重要运行时依据，我们通过以下手段保证配置的高可用：通过 Git Repo 保存最新的配置，并在构建镜像时同