一种用户无感的微服务容器部署方法及其部署装置

一种用户无感的微服务容器部署方法及其部署装置
1.技术领域
2.本发明涉及微服务容器部署技术领域，尤其涉及一种用户无感的微服务容器部署方法及其服务容器部署装置。


背景技术：

3.在中大型应用程序的实际开发过程中，随着应用程序的使用需求不断变化，开发者们需要不定期地更新版本，更新版本又需要开发者们修改代码、提交代码、发布新版本到生产环境。随着容器化技术的发展，容器变得越来越轻量级，使用成本越来越低，但是资源利用率和性能越来越高。在面对同一台服务器需要部署多个应用或者同一个应用需要部署到多台服务器的情况时，容器化技术显得十分实用。因此，在发布新版本到生产环境时，越来越多的企业和开发者们选择使用容器化技术来部署应用。虽然，使用容器化技术来部署应用已经广为人知，但目前的技术方案仍然存在以下问题：对于传统的容器部署来说，在发布新版本的时候，部署应用人员需要先将原有容器停止运行，再重新部署新版本容器并且运行，这样就使得用户往往有一段时间不能使用应用直到新版本发布完成，这段时间被称为停机时间。解决如何做到0停机时间发布新版本，即用户无感的容器部署这个问题变得很有价值。


技术实现要素：

