TTChat x Zadig 开源共创 Helm 接入场景搞定数百微服务的环境治理问题

通过 Zadig 直接复制一个现有的稳定环境,快速构建新环境,为每个开发者提供随时可用的自测子环境,全面推动研发自动化体系建设

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

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

# 01 回望过去

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

# 02 共创之路

从去年的 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 等进行一些初始数据的导入工作,这也是我们计划中但一直还没来得及做的事情。

# 03 落地与探索

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

我们期望能够结合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 余次。

# 04 期待与展望

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

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

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

Background Image

作为一名软件工程师,我们一直给各行各业写软件提升效率,但是软件工程本身却是非常低效,为什么市面上没有一个工具可以让研发团队不这么累,还能更好、更快地满足大客户的交付需求?我们是否能够打造一个面向开发者的交付平台呢?我们开源打造 Zadig 正是去满足这个愿望。

—— Zadig 创始人 Landy