Zadig,作为一款面向开发者的开源云原生 DevOps 平台,为开发者提供了全面的云原生运行环境。它不仅支持开发者进行本地联调、微服务的并行构建与部署,还涵盖了集成测试等关键功能。
在研发的日常流程中,环境管理是一项基础却至关重要的任务,涵盖了开发自测、联调、测试验证等多个环节。Zadig 在环境管理方面提供了以下核心能力:
- 创建/销毁环境:为开发者提供便捷的隔离环境使用。
- 复制/回溯环境:允许快速复制现有环境,确保在一致的环境中进行开发和联调。
- 托管环境:使开发者能够将现有的 namespace 及其应用纳入 Zadig,以实现应用分环境治理。
- 自测模式子环境:支持开发者共享一套基准环境,低成本构建子环境,仅部署必要服务,实现高效的开发和联调。
Zadig 环境管理功能,旨在简化开发者的工作流程,提高研发效率,同时降低环境管理的复杂性和成本。下述将针对 Zadig 的自测模式进行详细的技术解析,解密自测模式的技术实现:
基于拥有全量服务的基准环境,开发者可以低成本建立不同的子环境,在子环境中开发、变更目标服务,然后子环境与基准环境的服务交互来实现联调。
# 服务形态
在分析技术实现前,先通过如下简化的服务调用来回顾 Zadig 自测模式的使用体感:
在集群中搭建一套基准环境,该环境拥有完整的服务调用链。没有灰度标的请求会在基准环境中进行调用,调用链路为 A -> B -> C
。
当开发者需要进行开发、联调时,比如涉及到到 A / C 两个组件的变更,可以基于基准环境新建 dev1 子环境,该子环境中仅部署变更后的 A / C 组件,即 A' / C'。联调时请求加上灰度标,如在 http header 中设定 x-env=dev1
的灰度标,此时请求会按照 A' -> B -> C'
进行。
同理,当开发、联调时仅涉及到 B / C 两个组件的变更时,可以基于基准环境新建 dev2 子环境,该子环境仅部署变更后的 B / C 组件,即 B'' / C''。联调时加上灰度标 x-env=dev2
,这样请求按照 A -> B'' -> C''
进行。
通过 Zadig 自测模式,集群中每条业务线仅需一套完整的基准环境,变更的组件在隔离的子环境中开发、部署,然后通过灰度标控制请求在基准环境和子环境中流转,从而满足开发、联调的需求,同时降低搭建新环境的复杂度和成本。
用户操作流程图如下:
上图中,左侧表示用户操作阶段,右侧表示每个阶段可做的操作的组合和次数。
在自测模式的生命周期中,用户可针对存量环境开启自测模式,将该环境转变为基准环境。然后基于基准环境,为业务不同的需求或缺陷修复创建不同的子环境,在自环境中部署变更的服务,通过子环境和基准环境交互,来实现自测联调。
# 模型
系统模型是产品设计和技术实现的基础,可以整体理解复杂系统的核心。
Zadig 自测模式的模型如下:
系统层面:
- 一个 K8s 集群,可以有多套自测环境
- 每个项目,可以有多套自测环境
- 每个自测环境中,拥有一个基准环境和 n 个子环境 (n≥0)
- 每个自测环境中,所有服务全部在一个 K8s 集群,不能跨集群部署
- 每个自测环境中,子环境仅能和基准环境交互,请求链至多经过一个子环境
- 每个自测环境中,不支持子环境间请求交互
- 服务在一个环境中,至多有一个版本
自测环境:
- 任意时刻,基准环境拥有全量服务
- 同步请求的服务间通过 K8s Service 访问
- 同步请求的请求链通过 tracing 信息串接
- 子环境中可操作 (新增/删除/更新) 的服务是基准环境服务的子集
- 基准环境、子环境、直接访问者需要在同一个 Mesh 中
通过模型可知,自测环境支持的是同步请求的调用链,且处于同步请求调用链上的服务之间通过 K8s Service 进行访问。
故环境若要开启自测模式,需要确保业务的同步请求调用链的服务均有相应的 K8s Service,确保服务间调用通过 K8s Service 进行。
# 实现原理
先定义关键问题:
- 链路上各个组件和服务能够根据 请求流量特征 进行 动态路由
- 需要识别出 不同的灰度流量
- 需要对流量进行 灰度标识
- 需要对服务下的所有节点进行分组,能够 区分服务版本
为此,实现的一般思路为:
- 所有流量都经过流量管理组件 --- 根据流量特征进行动态路由
- 可在流量管理组件层面配置路由规则 --- 可控灰度标
- 经过流量管理组件的流量保持特殊标记 --- 灰度标可全链路传递
- 流量管理组件能够根据流量标记,选择出对应的服务实例 --- 由业务无关组件执行 动态路由/服务发现
- 不同版本的服务可部署在不同的环境中 -- 区分服务版本
通过上述实现一般思路可知,关键的技术实现在于 流量管理组件,通常可以考虑使用 网关 或 代理。
而在用户的技术栈中,流量与网关的关系通常会有如下两种场景:
- 所有 (南北/东西) 流量均经过网关
- 部分东西流量不经过网关
考虑到流量经过服务时必须均要经过一个流量管理组件,由于不能要求用户改动业务来处理流量路径,如服务调用均经过网关,故网关无法满足要求,因此选择代理作为流量管理的组件。
目前业界基于代理的流量管理服务比较成熟的是 ServiceMesh,根据上述需求,对 ServiceMesh 实现方案有如下技术要求:
- 可以基于 http header 等动态路由流量
- 基于 K8s Service 做服务发现
- proxy 支持 header propagation
Istio 和 Linkerd 均是当前主流的 ServiceMesh 开源项目,可以考虑选择一种作为 ServiceMesh 实现方案。
经调研,截止 Zadig 自测模式实现时,Linkerd 在如下功能层面暂不满足:
- 暂不支持 SMI TrafficSplit v1alpha3/v1alpha4,即不支持基于 http header 等做动态路由,issue 参见 link (opens new window)
- 暂不支持 header propagation,issue 参见 link (opens new window)
Istio 均满足上述需求,同时社区活跃,故采用 Istio 作为 Zadig 自测模式的 ServiceMesh 实现方案。
# 技术实现
# 流量管理
Istio 在实现自测模式中,主要依赖以下两个关键的 CRD:
- VirtualService:这一 CRD 用于定义精细的路由规则,控制进入服务的流量行为。基于部署平台的能力实现服务发现,如 K8s Service。
- EnvoyFilter:此 CRD 负责管理流量通过 Envoy 代理时的配置,可被用来动态调整流量特征。
通过这两个 CRD 的协同工作,Istio 能够灵活地控制服务间的流量流动和行为调整,为自测模式提供了强大的支持。
在 Zadig 自测模式中的使用如下:
备注:
- DestinationRule 也是 Istio 中常用的资源,在 VirtualSerivce 路由生效后,控制流量实际导入的服务
- 通过 Zadig 自测模式的模型可知,一个环境仅会部署服务至多一个版本,可通过环境区分服务版本,故无需借助 DestinationRule 来区分一个环境中同一类服务的不同版本
# 灰度标传递
在 Zadig 自测模式中,灰度标传递至关重要。我们考虑了三种解决方案:
- 应用主动传递:应用在引发出请求时,主动传递灰度标。
- Tracing 能力集成:应用通过集成的 tracing SDK,利用 trace id 串联请求。Istio 在服务接收请求时记录 trace id 与灰度标的关系,并在服务发出请求时自动添加灰度标。
- Java Agent 技术:对于 Java 应用,使用 Java Agent 劫持运行时流量,根据入请求引发的出请求,自动添加灰度标。
方案评估:
- 方案 1:需要对应用进行少量修改。
- 方案 2:适用于已集成 tracing 能力的应用,无需额外修改。
- 方案 3:限于 Java 语言,且需在 Java Agent 中实现服务发现和流量路由。
Zadig 自测模式选择:考虑到对用户现有应用的最小侵入性,Zadig 自测模式优先采用方案 2,它不限制开发语言且易于集成,为用户提供了一种既灵活又高效的灰度标传递方式。
简化后的方案如下:
Zadig 系统内置了 Cache 服务,用于管理请求的灰度标传递:
- 请求进入:当请求到达服务,Envoy 代理将向 Cache 服务查询,记录每个请求的 trace id 与对应的灰度标的映射关系。
- 请求流出:服务向外发出请求时,Envoy 代理会利用请求中的 trace id,从 Cache 服务中检索相应的灰度标,并将其配置到出站请求中。
这种机制确保了灰度标在服务间的传递既准确又高效,无需对应用代码进行修改,从而简化了整个灰度发布的流程。
# 用户操作实现
对于用户操作,下图整理了平台层面对应的操作实现:
用户对自测环境的操作,在平台层面会涉及对子环境、基准环境、Istio 环境的变更,具体的操作如上所示,不再赘述。
# 展望
自测模式是降低环境管理复杂度和部署成本的重要能力,Zadig 将会持续迭代,在产品层面给用户带来更好的环境管理体验。