4.本发明的目的是针对现有技术的不足而设计的一种用户无感的微服务容器部署方法及其部署装置，采用流水线的项目部署方法，通过流水线模块依次连接的代码扫描模块、镜像发布模块、升级镜像模块、服务网格模块和流量转发模块构成的装置，实现用户无感的微服务容器部署，使得发布新版本时停机时间为0，用户可以丝滑地过渡到新版本而不影响使用应用，通过静态代码扫描模块，可以扫描出静态代码可能存在的风险，减少了项目上线后的风险和企业的损失，通过服务网格模块，可以实现精细化控制流量，优化用户体验，使得用户对部署毫不知情，即可实现用户无感的微服务容器部署，大大简化了项目部署过程，节省时间与人力，较好解决了0停机时间发布新版本的问题，具有广泛的应用前景。
5.实现本发明的具体技术方案是：一种用户无感的微服务容器部署方法，其特点是该方法包括如下步骤：步骤s1：推送代码后自动启动流水线；步骤s2：推送新版本镜像到镜像仓库；步骤s3：静态代码扫描；步骤s4：在k8s集群上的空闲worker部署新版本镜像；步骤s5：启动istio服务网格；步骤s6：验证通过后将所有流量转发到新版本所在集群中。
6.所述步骤s1中推送代码后自动启动流水线，具体包括如下步骤：步骤s11：在服务器上部署runner用于运行流水线；步骤s12：通过git命令将代码推送至已有的gitlab代码仓库；步骤s13：启动gitlab ci/cd流水线。
7.所述步骤s2中推送新版本镜像到镜像仓库，具体包括如下步骤：步骤s21：使用docker拉取项目依赖的基础镜像；步骤s22：将项目打包成新版本镜像；步骤s23：通过docker将新版本镜像推送至阿里云镜像仓库；步骤s24：生成产物供所述步骤s3静态代码扫描使用。
8.所述步骤s3中静态代码扫描，具体包括如下步骤：步骤s31：拉取所述步骤s2推送新版本镜像到镜像仓库的产物；步骤s32：根据项目选择代码扫描工具，进行静态代码扫描。
9.所述步骤s4中在k8s集群上的空闲worker部署新版本镜像，具体包括如下步骤：步骤 s41：启动service服务；步骤 s42：定义pod模板；步骤s43：根据所述步骤s42中定义的模板创建replica set；所述步骤s41中启动service服务，通过设置服务的标签来使服务可以匹配到相应的pods。
10.所述步骤s42中定义pod模板，具体包括如下步骤：步骤s421：设置pod的副本数量；步骤s422：设置pod的标签，用于被相应的service服务选中；步骤s423：将pod的镜像设置为所述步骤2中推送的新版本镜像，用于创建对应pods；步骤s424：设置生存探针和就绪探针，用于判断pod是否存活和就绪；步骤s425：设置相应的环境变量。
11.所述步骤s5中启动istio服务网格，具体包括如下步骤：步骤s51：启动gateway服务；步骤s52：启动destination rule服务；步骤s53：启动virtual service服务。
12.所述步骤s51中启动gateway服务，具体包括如下步骤：步骤s511：通过设置标签以匹配istio出口网关；步骤s512：设置服务的protocol和端口号；步骤s513：设置匹配host。
13.所述步骤s52中启动destination rule服务，具体包括如下步骤：步骤 s521：设置host名；步骤s522：设置subsets集合，其中包括新版本和旧版本两个子集，并且设置对应版本的标签。
14.所述步骤s53中启动virtual service服务，具体包括如下步骤：步骤s531：设置匹配host名；
步骤s532：绑定所述步骤s51中启动的gateway服务；步骤s533：设置route规则。
15.所述步骤s533中设置route规则，具体包括如下步骤：步骤s5331：设置destination中所匹配的service服务；步骤s5332：设置destination中新、旧版本的subset子集；步骤s5333：设置将客户端的请求流量转移到新、旧版本上的流量比例，将新版本的weight设置为a，表明将有a%的流量被转移到新版本上；将旧版本的weight设置为b，表明将有b%的流量将被转移到旧版本上；其中a+b=100。
16.所述步骤s6中验证通过后将所有流量转发到新版本所在集群，具体包括如下步骤：步骤s61：验证所述步骤s5333中转移到新版本上的a%流量，检查是否存在bug；步骤s62：如果在新版本上的a%流量不存在bug，那么修改所述步骤s53中的virtual service服务，将所有流量转发到新版本上，并断开与旧版本的连接；如果在新版本上的a%流量存在bug，则进行回滚，将a%流量重新转移到旧版本中。
17.所述步骤s62中，通过修改所述步骤s5333中的流量比例来控制流量转移，并且重新启动所述步骤s53中的virtual service服务。
18.一种用户无感的微服务容器的部署装置，其特点是该装置（系统）由流水线模块依次连接的代码扫描模块、镜像发布模块、升级镜像模块、服务网格模块和流量转发模块组成，实现用户无感的微服务容器部署，所述流水线模块用于推送代码后自动启动流水线，简化项目部署过程；所述代码扫描模块用于静态代码扫描，检出代码中可能存在的风险；所述镜像发布模块用于推送新版本镜像到镜像仓库；所述升级镜像模块用于在k8s集群上的空闲worker部署新版本镜像；所述服务网格模块用于启动istio服务网格，实现精细化控制流量；所述流量转发模块用于验证通过后将所有流量转发到新版本所在集群中，实现用户无感的微服务容器部署。
19.本发明与现有技术相比具有以下的有益效果和显著的技术进步：1）通过流水线的方式简化项目部署过程，节省时间与人力；2）通过静态代码扫描模块，可以扫描出静态代码可能存在的风险，扫描出bug之后可以按bug的严重程度分等级，对于critical和high级别的bug可以让开发人员进行修复。修复成功后，即可通过镜像发布模块发布镜像，减少了项目上线后的风险，减少企业的损失。
20.3）通过服务网格模块，可以实现精细化控制流量。先将小部分流量转发到新版本进行测试，如果测试不通过可以立即回滚，以减小项目上线后的风险，可以优化用户体验。
21.4）通过流量转发模块，不会有任何流量转移到已经停机的pod上，这意味着在整个项目部署过程中，用户对于部署这件事情毫不知情，即可实现用户无感的部署。
附图说明
22.图1为本发明的用户无感的微服务容器部署流程示意图；图2为用户无感的微服务容器部署装置（系统）结构示意图；图3为执行流水线的流程示意图；
图4为pod模板的流程示意图；图5为探针工作的流程示意图；图6为启动服务网格的流程示意图；图7为部署过程中流量转发的流程示意图。
具体实施方式
23.参阅图1，所述用户无感的微服务容器部署方法，具体包括如下步骤：步骤s1：推送代码后自动启动流水线；步骤s2：推送新版本镜像到镜像仓库；步骤s3：静态代码扫描；步骤s4：在k8s集群上的空闲worker部署新版本镜像；步骤s5：启动istio服务网格；步骤s6：验证通过后将所有流量转发到新版本所在集群中。
24.参阅图2，所述用户无感的微服务容器部署装置（系统）由流水线模块依次连接的代码扫描模块、镜像发布模块、升级镜像模块、服务网格模块和流量转发模块组成，所述流水线模块用于推送代码后自动启动流水线，简化项目部署过程；所述代码扫描模块用于静态代码扫描，检出代码中可能存在的风险；所述镜像发布模块用于推送新版本镜像到镜像仓库；所述升级镜像模块用于在k8s集群上的空闲worker部署新版本镜像；所述服务网格模块用于启动istio服务网格，实现精细化控制流量；所述流量转发模块用于验证通过后将所有流量转发到新版本所在集群中，实现用户无感的微服务容器部署。
25.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
26.实施例1参阅图1，一种用户无感的微服务部署方法具体包括下述步骤：步骤s1：推送代码后自动启动流水线的过程如下：步骤s11：在服务器上部署runner用于运行流水线，在本实例中，使用gitlab的group runner；步骤s12：通过git命令将代码推送至已有的gitlab代码仓库；参阅图3，执行流水线的流程如下：步骤s13：启动gitlab ci/cd流水线，在本实例中通过编写.gitlab-ci.yml文件来设置流水线的相关阶段以及每个阶段需要运行的命令等配置。通过流水线的方式简化项目部署过程，大大节省了时间与人力。
27.步骤s2：推送新版本镜像到镜像仓库的过程具体包括：步骤s21：使用docker拉取项目依赖的基础镜像，在本实例中基础镜像为项目中用到的实体类依赖等，通过docker构建镜像后保存在阿里云镜像仓库；步骤s22：将项目打包成新版本镜像；步骤s23：通过docker将新版本镜像推送至阿里云镜像仓库；
步骤s24：生成产物供所述步骤s3静态代码扫描使用，在本实例中所述产物为项目编译后代码文件。
28.步骤s3：静态代码扫描的过程具体包括：步骤s31：拉取所述步骤s2推送新版本镜像到镜像仓库的产物，在本实例中通过docker从阿里云镜像仓库中拉取镜像；步骤s32：根据项目选择代码扫描工具，进行静态代码扫描，在本实例中选择spotbugs工具对java微服务进行静态代码扫描，通过静态代码扫描模块扫描出代码中可能存在的风险。
29.步骤s4：在k8s集群上的空闲worker部署新版本镜像的过程具体包括；步骤 s41：启动service服务；步骤 s42：定义pod模板；步骤s43：根据所述步骤s42中定义的模板创建replica set；所述步骤s41中启动service服务的过程中包括：通过设置服务的标签来使服务可以匹配到相应的pods，在本实例中通过配置service.yml文件中的label来设置标签。
30.参阅图4，所述步骤 s42的定义pod模板的流程具体包括以下步骤：步骤s421：设置pod的副本数量，在本实例中讲副本数量设置为3；步骤s422：设置pod的标签，用于被相应的service服务选中，在本实例中通过配置pod-template.yml文件中的label来设置标签；步骤s423：将pod的镜像设置为所述步骤2中推送的新版本镜像，用于创建对应pods，在本实例中通过配置pod-template.yml文件中的image来设置标签；步骤s424：设置生存探针和就绪探针，用于判断pod是否存活和就绪；参阅图5，对于生存探针，一共检测三次。第一次在pod启动后经过生存探针的initialdelayseconds秒后开始检测，检测结果正常；第二次经过生存探针的periodseconds秒后再进行检测，检测结果正常；第三次经过生存探针的periodseconds秒后再进行检测，检测结果正常。对于就绪探针，一共检测三次。第一次在pod启动后经过就绪探针的initialdelayseconds秒后开始检测，检测结果正常；第二次经过就绪探针的periodseconds秒后再进行检测，检测结果正常；第三次经过就绪探针的periodseconds秒后再进行检测，检测结果正常。
31.步骤s425：设置相应的环境变量。
32.所述步骤s43中根据所述步骤s42中定义的模板创建replica set过程中，在本实例中通过kubectl创建replica set。
33.参阅图6，所述步骤s5的启动istio服务网格的过程具体包括如下步骤：步骤s51：启动gateway服务；步骤s52：启动destination rule服务；步骤s53：启动virtual service服务。
34.所述步骤s51中启动gateway服务的过程具体包括如下步骤：步骤s511：通过设置标签以匹配istio出口网关，在本实例中通过设置gateway.yml文件中的selector来设置需要匹配的标签；步骤s512：设置服务的protocol和端口号，在本实例中protocol为http，并且绑定
端口号80；步骤s513：设置匹配host，在本实例中设置为*。
35.所述步骤s52中启动destination rule服务的过程具体包括如下步骤：步骤s521：设置host名，在本实例中设置为destination-rule；步骤s522：设置subsets集合，其中包括新版本和旧版本两个子集，并且设置对应版本的标签，在本实例中通过设置destinationrule.yml文件中的subsets来设置子集。
36.所述步骤s53中启动virtual service服务的过程具体包括如下步骤：步骤s531：设置匹配host名，在本实例中设置为*；步骤s532：绑定所述步骤s51中启动的gateway服务，在本实例中设置为所述步骤s51中的gateway；步骤s533：设置route规则。
37.所述步骤s533中设置route规则的过程具体包括如下步骤：步骤s5331：设置destination中所匹配的service服务，在本实例中为所述步骤s41启动的service服务；步骤s5332：设置destination中新、旧版本的subset子集，在本实例中为所述步骤s522中所述两个子集；步骤s5333：设置将客户端的请求流量转移到新、旧版本上的流量比例，在本实例中将新版本的weight设置为10，表明将有10%的流量被转移到新版本上；将旧版本的weight设置为90，表明将有90%的流量将被转移到旧版本上，通过服务网格实现精细化控制流量。
38.参阅图7，所述步骤s6将所有流量转发到新版本所在的集群中，具体包括如下步骤：步骤s61：验证所述步骤s5333中转移到新版本上的10%流量，检查是否存在bug；步骤s62：如果在新版本上的10%流量不存在bug，那么修改所述步骤s53中的virtual service服务，将所有流量转发到新版本上，并断开与旧版本的连接；如果在新版本上的10%流量存在bug，则进行回滚，将10%流量重新转移到旧版本中，通过流量转发模块使得用户对部署毫不知情，实现用户无感的微服务容器部署。
39.本发明采用流水线的项目部署方法，通过静态代码扫描模块、服务网格实和流量转发模块，使得发布新版本时停机时间为0，用户可以丝滑地过渡到新版本而不影响使用应用。以上只是对本发明作进一步的说明，并非用以限制本专利，凡为本发明等效实施，均应包含于本专利的权利要求范围之内。