关于微服务:长连接网关技术专题八B站基于微服务的API网关从0到1的演进之路

本文由 B 站微服务技术团队资深开发工程师周佳辉原创分享。

1、引言

如果你在 2015 年就应用 B 站，那么你肯定不会遗记那一年 B 站工作日选择性解体，周末偶然性解体的一段时间。

也是那一年 B 站投稿量激增，访问量随之成倍回升，而过来的 PHP 全家桶也开始逐步展露出颓势，运维难、监控难、排查故障难、调用门路深不见底。

也就是在这一年，B 站开始正式用 Go 重构 B 站，从此 B 站的 API 网关技术子开始了从 0 到 1 的继续演进。。。

• 补充阐明：本次 API 网关演进也以开源模式进行了开发，源码详见本文“12、本文源码”。

PS：本文分享的 API 网关波及到的次要是 HTTP 短连贯，尽管跟长连贯技术有些差别，但从架构设计思路和实际上是一脉相承的，所以也就收录到了本《长连贯网关技术专题》系列文章中。

学习交换：

• 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
• 开源 IM 框架源码：https://github.com/JackJiang2…（备用地址点此）

（本文已同步公布于：http://www.52im.net/thread-39…）

2、对于作者

周佳辉：哔哩哔哩资深开发工程师。始终以简略为外围的技术设计理念，谋求极致简略无效的后端架构。

2017 年退出 B 站，先后从事账号、网关、根底库等开发工作。编码 C/V 技能传授者，技术文档背诵者。开源社区爱好者，平安技术爱好者，云计算行业沉闷用户，网络工程熟练工。史诗级 bug 生产者，熟练掌握 bug 产生的各类场景。

3、专题目录

本文是专题系列文章的第 8 篇，总目录如下：

《长连贯网关技术专题 (一)：京东京麦的生产级 TCP 网关技术实际总结》
《长连贯网关技术专题 (二)：知乎千万级并发的高性能长连贯网关技术实际》
《长连贯网关技术专题 (三)：手淘亿级挪动端接入层网关的技术演进之路》
《长连贯网关技术专题 (四)：爱奇艺 WebSocket 实时推送网关技术实际》
《长连贯网关技术专题 (五)：喜马拉雅自研亿级 API 网关技术实际》
《长连贯网关技术专题 (六)：石墨文档单机 50 万 WebSocket 长连贯架构实际》
《长连贯网关技术专题 (七)：小米小爱单机 120 万长连贯接入层的架构演进》
《长连贯网关技术专题 (八)：B 站基于微服务的 API 网关从 0 到 1 的演进之路》（* 本文）

4、正式用 Go 重构 B 站

鉴于引言中所列举的各种技术问题，也是在 2015 年，财队开始正式用 Go 重构 B 站。

B 站第一个 Go 我的项目——bilizone，由冠冠老师（郝冠伟）花了一个周末工夫编码实现。

commit 4ccb1497ca6d94cec0ea1b2555dd1859e6f4f223
Author: felixhao <g[url=mailto:1@gmail.com]1@gmail.com[/url]>
Date: Wed Jul 1 18:55:00 2015 +0800

project init

commit 6e338bc0ee638621e01918adb183747cf2a9e567
Author: 郝冠伟 <h*@bilibili.com>
Date: Wed Jul 1 11:21:18 2015 +0800

readme

▲ 郝冠伟：哔哩哔哩主站技术核心架构师
bilizone 其实还是一个大而全的利用，bilizone 在过后重构的次要意义是将谁也理不清的 PHP 逻辑梳理成了一个比拟规范的 Go 利用。

bilizone 在过后最大的意义就是为用户终端提供了根本稳固的数据结构、绝对牢靠的接口和比拟无效的监控。

但因 bilizone 仍旧是一个单体利用，所以它仍旧继承了单体利用所具备的毛病：

1）代码复杂度高：办法被滥用、超时设置凌乱、牵一发而动全身；
2）一挂全挂：最常见的比方，超时设置不合理、goroutine 大量沉积、雪崩；
3）测试及保护老本高：小改变都须要测试所有 case，运维公布胆战心惊。

所以此时 B 站的解体频率尽管曾经有所升高，但一炸全炸的问题仍旧是一个心腹大患。

5、基于微服务的 B 站架构初具雏形

鉴于 bilizone 所面临的单体利用技术毛病，接下来的一次重构，让 B 站基于微服务的全局架构风貌就将初具雏形。

为了实现微服务模式下的 bilibili，咱们将一个 bilizone 利用拆分成多个独立业务利用，如账号、稿件、广告等等，这些业务通过 SLB 间接对外提供 API。

