Zadig 面向开发者的自测联调子环境技术方案详解

发布时间：2025-11-04 19:23:20 来源：创站工坊 作者：IT科技

Zadig 作为一款先进的向开开源云原生软件交付平台，为开发者提供云原生运行环境，自调环支持开发者本地联调、测联微服务并行构建和部署、境技解集成测试等。术方

环境管理在日常的案详研发过程中基础问题，开发自测、向开联调均需在环境中进行。自调环Zadig 针对环境管理，测联当前提供了如下能力：

通过创建/销毁环境，境技解开发者可以便利使用隔离的术方环境。

通过复制环境，案详开发者可以快速复制出存量环境，向开在隔离的自调环相同环境中进行开发、联调。测联

通过托管环境，开发者可以将已经存在的 namespace 及该 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 自测模式，集群中每条业务线仅需一套完整的基准环境，变更的组件在隔离的子环境中开发、部署，然后通过灰度标控制请求在基准环境和子环境中流转，从而满足开发、联调的需求，同时降低搭建新环境的复杂度和成本。

用户操作流程图如下：

上图中，左侧表示用户操作阶段，右侧表示每个阶段可做的操作的组合和次数。

在自测模式的生命周期中，用户可针对存量环境开启自测模式，将该环境转变为基准环境。然后基于基准环境，为业务不同的需求或缺陷修复创建不同的子环境，在自环境中部署变更的WordPress模板服务，通过子环境和基准环境交互，来实现自测联调。

系统模型是产品设计和技术实现的基础，可以整体理解复杂系统的核心。

Zadig 自测模式的模型如下：

系统层面：

自测环境：

通过模型可知，自测环境支持的是同步请求的调用链，且处于同步请求调用链上的服务之间通过 K8s Service 进行访问。

故环境若要开启自测模式，需要确保业务的同步请求调用链的服务均有相应的 K8s Service，确保服务间调用通过 K8s Service 进行。

先定义关键问题：

为此，实现的一般思路为：

经过流量管理组件的流量保持特殊标记 --- 灰度标可全链路传递

流量管理组件能够根据流量标记，选择出对应的服务实例 --- 由业务无关组件执行 动态路由/服务发现

不同版本的服务可部署在不同的环境中 -- 区分服务版本

通过上述实现一般思路可知，关键的技术实现在于 流量管理组件，通常可以考虑使用 网关 或 代理。

而在用户的技术栈中，流量与网关的关系通常会有如下两种场景：

所有 (南北/东西) 流量均经过网关

部分东西流量不经过网关

考虑到流量经过服务时必须均要经过一个流量管理组件，由于不能要求用户改动业务来处理流量路径，如服务调用均经过网关，故网关无法满足要求，因此选择代理作为流量管理的组件。

目前业界基于代理的流量管理服务比较成熟的是 ServiceMesh，根据上述需求，对 ServiceMesh 实现方案有如下技术要求：

Istio 和 Linkerd 均是当前主流的 ServiceMesh 开源项目，可以考虑选择一种作为 ServiceMesh 实现方案。经调研，截止 Zadig 自测模式实现时，Linkerd 在如下功能层面暂不满足：

暂不支持 SMI TrafficSplit v1alpha3/v1alpha4，即不支持基于 http header 等做动态路由，issue 参见 link[1]

暂不支持 header propagation，issue 参见 link[2]

Istio 均满足上述需求，同时社区活跃，故采用 Istio 作为 Zadig 自测模式的 ServiceMesh 实现方案。

流量管理

VirtualService 定义路由规则，控制流量路由到服务上的行为，基于部署平台的能力实现服务发现，如 K8s Service。

EnvoyFilter 管理每个服务流量经过的 Envoy 配置，可被用来动态调整流量特征。

在 Zadig 自测模式中的使用如下：

备注：

灰度标传递

灰度标的传递在自测模式中是关键问题，有三种解决方案：

方案 1 需要应用少量修改。

方案 2 依赖应用已经集成 tracing 能力。

方案 3 会限制应用开发语言，同时需要在 Java Agent 中实现类似 Istio 中的服务发现和流量动态路由的能力。

Zadig 自测模式不限制用户使用的开发语言，同时又希望尽量减少对用户现有应用的侵入，故采用方案 2。

简化后的方案如下：

Zadig 在系统层面提供一个 Cache 服务：

用户操作实现

对于用户操作，下图整理了平台层面对应的操作实现：

用户对自测环境的操作，在平台层面会涉及对子环境、基准环境、Istio 环境的变更，具体的操作如上所示，不再赘述。

K8s 项目:

Helm 项目：

开发者常用的开发工具是 IDE，随着 Zadig v1.12.0 的重磅发布，已推出面向 VScode IDE 的插件，结合自测模式的能力，使得开发者之间在一个工作界面中就可以轻松进行远程开发和联调，进一步提升开发者的生产力。

自测模式是降低环境管理复杂度和部署成本的重要能力，Zadig 将会持续迭代，在产品层面给用户带来更好的环境管理体验。

官网：https://koderover.com/

github: https://github.com/koderover/zadig

[1]  https://github.com/linkerd/linkerd2/issues/7155

[2]  https://github.com/linkerd/linkerd2/issues/4219

相关文章