一种基于ServiceMesh的热调试方法与流程

一种基于service mesh的热调试方法
技术领域
1.本发明涉及软件开发技术领域，具体涉及一种基于service mesh的热调试方法。


背景技术：

2.云原生时代下，越来越多的业务系统选择使用微服务架构进行开发。通过对业务逻辑的拆分和解耦，一个个小的微服务相互协调、配合，为用户提供最终价值。每个微服务都围绕着具体业务进行构建，有效地减小了故障的爆炸半径。伴随着微服务规模的不断扩大，也催生着部署方式和运维模式的不断升级。docker的出现解决了运行环境的问题，部署应用不再需要安装一个又一个的依赖包。而kubernetes的出现则解决了资源调度的问题，算力、内存、磁盘、甚至网络都可以通过配置清单随时调用，同时其提供的自动部署、滚动更新、水平扩展、故障自愈的能力，也显著提升了环境的可用性。
3.但由于kubernetes集群网络与主机网络相互隔离，外部计算机设备无法直接接入。而传统的软件开发方法主要是面向主机部署的，通过在开发环境进行软件开发，不断将软件更新代码拷贝到开发机、部署、重启的方式进行测试。
4.传统的软件开发方法，反馈周期长，必须完整走完整个开发、部署整个过程才能进行测试。而使用kubernetes部署往往是由ci(持续集成)和cd(持续部署)工具来完成的，ci/cd流程通常包括构建jar包并上传nexus仓库、构建docker镜像并上传harbor仓库、构建chart并上传chartmuseum仓库、使用helm更新发布、kubernetes拉取docker镜像等。整个过程冗长、复杂，使用传统的软件开发方法，严重降低开发效率，无法适应越来越快的云原生时代。此外，当多人开发同一个应用时，往往相互干扰。不断重启服务也会导致较低的环境可用性，影响测试团队的测试效率。


技术实现要素：