过后的调用模式如下图所示：

然而随着性能拆分后，咱们对外裸露了一批微服务，然而因为不足对立的进口而面临了不少艰难。

这些艰难次要是：

1）客户端与微服务间接通信，强耦合；
2）须要屡次申请，客户端聚合数据，工作量微小，提早高；
3）协定不利于对立，各个部门间有差别，反而须要通过客户端来兼容；
4）面向“端”的 API 适配，耦合到了外部服务；
5）多终端兼容逻辑简单，每个服务都须要解决；
6）对立逻辑无奈收敛，比方平安认证、限流。

6、基于 BFF 模式的微服务架构

基于上节的初阶微服务架构带来的技术问题，以及咱们想要将对端的解决进行内聚的想法，咱们天然的而然的就想到在客户端与后端服务之间加一个 app-interface 的组件，这就是接下来的 BFF（Backend for Frontend）模式。

app-interface 的工作模式如下图所示：

有了这个 BFF 之后，咱们能够在该服务内进行大量的数据聚合，依照业务场景来设计粗粒度的 API。

这样，后续服务的演进也带来了很多劣势：

1）轻量交互：协定精简、聚合；
2）差别服务：数据裁剪以及聚合、针对终端定制化 API；
3）动静降级：原有零碎兼容降级，更新服务而非协定；
4）沟通效率晋升：合作模式演进为挪动业务和网关小组。

BFF 能够认为是一种适配服务，将后端的微服务为客户端的须要进行适配（次要包含聚合裁剪和格局适配等逻辑），向终端设备裸露敌对和对立的 API，不便无线设施接入拜访后端服务，在其中可能还随同有埋点、日志、统计等需要。

然而，这个期间的 BFF 还有一个致命的一个问题是——整个 app-interface 属于 single point of failure，重大代码缺点或者流量洪峰可能引发集群宕机所有接口不可用。

7、基于多套 BFF 模式的微服务架构

针对上节中 BFF 模式下架构的技术问题，于是咱们在上述根底上进一步迭代，将 app-interface 进行业务拆分。

进而多套 BFF 的模式横空出世：

由此模式开始，根本确定了 B 站微服务接口的对接模式，这套模式也随之在全公司内推广开来。

8、垂直 BFF 模式时代（2016 年至 2019 年）

接上节，当 B 站网关的架构倒退为多套垂直 BFF 之后，开发团队围绕该模式安稳迭代了相当长的一段时间。

而后随着 B 站业务的倒退，团队人员的裁减和几次组织架构调整，此时开始呈现直播、电商等独立业务，这些业务的倒退咱们之后再细说。

而在这些调整之后，有一个团队的职责越来越清晰：主站网关组。

主站网关组的主要职责就是保护上述各类性能的 BFF 网关，此时 bilibili 的次要流量入口为粉板 App。这里能够简略细说一下粉板 App 上的所有业务组成。

主站业务：

1）网关组保护的 BFF，如举荐、稿件播放页等；
2）业务层自行保护的 BFF，如评论、弹幕、账号等。

独立业务：

1）电商服务；
2）直播服务；
3）动静服务。

主站业务的 BFF 其实被分为两类：

1）一类是由网关组负责的 BFF；
2）另一类是业务自行保护的 BFF。

而这两类 BFF 的技术栈其实基本一致，基本功能职责也相差不多。如此划分的起因是让网关组能够更专一于迭代客户端个性性能，免去了解局部独立业务场景的接口，如登陆页应该让对平安更业余账号的同学自行保护。

在这里咱们也能够简述一下，一个新需要应该如何决定参加的 BFF：

1）如果这个性能能由业务层的业务 BFF 独立实现，则网关组不需染指；
2）如果该性能是一个客户端个性需要，如举荐流等复合型业务，须要对接公司大量部门时，则由网关同学参加开发 BFF。

过后主站技术部的后端同学遵循以上两个规定，根本可能满足业务的疾速开发和迭代。

我把这段时间称为垂直 BFF 时代，因为根本主站每个业务或多或少都有各种模式的网关存在，大家通过这个网关向外提供接口，该网关和 SLB 进行间接交互。

9、基于业务的对立 API 网关架构

接上节，咱们再来谈一谈几项重要的业务：电商、直播和动静。

电商和直播其实并不是同一期间衍生的，直播在主站 PHP 期间就诞生了，而电商绝对更晚一些。

