Detailed explanation of Zadig's self-test and joint debugging sub environment for developers

Zadig  As an advanced open source cloud native software delivery platform , Provide cloud native running environment for developers , Support local joint debugging of developers 、 Microservices are built and deployed in parallel 、 Integration testing, etc .

Environmental management is a basic problem in the daily R & D process , Development self testing 、 The joint commissioning shall be carried out in the environment .Zadig  For environmental management , The following capabilities are currently available ：

• establish / Destroy the environment

• Copy the environment

• Hosting environment

• Self test mode （ since  v1.11.0  Version launch ）

By creating a / Destroy the environment , Developers can easily use isolated environments .

By copying the environment , Developers can quickly copy the stock environment , Develop in the same isolated environment 、 Joint tune .

Through the managed environment , Developers can add existing  namespace  And  namespace  The application of to  Zadig  in , adopt  Zadig  Ability to manage environments and applications .

Through self-test mode , Developers can share the same benchmark environment , Build sub environment at low cost , Only a few services are deployed in the sub environment , And interact with the benchmark service to realize development 、 Joint tune .

The following will be for  Zadig  A detailed technical analysis of the self-test mode , Technical implementation of decryption self-test mode ：

Based on the benchmark environment with full service , Developers can build different sub environments at low cost , Develop in a sub environment 、 Change target services , Then the service interaction between the sub environment and the benchmark environment is used to realize joint debugging .

Service form

Before analyzing technology implementation , Let's review the following simplified service invocation  Zadig  The use of the self-test mode ：

Set up a benchmark environment in the cluster , The environment has a complete chain of service invocations . Requests without gray scale will be called in the reference environment , The call link is  

A -> B -> C

.

When developers need to develop 、 Joint commissioning , For example, it involves  A / C  Changes to the two components , You can create a new... Based on the baseline environment  dev1  Sub environment , Only the changed... Are deployed in this sub environment  A / C  Components , namely  A' / C'. It is required to add gray scale during joint commissioning , If in  http header  Set the  

x-env=dev1

  Gray scale of , At this time, the request will be made according to  

A' -> B -> C'

  Conduct .

Empathy , When developing 、 The joint commissioning only involves  B / C  When two components change , You can create a new... Based on the baseline environment  dev2  Sub environment , This sub environment only deploys the changed  B / C  Components , namely  B'' / C''. Add gray scale during joint commissioning  

x-env=dev2

, This request is made in accordance with  

A -> B'' -> C''

  Conduct .

adopt  Zadig  Self test mode , Each business line in the cluster only needs a complete set of benchmark environment , The changed components are developed in an isolated sub environment 、 Deploy , Then the request flows through the reference environment and sub environment through the gray scale control , So as to meet the requirements of development 、 Requirements for joint commissioning , At the same time, reduce the complexity and cost of building a new environment .

The user operation flow chart is as follows ：

Above picture , The left side indicates the user operation stage , The right side shows the combination and number of operations that can be done in each stage .

In the life cycle of self-test mode , The user can start the self-test mode according to the stock environment , Turn this environment into a baseline environment . Then based on the benchmark environment , Create different sub environments for different business requirements or defect fixes , Deploy the changed service in the self environment , Interact with the base environment through the sub environment , To realize self-test and joint commissioning .

Model

System model is the basis of product design and technology realization , Can understand the core of complex system as a whole .

Zadig  The model of self-test mode is as follows ：

System level ：

• One  K8s  colony , There can be multiple sets of self-test environments

• Each project , There can be multiple sets of self-test environments

• In each self-test environment , Have a baseline environment and  n  Sub environment  (n≥0)

• In each self-test environment , All services are in one  K8s  colony , Cannot deploy across clusters

• In each self-test environment , The sub environment can only interact with the base environment , The request chain passes through at most one sub environment

• In each self-test environment , Request interaction between sub environments is not supported

• Services in an environment , There is at most one version

Self test environment ：

• Anytime , The baseline environment has
  Total quantity
  service

• The service of the synchronization request passes through  K8s Service  visit

• The request chain of synchronous requests passes through  tracing  Information concatenation

• Operational in the sub environment  ( newly added / Delete / to update )  The services of are a subset of the benchmark environment services

• Benchmark environment 、 Sub environment 、 Direct visitors need to be in the same  Mesh  in

We can know from the model , The self-test environment supports the call chain of synchronous requests , And between services on the synchronous request invocation chain  K8s Service  Visit .

So if the environment wants to start the self-test mode , It is necessary to ensure that the services in the synchronous request calling chain of the business have corresponding  K8s Service, Make sure that the inter service call passes  K8s Service  Conduct .

Realization principle

Define the key issues first ：

• Each component and service on the link can be based on  
  Request traffic characteristics  
  Conduct  
  Dynamic routing

• Need to identify  
  Different grayscale traffic

• The flow needs to be  
  Grayscale identification

• All nodes under the service need to be grouped , can  
  Differentiated service versions

So , The general idea of implementation is ：

• All traffic passes through the traffic management component  ---  Dynamic routing according to traffic characteristics

• Routing rules can be configured at the traffic management component level  ---  Controllable gray scale

• The traffic passing through the traffic management component maintains a special mark  ---  Gray scale can be transmitted through the whole link

