CN111131034A - 一种用于分布式系统的基于标签的环境隔离方法 - Google Patents

Abstract

本发明公开了一种用于分布式系统的基于标签的环境隔离方法，涉及环境隔离技术领域，具体包含服务调用按流量标签路由、配置按照标签拉取、消息队列按照标签发送和消费、调度中心按照标签调度四部分。本发明针对分布式服务的服务调用提供了按标签路由，配置中心按照标签拉取配置，任务调度按照标签调度和消息队列按照标签消费；同时通过标签未匹配上路由到不带标签的服务实例的方式，实现了不带标签实例的共享，这样可以以极小的资源就复制出一套独立环境。

Description

一种用于分布式系统的基于标签的环境隔离方法

技术领域

本发明涉及环境隔离技术领域，尤其涉及一种用于分布式系统的基于标签的环境隔离方法。

背景技术

目前一种典型的前后端分离的分布式应用环境的部署是这样的，将全部的服务和中间件以及数据库部署在服务器上，分布式服务之间通过注册到同一个服务注册中心相连，使用共同的消息队列集群，redis集群等中间件，然后通过nginx来做一个负载均衡。

如图1所示，基于这种方式部署的环境，由于每个服务只能提供一个版本的服务，所以具有几个显著的特性：

用作测试环境时，稳定性低。主要是由几个因素导致，1.代码变更频繁，难免有低质量代码会被合并和发布到测试环境中，导致服务不稳定 2.不同需求之间存在冲突，api变更频繁，可能会导致冲突

用作线上环境时，不够灵活。不能够灵活的支撑业务需要的A/B版本测试，或者是针对特定用户的beta测试等

在业务需要重新部署一套环境的情况下，代价很大，服务和中间件还有环境的配置等都需要重新弄。浪费了大量的人力和计算资源，提高了成本

基于上述原因，我们迫切的需要一种能够保障测试环境稳定运行，线上环境能很好的服务用户，同时能够快速部署新环境的解决方案，于是一种用于分布式系统的流量标签路由方法出现了，通过对分布式服务打标签，控制流量按照标签路由来解决我们遇到的分布式服务环境中的问题。

发明内容

本发明所要解决的技术问题是针对分布式服务的服务调用提供了按标签路由，配置中心按照标签拉取配置，任务调度按照标签调度和消息队列按照标签消费，同时通过标签未匹配上路由到不带标签的服务实例的方式，实现了不带标签实例的共享，可以极小的资源就复制出一套独立环境。

本发明为解决上述技术问题采用以下技术方案：

一种用于分布式系统的基于标签的环境隔离方法，具体包含服务调用按流量标签路由、

配置按照标签拉取、消息队列按照标签发送和消费、调度中心按照标签调度四部分；

其中，一、服务调用按流量标签路由，通过SDK的方式实现；

（1） 服务调用时，流量的精细化控制，通过标签实现流量打到特定版本的服务实例上，用于实现应用的A/B测试；

（2）针对特定用户打上标签，用于实现精准的针对特定用户的应用的beta测试，A/B测试；

（3）通过标签的流量路由，用于实现环境的隔离，且作为复制一套自定义环境的基础；

（4）发布阶段，测试人员通过特定的流量标签可直接在线上环境对新发布的代码进行测试，测试完成后直接去除标签，新发布的代码即可对所有用户开放，进而降低线上发布风险；

二、配置按照标签拉取，用于实现新需求的代码在配置变更的情况下，通过给修改的配置打上标签，则可拉取到特定标签的修改后的配置，而不需要改动原有的配置，同时保障原有的服务仍然是稳定的，不会受配置变更的影响；

三、消息队列按照标签发送和消费；

控制消息的消费是按照特定的标签的消费者来消费的：当复制出一套自定义环境，并修改了生产者或者消费者的逻辑或消息体时，通过打上标签，可实现修改过的消息只会被特定标签的消费者消费，而不会被原有的无标签实例消费，实现了环境的隔离；

四、调度中心按照标签调度，用于实现某些调度任务只被特定标签调度的场景和需求。

作为本发明一种用于分布式系统的基于标签的环境隔离方法的进一步优选方案，服务调

用按流量标签路由，通过SDK的方式实现，具体如下：