5.为此，本发明提供一种基于service mesh的热调试方法，以解决现有软件开发方案过程繁琐、效率低下的问题。
6.为了实现上述目的，本发明提供如下技术方案：
7.本发明公开了一种基于service mesh的热调试方法，所述方法为：
8.s1、进行网络打通，通过vpn服务端建立kubernetes集群与开发人员本机的连接；
9.s2、通过命令行工具z5nctl，执行“z5nctl init”命令进行初始化工作，并保存输入的虚拟版本代码；
10.s3、开发人员进行app应用的代码开发，开发完成后在本机启动应用；
11.s4、通过命令行工具执行z5nctl mesh，在kubernetes集群中创建对应应用的代理pod，代理pod通过ssh隧道将所有请求到对应端口的流量转发到本机；
12.s5、z5nctl-operator监听到代理pod的创建后，根据app和virtual-version两个标签生成istio的两个crd；
13.s6、开发人员进行线上连调本机的热调试和联合调试。
14.进一步地，所述命令行工具z5nctl能够自动获取必要信息，并根据获取的信息在kubernetes集群中创建对应的代理pod，接着建立代理pod与本机之间的ssh隧道，将线上请求转发到开发人员本机。
15.进一步地，所述z5nctl-operator通过kubernetes mutating admission webhook系统，持续监听应用pod的创建，并根据app和virtual-version两个标签动态生成基于请求头的istio路由规则。
16.进一步地，所述s1步骤中kubernetes集群中安装vpn服务端，并暴露端口供客户端接入，开发人员本机安装vpn客户端，接入vpn服务端。
17.进一步地，所述s2步骤中开发人员打开命令行工具，执行z5nctl init命令进行初始化工作，并输入自己的虚拟版本代码，z5nctl会将其保存到自己的配置目录下。
18.进一步地，所述s4步骤中，开发人员打开命令行工具，并在app应用的工作目录下执行z5nctl mesh；
19.z5nctl基于app-b应用的配置文件，自动搜集应用名称、应用端口信息，并读取的虚拟版本代码；
20.z5nctl基于获取的信息，在kubernetes集群中创建对应应用的代理pod，并为pod打上虚拟版本代码virtual-version＝6587和app＝app-b的标签。
21.进一步地，所述z5nctl为pod打上标签后，等待代理pod启动完成，z5nctl会创建代理pod到本机之间的ssh隧道，并将上述步骤获取到的应用端口，由代理pod转发到本机，即将线上请求转发到本地。
22.进一步地，所述s5步骤中根据app和virtual-version两个标签生成istio的两个crd资源包括：virtualservice和destinationrule，destinationrule根据pod上的virtual-version标签将app-b划分为2个子集：dev线上版本和本机版本，virtualservice则根据请求头z-virtual-version将请求路由到对应的子集上。
23.进一步地，所述开发人员进行线上连调本机的热调试过程中，开发人员在浏览器配置请求头本机版本，并访问线上系统，
24.istio检测到本机版本的请求头，按照virtualservice中的路由策略，将请求路由到代理pod上，代理pod通过ssh隧道将请求最终转发到开发人员本机运行的应用上；
25.开发人员通过修改，再重载应用的方式，便实现了线上连调本机的热调试。
26.进一步地，所述联合调试过程中两名开发人员协商好虚拟版本代码，然后重新执行z5nctl init，并输入协商好的虚拟版本代码，按照s3-s6步骤进行联合调试。
27.本发明具有如下优点：
28.本发明公开了一种基于service mesh的热调试方法，提高了开发环境的稳定性，将线上版本和本机版本划分为两个服务子集，能够自动搜集所需信息，创建ssh隧道，动态生成路由规则，基于请求头实现了流量的精准路由，避免了多名开发人员开发同一应用时的相互干扰。通过将线上请求转发到本机，实现了新开发代码的快速热调试；将请求从线上环境转发到本机应用，实现了应用的热调试。大幅降低了软件的开发、调试成本，并且能很好的支持多人联合调试，提升了整体的开发效率。
附图说明
29.为了更清楚地说明本发明的实施方式或现有技术中的技术方案，下面将对实施方式或现有技术描述中所需要使用的附图作简单地介绍。显而易见地，下面描述中的附图仅仅是示例性的，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图引申获得其它的实施附图。
30.本说明书所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本发明可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本发明所能产生的功效及所能达成的目的下，均应仍落在本发明所揭示的技术内容得能涵盖的范围内。
31.图1为本发明实施例提供的一种基于service mesh的热调试方法的整体架构图；
32.图2为本发明实施例提供的一种基于service mesh的热调试方法的流程图；
具体实施方式
33.以下由特定的具体实施例说明本发明的实施方式，熟悉此技术的人士可由本说明书所揭露的内容轻易地了解本发明的其他优点及功效，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
34.实施例1
35.本实施例公开了一种基于service mesh的热调试方法，所述方法为：
36.s1、进行网络打通，通过vpn服务端建立kubernetes集群与开发人员本机的连接；
37.s2、通过命令行工具z5nctl，执行“z5nctl init”命令进行初始化工作，并保存输入的虚拟版本代码；
38.s3、开发人员进行app应用的代码开发，开发完成后在本机启动应用；
39.s4、通过命令行工具执行z5nctl mesh，在kubernetes集群中创建对应应用的代理pod，代理pod通过ssh隧道将所有请求到对应端口的流量转发到本机；
40.s5、z5nctl-operator监听到代理pod的创建后，根据app和virtual-version两个标签生成istio的两个crd；
41.s6、开发人员进行线上连调本机的热调试和联合调试。
42.本技术中z5nctl为命令行工具，可以自动获取必要信息，并据此在kubernetes集群中创建对应的代理pod，接着建立代理pod与本机之间的ssh隧道，将线上请求转发到开发人员本机。
43.z5nctl-operator为本发明提供的kubernetes operator，通过kubernetes mutating admission webhook系统，持续地监听应用pod的创建，并根据app和virtual-version两个标签动态生成基于请求头的istio路由规则。
44.kubernetes为开源的容器调度引擎，本发明使用它作为基础运行环境。相较于主机部署，能提高系统稳定性，尤其适用于微服务场景。是一个开源的，用于管理云平台中多个主机上的容器化的应用，kubernetes的目标是让部署容器化的应用简单并且高效(powerful),kubernetes提供了应用部署，规划，更新，维护的一种机制。通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，
能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。
45.istio为开源的service mesh(服务网格)引擎，本发明使用它作为流量治理工具。
46.网络打通依赖于vpn服务端，本实施例中在kubernetes集群中安装vpn服务端，并暴露端口供客户端接入，开发人员本机安装vpn客户端，接入vpn服务端。
47.openvpn为开源的vpn解决方案，部署在kubernetes集群中，本发明使用它进行网络穿透，开发人员通过本机的客户端稳定地连接到kubernetes集群网络中。同时将集群网络中的dns服务器推送到开发人员本机，实现了service解析、pod ip直达。
48.开发人员打开命令行工具，执行z5nctl init命令进行初始化工作，并输入自己的虚拟版本代码，通常推荐使用自己的工号，便于区分，z5nctl会将其保存到自己的配置目录下，便于后续使用虚拟版本标签。
49.进行app应用的代码开发，在开发完成后，在本机启动应用。
50.s4步骤中开发人员打开命令行工具，并在app应用的工作目录下执行z5nctl mesh；
51.z5nctl基于app应用的配置文件，自动搜集应用名称、应用端口信息，并读取的虚拟版本代码；
52.z5nctl基于获取的信息，在kubernetes集群中创建对应应用的代理pod，并为pod打上虚拟版本代码virtual-version＝6587和app＝app-b的标签；
53.等待代理pod启动完成后，z5nctl会创建代理pod到本机之间的ssh隧道，并将上述步骤获取到的应用端口，由代理pod转发到本机，也即将线上请求转发到了本地。
54.在完成pod创建后，进行动态路由，z5nctl-operator监听到代理pod的创建，根据app和virtual-version两个标签生成istio的两个crd资源如下：
55.virtualservice：
[0056][0057]
destinationrule:
[0058]
[0059][0060]
destinationrule根据pod上的virtual-version标签将app-b划分为2个子集：dev线上版本和本机版本，virtualservice则根据请求头z-virtual-version将请求路由到对应的子集上。
[0061]
在开发完成后，需要进行调试，开发人员在浏览器配置请求头“virtual-version＝6587(本机版本)”，并访问线上系统；istio检测到“virtual-version＝6587”的请求头，按照virtualservice中的路由策略，将请求路由到代理pod上，接着代理pod通过ssh隧道将请求最终转发到开发人员本机运行的应用上；开发人员通过修改，再重载应用的方式，便实现了线上连调本机的热调试。
[0062]
多个技术开发人员进行联合调试时，两名开发人员协商好虚拟版本代码，然后重新执行z5nctl init，并输入协商好的虚拟版本代码，按照s3-s6步骤进行联合调试。
[0063]
本实施例公开的一种基于service mesh的热调试方法，提高了开发环境的稳定性，将线上版本和本机版本划分为两个服务子集，能够自动搜集所需信息，创建ssh隧道，动态生成路由规则，基于请求头实现了流量的精准路由，避免了多名开发人员开发同一应用时的相互干扰。通过将线上请求转发到本机，实现了新开发代码的快速热调试；将请求从线上环境转发到本机应用，实现了应用的热调试。大幅降低了软件的开发、调试成本，并且能很好的支持多人联合调试，提升了整体的开发效率。
[0064]
虽然，上文中已经用一般性说明及具体实施例对本发明作了详尽的描述，但在本发明基础上，可以对之作一些修改或改进，这对本领域技术人员而言是显而易见的。因此，在不偏离本发明精神的基础上所做的这些修改或改进，均属于本发明要求保护的范围。