谁说 Zadig 只能复制环境？数百微服务一套环境实现高效协作
Zadig on GitHub https://github.com/koderover/zadig
Zadig on Gitee https://gitee.com/koderover/zadig
在日常开发中，能够支持不同的开发者都有自己的测试环境是一件体感很爽的事情。然而，当业务特点复杂时，一套测试环境中可能包含成千上百个服务，在这种场景下复制一套可用的环境成本极其高。更甚者，因为部分微服务基础架构的原因，无法完整地复制出多套环境。工程师们只得将就地使用一套测试环境来做日常开发。环境不够用、管理混乱、多人对同一个服务有变更诉求时必须彼此等待...面对这种情况，只能等等等，忍忍忍！
开发者的烦恼
| 1 |
开发频率快，业务验证需求旺盛 |
| 2 |
业务复杂度高，环境复制难度高 |
| 3 |
微服务数量大，环境复制成本高 |
| 4 |
环境一致性差，版本混乱上线风险高 |
| 5 |
环境不稳定，开发被频繁打断，工程师体感差 |
为解决上述痛点，在最新发布的 v1.11.0 版本中，Zadig 对环境的能力有了进一步的增强：支持开发者用最低成本快速拉起包括部分服务的子环境，在子环境中开发、变更目标服务，并和包括全量服务的基准环境交互来实现自测联调。下面展开介绍。
Zadig 自测模式
自测模式是 Zadig 为降低环境管理复杂度和部署成本而推出的一种面向开发者的功能模块。当开启了环境的自测模式后，该环境则成为基准环境，开发者们可以基于基准环境快速复制出属于自己的自测环境（即：子环境），并且只关注和自己日常改动相关的服务。对于其上下游服务无需理会，基准环境中会提供这部分服务的能力。图示如下：
适用场景
Zadig 环境的自测模式能力尤其适用以下场景：：
1、有一套完整的测试环境，但多人基于同一套环境协同合作开发，测试环境资源有限，日常存在多名开发者互相等待环境的现象
2、业务规模大，服务数量级可观，完整复制出多套测试环境的成本高
3、服务相互关联，受限于基础架构，完整复制出多套测试环境的难度大
4、日常变更多，大量工程师协作，需要高频的验证
如何使用
下面以 simple-service 项目为例来说明如何使用环境的自测模式。项目中环境和服务背景，以及自测联调需求说明如下：
-
项目中共包括 3 个微服务 a、b、c，服务调用链路：a -> b -> c
-
dev 环境为日常完整稳定的测试环境，包括全部微服务 a、b、c
-
日常会对 a 服务进行高频改动，希望能对 a 服务进行充分自测，确定其变更可交付
具体操作步骤如下：
管理员：开启自测模式
在 dev 环境，开启自测模式：
这时会对自测模式的依赖条件做检查：
-
系统无法自动检查 Tracing 组件，需要管理员自行确保，此处支持较为广泛应用的 SkyWalking、Zipkin、Jaeger 等。
-
系统会对 Istio 是否安装做自动检查，如果没有请在环境所在集群进行安装
-
服务调用链自动检查，主要依据是有 K8s Service 类型的资源和服务 a、b、c 对应
当开启自测模式后，dev 环境即成为基准环境。
工程师：日常自测联调
创建子环境
在 dev 基准环境中通过点击创建子环境，选择 a 服务可创建包含 a 服务的子环境 dev-test-env1：
子环境服务请求
当需要请求服务 a 时，在请求的 Header 头中加入 x-env:dev-test-env1 即可将请求流量转发到子环境 dev-test-env1 中，实现子环境和 dev 环境的自测联调。效果如下所示：
1、未加 x-env 请求头，直接请求服务 a，dev 环境中的服务 a/b/c 会处理请求，子环境中无请求流量输入。
2、增加 x-env: dev-test-env1 请求头访问服务 a，子环境中的服务 a 会接收到请求并给出响应，对于请求链路上的 b/c 服务，dev 环境中的服务会给出正常响应。
展望
开发者日常工作交互最频繁的当属 IDE，Zadig 小伙伴也在紧锣密鼓完善面向 IDE 的插件能力，结合Zadig 自测模式，可以让开发者轻松开发联调又无需切换多个工作界面，大大提升开发者生产力和工作体验。
自测模式的推出，对降低环境管理复杂度和部署成本效果显著，同时也非常期待社区小伙伴的反馈，一起打磨完善，同社区一起迭代更好的易用性！
Zadig on GitHub https://github.com/koderover/zadig
Zadig on Gitee https://gitee.com/koderover/zadig
Zadig，让工程师更专注创造！欢迎加入 开源吐槽群🔥