步骤1，服务注册时，若当前实例有标签，则将当前标签写入服务元数据中；

步骤2，服务调用时，获取目标应用元数据和当前流量标签，若当前流量存在标签，则匹配当前标签，若未匹配上，则选取无标签实例；

步骤3，通过对服务注册写入元数据和服务发现时对标签的匹配处理，可实现服务调用的标签路由。

作为本发明一种用于分布式系统的基于标签的环境隔离方法的进一步优选方案，配置按照标签拉取，通过SDK的方式实现，具体如下：

对于带标签的服务：

当发生了配置变更时，拉取带标签的配置；当未发生配置变更，拉取不带标签的配置，减少重新配置的工作量；

对于不带标签的服务：可通过指定文件名或者指定dataId来拉取应用的配置直接拉取不带标签的配置；

若配置中心的配置不存在元数据或者标签的设计，则可通过添加后缀的方式来实现；

设存在服务A读取的dataId为config_data_A；

当服务A以标签label-1启动时，读取data_id为config_data_A#label-1的配置；

若config_data_A#label-1未读取到，则再读取data_id为config_data_A的配置；

当带标签的实例有特殊配置时，可建立dataId为原有dataId#标签后缀的方式实现对其他实例无影响的配置。

作为本发明一种用于分布式系统的基于标签的环境隔离方法的进一步优选方案，消息队列按照标签发送和消费，通过修改sdk的调度器注册和任务调度server的任务调度策略，应用引入sdk依赖，部署修改后的调度server，具体如下：

步骤4，生产者获取消费者监听的队列和队列对应的label；

步骤5，当前消息带label，则按label匹配，匹配上则将消息投递到对应队列，若未匹配上，则将消息投递到不带标签的队列；

步骤6，当前消息不带label，则直接将消息投递到不带标签的队列，对于消费特定标签的消费者，则会消费特定标签的消息而不会对其他消息造成影响。

作为本发明一种用于分布式系统的基于标签的环境隔离方法的进一步优选方案，调度中心按照标签调度，通过SDK的方式实现，具体如下：

步骤7，注册部分增加标签属性；

步骤8，调度时按照标签匹配；

步骤9，通过指定当前调度任务标签，将任务调度优先调度到标签匹配的实例中。

本发明采用以上技术方案与现有技术相比，具有以下技术效果：

1、本发明针对分布式服务的服务调用提供了按标签路由，配置中心按照标签拉取配置，任务调度按照标签调度和消息队列按照标签消费；同时通过标签未匹配上路由到不带标签的服务实例的方式，实现了不带标签实例的共享，这样可以以极小的资源就复制出一套独立环境；

2、通过本发明，我们可以使用稳定代码例如定期同步线上release代码在测试环境构建一个不带标签的基线环境，保障测试环境的稳定高可用；

3、既保障了环境稳定可用也实现了以最小代价实现了重新部署一套独立环境使用，能让开发测试人员专注于有业务价值的代码，而不用关心环境和配置。同时通过对无标签应用的复用，既实现了复制一套独立部署的环境，又节省了计算资源；

4、通过本发明，还可以在生产环境，针对特定用户配置特定的标签来进行精准的A/B测试。还可以通过配置标签进行线上的冒烟测试，测试完成后去掉标签的蓝绿发布或者金丝雀发布，同时，配合影子库方案，还能提供安全方便的线上压测；

5、在当前发展速度快，需求变化多的互联网发展背景下，应用本发明可以在稳定的前提下，进一步加速互联网应用和功能快速推向客户和市场的速度。

附图说明

图1是一种典型的前后端分离的分布式应用环境的部署；

图2是本发明按照标签路由的规则规定流量的示意图；

图3是本发明消息消费者按照一定的负载规则来监听不同的队列的示例图。

具体实施方式

下面结合附图对本发明的技术方案做进一步的详细说明：

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，一种用于分布式系统的基于标签的环境隔离方法，具体包含服务调用按流

量标签路由、配置按照标签拉取、消息队列按照标签发送和消费、调度中心按照标签调度四部分；

其中，一、服务调用按流量标签路由，通过SDK的方式实现；

（1） 服务调用时，流量的精细化控制，通过标签实现流量打到特定版本的服务实例上，用于实现应用的A/B测试；

