CN116243930A - 多版本并行环境设计方法及搭建系统 - Google Patents

Abstract

本发明提供了一种多版本并行环境设计方法及搭建系统，涉及计算机技术领域，包括：步骤S1：将所有服务的实例部署到一套物理环境中，服务名以迭代版本号+原服务名进行区分；步骤S2：部署完成后，建立并行环境隔离策略，包括服务路由隔离、中间件隔离以及数据库隔离。该发明能够充分利用资源，扩容缩容灵活无上线，维护成本低，开发效率高；重复利用未变更资源，使其充分复用，通过相关自定义的隔离策略来避免资源复用带来的干扰，既不影响业务的正常运转，还能够提高资源利用率。

Description

多版本并行环境设计方法及搭建系统

技术领域

本发明涉及计算机技术领域，具体地，涉及一种多版本并行环境设计方法及搭建系统。

背景技术

在微服务架构模式下，随着业务的不断发展和团队规模的日渐壮大，微服务数量不断膨胀，当前的依靠物理隔离的多环境部署方式维护成本与日俱增，渐渐无法满足需求。图1为最初的依靠物理隔离的多环境部署方式，开发和测试环境各自有三套完全独立的环境，从网关、中间件到数据库都是完全独立的一套。开发如果有并行的开发需求时，提前商量好占用不同的开发环境，测试也是如此。

这种部署方式在应用数量不多、团队规模一般的情况下，可以比较正常的运转。但是随着服务数量的不断增加，团队规模的日渐壮大，很多问题就开始慢慢暴露出来了。比如：1)开发和测试为了保证环境的一致，每次开发和提测，需要花较多时间在环境准备上，非常影响项目的迭代效率；2)团队规模大了以后，多需求并行的情况增多，争抢环境严重；3)完全依靠物理隔离的方式来实现多需求并行，维护成本高，且资源利用率非常低。

综上所述，环境治理的需求也就应运而生。当前的场景，急需一套设计完善的多版本并行环境来解决上述的问题。

发明内容

针对现有技术中的缺陷，本发明提供一种多版本并行环境设计方法及搭建系统。

根据本发明提供的一种多版本并行环境设计方法及搭建系统，所述方案如下：

第一方面，提供了一种多版本并行环境设计方法，所述方法包括：

步骤S1：将所有服务的实例部署到一套物理环境中，服务名以迭代版本号+原服务名进行区分；

步骤S2：部署完成后，建立并行环境隔离策略，包括服务路由隔离、中间件隔离以及数据库隔离。

优选地，所述步骤S1包括：将实例都部署在一套dev环境上，多个服务都根据master部署对应的实例，此为主环境；

此后每一次需求，即为一个新的迭代，但每一次迭代不需要部署全链路涉及的全部服务，只需新部署需要改动的服务。

优选地，所述服务路由隔离解决不变更应用复用的问题，通过自定义负载均衡策略，如果对应并行版本实例存在，由对应并行版本实例处理，如果对应并行版本不存在，则由主环境来处理，具体包括：

请求入口：需要请求header中塞入并行版本号request-version字段，并由此开始一路向下全链路透传；

网关：拦截所有的请求，取出请求头中的并行版本号，根据并行版本号请求到对应版本的服务实例；

服务间调用：服务之间的调用需进行自定义负载，根据并行版本存在由并行版本消费，并行版本不存在由主环境消费的原则，将并行版本号一直向下传递。

优选地，所述网关使用的是spring cloud gateway；通过实现GlobalFilter接口，重写filter方法来实现对请求进行拦截，取出请求header中的并行版本号字段，然后通过实现ReactorServiceInstanceLoadBalancer接口，重写choose方法来实现自定义负载均衡。

优选地，所述网关还包括：将并行版本号和对应的服务实例对应上，需在实例的元数据中塞入并行版本号；

通过配置文件的方式将并行版本号塞入实例的元数据，在进行负载均衡的时候，请求header中的版本号和获取的所有在线实例中的并行版本号进行匹配，如果对应并行版本号的实例在线，则请求到对应并行版本实例，如果对应并行版本号的实例不存在，则请求到主环境。

优选地，所述服务间调用中将并行版本号向下传递包括：通过实现RequestInterceptor，重写apply方法，将并行版本号放进RequestTemplate的header中实现向下透传。

