游戏业务出海：APISIX稳定运营实践

InfoQ · 公众号 · 科技媒体 · 2025-05-07 15:22

正文

请到「今天看啥」查看全文

通过定义开发规范和提供本地快速开发支持，我们有效降低了开发门槛，加速了插件的验证过程。开发人员可以专注于功能实现，而无需担心复杂的部署和测试流程，从而提高了整体开发效率。

3. 流水线建设（构建流程）

在流水线建设过程中，需要保证可靠性和开发插件的稳定性。开发流程如下：

分支管理与 PR 流程 ：

a. 开发人员从 master 分支拉取一个新分支进行开发。

b. 完成开发后，提交 Pull Request（PR）至 master 分支。

Webhook 触发 ：提交 PR 后，系统会自动触发 Webhook，启动流水线。
流水线检测 ：

a. Lint 检查 ：主要检查代码格式规范。

b. 单元测试 ：运行单元测试，验证插件的功能是否符合预期。

c. Try Build ：使用源代码构建镜像，验证代码的可构建性。

4. 可靠性保障（CR、lint、单侧、黑盒测试）

我们使用了 Grafana 旗下的 k6 测试框架进行核心用例的验证。k6 框架支持声明式编写测试用例，可以覆盖多种场景。我们定期回放这些用例，检查接口是否通过。例如，即使只是修改了插件，我们也会进行全面的回放测试，包括解析能力和服务发现能力等。

核心用例与 k6 测试框架

k6 测试用例 ：包含几百个测试用例，覆盖了核心流程，确保插件的可靠性。

通过本地开发、快速验证、MR 提交、流水线检测、可靠性保障以及打包部署的完整流程，我们确保了插件从开发到上线的每个环节都经过严格的质量控制。

二、部署运维

接下来简要介绍 APISIX 的部署模式，分为数据面和控制面。数据面负责实际的代理工作；控制面负责管理配置，包括管理端和其他功能，将配置写入 etcd，数据面从 etcd 读取配置并加载到内存中，完成路由功能。

APISIX 提供了三种部署方式，以适应不同的生产环境需求：

传统模式 ：数据面和控制面同时部署在一个实例中。
分离模式 ：数据面和控制面独立部署，数据面宕机时，控制面仍可操作和修改。
独立模式 ：仅部署数据面，配置从本地 YAML 文件加载，不依赖 etcd。

只保留数据面的独立模式也是我们使用的方式，所有的配置都存储在本地，避免了对 etcd 的依赖。这种模式更适用于海外场景。由于 etcd 属于数据库选型，部分云厂商不提供 etcd 服务，且海外对数据合规性要求严格，并且我们的部署环境在 k8s，因此也采用了对 k8s 友好的配置管理方式。

YAML 配置 ：所有配置直接存储在 YAML 文件中，便于管理和自动化部署。
ConfigMap 存储 ：将 yaml 文件直接放置在 k8s 的 ConfigMap 中，确保配置的版本化和可追溯性。

我们定义网关为不可变基础设施，日常运营中不会进行频繁的变更。即使是路由变更，也被视为一次完整的变更操作。

Kubernetes 配置管理与部署实践

问题描述 ：在管理 config.yaml 时，我们发现 k8s 的部署实际上依赖于一系列复杂的配置文件，例如 Service.yaml、ConfigMap.yaml 和 Workload 等。这些配置文件数量庞大且细节繁多，容易导致管理上的复杂性和错误。

解决方案 ： K8 s 社区提出 Helm Chart 作为解决方案。Helm Chart 是一种将 k 8 s 配置文件模板化的工具，能够显著简化配置管理。APISIX 官方提供了 Helm Chart，助力我们高效管理核心配置（如节点数等），无需手动填写大量 YAML 文件。目前，Helm Chart 已有效解决配置复杂性问题。

衍生问题 ：然而，衍生出来的另一个关键问题是：如何将 Helm Chart 或 YAML 文件部署到 k 8 s 集群上。

解决方案 ：为此，我们采用了 GitOps 模式，通过流水线将 YAML 文件部署到 K8 s 集群。在 GitOps 模式下，所有配置以代码形式存储在 Git 中。借助 Git 触发 CI/CD 流程，实现自动化部署。config.yaml 和其他配置文件均存储在 Git 中，确保了配置的版本化管理和可追溯性。通过这种方式，我们不仅简化了配置管理，还实现了部署流程的自动化和标准化，提升了整体效率和可靠性。