（2）针对特定用户打上标签，用于实现精准的针对特定用户的应用的beta测试，A/B测试；

（3）通过标签的流量路由，用于实现环境的隔离，且作为复制一套自定义环境的基础；

（4）发布阶段，测试人员通过特定的流量标签可直接在线上环境对新发布的代码进行测试，测试完成后直接去除标签，新发布的代码即可对所有用户开放，进而降低线上发布风险；

二、配置按照标签拉取，用于实现新需求的代码在配置变更的情况下，通过给修改的配置打上标签，则可拉取到特定标签的修改后的配置，而不需要改动原有的配置，同时保障原有的服务仍然是稳定的，不会受配置变更的影响；

三、消息队列按照标签发送和消费；

控制消息的消费是按照特定的标签的消费者来消费的：当复制出一套自定义环境，并修改了生产者或者消费者的逻辑或消息体时，通过打上标签，可实现修改过的消息只会被特定标签的消费者消费，而不会被原有的无标签实例消费，实现了环境的隔离；

四、调度中心按照标签调度，用于实现某些调度任务只被特定标签调度的场景和需求。

首先，如图2所示，所示我们规定我们流量按照标签路由的规则；

当服务A调用服务B时，如果这次调用带有标签label-1；

服务B存在标签为label-1的实例，则调用该label-1实例；

如果服务B不存在标签为label-1的实例（服务B的实例不带标签，或者标签不为label-1），则调用服务B不带标签的实例；

如果服务B既不存在标签为label-1的实例也不存在不带标签的实例，则调用失败，抛出服务未找到异常。

上述的第3条就是我们这次发明的核心重点，当标签未匹配上时，流量路由到不带标签的实例。这样，我们就可以实现不带标签的服务资源的共享，如此我们就可以把不带标签的服务作为基线（baseline）环境，我们只要保障基线环境的稳定，那么整个环境就是稳定的。当一个服务引入变化的同时又打上标签label-1，那么这个变化只会影响到label-1这个标签的流量，不会对任何其他不带标签的流量，或者标签不为label-1的流量产生影响。

要实现基于标签的多环境，我们需要实现的有；

服务调用按流量标签路由；

配置按照标签拉取；

消息队列按照标签发送和消费；

调度中心按照标签调度；

服务的标签由启动参数或者环境变量指定，这部分由发布脚本或者其他发布系统控制；

流量的标签由流量发起方传入，以app和http协议为例，app在发起调用时在http头中传入标签header来标记流量；

必须保证标签在分布式服务之间传递时不丢失，这样流量才能正确路由，应用可以通过值传递，对于java应用通过ThreadLocal等都行；

该说明部分内容不在本次发明讨论范围内；

服务调用按照标签路由；

服务调用的标签路由通过SDK的方式实现；

服务注册时，如果当前实例有标签，则将当前标签写入服务元数据中；

服务调用时，获取目标应用元数据和当前流量标签，如果当前流量存在标签，则匹配当前标签，若未匹配上，则选取无标签实例；

通过对服务注册写入元数据和服务发现时对标签的匹配处理，我们可以实现服务调用的标签路由；

配置按照标签拉取；

对于配置的拉取策略我们仍然使用服务调用类似的策略；

对于带标签的服务：

当发生了配置变更时，拉取带标签的配置；

当未发生配置变更，仍然拉取不带标签的配置，减少重新配置的工作量；

对于不带标签的服务：

直接拉取不带标签的配置；

现在分布式服务中常用的配置中心一般来说时通过指定文件名或者指定dataId来拉取应用的配置，无论是文件名或者是dataId，实现方式都是一样的，这边就以dataId的方式来说明。

一般的，配置中心的配置不存在元数据或者标签的设计，但我们可以通过添加后缀的方式来实现。

假设存在服务A读取的dataId为config_data_A；

当服务A以标签label-1启动时，首先读取data_id为config_data_A#label-1的配置

若config_data_A#label-1未读取到，则再读取data_id为config_data_A的配置；

这样，当带标签的实例有特殊配置时，可以建立dataId为原有dataId#标签后缀的方式实现对其他实例无影响的配置。

消息队列按照标签发送和消费；