优选地，所述中间件隔离主要降低多需求并行时的干扰，具体包括：

1)每个迭代的实例都有一份自己的配置，实现配置的隔离；

2)当并行版本实例存在时，并行版本的消息只被并行版本的实例消费，只有当并行版本实例不存在时才被主环境消费。

优选地，将并行版本号在生产者端放进消息的properties中，消费者从消息上下文的properties中获取，实现并行版本号的透传。

优选地，采用切换consumerGroup的方式实现控制某些消费者消费，某些不消费；

同一个topic下，多个consumeGroup下的消费进度是各自维护，互不干扰的，生产者往对应topic发送的消息，被每一个consumerGroup消费一次，对应并行版本号的消费者实例正常消费，其他消费者实例进行空消费；对应并行版本号的消费者在线，则由对应并行版本消费者实例消费，否则由主环境代为消费；

其中，通过queryTopicConsumeByWho和getClientConnection方法判断对应consumerGroup是否有实例在线。

第二方面，提供了一种多版本并行环境搭建系统，所述系统包括：

模块M1：将所有服务的实例部署到一套物理环境中，服务名以迭代版本号+原服务名进行区分；

模块M2：部署完成后，建立并行环境隔离策略，包括服务路由隔离、中间件隔离以及数据库隔离。

与现有技术相比，本发明具有如下的有益效果：

1、相比传统物理隔离的方式，该方案充分利用资源，扩容缩容灵活无上线，维护成本低，开发效率高；

2、重复利用未变更资源，使其充分复用，通过相关自定义的隔离策略来避免资源复用带来的干扰，既不影响业务的正常运转，也使得资源利用率有了明显的提高。

本发明的其他有益效果，将在具体实施方式中通过具体技术特征和技术方案的介绍来阐述，本领域技术人员通过这些技术特征和技术方案的介绍，应能理解所述技术特征和技术方案带来的有益技术效果。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为最初的依靠物理隔离的多环境部署方式；

图2为本发明实例部署图；

图3为服务路由隔离实现示意图；

图4为消息中间件多版本并行消费示意图。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。

本发明实施例提供了一种多版本并行环境设计方法，参照图2所示，该方法具体包括：

步骤S1：将所有服务的实例部署到一套物理环境k8s中，每个服务都是以一个容器(实例)的方式部署，服务名以迭代版本号+原服务名进行区分；

步骤S2：部署完成后，建立并行环境隔离策略，包括服务路由隔离、中间件隔离以及数据库隔离。

其中，步骤S1包括：将实例都部署在一套dev环境上，多个服务都根据master分支(代码主分支)部署对应的实例，此为主环境；此后每一次需求，即为一个新的迭代，但每一次迭代不需要部署全链路涉及的全部服务，只需新部署需要改动的服务。

步骤S2中的服务路由隔离解决不变更应用复用的问题，通过自定义负载均衡策略，如果对应并行版本实例存在，由对应并行版本实例处理，如果对应并行版本不存在，则由主环境来处理，具体包括：

请求入口：需要请求header中塞入并行版本号request-version(自定义的并行版本号字段)字段，并由此开始一路向下全链路透传；

网关：拦截所有的请求，取出请求头中的并行版本号，根据并行版本号请求到对应版本的服务实例；

服务间调用：服务之间的调用需进行自定义负载，根据并行版本存在由并行版本消费，并行版本不存在由主环境消费的原则，将并行版本号一直向下传递。

网关使用的是spring cloud gateway(网关服务)；通过实现GlobalFilter(全局过滤器接口)接口，重写filter方法(需重写的过滤方法)来实现对请求进行拦截，取出请求header中的并行版本号字段，然后通过实现ReactorServiceInstanceLoadBalancer接口(负载均衡器接口)，重写choose方法(需重写的自定义负载均衡方法)来实现自定义负载均衡。

网关还包括：将并行版本号和对应的服务实例对应上，需在实例的元数据中塞入并行版本号；通过配置文件的方式将并行版本号塞入实例的元数据，在进行负载均衡的时候，请求头中的版本号和获取的所有在线实例中的并行版本号进行匹配，如果对应并行版本号的实例在线，则请求到对应并行版本实例，如果对应并行版本号的实例不存在，则请求到主环境。

