首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

B 站游戏技术平台微服务通用网关实践

1. 背景

随着 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 语言开发的网关系统,常见的有:

· TykTechnologies 提供的:tyk

· Traefixlabs 提供的:traefix proxy

· Eolinker 提供的:goku API Gateway

3. Service Mesh:

· Istio 数据面板,CNCF 项目:Envoy

· CNCF 项目,Linkerd 提供的:Linker2-proxy

4. OpenResty:

· Kong 提供的:Kong Gateway

· Apache 顶级项目:Apache APISIX

结合 B 站游戏业务特点,我们基于以下几点思考最终选择了 Apache APISIX。

· 优异的性能;

· 足够的稳定;

· 非常扩展容易;

· 学习成本低;

· 尽量少的依赖,尽量简洁的架构。

下面将介绍 B 站游戏技术平台是如何使用 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 做了一些定制开发。主要有以下一些内容:

· 增强流量管控功能,实现 Region、Zone 级别的摘、接流控制。

· 增强路由转发功能,新增了”流量单元”概念。

· 新增 API 签名验证功能。

· 增强 grpc 协议转换功能,支持默认路径匹配功能。

· 丰富 prometheus 数据采样,满足我们业务对流量观测需求。

· 增强日志记录能力,默认将日志上报至 Skywalking。

· 增强控制面板,新增服务发现模块。

3.3.3. 与开源社区保持版本同步

APISIX 还在快速迭代升级中,与社区保持版本和功能同步,是非常必要的工作。我们设计了通用网关 git 分支工作流,保持定期同步社区版本。对于我们增加的 一些通用功能,在公司政策允许的情况下,我们也将尝试反馈回社区。

3.3.4. 性能情况

在通用网关上线前,我们对其进行了一系列压测。性能虽和官方数据有一定差距,但也达到了我们设计期望的。

4. 踩过的坑

1. nginx resolve 不会解析本地 Hosts 文件。常见的解决方式是使用 dnsmasq 搭建私有的 DNS 服务。但出于维护成本等角度考虑我们并没有采取这种方式,而是使用调用“curl”命令替代“resty.http”的方案。

2. etcd 出现“etcdserver: mvcc: database space exceeded”异常。第一版的服务发现集成方案(也是官方方案)是每个 nginx work process 都会通过服务发现拉取服务实例信息,而在我们的设计中是会将实例信息写回 etcd 中。 这就会导致 etcd 存在大量的写操作,从而引起该问题。我们最终采用了多级缓存机制避免每个 nginx work process 都会拉取服务实例,同时也对写会操作进行 了优化。

3. APISIX “error-log-logger”插件的异常。APISIX V2.3 版本中,“error-log-logger”插件存在 bug,我们解决了该 bug。社区在新版本中也将这个问题解决了,这里赞一下社区的速度。

5. 总结

在实施过程中遇到一些挑战,但在团队努力下都得到有效的解决。通用网关上线后完美达到我们的设计目标,降低了业务系统的开发复杂度,同时进一步加强了系统的稳定性,鲁棒性。为业务高速发展提供了技术支撑和保障。

6. 后续计划

1. 支持业务系统单元化升级,实现单元化流量治理。

2. 自动化全链路压测。

3. 混沌工程。

4. 一站式 API 全生命周期管理平台。

作者:游戏事业部 技术部 基础架构团队

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/95c80dcb18ebc2c26237868f3
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券