一种基于k8s+docker及nacos配置中心的系统群环境泳道切换方法与流程

1.本发明涉及互联网技术领域，具体是一种基于k8s docker及 nacos配置中心的系统群环境泳道切换方法。


背景技术：

2.银行同业中大型项目如统一授信项目，关联改造及配合测试回归的系统较多，涉及业务条线较广，所需对应的环境繁杂，各类系统的新环境机器分配、环境搭建、配置变更、持续集成等各个阶段耗时较多，且环境不稳定。
3.现有技术依托于服务器部署weblogic或tomcat等容器，部署 java应用，当需要新的测试环境、数据移植环境场景，则需要新申请服务器，手动部署新的环境依赖，依赖包括但不限于web中间件、缓存中间件(如redis)、数据库等。现有的新环境发布流程和传统的研发投产流程一样。
4.然而，现有的新环境发布流程中涉及到至少三个环境:开发、测试和生产。现实情况是，大型项目还需要新增单独的sit、uat、数据移植、准生产等多套环境，且环境部署的过程中，开发自测没问题，但到了测试或者生产环境程序无法运行，让开发团队排查，经过长时间排查最后发现是测试环境的一个第三方库过时了。这样的现象在软件开发中很普遍，已经不适用如今的快速开发和部署。


技术实现要素：