• The traffic management component can mark according to traffic , Select the corresponding service instance  ---  Performed by business independent components   Dynamic routing / Service discovery

• Different versions of services can be deployed in different environments  --  Differentiated service versions

From the general idea of the above implementation, we can see , The key technical realization lies in  

Traffic management components

, You can usually consider using  

gateway

  or  

agent .

In the user's technology stack , The relationship between traffic and gateway usually has the following two scenarios ：

• all  ( north and south / thing )  The traffic flows through the gateway

• Some east-west traffic does not pass through the gateway

Considering that the traffic must pass through a traffic management component when passing through the service , Since the user cannot be required to change the service to process the traffic path , For example, all service calls pass through the gateway , Therefore, the gateway cannot meet the requirements , Therefore, the agent is selected as the component of traffic management .

At present, the mature agent-based traffic management services in the industry are  ServiceMesh, According to the above requirements , Yes  ServiceMesh  The implementation scheme has the following technical requirements ：

• Can be based on  http header  And other dynamic routing traffic

• be based on  K8s Service  Service discovery

• proxy  Support  header propagation

Istio  and  Linkerd  Are the current mainstream  ServiceMesh  Open source project , Consider choosing one as  ServiceMesh  Implementation scheme . After investigation , end  Zadig  When the self-test mode is implemented ,Linkerd  The following functions are not satisfied for the time being ：

• Temporary does not support  SMI TrafficSplit v1alpha3/v1alpha4, That is, based on  http header  Wait for dynamic routing ,issue  See  
  link

• Temporary does not support  header propagation,issue  See  
  link

Istio  All meet the above requirements , At the same time, the community is active , Therefore adopt  Istio  As  Zadig  Self test mode  ServiceMesh  Implementation scheme .

Technical realization

Traffic management

Istio  Implement self-test mode , It mainly depends on the following  2  individual  CRD：

• VirtualService

• EnvoyFilter

VirtualService  Define routing rules , Control the behavior of traffic routing to services , Implement service discovery based on the capabilities of the deployment platform , Such as  K8s Service.

EnvoyFilter  Manage the flow of each service  Envoy  To configure , It can be used to dynamically adjust the flow characteristics .

stay  Zadig  The use in the self-test mode is as follows ：

remarks ：

• DestinationRule  It's also  Istio  Common resources in , stay  VirtualSerivce  After the route takes effect , The service that controls the actual import of traffic

• But through  Zadig  The model of self-test mode shows , Only one version of the service can be deployed in an environment , Service versions can be differentiated by environment , Therefore, there is no need to use  DestinationRule  To distinguish different versions of the same type of service in an environment

Gray scale transfer

The transfer of gray scale is a key problem in self-test mode , There are three solutions ：

• The outgoing request caused by the application itself for the incoming request , Actively transfer the corresponding gray scale

• Integrated  tracing  Application of ability , Will pass  tracing sdk  Etc  trace id  Wait for the serial request ,Istio  It can be recorded when the service receives the request  trace id  And gray scale , Then the service sends a request according to  trace id  Automatically increase the gray scale

• about  Java  Language , It can be done by  Java Agent  Hijack program runtime traffic , The outgoing request caused by the incoming request , Automatically add gray scale

programme  1  Minor changes need to be applied .

programme  2  Dependent applications have been integrated  tracing  Ability .

programme  3  Will restrict the application development language , At the same time, it needs to be in  Java Agent  The implementation is similar to  Istio  The ability of service discovery and traffic dynamic routing in .

Zadig  The self-test mode does not limit the development languages that users use , At the same time, we hope to minimize the intrusion into users' existing applications , Therefore, the scheme is adopted  2.

The simplified scheme is as follows ：

Zadig  Provide a at the system level  Cache  service ：

• When requesting access to the service ,Envoy  Will ask  Cache  Service record  trace id  and   Gray scale   Correspondence of

• When the request flows out of the service ,Envoy  According to the request  trace id, Inquire about  Cache  Service acquisition   Gray scale , Configure the outgoing request

User operation implementation

For user operation , The following figure sorts out the corresponding operation implementation at the platform level ：

User's operation on self-test environment , At the platform level, the sub environment will be involved 、 Benchmark environment 、Istio  Change of environment , The specific operation is as shown above , I won't repeat .

Core code

• K8s  project :

• Back end ：https://github.com/koderover/zadig/pull/1214

• front end ：https://github.com/koderover/zadig-portal/pull/660

• Helm  project ：

• Back end ：https://github.com/koderover/zadig/pull/1425

• front end ：https://github.com/koderover/zadig-portal/pull/791

expectation

The development tools commonly used by developers are  IDE, With  Zadig v1.12.0  The heavyweight release of , Has launched for  VScode IDE  Plug in for , Ability to combine self-test mode , So that developers can easily carry out remote development and joint debugging in a working interface , Further improve the productivity of developers .

Self test mode is an important ability to reduce the complexity of environmental management and deployment costs ,Zadig  Will continue iterating , Bring users a better environmental management experience at the product level .

Zadig, Let engineers focus more on creating ！ Welcome to join  

Make complaints about open source Tucao group

Zadig on Github

 

https://github.com/koderover/zadig

Zadig on Gitee

 

https://gitee.com/koderover/zadig