不同消息队列的设计并不一样，所以在实现消息按照标签发送和消费的实现是不一样的，这边以阿里巴巴捐献给Apache基金会的RocketMQ来说明；

RocketMQ消息的发送和消费是基于topic的来进行的，对于一个topic又会有多个队列，消息消费者会按照一定的负载规则来监听不同的队列，如图3所示，我们假设topic名字为label_router，topic存在4个队列为queue0到queue3，topic label_router存在两个消费者，服务A的实例inst1和inst2，inst1不带标签，inst2的标签为x1。Inst1监听队列queue0和queue1，inst2监听队列queue2和queue3；

所以我们需要实现的是生产者能够将无标签消息和非label:x1的消息发送到queue0和queue1，而将label:x1的消息发送到queue2和queue3。

RocketMQ常见的分配队列的方式是将消息做hash后模除队列长度，我们这边就需要改变rocketMQ分配队列的方式。

生产者获取消费者监听的队列和队列对应的label；

当前消息带label，则按label匹配，匹配上则将消息投递到对应队列；

若未匹配上，则将消息投递到不带标签的队列；

当前消息不带label，则直接将消息投递到不带标签的队列；

这样，对于消费特定标签的消费者，它只会消费特定标签的消息而不会对其他消息造成影响；

调度中心按照标签调度；

调度中心按照标签过滤可以实现某些调度任务只被特定标签调度的场景和需求，调度中心和服务注册中心类似，服务注册调度器到调度中心，并注册当前调度器的标签到调度中心。但是一般的，调度中心并未又针对标签的设计，所以我们需要改造调度中心和调度策略来实现这部分功能。

注册部分增加标签属性：

调度时按照标签匹配：

这样我们通过指定当前调度任务标签，这样这次任务调度就能优先调度到标签匹配的实例中。

本发明针对分布式服务的服务调用提供了按标签路由，配置中心按照标签拉取配置，任务调度按照标签调度和消息队列按照标签消费。同时通过标签未匹配上路由到不带标签的服务实例的方式，实现了不带标签实例的共享，这样可以以极小的资源就复制出一套独立环境。

通过本发明，我们可以使用稳定代码（例如定期同步线上release代码）在测试环境构建一个不带标签的基线环境，保障测试环境的稳定高可用。

对于用户A而言，他只需要按照需要，部署有代码变更的应用并打上标签x1，然后通过标签为x1的流量进行测试调用;对于用户B，他也只需要部署有变更的服务，并打上另一个标签x2，然后通过标签为x2的流量进行测试调用。这两个用户之间互不干扰，它们的代码变更也不会影响到其他流量的正常使用。

这样既保障了环境稳定可用也实现了以最小代价实现了重新部署一套独立环境使用，既极大的提高了开发和测试的效率也大大的节省了服务器资源，计算资源；

通过本发明，还可以在生产环境，针对特定用户配置特定的标签来进行精准的A/B测试。还可以通过配置标签进行线上的冒烟测试，测试完成后去掉标签的蓝绿发布或者金丝雀发布。同时，配合影子库方案，还能提供安全方便的线上压测。

在当前发展速度快，需求变化多的互联网发展背景下，应用本发明可以在稳定的前提下，进一步加速互联网应用和功能快速推向客户和市场的速度

本发明为用于分布式系统的流量标签路由方法，针对分布式系统常用的组件实现了基于标签的控制和路由；

对于服务调用，通过sdk的方式实现，应用引入sdk的依赖即可；

对于配置拉取，通过sdk的方式实现，应用引入sdk的依赖即可；

对于任务调度，通过修改sdk的调度器注册和任务调度server的任务调度策略，应用引入sdk依赖，部署修改后的调度server即可；

对于消息队列按照标签消费，通过sdk的方式实现；

本发明为一种方法，提供的是设计上和逻辑上的实践方法，大部分通过SDK的方式实现。

本技术领域技术人员可以理解的是，除非另外定义，这里使用的所有术语（包括技术术语和科学术语）具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

以上实施例仅为说明本发明的技术思想，不能以此限定本发明的保护范围，凡是按照本发明提出的技术思想，在技术方案基础上所做的任何改动，均落入本发明保护范围之内。上面对本发明的实施方式作了详细说明，但是本发明并不限于上述实施方式，在本领域普通技术人员所具备的知识范围内，还可以再不脱离本发明宗旨的前提下做出各种变化。

