Zadig 面向开发者的自测联调子环境技术方案详解
Zadig 作为一款先进的开源云原生软件交付平台，为开发者提供云原生运行环境，支持开发者本地联调、微服务并行构建和部署、集成测试等。
环境管理在日常的研发过程中基础问题，开发自测、联调均需在环境中进行。Zadig 针对环境管理，当前提供了如下能力：
创建/销毁环境
复制环境
托管环境
自测模式（自 v1.11.0 版本推出）
通过创建/销毁环境，开发者可以便利使用隔离的环境。
通过复制环境，开发者可以快速复制出存量环境，在隔离的相同环境中进行开发、联调。
通过托管环境，开发者可以将已经存在的 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 自测模式，集群中每条业务线仅需一套完整的基准环境，变更的组件在隔离的子环境中开发、部署，然后通过灰度标控制请求在基准环境和子环境中流转，从而满足开发、联调的需求，同时降低搭建新环境的复杂度和成本。
用户操作流程图如下：
上图中，左侧表示用户操作阶段，右侧表示每个阶段可做的操作的组合和次数。
在自测模式的生命周期中，用户可针对存量环境开启自测模式，将该环境转变为基准环境。然后基于基准环境，为业务不同的需求或缺陷修复创建不同的子环境，在自环境中部署变更的服务，通过子环境和基准环境交互，来实现自测联调。
模型
系统模型是产品设计和技术实现的基础，可以整体理解复杂系统的核心。
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
暂不支持 header propagation，issue 参见 link
Istio 均满足上述需求，同时社区活跃，故采用 Istio 作为 Zadig 自测模式的 ServiceMesh 实现方案。
技术实现
流量管理
Istio 实现自测模式，主要依赖于如下 2 个 CRD：
VirtualService
EnvoyFilter
VirtualService 定义路由规则，控制流量路由到服务上的行为，基于部署平台的能力实现服务发现，如 K8s Service。
EnvoyFilter 管理每个服务流量经过的 Envoy 配置，可被用来动态调整流量特征。
在 Zadig 自测模式中的使用如下：
备注：
DestinationRule 也是 Istio 中常用的资源，在 VirtualSerivce 路由生效后，控制流量实际导入的服务
但通过 Zadig 自测模式的模型可知，一个环境仅会部署服务至多一个版本，可通过环境区分服务版本，故无需借助 DestinationRule 来区分一个环境中同一类服务的不同版本
灰度标传递
灰度标的传递在自测模式中是关键问题，有三种解决方案：
应用自身对于入请求引发的出请求，主动传递对应的灰度标
集成了 tracing 能力的应用，会通过 tracing sdk 等通过 trace id 等串联请求，Istio 可在服务接收到请求时记录 trace id 和灰度标的关系，然后服务发出请求时根据 trace id 自动增加灰度标
对于 Java 语言，可通过 Java Agent 劫持程序运行时流量，根据入请求引发的出请求，自动添加灰度标
方案 1 需要应用少量修改。
方案 2 依赖应用已经集成 tracing 能力。
方案 3 会限制应用开发语言，同时需要在 Java Agent 中实现类似 Istio 中的服务发现和流量动态路由的能力。
Zadig 自测模式不限制用户使用的开发语言，同时又希望尽量减少对用户现有应用的侵入，故采用方案 2。
简化后的方案如下：
Zadig 在系统层面提供一个 Cache 服务：
当请求进入服务时，Envoy 会请求 Cache 服务记录 trace id 和 灰度标 的对应关系
当请求流出服务时，Envoy 会根据请求中的 trace id，查询 Cache 服务获取 灰度标，配置在出请求
用户操作实现
对于用户操作，下图整理了平台层面对应的操作实现：
用户对自测环境的操作，在平台层面会涉及对子环境、基准环境、Istio 环境的变更，具体的操作如上所示，不再赘述。
核心代码
K8s 项目:
后端：https://github.com/koderover/zadig/pull/1214
前端：https://github.com/koderover/zadig-portal/pull/660
Helm 项目：
后端：https://github.com/koderover/zadig/pull/1425
前端：https://github.com/koderover/zadig-portal/pull/791
展望
开发者常用的开发工具是 IDE，随着 Zadig v1.12.0 的重磅发布，已推出面向 VScode IDE 的插件，结合自测模式的能力，使得开发者之间在一个工作界面中就可以轻松进行远程开发和联调，进一步提升开发者的生产力。
自测模式是降低环境管理复杂度和部署成本的重要能力，Zadig 将会持续迭代，在产品层面给用户带来更好的环境管理体验。
Zadig，让工程师更专注创造！欢迎加入 开源吐槽群🔥
软件交付更丝滑～ 2022.04.06 加入
Zadig 是 KodeRover 团队基于 K8s 自主研发的开源分布式持续交付产品，重点解决企业级软件交付验证的痛点，并且 100% 开放源代码
评论