火山引擎 A/B 测试私有化实践

动手点关注 干货不迷路 👆

作为一款面向 ToB 市场的产品——火山引擎 A/B 测试（DataTester）为了满足客户对数据安全、合规问题等需求，探索私有化部署是产品无法绕开的一条路。

在面向 ToB 客户私有化的实际落地中，火山引擎 A/B 测试（DataTester）也遇到了字节内部服务和企业 SaaS 服务都不容易遇到的问题。在解决这些问题的落地实践中，火山引擎 A/B 测试团队沉淀了一些流程管理、性能优化等方面的经验。

本文主要分享火山引擎 A/B 测试当前的私有化架构，遇到的主要问题以及从业务角度出发的解决思路。

火山引擎 A/B 测试私有化架构

架构图

整套系统采用 Ansible+Bash 的方式构建，为了适应私有化小集群部署，既允许各实例对等部署，复用资源，实现最小三节点交付的目标,，又可以做在线、离线资源隔离提高集群稳定性。集群内可以划分为三部分：

1. 业务服务: 主要是直接向用户提供界面或者功能服务的, 例如实验管理、实验报告、OpenAPI、数据接入等。

2. 基础服务: 不直接面向用户,为上层服务的运行提供支撑,例如支持实验报告的计算引擎、为指标创建提供元信息的元信息服务;基础服务同时还会充当一层对基础设施的适配,用来屏蔽基础设施在 SaaS 和私有化上的差异, 例如 SaaS 采用的实时+离线的 Lambda 架构, 私有化为了减少资源开销,适应中小集群部署只保留实时部分, 计算引擎服务向上层屏蔽了这一差异。

3. 基础设施: 内部团队提供统一私有化基础设施底座 minibase,采用宿主机和 k8s 结合的部署方式,由 minibase 适配底层操作系统和硬件, 上层业务直接对接 minibase。

私有化带来的挑战

挑战 1：版本管理

传统 SaaS 服务只需要部署维护一套产品供全部客户使用，因此产品只需要针对单个或几个服务更新，快速上线一个版本特性，而不需要考虑从零开始搭建一套产品。SaaS 服务的版本发布周期往往以周为单位，保持每周 1-2 个版本更新频率。

但是，在私有化交付中，我们需要确定一个基线版本并且绑定每个服务的小版本号以确保相同版本下每套环境中的交付物等价，以减轻后续升级运维成本。通常，基线版本的发布周期往往以双月为单位。