B站 API 网关的发展

本期作者

▼

如果你在 2015 年就使用 B 站，那么你一定不会忘记那一年 B 站工作日选择性崩溃，周末必然性崩溃的一段时间。也是那一年 B 站投稿量激增，访问量随之成倍上升，而过去的 PHP 全家桶也开始逐渐展露出颓势，运维难、监控难、排查故障难、调用路径深不见底，而也就是在这一年，B 站开始正式用 Go 重构 B 站。

B站第一个 Go 项目：bilizone 由冠冠老师（一个周末）编码完成。

• 代码复杂度高

  方法被滥用、超时设置混乱、牵一发而动全身

• 一挂全挂

  最常见的：超时设置不合理，goroutine 大量堆积，雪崩

• 测试及维护成本高

  小改动都需要测试所有 case，运维发布胆战心惊

• 客户端与微服务直接通信，强耦合
• 需要多次请求，客户端聚合数据，工作量巨大，延迟高。
• 协议不利于统一，各个部门间有差异，反而需要通过客户端来兼容。
• 面向“端”的 API 适配，耦合到了内部服务。
• 多终端兼容逻辑复杂，每个服务都需要处理。
• 统一逻辑无法收敛，比如安全认证、限流。

有了这个 BFF 之后，我们可以在该服务内进行大量的数据聚合，按照业务场景来设计粗粒度的 API，给后续服务的演进带来的很多优势：

• 轻量交互：协议精简、聚合。

• 差异服务：数据裁剪以及聚合、针对终端定制化 API。

• 动态升级：原有系统兼容升级，更新服务而非协议。

• 沟通效率提升，协作模式演进为移动业务和网关小组。

BFF 可以认为是一种适配服务，将后端的微服务为客户端的需要进行适配（主要包括聚合裁剪和格式适配等逻辑），向终端设备暴露友好和统一的 API，方便无线设备接入访问后端服务，在其中可能还伴随有埋点、日志、统计等需求。

这个时期的 BFF 还有一个致命的一个问题是整个 app-interface 属于 single point of failure，严重代码缺陷或者流量洪峰可能引发集群宕机所有接口不可用。于是我们在上述基础上进一步迭代，将 app-interface 进行业务拆分，进而多套 BFF 的模式横空出世：

主站网关组的主要职责就是维护上述各类功能的 BFF 网关，此时 bilibili 的主要流量入口为粉板 App，这里可以简单细说一下粉板 App 上的所有

从多个网关到最后一个统一网关 2022-至今

在这两三年的时间里，各个业务团队或多或少都有自己业务网关组建独立的维护团队，也为网关的功能作出过相当多的投入。但随着 B 站业务的发展，公司级中间件功能的不断更替演进，如果将对接各个中间件的工作在每个网关上都实现一次的话带来的人力投入和沟通成本会相当巨大，且实现标准不统一、运营方式不统一无法起到 API 网关所带来的最佳收益。

因此微服务团队开发了一款 B 站内部意义上的标准 API 网关，该 API 网关汇集以往各型网关中流量治理的优秀经验，对相关功能做出完善设计改进。该 API 网关的目前的主要功能除了常规的限流、熔断、降级、染色外，还会基于这些基础功能和公司各类中间件的基础上，提供了：

• 全链路灰度
• 流量采样分析、回放
• 流量安全控制
• ...

等等进阶型 API 质量治理的相关功能，这些功能业务团队在接入 API 网关后都可以一并获得，为业务的迅速迭代做出力所能及的保障。

• 规划 API 业务域，简化 SRE 运维
• 标准 API 元信息平台
• 精确的 API 文档和调试工具
• 类型安全的 API 集成 SDK
• API 兼容性保障服务

API 网关是我们 API 治理生态中的一个标志性里程碑，我们希望在 API 网关的开发中能够多多倾听大家的意见，希望能有更多的声音来帮助我们理清思路。本次 API 网关也以开源形式进行开发，在这里欢迎大家指导：https://github.com/go-kratos/gateway