微服务架构下的一种测试环境多级路由复用方案的制作方法

1.本发明涉及多类数据调用与处理技术领域，尤其涉及微服务架构下的一种测试环境多级路由复用方案。


背景技术：

2.本部分中的陈述仅提供与本公开有关的背景信息并且不构成现有技术。
3.数据的调用是一种将不同算法不同处理逻辑的数据统一导向或者执行到同一位置的过程，其中数据调用通常采用数据库之间的衔接作用，随着技术的日益革新，数据的调用以及处理逐渐由单独的数据调用处理，变成了多种数据的调用处理，也就是并行数据处理，在并行数据处理下，通常面临多套开发环境以及多套测试环境。
4.现有公开的技术中，在面向并行业务时，具有两种常见的模式：一种是维护多套完整、独立的开发、测试环境，每套环境使用独占的资源、以及固定的分支，需求分支合并到相应的环境进行开发、测试，逐级推进，直至上线；另外一种是基于全链路染色的服务调用路由方案，上述两种方案均可以解决并行的复杂运行环境，但是上述两种在进行并行环境的数据处理、复用等时，只能停留在基础的环境中，并且每次处理过程中，不同需求之间具有依赖顺序关系，也就是需要按照规定顺序进行并行开发等。


技术实现要素：

5.发明人通过研究发现：目前公开的技术中，很多并行路线的处理以及开发，经常会需要依靠上一级或者上一步的开发结果或者开发的需求进行，这样无非就是增加了开发的时间成本，其实并没有达到真正意义上的并行开发，因而也无法进行多级复用环境的路由处理。
6.本公开的目的在于提供微服务架构下的一种测试环境多级路由复用方案，通过执行本公开的所记载的步骤1至步骤4，可以有效解决现有技术在面向多级复用环境路由时，需要按环境和需求进行独立建立资源且必须要对需求的子需求进行层层依赖处理的技术问题。
7.据本公开的一个方面，提供微服务架构下的一种测试环境多级路由复用方案，包括以下步骤：步骤1.环境启动，启动特性环境，隔离打包环境代码以及组件；步骤2.环境变量配置，注册中间件资源，得到附有特性环境标值的中间信息；步骤3.调用请求，根据用户点击选择的浏览器时发送的请求，来确定对应的特性环境，调用相应请求处理；步骤4.循环上述步骤1-3，直至用户需要的调用结束，结束循环。
8.发明人在工作过程中发现，目前公开的技术中，虽然已经具有面向多级复用环境的路由方法，但是均为基于基础环境的使用，无法真正意义上满足并行开发的要求与速度，基于此，发明人通过大量数据的调试以及处理模式的融合试错，得到了本公开所记载的技术方案，来有效解决面向多级复用环境时的并行开发。
9.本公开的一些实施例中，所述步骤1包括以下内容：隔离打包环境代码以及组件，
形成容器化部署，在容器化部署的过程中，将容器的名称命名为：服务名称 特性环境标；以此类推，增加后续新增容器。
10.本公开的一些实施例中，所述步骤2包括以下内容：注册的中间件资源包括 zookeeper、nacos、activemq的中间件资源。
11.本公开的一些实施例中，所述步骤2包括以下内容：注册的中间件资源包括 zookeeper、nacos、activemq的中间件资源。
12.本公开的一些实施例中，所述步骤3包括以下内容：请求调用时根据app 发送的请求来确定当前请求的是那个特性环境，如果请求中没有加入特性环境，则视为走基线环境。
13.本公开的一些实施例中，所述步骤3具体包括以下步骤：步骤3-1.在发现服务过程中，要先获取可用集群列表；步骤3-2.从集群列表中获取对应的所需的可用服务；步骤3-3.把步骤3-2的结果添加到方法域缓存列表中；步骤3-4. 判断是否存在多个集群环境，判断结果为是，继续执行迭代步骤3-1至3-3,；判断结果为否，在进行执行新的迭代算法；步骤3-5.根据规则计算迭代次数，至少迭代一次，若仅执行一次迭代，则判断为没有子级需求；步骤3-6.获取迭代截取的值，进而根据不同的中间件去匹配不同的服务列表。
14.本公开的一些实施例中，所述步骤3还具体包括如下步骤：步骤3-7.判断是否匹配到值；步骤3-8.判断结果为否，则迭代的索引值加一，继续步骤3-5 至3-6的操作，直至迭代数量终结；步骤3-9：判断结果为是，则为最优的服务列表，即立即跳出迭代；步骤3-10：匹配选择逻辑，若没有匹配到，则执行基线服务；若匹配到，则执行所匹配到的服务。
15.本发明与目前公开的技术相比，具有如下的优点和有益效果：本公开所记载的技术方案利用了特性环境、环境配置以及调用请求来实现多级路由，功能更加强大与灵活，部署成本低，无需人工维护路由表，部署时设置微服务的环境标识，系统自动、实时维护依赖关系，并自动路由到相应的父级环境，如直接父级不存在，则可以复用父父级环境，直至复用根环境；同时很好的支持了有时间先后依赖的这种常见业务需求的并行研发，大大提高研发效率，也可以非常方便对某个环境的服务进行本地服务的在线替换、调试，而不会阻碍、影响其他开发和测试人员的正常工作。
附图说明
16.图1是本发明的处理逻辑图；
17.图2是本发明的并行需求处理逻辑图。
具体实施方式
18.请一并参考说明附图1-说明附图2，本实施例提供了微服务架构下的一种测试环境多级路由复用方案，该微服务架构下的一种测试环境多级路由复用方案已经处于实际测试使用阶段，且发明人已经进行了部分实际案例测试。
19.在以下段落中，更为详细地限定了实施例的不同方面。如此限定的各方面可与任何其他的一个方面或多个方面组合，除非明确指出不可组合。尤其是，被认为是优选的或有利的任何特征可与其他一个或多个被认为是优选的或有利的特征组合。本发明中出现的“第一”、“第二”等用语仅是为了方便描述，以区分具有相同名称的不同组成部件，并不表示先后或主次关系。
20.本公开的一些实施例为：包括以下步骤：步骤1.环境启动，启动特性环境，隔离打包环境代码以及组件；步骤2.环境变量配置，注册中间件资源，得到附有特性环境标值的中间信息；步骤3.调用请求，根据用户点击选择的浏览器时发送的请求，来确定对应的特性环境，其中发送请求也可以来自于app或者其他需要进行请求命令发布的客户端等，调用相应请求处理；步骤4.循环上述步骤 1-3，直至用户需要的调用结束，结束循环。上述处理逻辑与已经公开的技术相比具有无需按环境和需求进行独立建立资源，即复用资源，同时可以为需求的子需求的层层依赖提供了解决方案，进而大大提高研发效率，具体对比来说：
21.其中一种公开的技术执行过程为：开发环境到测试环境到预发环境再到线上环境，每一个环节都必须依靠或者按照顺序进行，初始要投入一至两周的时间搭建环境，既占用较多服务器资源，也需要持续投入人力维护，而且还长期存在着其他方面的问题，如分支合并经常冲突、多套环境的配置经常不同步、专属环境总是不够、各固定分支代码差异随时间越来越大、环境极其不稳定等等；
22.另外一种公开的技术执行过程为从特性环境到集成环境再到预发环境再到线上环境，虽然整个过程中，做到了环境复用，但仅支持基础环境的复用，还有一些需求是有依赖关系的，例如需求a上线后，需求b才能上线，但等a上线后再开发b需求，时间成本将会大大增加。
23.根据上述公开技术的问题，发明人进行整合分析，得到了本公开的技术方案，参考说明附图2，本公开的技术录像可以在需求a执行需求b的时候，并行执行需求c以及需求d，可以大大提高开发效率，降低时间成本。
24.其中，步骤1包括以下内容：隔离打包环境代码以及组件，形成容器化部署，在容器化部署的过程中，将容器的名称命名为：服务名称 特性环境标；以此类推，增加后续新增容器，需要说明的是，后续新增容器的命名规则也同样为：服务名称 特性环境标；步骤2包括以下内容：注册的中间件资源包括zookeeper (分布式的，开放源码的分布式应用程序协调服务)、nacos(帮助构建云原生应用的动态服务发现、配置和服务管理平台)、activemq(开放源代码消息中间件) 的中间件资源；步骤3包括以下内容：请求调用时根据app发送的请求来确定当前请求的是那个特性环境，如果请求中没有加入特性环境，则视为走基线环境；步骤3具体包括以下步骤：步骤3-1.在发现服务过程中，要先获取可用集群列表；步骤3-2.从集群列表中获取对应的所需的可用服务，例如：a逻辑代码需要获取b服务的b_1接口，如果存在，则返回这个集群中b_1的提供者服务信息，以便后面筛选调用；步骤3-3.把步骤3-2的结果添加到方法域缓存列表中；步骤3-4.判断是否存在多个集群环境，判断结果为是，继续执行迭代步骤3-1 至3-3,；判断结果为否，在进行执行新的迭代算法，从当前的请求链路中获取环境标识，需要注意的是，此处使用到了全链路追踪技术，最终的环境标识要根据具体的链路技术去获取；步骤3-5.根据规则计算迭代次数，至少迭代一次，若仅执行一次迭代，则判断为没有子级需求；步骤3-6.获取迭代截取的值，进而根据不同的中间件去匹配不同的服务列表，此处的实现基于接口实现，具体的实现逻辑为多个中间件一对一匹配执行。
25.步骤3还具体包括如下步骤：步骤3-7.判断是否匹配到值；步骤3-8.判断结果为否，则迭代的索引值加一，继续步骤3-5至3-6的操作，直至迭代数量终结；步骤3-9：判断结果为是，则为最优的服务列表，即立即跳出迭代；步骤3-10：匹配选择逻辑，若没有匹配到，则执行基线服务；若匹配到，则执行所匹配到的服务。
26.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。