Claims (5)

1.一种用于分布式系统的基于标签的环境隔离方法，其特征在于：具体包含

服务调用按流量标签路由、配置按照标签拉取、消息队列按照标签发送和消费、调度中心按照标签调度四部分；

其中，一、服务调用按流量标签路由，通过SDK的方式实现；

（1） 服务调用时，流量的精细化控制，通过标签实现流量打到特定版本的服务实例上，用于实现应用的A/B测试；

（2）针对特定用户打上标签，用于实现精准的针对特定用户的应用的beta测试，A/B测试；

（3）通过标签的流量路由，用于实现环境的隔离，且作为复制一套自定义环境的基础；

（4）发布阶段，测试人员通过特定的流量标签可直接在线上环境对新发布的代码进行测试，测试完成后直接去除标签，新发布的代码即可对所有用户开放，进而降低线上发布风险；

二、配置按照标签拉取，用于实现新需求的代码在配置变更的情况下，通过给修改的配置打上标签，则可拉取到特定标签的修改后的配置，而不需要改动原有的配置，同时保障原有的服务仍然是稳定的，不会受配置变更的影响；

三、消息队列按照标签发送和消费；

控制消息的消费是按照特定的标签的消费者来消费的：当复制出一套自定义环境，并修改了生产者或者消费者的逻辑或消息体时，通过打上标签，可实现修改过的消息只会被特定标签的消费者消费，而不会被原有的无标签实例消费，实现了环境的隔离；

四、调度中心按照标签调度，用于实现某些调度任务只被特定标签调度的场景和需求。

2.根据权利要求1所述的一种用于分布式系统的基于标签的环境隔离方法，其特征在

于：在一个实施方式中，服务调用按流量标签路由，通过SDK的方式实现，具体如下：

步骤1，服务注册时，若当前实例有标签，则将当前标签写入服务元数据中；

步骤2，服务调用时，获取目标应用元数据和当前流量标签，若当前流量存在标签，则匹配当前标签，若未匹配上，则选取无标签实例；

步骤3，通过对服务注册写入元数据和服务发现时对标签的匹配处理，可实现服

务调用的标签路由。

3.根据权利要求1所述的一种用于分布式系统的基于标签的环境隔离方法，其特征在

于：在一个实施方式中，配置按照标签拉取，通过SDK的方式实现，具体如下：

对于带标签的服务：

当发生了配置变更时，拉取带标签的配置；当未发生配置变更，拉取不带标签的配置，减少重新配置的工作量；

对于不带标签的服务：可通过指定文件名或者指定dataId来拉取应用的配置直接拉取不带标签的配置；

若配置中心的配置不存在元数据或者标签的设计，则可通过添加后缀的方式来实现；

设存在服务A读取的dataId为config_data_A；

当服务A以标签label-1启动时，读取data_id为config_data_A#label-1的配置；

若config_data_A#label-1未读取到，则再读取data_id为config_data_A的配置；

当带标签的实例有特殊配置时，可建立dataId为原有dataId#标签后缀的方式实现对其他实例无影响的配置。

4.根据权利要求1所述的一种用于分布式系统的基于标签的环境隔离方法，其特征在

于：在一个实施方式中，消息队列按照标签发送和消费，通过修改sdk的调度器注册和任务调度server的任务调度策略，应用引入sdk依赖，部署修改后的调度server，具体如下：

步骤4，生产者获取消费者监听的队列和队列对应的label；

步骤5，当前消息带label，则按label匹配，匹配上则将消息投递到对应队列，若未匹配上，则将消息投递到不带标签的队列；

步骤6，当前消息不带label，则直接将消息投递到不带标签的队列，对于消费特定标签的消费者，则会消费特定标签的消息而不会对其他消息造成影响。

5.根据权利要求1所述的一种用于分布式系统的基于标签的环境隔离方法，其特征在

于：在一个实施方式中，调度中心按照标签调度，通过SDK的方式实现，具体如下：

步骤7，注册部分增加标签属性；

步骤8，调度时按照标签匹配；

步骤9，通过指定当前调度任务标签，将任务调度优先调度到标签匹配的实例中。

Images