过后直播的技术栈组成有 C++、PHP、Go，其中晚期大部分业务逻辑由 PHP 和 C++ 实现，稍晚一些也开始逐渐试用主站的 Go 实现局部业务逻辑。其中 PHP 负责对终端提供接口，C++ 次要实现外围业务性能。因而咱们能够简略了解为直播应用由 PHP 编写的 BFF 网关。

动静团队其实派生自直播团队，因而技术栈和直播过后基本一致，这里能够简略省略。

而家喻户晓，大部分电商团队的技术栈都是 Java 和 Spring 或 Dubbo。

因这几个业务实现上简直没有类似的中央，且大家对 gRPC 协定逐步地认同，因而技术栈上大家根本没有大一统的想法，相互能调通即可。

而随着 B 站团队进一步的壮大、流量继续的增长，进而经验了诸多线上故障、事变剖析之后，大家缓缓发现了这套架构下的各种问题。

这些问题次要是：

1）单个简单模块也会导致后续业务集成的高难度，依据康威法令，简单聚合型 BFF 和多团队之间就呈现不匹配问题，团队之间沟通协调老本高，交付效率低下；
2）很多跨横切面逻辑，比方平安认证，日志监控，限流熔断等。随着工夫的推移，性能的迭代，代码变得越来越简单，技术债越堆越多。

此时：咱们可能还须要一个能协调横跨切面的组件，将路由、认证、限流、平安等组件全副上提，可能对立更新公布，把业务集成度高的 BFF 层和通用性能服务层进行分层，进而大家开始引入基于业务的“对立 API 网关”架构（如下图所示）。

在新的架构中：对立网关承当了重要的角色，它是解耦拆分和后续降级迁徙的利器。

在对立网关的配合下：单块 BFF 实现理解耦拆分，各业务线团队能够独立开发和交付各自的微服务，研发效率大大晋升。

另外：把跨横切面逻辑从 BFF 剥离到网关下来当前，BFF 的开发人员能够更加专一业务逻辑交付，实现了架构上的关注拆散（Separation of Concerns）。

10、从基于业务的多网关到全局对立网关（2022 年至今）

在这两三年的工夫里，各个业务团队或多或少都有本人业务网关组建独立的保护团队，也为网关的性能作出过相当多的投入。

但随着 B 站业务的倒退，公司级中间件性能的一直更替演进，如果将对接各个中间件的工作在每个网关上都实现一次的话带来的人力投入和沟通老本会相当微小，且实现规范不对立、经营形式不对立无奈起到 API 网关所带来的最佳收益。

因而微服务团队开发了一款 B 站外部意义上的规范 API 网关（全局对立 API 网关），该 API 网关会集以往各型网关中流量治理的优良教训，对相干性能做出欠缺设计改良。

该 API 网关的目前的次要性能除了惯例的限流、熔断、降级、染色外，还会基于这些根底性能和公司各类中间件的根底上，提供各种额定能力。

这些额定进阶型 AP 品质治理的相干性能次要是：

1）全链路灰度；
2）流量采样剖析、回放；
3）流量安全控制；
…

业务团队在接入 API 网关后都能够一并取得这些性能，为业务的迅速迭代做出力不从心的保障。

11、不仅仅是 API 网关

在开发 API 网关的同时，咱们也会更进一步关注业务团队开发、对接 API 时的体验，咱们将以网关作为统一标准 API 标准的终点，为业务团队提供更无效的 API 开发生态。

这些 API 开发生态可能是：

1）布局 API 业务域，简化 SRE 运维；
2）规范 API 元信息平台；
3）准确的 API 文档和调试工具；
4）类型平安的 API 集成 SDK；
5）API 兼容性保障服务。

API 网关是咱们 API 治理生态中的一个标志性里程碑，咱们心愿在 API 网关的开发中可能多多聆听大家的意见，心愿能有更多的声音来帮忙咱们理清思路。

本次 API 网关演进也以开源模式进行了开发，在这里欢送大家领导（本次源码详见本文“12、本文源码”）。

12、本文源码

主地址：https://github.com/go-kratos/…
备地址：https://github.com/52im/gateway
或从原文链接中下载附件：http://www.52im.net/thread-39…

13、参考资料

[1] 喜马拉雅自研亿级 API 网关技术实际
[2] 手淘亿级挪动端接入层网关的技术演进之路
[3] 从 100 到 1000 万高并发的架构演进之路
[4] 一文读懂大型分布式系统设计的方方面面
[5] 零根底了解大型分布式架构的演进历史、技术原理、最佳实际

（本文已同步公布于：http://www.52im.net/thread-39…）