服务间调用中将并行版本号向下传递包括：通过实现RequestInterceptor(Feign拦截器接口)，重写apply方法(需重写的拦截后处理方法)，将并行版本号放进请求的header中实现向下透传。中间件隔离主要降低多需求并行时的干扰，具体包括：

1)每个迭代的实例都有一份自己的配置，实现配置的隔离；

2)当并行版本实例存在时，并行版本的消息只被并行版本的实例消费，只有当并行版本实例不存在时才被主环境消费。

将并行版本号在生产者端放进消息的properties(属性)中，消费者从消息上下文的properties中获取，实现并行版本号的透传。采用切换consumerGroup(消费者组)的方式实现控制某些消费者消费，某些不消费；同一个topic(主题)下，多个consumeGroup下的消费进度是各自维护，互不干扰的，生产者往对应topic发送的消息，被每一个consumerGroup消费一次，对应并行版本号的消费者实例正常消费，其他消费者实例进行空消费；对应并行版本号的消费者在线，则由对应并行版本消费者实例消费，否则由主环境代为消费；

其中，通过queryTopicConsumeByWho(mqadmin内置方法)和getClientConnection方法(mqadmin内置方法)判断对应consumerGroup是否有实例在线。

本发明还提供一种多版本并行环境搭建系统，所述多版本并行环境搭建系统可以通过执行所述多版本并行环境设计方法的流程步骤予以实现，即本领域技术人员可以将所述多版本并行环境设计方法理解为所述多版本并行环境搭建系统的优选实施方式。该系统具体包括：

模块M1：对环境中的实例进行部署；

模块M2：部署完成后，建立并行环境隔离策略，包括服务路由隔离、中间件隔离以及数据库隔离。

接下来，对本发明进行更为具体的说明。

多版本并行环境简单来说就是一套能满足多个需求并行开发迭代的运行环境。这里需要重点强调“一套”和“多需求并行开发”。

之前旧的部署方式依靠维护多套环境这种物理隔离的方式来满足多个需求并行开发和测试，就会产生上述那些维护困难，资源利用低效的问题。这些问题主要是因为要从头到尾维护多套独立的环境产生的，那么是不是可以考虑只用一套环境。

参照图2所示，上述实例都部署在一套dev环境上，服务A\B\C都根据master部署对应的实例，此为主环境。(主环境是相对稳定的环境，和每一次迭代不相关)。

此后每一次需求，即为一个新的迭代，但是每一次迭代不需要部署全链路涉及的全部服务，只需要新部署需要改动的服务。比如迭代211只需要修改服务A和服务B，那么就只需要用对应的分支部署服务A和服务C，而不用全链路的应用都部署一遍，避免了不必要的资源浪费。且该方式需求的并行完全不受限于实际物理环境，可以无限扩展。该方案对没有变更的应用服务进行复用，复用就会带来一个新的问题，就是如何在复用的前提下，避免需求并行开发带来的干扰？

并行环境隔离策略：

在一套物理环境情况下，想要复用相关组件和未变更应用，实现完整的多版本并行环境，就需要一套完善的并行环境隔离策略。这里主要包含以下几个方面：

·服务路由隔离；

·中间件隔离；

其中，服务路由隔离包括：

服务A-311发起的请求，如何保证请求到服务B-311上而不是主环境上？当服务B在211迭代中不涉及变更，实例B-211不存在时，服务A-211的请求如何自动调用到主环境上，后续又如何调回到迭代211中的服务C-211？

参照图3所示，解决上述的问题，就需要实现服务路由隔离，让请求根据并行版本号请求到指定的实例。

请求入口：

前端等请求入口需要请求header中塞入并行版本号request-version字段，并由此开始一路向下全链路透传。

网关：

网关需要拦截所有的请求，取出请求头中的并行版本号，根据并行版本号请求到对应版本的服务实例，比如原先是需要请求到服务A的任一实例，但是现在需要请求到并行版本号为311的实例，并将并行版本号继续往下透传。

该处需要解决的问题：

1)怎么拦截所有的请求，实现自定义负载均衡？

2)怎么根据并行版本号和对应的服务实例对应上？

