随着B站游戏业务持续快速发展，对业务系统的稳定性和快速迭代能力提出了更高的要求。 因此，我们对游戏技术平台进行了技术升级和改造，引入了微服务架构。
众所周知，在微服务架构体系下，应用程序按照业务或功能模块划分为独立的小型服务，可以独立部署、升级和替换。 这些服务可以根据业务特点使用不同的语言和协议来构建，大大增强了业务开发的灵活性。 但同时我们也会面临很多问题，例如服务接入、分布式事务、微服务划分等。本文主要关注微服务架构下服务如何对外提供服务。
在游戏业务场景中，这个问题具体体现为：游戏客户端如何与后端业务微服务通信？ 如果游戏客户端直接与各个微服务通信，我们将面临以下挑战：
·微服务的通信协议有多种，游戏客户端需要支持多种协议。
·游戏客户端接入的成本和复杂度急剧增加。
·每个微服务需要实现过载保护、身份验证、接口签名验证、灰度发布等常用功能。
为了解决上述挑战，我们引入了位于游戏客户端和微服务之间的中间层。 它为底层微服务API提供单一入口，充当微服务的反向代理服务，即微服务的通用网关。
2. 目标
结合游戏业务的特点，比如对延迟敏感、经常出现流量高峰等，我们也希望降低游戏接入的复杂度； 因此，我们的微服务通用网关应该具备以下能力：
·接入成本足够低，甚至零成本接入。
·高性能、高稳定性。
·支持多种协议。
·支持协议转换。
·支持复杂路由策略、过载保护、断路器降级、灰度发布、身份验证、接口签名验证等功能。
·完善的监控系统。
3、解决方案
自己从头开始研究还是依靠开源社区的力量？
B站游戏技术平台是一个开放、务实的团队。 与其完全重新发明轮子，我们更愿意依靠社区的力量，与社区一起共建。 并且开源社区中有很多成熟度较高、社区活跃的网关系统。 因此，我们决定借助开源社区项目来构建微服务的通用网关。
3.1. 技术选型
对于流量网关技术选型，目前有很多开源解决方案。 根据技术体系，大致可分为以下四类：
1. Spring Cloud：在Java生态中，Spring Cloud系统提供了网关组件：
·Netflix 贡献：ZUUL1.x、ZUUL2.x 系列
·Spring官方维护：Spring Cloud Gateway
2、Golang：目前在开源社区橙光游戏，有很多针对Golang语言开发的网关系统。 常见的包括：
·泰克科技提供：tyk
·Traefixlabs提供：traefix proxy
·Elinker提供：悟空API网关
3.服务网格：
·Istio数据面板，CNCF项目：Envoy
·CNCF项目，Linkerd提供：Linker2-proxy
4.打开Resty：
·Kong提供：Kong Gateway
·Apache顶级项目：Apache APISIX
结合B站游戏业务的特点，基于以下考虑，我们最终选择了Apache APISIX。
·完美的表现;
·足够的稳定性；
·非常容易扩展；
·学习成本低；
·尽可能少的依赖关系和尽可能简单的架构。
下面将介绍Bilibili游戏技术平台如何使用Apache APISIX构建通用网关。
3.2. 架构设计
我们先看一下基于Apache APISIX的通用网关架构设计：
通过网关的架构足够简单，只有对etcd的强依赖。 还支持基于Prometheus+Grafana的服务状态监控以及基于Skywalking的全链路监控系统。 简单的架构降低了服务运维成本，完善的监控体系提高了服务的可观察性。
接下来我们将介绍基于APISIX的通用网关系统的实现过程以及对APISIX所做的增强，以及实现过程中遇到的一些坑。
3.3. 实施过程3.3.1。 与现有基础服务集成
这部分我们主要有两个任务：对接现有的服务发现系统以及集成CI/CD工具。 通过连接现有的服务发现系统，配合我们现在的容器环境，通用网关就可以具备发现上游微服务的能力。 集成CI/CD系统后，可以实现通用网关快速升级和发布的需求。
1.连接现有的“服务发现”系统
我们的接入服务发现接入解决方案具有以下特点，提高了服务发现的效率和稳定性，同时降低了接入的成本和复杂度。
·多级缓存机制。
· 微服务节点信息的可观测性。
·动态拉取和自刷新机制。
2. 集成CI/CD工具
为了更好地支撑通用网关快速升级和发布的需求，我们主要做了以下两项工作。 实现业务一键编译、一键发布/回滚等功能。
·定制APISIX的编译和运行环境。
·基于公司现有CI/CD工具优化编译/发布流程。
3.3.2. 神奇修改APISIX
为了满足我们的业务需求，我们基于APISIX做了一些定制开发。 主要包括以下内容：
·增强流量管理和控制功能，实现区域级提取和连接控制。
·增强路由转发功能，增加“流量单元”概念。
·新增API签名验证功能。
·增强grpc协议转换功能，支持默认路径匹配功能。
·丰富prometheus数据采样，满足我们对流量观测的业务需求。
·增强日志记录功能游戏网关开发，默认将日志报告给Skywalking。
·增强控制面板并添加新的服务发现模块。
3.3.3. 保持版本与开源社区同步
APISIX仍在快速迭代升级，保持版本和功能与社区同步非常有必要。 我们设计了通用网关git分支工作流程来维护社区版本的定期同步。 对于我们添加的一些通用功能，如果公司政策允许，我们也会尝试反馈给社区。
3.3.4. 表现
在通用网关上线之前，我们对其进行了一系列的压力测试。 虽然性能与官方数据存在一定差距，但也符合我们的设计预期。
4. 踩过的坑
1.nginx解析不会解析本地Hosts文件。 常见的解决方案是使用 dnsmasq 构建私有 DNS 服务。 但出于维护成本等考虑，我们没有采用这种方式。 相反，我们使用了调用“curl”命令而不是“resty.http”的解决方案。
2、etcd出现“etcdserver: mvcc:数据库空间超出”异常。 第一个版本的服务发现集成方案（也是官方的方案）是每个nginx工作进程都会通过服务发现拉取服务实例信息人物立绘，而在我们的设计中，实例信息会被写回到etcd中。 这样就会导致etcd中出现大量的写操作，从而导致这个问题。 我们最终采用了多级缓存机制来防止每个nginx工作进程拉取服务实例，并且还优化了写入操作。
3.APISIX“error-log-logger”插件异常。 在APISIX V2.3版本中，“error-log-logger”插件存在一个bug，我们已经解决了该bug。 社区在新版本中也解决了这个问题。 我要赞扬社区的速度。
5. 总结
实施过程中遇到了一些挑战，但通过团队努力得到了有效解决。 通用网关上线后，完美实现了我们的设计目标，降低了业务系统的开发复杂度，进一步增强了系统的稳定性和健壮性。 为业务的快速发展提供了技术支持和保障。
六、后续计划
1、支持业务系统的统一升级游戏网关开发，实现流量的统一管理。
2、自动化全链路压测。
3.混沌工程。
4.一站式API生命周期管理平台。