5.本发明的目的在于提供一种基于k8s docker及nacos配置中心的系统群环境泳道切换方法，以解决上述背景技术中提出的问题。
6.本发明的技术方案是：一种基于k8s docker及nacos配置中心的系统群环境泳道切换方法，包括以下步骤：
7.s1、使用容器和容器编排技术来部署服务；
8.s2、使用helm进行编排配置管理；
9.s3、泳道间服务路由实现；
10.s4、使用jenkins pipeline自动化构建及部署服务。
11.进一步的，s1中，使用容器和容器编排技术来部署服务包括以下步骤：
12.s11、编译应用jar包并创建启动脚本；
13.s12、编写dockerfile文件；
14.s13、制作镜像并启动测试。
15.进一步的，s2中，使用helm进行编排配置管理包括以下步骤：
16.s21、安装配置helm；
17.s22、创建chart应用；
18.s23、创建修改模板。
19.进一步的，s23中，创建修改模板包括以下步骤：
20.s231、将服务抽象分类，分为前端、中间层、dubbo后端、 springboot后端，每类各创建一份能兼容到各个环境的抽象编排配置模板；
21.s232、将相似的地方通过抽象的方式包装起来，将不同的、与服务相关的特性分别存放在一个单独的yaml配置文件。
22.进一步的，s3中，泳道间服务路由实现包括以下步骤：
23.s31、去掉lb、nginx、zk等组件，将服务抽象成两层，第一层包括前端和dubbo consumer，第二层包括dubbo provider；
24.s32、前端和consumer层的服务路由实现；
25.s33、dubbo provider层的服务路由实现。
26.进一步的，s33中，dubbo provider层的服务路由实现包括重写dubbo的loadbalancer接口。
27.进一步的，s3中，provider注册时附带泳道信息，consumer 调用provider时根据流量标识选择相应的provider，若无相应的后端，则fallback到主泳道上。
28.进一步的，s4中，使用jenkins pipeline自动化构建及部署服务包括以下步骤：
29.s41、代码构建阶段：根据项目编写语言使用对应的构建工具进行构建；
30.s42、check阶段：做代码检测和代码扫描；
31.s43、镜像构建阶段：把代码构建产物和基础镜像合成业务镜像；
32.s44、k8s编排配置生成阶段：主要做编排配置渲染；
33.s45、k8s集群更新阶段：利用上一阶段生成的配置对集群的服务进行滚动更新。
34.本发明通过改进在此提供一种基于k8s docker及nacos配置中心的系统群环境泳道切换方法，与现有技术相比，具有如下改进及优点：
35.本发明整合k8s、docker、apollo各自的技术特点，搭建一个统一服务发布平台，实现快速切换泳道并支撑各类项目需要的统一新环境。
附图说明
36.下面结合附图和实施例对本发明作进一步解释：
37.图1是本发明的基于k8s的服务部署架构图；
38.图2是本发明的应用容器结合配置中心的示意图；
39.图3是本发明加了服务路由后的调用关系结构示意图；
40.图4是本发明的helm chart目录结构图；
41.图5是本发明的泳道设计原理图；
42.图6是本发明的服务层次抽象示意图。
具体实施方式
43.下面对本发明进行详细说明，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
44.本发明通过改进在此提供一种基于k8s docker及nacos配置中心的系统群环境泳道切换方法，本发明的技术方案是：
45.如图1-图6所示，一种基于k8s docker及nacos配置中心的系统群环境泳道切换方法，系统涉及前端，后端和相关中间件，整合k8s、docker、apollo各自的技术特点，搭建一个统一服务发布平台，实现快速切换泳道并支撑各类项目需要的统一新环境。
46.首先固定一条主泳道，包含系统完整的服务，其余泳道都对应一个需求分支，如果需求改动了一个或多个服务，那么相应泳道也将包含一个或多个服务。
47.然后将每条泳道都定义好一个指定的入口，如feature
‑ꢀ
id.test.project.oa.com，域名和泳道是一对一的关系，访问指定域名时会优先访问对应泳道中存在的服务，如果该泳道中不存在的服务则会fallback到主泳道上，以此完成整个链路的调用关系
48.具体包括以下步骤：
49.s1、使用容器和容器编排技术来部署服务；
50.s2、使用helm进行编排配置管理；
51.s3、泳道间服务路由实现；
52.s4、使用jenkins pipeline自动化构建及部署服务。
53.其中，s1中，使用容器和容器编排技术来部署服务包括以下步骤：
54.s11、编译应用jar包并创建启动脚本；
55.s12、编写dockerfile文件：
56.touch dockerfile
57.from jdk15:15.0.2
58.maintainer sean《9376168@qq.com》
59.add docker.jar docker.jar
60.add application.properties application.properties
61.add run.sh run.sh
62.cmd["sh","./run.sh"]；
[0063]
s13、制作镜像并启动测试：
[0064]
docker run-d-p 8080:8080springbootdemo
[0065]
浏览器访问：http://ip:8080/test/docker。
[0066]
其中，s2中，使用helm进行编排配置管理包括以下步骤：
[0067]
s21、安装配置helm；
[0068]
s22、创建chart应用；
[0069]
s23、创建修改模板。
[0070]
其中，s23中，创建修改模板包括以下步骤：
[0071]
s231、将服务抽象分类，分为前端、中间层、dubbo后端、 springboot后端，每类各创建一份能兼容到各个环境的抽象编排配置模板；
[0072]
s232、将相似的地方通过抽象的方式包装起来，将不同的、与服务相关的特性分别存放在一个单独的yaml配置文件。
[0073]
chart.yaml记录了项目的基本项目(名字、版本等)， values.yaml记录了项目之
间不一样的特性变量(如健康检测端口， url，副本数量等)。
[0074]
而chart_tpl.yaml、values_tpl.yaml都是模板文件，会根据服务的特性分别渲染成chart.yaml和values.yaml。
[0075]
这样下来，即便有几百个微服务配置只需几份模板就可以满足。
[0076]
其中，s3中，泳道间服务路由实现包括以下步骤：
[0077]
s31、去掉lb、nginx、zk等组件，将服务抽象成两层，第一层包括前端和dubbo consumer，第二层包括dubbo provider；
[0078]
s32、前端和consumer层的服务路由实现：
[0079]
这是服务接入的最外层，每个环境构建完成的时候都将生成一个唯一的域名，如：tapd-123.test.project.oa.com，当我们访问这个域名的时候，流量将进入到指定的nginx-ingress，这个 nginx-ingress则为服务流量做了第一层的路由，将流量优先打到该环境的服务，如果该环境没有对应的服务，则打到主泳道也就是我们的主测试环境；
[0080]
s33、dubbo provider层的服务路由实现：
[0081]
dubbo的consumer选择provider的时候会调用loadbalancer 接口，需要重写dubbo的loadbalancer接口。
[0082]
其中，s3中，provider注册时附带泳道信息，consumer调用 provider时根据流量标识选择相应的provider，若无相应的后端，则fallback到主泳道上。
[0083]
其中，s4中，使用jenkins pipeline自动化构建及部署服务包括以下步骤：
[0084]
s41、代码构建阶段：根据项目编写语言使用对应的构建工具进行构建；
[0085]
s42、check阶段：做代码检测和代码扫描；
[0086]
s43、镜像构建阶段：把代码构建产物和基础镜像合成业务镜像；
[0087]
s44、k8s编排配置生成阶段：主要做编排配置渲染；
[0088]
s45、k8s集群更新阶段：利用上一阶段生成的配置对集群的服务进行滚动更新。
[0089]
其中，k8s docker的部署方式作为本发明的基础设施，在本方案中具有以下优势：简化配置：docker在降低额外开销的情况下提供了同样的功能，将运行环境和配置放在代码汇总然后部署，同一个docker的配置可以在不同的环境环境中使用，降低了硬件要求和应用环境之间耦合度；代码流水线管理：docker给应用提供了一个从开发到上线均一致的环境，让代码的流水线变得简单；提升开发效率：docker可以让几十个服务在docker中运行；调试能力： docker提供了很多的工具，这些工具不一定只是针对容器，但是却适用于容器，其功能包括可以为容器设置检查点，设置版本，查看两个容器之间的差别，这些特性可以帮助调试bug；快速部署： docker为进程创建一个容器，不需要启动一个操作系统，时间缩短为秒级别，可以在数据中心创建销毁资源而无须担心重新启动带来的开销。通常数据中心的资源利用率只有30％，通过使用docker 并进行有效的资源分配可以提高资源的利用率。
[0090]
其中，配置中心设置有配置中心架构，配置中心架构包括：统一管理不同环境、不同集群的配置，其中，apollo提供了一个统一的接口来集中管理不同环境、不同集群、不同命名空间的配置；相同的代码库在不同的集群中部署时可能有不同的配置；有了命名空间的概念，很容易支持多个应用程序共享相同的配置，同时也允许自定义配置；
[0091]
配置更改实时生效，用户修改配置并在apollo发布后，sdk会实时(1秒)接收到最
新配置并通知应用。
[0092]
上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。