针对第1)个问题，以实际情况为例，网关使用的是spring cloud gateway。因此，可以通过实现GlobalFilter接口，重写filter方法来实现对请求进行拦截，取出Request中header的并行版本号字段。然后，通过实现ReactorServiceInstanceLoadBalancer接口，重写choose方法来实现自定义负载均衡。

针对第2)个问题，为了将并行版本号和对应的服务实例对应上，那么我就需要在实例的元数据中塞入并行版本号。以nacos为例，可以通过配置文件的方式将并行版本号塞入实例的元数据中，比如在进行负载均衡的时候，可以请求头中的版本号和获取的所有在线实例中的并行版本号进行匹配，如果对应并行版本号的实例在线，则请求到对应并行版本实例，如果对应并行版本号的实例不存在，则请求到主环境。

服务间调用：

服务之间的调用也需要进行自定义负载，根据并行版本存在由并行版本消费，并行版本不存在由主环境消费的原则，将并行版本号一直向下传递。

以OpenFeign为例，首先我们需要拦截所有请求，获取请求中的并行版本号。这里可以通过实现HandlerInterceptor接口，重写preHandle方法来获取request中的并行版本号。第二步就需要自定义负载均衡策略，通过继承AbstractLoadBalancerRule类，重写choose方法来实现。通过比较从nacos获取的所有在线实例元数据中的并行版本号和请求中的并行版本号是否一致来判断并行版本号对应的实例是否在线，如果存在对应并行版本的实例，则请求到对应并行版本实例，否则请求到主环境实例。

最后就需要解决如何将并行版本号向下传递的问题？

可以通过实现RequestInterceptor，重写apply方法，将并行版本号放进RequestTemplate的header中实现向下透传。

中间件隔离：

上述服务路由隔离主要是解决不变更应用复用的问题，通过自定义负载均衡策略，如果对应并行版本实例存在，由对应并行版本实例处理，如果对应并行版本不存在，则由主环境来处理。那么对于复用的中间件，如何操作来降低多需求并行时的干扰成为下一步需要重点思考的问题。

配置中心：

通过在注册中心往对应实例的元数据中塞入对应的并行版本号和服务路由隔离策略来实现了同一服务不同并行实例之间的隔离。但是此时，配置上还未进行隔离，同一服务多个版本的实例此时仍共用配置中心的同一份配置，如果不同迭代使用的配置信息存在不一致，此时仍会互相干扰，带来影响。所以需要实现每个迭代的实例都有一份自己的配置，实现配置的隔离。

以nacos为例，可以在创建对应服务实例的时候新建一份applicationName-并行版本号.yaml类似的配置文件。为了让此配置文件生效，在对应实例的环境变量中注入：

SPRING_PROFILES_ACTIVE＝并行版本号；

至此，就已实现了并行版本实例间配置上的隔离。

消息队列：

复用同一套mq，在消费逻辑有改动的情况下，因为此时不同消费者的消费逻辑不一致了，就会存在多需求并行开发互相干扰的问题。此时，就需要一套方案来实现当并行版本实例存在时，并行版本的消息只被并行版本的实例消费，只有当并行版本实例不存在的时候才被主环境消费。

这里需要考虑的几个问题：

如何透传并行版本号：

可以将并行版本号在生产者端放进消息的properties中，消费者从消息上下文的properties中获取，以此来实现并行版本号的透传。

如何控制某些消费者消费，某些不消费：

参照图4所示，采用切换consumerGroup的方式来实现。同一个topic下，多个consumeGroup下的消费进度是各自维护，互不干扰的，生产者往对应topic发送的消息，会被每一个consumerGroup消费一次。对应并行版本号的消费者实例正常消费，其他消费者实例进行空消费。对应并行版本号的消费者在线，则由对应并行版本消费者实例消费，否则由主环境代为消费。

mqAdmin中提供了对应的方法，借助queryTopicConsumeByWho和getClientConnection方法即可判断对应consumerGroup是否有实例在线。

本发明实施例提供了一种多版本并行环境设计方法及搭建系统，相比传统物理隔离的方式，该方案充分利用资源，扩容缩容灵活无上线，维护成本低，开发效率高。重复利用未变更资源，使其充分复用，通过相关自定义的隔离策略来避免资源复用带来的干扰，既不影响业务的正常运转，也使得资源利用率有了明显的提高。

