TTChat 是趣丸科技（TT 语音）旗下的一款针对海外用户的游戏社交产品，包含实时语聊房、IM、开黑交友、赛事等一系列业务场景。团队对云原生技术非常推崇，加之在国内的 TT 语音产品上也有了一定的相关技术探索与积累，所以在新业务创立之初，我们就全面使用了 Kubernetes 与 Istio 进行服务治理。

本文作者：吴畏  TTChat 技术负责人 @趣丸

回望过去

起初在团队规模较小的时候，我们简单使用 GitLab CI 搭建了流水线，实现完全容器化的构建和部署，维护了开发与生产两套环境。经过了一年多的产品迭代，团队“创造”出了近两百个微服务，也因为团队规模变多，不断产生出了协作问题，比如多分支开发与单一共享环境经常引起的服务覆盖问题、缺少不同功能的环境以便提供给不同角色的人使用等等。这就催生出了多套环境的需求，面对如此多的服务，亟需一个合适的工具/平台来帮助我们快速地“复制”多套新环境出来，正当我们一筹莫展的时候，我们看到了号称具有「强大的云原生多环境能力」的 Zadig。

共创之路

从去年的 10 月开始，我们开始尝试进行 Zadig 的接入，彼时 Zadig 在使用 Kubernetes YAML 来管理与部署服务时，能够很好的工作，而对于我们所使用 Helm Chart，却仍然处于一个很初级的阶段，加上我们自身对于 Helm Chart 使用姿势不佳，导致在接入的过程中也遇到了许多困难。通过与 Zadig 团队多次在广沪两地的面对面交流和思想碰撞，打磨出了不少针对 Helm Chart 场景的需求点。

Zadig 团队也逐渐丰富了 Helm Chart 场景的支持，我简单列一些我认为非常能够体现 Zadig「强大的云原生多环境能力」的功能点：

环境全局变量

通过该能力，我们可以结合自己的 Helm Chart 模板，为所有服务提供环境级别的 Values 覆盖，例如：

• 挂载公共配置至所有的 Pod 中，如特性开关配置、业务区域配置

• Istio Virtual Service 中的 Gateway、Host 配置

• 全局生效的环境变量

• 全局注入的 annotations

环境配置

这个目前我们通常是结合环境全局变量一起来使用的，比如用它来托管公共配置（前面提到的特性开关配置、业务区域配置等），也可以用来管理一些不适合放在服务配置中的敏感信息（如密码、证书）等。

环境复制

我们从 Git 中导入的 Helm Values，其中所包含镜像很可能是不可用的，或是一个非常古早的版本，早期通过创建环境，经常面临的问题就是服务无法启动，或是某个服务版本过旧，无法正常工作，当时的做法是在环境创建之后，立刻运行一个工作流，对所有的服务进行重新构建，这无疑是非常消耗时间和构建资源的。环境复制功能则通过直接复制一个现有的稳定环境，从而实现快速构建新环境并且能直接投入使用，切实解决了痛点。

基于这些环境能力，我们现在能够在短短的一二十分钟内，快速地建立起一套拥有几百个服务的全新环境。

除了环境能力，我们在和 Zadig 的接入过程中也解决了不少非常痛的问题：

从 Git 中批量导入：

对于拥有几百个存量服务业务来说，这项功能极大程度解放了双手，最终我们可以顺利地在短短的十几分钟内，完成所有服务的导入。可以说这是我们能够坚持下来的一个重要原因。

服务编排：

通过管理服务的启动顺序，这项能力帮助我们有效地解决了服务部署时对配置、密钥等强依赖的问题。此外，还可以使用 Zadig 托管部署测试环境的数据库、Redis 等进行一些初始数据的导入工作，这也是我们计划中但一直还没来得及做的事情。

落地与探索

在业务交付过程中，不同角色的人员对环境有着不同的诉求，例如开发人员需要一个统一的环境进行集成、联调，测试人员需要一个独立稳定的环境用于功能测试、验收、实施自动化测试。

我们期望能够结合 Zadig 的多环境管理以及可定制化的 Workflow，非常快速地拉起一套完整的环境，并且尽可能实现自动化，这也是云原生文化所非常倡导的价值观之一。因此除了托管常规的服务之外，我们也用 Zadig 托管了很多环境所依赖的底层资源：

• 环境启动所依赖的 ConfigMaps、Secrets

• 提供访问入口配置的 Istio Gateway CR

• 用于自动化生成 TLS 证书的 Certificate CR（结合 CertManager & Let's Encrypt）

在 TTChat 主项目中，由于服务数量较多，存在一定的环境维护成本，我们使用 Zadig 管理了 dev 和 qa 两套标准环境。

下图以 Zadig 为界分为了两个部分，上半部分是业务运行时的一个视角，我们在业务架构上面使用了 istio-ingressgateway 作为七层网关对 TTChat App 提供了 HTTP/2 和 HTTP/3 的接入能力，因此使用了不同的域名将流量路由到不同的环境中（PS：图中域名为示例）；

下半部分则描绘了我们现阶段在交付中，从代码提交或者合并触发工作流，然后部署到两套环境中的过程。图中的红色区域的自测环境是我们目前基于 Zadig 新发布的子环境能力进行的一项新的尝试，希望能够给研发人员提供更加好的开发体验。

目前我们一共有六个活跃的项目运行在了 Zadig 之上，共计管理了 16 套开发 &测试环境，近 300 个服务，每周进行数百次的构建部署，构建成功率 >96%，自接入以来累计产生的交付物 12000 多个，部署 20000 余次。

期待与展望

Zadig 作为完整的持续交付方案，我们团队目前只发挥了它不到 50% 的有效价值；现今，团队正在进行主干开发与主干发布的尝试，我们也希望发挥 Zadig 的「测试管理」这一差异化价值，结合自身的自动化测试建设，能够实现更加顺畅的持续交付。

另外，最近的几个版本中，出现了一些基于 Service Mesh 的非常有意思的新功能，比如运行部分服务的环境、自测（沙盒）环境。可以看到，经过了半年，我们所期待的一些饼都逐一实现出来了，这些功能的完善解决了不少我们目前面临的痛点，可以帮助我们缓解甚至解决在大体量业务场景下，多环境管理时的高资源成本和开发者对独立环境的诉求之间的矛盾。

非常期待未来继续与 Zadig 帮助工程师更好地专注价值创造。

Zadig，让工程师更专注创造！欢迎加入 开源吐槽群🔥

Zadig on Github https://github.com/koderover/zadig

Zadig on Gitee https://gitee.com/koderover/zadig