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[1]

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

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

技术实现

流量管理

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 将会持续迭代,在产品层面给用户带来更好的环境管理体验。

官网: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

责任编辑:武晓燕 来源: KodeRover
相关推荐

2015-07-10 15:57:24

惠普开发者测试

2015-06-11 09:16:08

开发人员云计算技术学习

2022-07-28 10:46:16

开放策略代理引擎

2019-01-16 18:22:24

机器学习人工智能计算机

2017-08-28 14:28:44

Python文档编程正确姿势

2012-06-13 01:23:30

开发者程序员

2023-06-21 18:16:59

2013-07-12 09:39:44

SDK经济学移动开发者B2D

2016-11-08 20:57:51

文档型语言编程利器

2019-08-27 09:08:52

后端队列系统

2009-03-24 08:51:30

YUIJavaJavascript

2014-12-19 12:10:04

容联云通讯

2015-03-17 14:31:53

Web开发web开发者云开发环境

2023-06-12 14:12:35

2023-09-08 10:13:30

开发技术

2017-09-07 08:40:34

华为

2017-11-07 09:49:21

开发者华为SAP HANA

2014-11-14 14:06:01

容联云通讯

2012-05-02 09:42:19

开发者技术博客

2018-01-08 10:39:17

前端技术框架
点赞
收藏

51CTO技术栈公众号