本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统及其各个装置、模块、单元以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统及其各个装置、模块、单元以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同功能。所以，本发明提供的系统及其各项装置、模块、单元可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置、模块、单元也可以视为硬件部件内的结构；也可以将用于实现各种功能的装置、模块、单元视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

Claims (10)

1.一种多版本并行环境设计方法，其特征在于，包括：

步骤S1：将所有服务的实例部署到一套物理环境中，服务名以迭代版本号+原服务名进行区分；

步骤S2：部署完成后，建立并行环境隔离策略，包括服务路由隔离、中间件隔离以及数据库隔离。

2.根据权利要求1所述的多版本并行环境设计方法，其特征在于，所述步骤S1包括：将实例都部署在一套dev环境上，多个服务都根据master部署对应的实例，此为主环境；

此后每一次需求，即为一个新的迭代，但每一次迭代不需要部署全链路涉及的全部服务，只需新部署需要改动的服务。

3.根据权利要求2所述的多版本并行环境设计方法，其特征在于，所述服务路由隔离解决不变更应用复用的问题，通过自定义负载均衡策略，如果对应并行版本实例存在，由对应并行版本实例处理，如果对应并行版本不存在，则由主环境来处理，具体包括：

请求入口：需要请求header中塞入并行版本号request-version字段，并由此开始一路向下全链路透传；

网关：拦截所有的请求，取出请求头中的并行版本号，根据并行版本号请求到对应版本的服务实例；

服务间调用：服务之间的调用需进行自定义负载，根据并行版本存在由并行版本消费，并行版本不存在由主环境消费的原则，将并行版本号一直向下传递。

4.根据权利要求3所述的多版本并行环境设计方法，其特征在于，所述网关使用的是spring cloud gateway；通过实现GlobalFilter接口，重写filter方法来实现对请求进行拦截，取出请求header中的并行版本号字段，然后通过实现ReactorServiceInstanceLoadBalancer接口，重写choose方法来实现自定义负载均衡。

5.根据权利要求3所述的多版本并行环境设计方法，其特征在于，所述网关还包括：将并行版本号和对应的服务实例对应上，需在实例的元数据中塞入并行版本号；

通过配置文件的方式将并行版本号塞入实例的元数据，在进行负载均衡的时候，请求header中的版本号和获取的所有在线实例中的并行版本号进行匹配，如果对应并行版本号的实例在线，则请求到对应并行版本实例，如果对应并行版本号的实例不存在，则请求到主环境。

6.根据权利要求3所述的多版本并行环境设计方法，其特征在于，所述服务间调用中将并行版本号向下传递包括：通过实现RequestInterceptor，重写apply方法，将并行版本号放进RequestTemplate的header中实现向下透传。

7.根据权利要求3所述的多版本并行环境设计方法，其特征在于，所述中间件隔离主要降低多需求并行时的干扰，具体包括：

1)每个迭代的实例都有一份自己的配置，实现配置的隔离；

2)当并行版本实例存在时，并行版本的消息只被并行版本的实例消费，只有当并行版本实例不存在时才被主环境消费。

8.根据权利要求7所述的多版本并行环境设计方法，其特征在于，将并行版本号在生产者端放进消息的properties中，消费者从消息上下文的properties中获取，实现并行版本号的透传。

9.据权利要求7所述的多版本并行环境设计方法，其特征在于，采用切换consumerGroup的方式实现控制某些消费者消费，某些不消费；

同一个topic下，多个consumeGroup下的消费进度是各自维护，互不干扰的，生产者往对应topic发送的消息，被每一个consumerGroup消费一次，对应并行版本号的消费者实例正常消费，其他消费者实例进行空消费；对应并行版本号的消费者在线，则由对应并行版本消费者实例消费，否则由主环境代为消费；

其中，通过queryTopicConsumeByWho和getClientConnection方法判断对应consumerGroup是否有实例在线。

10.一种多版本并行环境搭建系统，其特征在于，包括：

模块M1：将所有服务的实例部署到一套物理环境中，服务名以迭代版本号+原服务名进行区分；

模块M2：部署完成后，建立并行环境隔离策略，包括服务路由隔离、中间件隔离以及数据库隔离。

Images