Zadig作为先进的开源云原生软件交付平台，为开发者提供云原生运行环境，支持开发者本地联调、并行构建微服务的部署、集成测试等。环境管理是日常研发过程中的一个基本问题。需要在环境中进行开发自测和联调。Zadig目前提供以下环境管理能力：创建/销毁环境复制环境托管环境自测模式（v1.11.0上线）通过创建/销毁环境，开发者可以方便的使用隔离环境。通过复制环境，开发者可以快速复制存量环境，在同一个隔离环境中进行开发和联合调试。通过托管环境，开发者可以将已有的命名空间和命名空间中的应用整合到Zadig中，通过Zadig的能力管理环境和应用。通过自测模式，开发者可以共享同一个基准环境，低成本搭建子环境，在子环境中只部署少量服务，与基准服务交互，实现开发联调。下面将对Zadig的自测模式进行详细的技术解析，并解密自测模式的技术实现：基于全服务的基准环境，开发者可以低成本搭建不同的子环境，进行开发和变更targets在子环境服务中，然后子环境与基线环境的服务进行交互，实现联调。在服务形态分析技术实现之前，通过以下简化的服务调用回顾Zadig自测模式的使用：在集群中搭建一个基准环境，它有完整的服务调用链。没有灰度的请求会在benchmark环境中调用，调用链接为A->B->C。当开发者需要开发调试时，比如涉及到A/C两个组件的变更，可以基于baseenvironment创建一个dev1子环境，其中仅部署更改的A/C组件，即A'/C'。联调时要求增加灰阶。比如你在http头中设置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集群中，不能跨集群部署在每个自测环境中，子环境只能与基准环境交互，请求链对于每个自测环境至多经过一个子环境在一个环境中，至多有一个版本的自测环境：任何时候，参考环境服务之间有全量的服务同步请求，通过跟踪信息通过K8sService访问同步请求的请求链。子环境中的可操作（添加/删除/更新）服务是参考环境服务的子集。参考环境、子环境、直接访问者需要通过同一Mesh中的模型获知，自测环境支持同步请求。调用链，同步请求调用链上的服务通过K8sService访问。因此，如果环境要开启自测模式，需要保证业务的同步请求调用链中的服务有对应的K8sService，并保证服务间调用都是通过K8sService进行的.实现原理首先定义了关键问题：链路上的各个组件和服务可以根据请求流量的特点进行动态路由。需要识别不同的灰度流量。需要对流量进行灰度识别。需要对服务下的所有节点进行分组，并能够区分服务。对于这个版本，实现的总体思路是：所有流量都经过流量管理组件---可以在流量管理组件层面配置根据流量特征进行动态路由---通过流量管理可控的灰度流量组件保留特殊标记---灰度可以跨链路传输流量管理组件可以根据流量标记选择相应的服务实例---动态路由/服务发现由业务独立的组件进行不同版本的服务可以部署在不同环境中——区分服务版本从上面实现的大致思路可以看出，关键的技术实现在于流量管理组件，通常可以考虑网关或者代理。在用户的技术栈中，流量与网关的关系通常有以下两种场景：所有（南北向/东西向）流量都经过网关，部分东西向流量不经过网关。考虑到流量在经过服务组件时必须经过一个流量管理，因为不能要求用户改变业务来处理流量路径，比如服务调用都经过网关，所以网关不能满足要求，所以选择代理作为流量管理的组件。目前，ServiceMesh是业界比较成熟的基于代理的流量管理服务。根据以上需求，ServiceMesh实现有如下技术需求：能够基于HTTPheaders动态路由流量，基于K8sService进行服务发现。Proxy支持标头传播。Istio和Linkerd都是当前主流的ServiceMesh开源项目之一，可以认为是ServiceMesh的实现。经查，截至Zadig自测模式的实现，Linkerd在以下功能方面不满意：暂时不支持SMITrafficSplitv1alpha3/v1alpha4，即不支持基于httpheaders的动态路由。问题请参阅链接[1]不支持标头请参阅链接[2]以了解传播和问题。Istio满足以上要求，社区活跃。因此，Istio被用作Zadig自测模式的ServiceMesh实现。技术实现流量管理VirtualService定义路由规则，控制流量路由到服务的行为，并基于部署平台的能力实现服务发现，如K8sService。EnvoyFilter管理每个服务流量经过的Envoy配置，可用于动态调整流量特性。Zadig自测模式下的使用如下：备注：DestinationRule也是Istio中常用的资源。VirtualSerivce路由生效后，控制流量实际导入的服务。但是根据Zadig自测模式的模型，一个环境最多只会部署一个Version的服务，可以通过环境来区分服务版本，所以不需要使用DestinationRule来区分同类型的不同版本环境中的服务。对于请求触发的出站请求，集成了tracing能力的应用会主动通过对应的灰度，通过traceid使用tracingsdk等串口请求。Istio可以在服务收到请求时记录traceid和灰度的关系，然后当服务发出请求时，根据traceid自动添加灰度。对于Java语言，可以通过JavaAgent劫持程序运行时流量，根据传入请求触发的传出请求自动添加灰度。解决方案1需要进行少量修改。解决方案2依赖于集成跟踪功能的应用程序。方案三会限制应用开发语言，同时需要在JavaAgent中实现类似Istio的服务发现和流量动态路由能力。Zadig自测方式不限制用户使用的开发语言，同时希望尽可能减少对用户现有应用的侵入，因此采用方案2。简化方案如下：Zadig在系统层面提供了一个Cache服务：当请求进入该服务时，Envoy会请求Cache服务记录traceid和灰度的对应关系。当请求流出服务时，Envoy会根据请求中的traceid，查询Cache服务获取灰度，并在出站请求中配置用户操作实现。对于用户操作，下图梳理了平台层面对应的操作实现：用户对自测环境的操作会涉及到子环境、基准环境、Istio环境的变更，具体操作如图所示以上，这里不再赘述。核心代码：K8s项目：后端：https://github.com/koderover/zadig/pull/1214前端：https://github.com/koderover/zadig-portal/pull/660Helm项目：后端：https://github.com/koderover/zadig/pull/1425前端：https://github.com/koderover/zadig-portal/pull/791开发者常用的开发工具是IDE。随着重磅Zadigv1.12.0的发布，推出了VScodeIDE插件，结合自测模式的能力，让开发者可以在工作界面轻松进行远程开发和联调，进一步完善开发人员的生产力。自测模式是降低环境管理复杂度和部署成本的重要能力。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
