CN114205280A - 基于容器云和服务网格的应用发布方法及流量路由方法 - Google Patents

Abstract

本发明公开了基于容器云和服务网格的应用发布方法及流量路由方法。该应用发布方法应用于kubernetes中，通过应用发布模板设置用于发布不同版本的第一应用的参数；根据所述应用发布模板和参数生成容器云的第一资源配置和服务网格的第二资源配置；生成所述第一资源配置和第二资源配置后，形成虚拟服务和目标规则第一流量路由规则、所述目标规则和微服务的第二流量路由规则以及各个微服务之间的调用关系；发布所述不同版本的第一应用，所述不同版本的第一应用以微服务的形式部署。本发明技术方案实现了自动生成容器云和服务网格的资源配置，降低了人工在容器云和服务网格中采用灰度发布方式发布应用的门槛。

Description

基于容器云和服务网格的应用发布方法及流量路由方法

技术领域

本发明涉及容器云技术领域，尤其涉及基于容器云和服务网格的应用发布方法及流量路由方法。

背景技术

灰度发布是指在环境中同时部署集了新版本应用和旧版本应用，并通过调整流量策略，让一部分用户继续用老版本，一部分用户开始用新版本，并逐步扩大新版本的使用范围，最终把所有用户都迁移到新版本上面来。通过灰度发布的方式可以减少因版本升级引起的不良影响范围，通过升级过程中对试用用户的使用反馈，调整发布策略，从而提高用户满意度。

灰度发布的模式包括蓝绿发布、金丝雀发布和AB测试。现有技术方案中，将应用部署集在主机时，实现灰度发布需要通过负载均衡器上编写各类脚本，配合主机上的应用发布，实现灰度发布。此种发布方式存在脚本编写难度高和应用部署集配合难度高的缺点。将应用部署集在容器云(kubernetes)时，实现灰度发布可以通过服务网格(istio)实现各类灰度发布，此种发布方式存在服务网格(istio)使用难度高和跨多个微服务情况下实现多个微服务的灰度发布的操作难度高的问题。现有灰度发布模式存在以下缺陷：

(1)灰度发布只能针对单个微服务实施灰度发布，无法针对多个微服务实施灰度发布；

(2)灰度发布操作流程复杂；

(3)灰度发布与应用的部署集协同配合难度高；

(4)istio服务网格使用门槛高，普及难；

(5)需要多个环境支持灰度发布。

发明内容

本发明提供一种基于容器云和服务网格的应用发布方法及流量路由方法，实现了自动生成容器云和服务网格的资源配置，降低了人工在容器云和服务网格中采用灰度发布方式发布应用的门槛。

本发明一实施例提供一种基于容器云和服务网格的应用发布方法，应用于kubernetes中，其特征在于，包括以下步骤：

通过应用发布模板设置用于发布不同版本的第一应用的参数；所述参数包括：新版本域名、旧版本域名、新版本流量比例、旧版本流量比例、各个微服务的服务名、各个微服务的标签版本信息、各个微服务的头部信息的匹配规则、各个微服务访问路径前缀，以及各个微服务是否为默认入口微服务；

根据所述应用发布模板和参数生成容器云的第一资源配置和服务网格的第二资源配置；生成所述第一资源配置和第二资源配置后，形成虚拟服务和目标规则的第一流量路由规则、所述目标规则和微服务的第二流量路由规则以及各个微服务之间的调用关系；

发布所述不同版本的第一应用，所述不同版本的第一应用部署在容器云中，并通过访问微服务的部署集来访问不同版本的第一应用。

进一步地，所述新版本域名用于设置蓝绿发布时，访问新版本应用的域名信息；

所述旧版本域名用于设置蓝绿发布时，访问旧版本应用的域名信息；

所述新版本流量比例用于设置金丝雀发布时，访问新版本应用的流量比例；

所述旧版本流量比例用于设置金丝雀发布时，访问旧版本应用的流量比例；

所述各个微服务的服务名，用于设置目标规则所指向的微服务；

所述各个微服务的标签版本信息，用于设置目标规则中的目标子集的标签上的版本信息，所述版本信息包括新版本信息和旧版本信息；

所述各个微服务的头部信息的匹配规则，用于设置所述头部信息中的版本标记信息的匹配规则；所述头部信息为HTTP header；

所述各个微服务访问路径前缀，用于设置访问微服务的访问路径前缀的匹配规则；

所述各个微服务是否为默认入口微服务，用于设置在默认情况下是否访问当前网关的默认微服务，所述默认情况指访问路径不符合所述各个微服务访问路径前缀的匹配规则。

本发明又一实施例提供一种基于容器云和服务网格的流量路由方法，适用于如权利要求1所述的基于容器云和服务网格的应用发布方法发布的第一应用，其特征在于，包括以下步骤：

通过虚拟服务接收来自网关的第一请求，所述虚拟服务根据预设的第一流量路由规则，将所述第一请求路由至对应目标规则中的目标子集；所述目标规则包括标签信息为新版本的目标子集和标签信息为旧版本的目标子集；

根据所述目标子集的标签信息上的版本信息将所述第一请求路由至对应版本的微服务的部署集；

根据所述部署集上运行的版本信息和所述微服务和其他微服务之间的调用关系，将所述第一请求路由至其他微服务的部署集，以使所述第一请求访问对应版本的第一应用。

进一步地，所述第一流量路由规则包括以下分发规则中的一种或多种组合：

第一分发规则为：将从不同网关进入的请求，根据所述不同网关各自对应的版本信息，将进入的请求路由至对应目标规则的目标子集；所述从不同网关进入的请求，在进入网关之间，根据域名和网关的对应关系，将请求路由至相应的网关；

第二分发规则为：针对从同一网关进入的请求，根据预设的头部信息匹配规则，将符合所述头部信息匹配规则的进入的请求和不符合所述头部信息匹配规则的进入的请求，分别路由至对应目标规则的目标子集；所述头部信息为HTTP header；

第三分发规则为：针对从同一网关进入的请求，按照预设的新版本的流量比例和旧版本的流量比例，将进入的请求随机路由至对应目标规则的目标子集。

进一步地，当所述第一流量路由规则包括分发规则中的多种组合时，所述虚拟服务按照分发规则的优先级执行流量路由规则；所述分发规则的优先级为：所述第一分发规则的优先级高于所述第二分发规则的优先级高于所述第三分发规则的优先级。

进一步地，当第一流量路由规则包括第一分发规则和第二分发规则时，所述虚拟服务根据预设的第一流量路由规则将所述第一请求路由至对应目标规则的目标子集，具体为：

所述虚拟服务确定第一请求的网关对应的版本信息为旧版本时，获取所述第一请求的头部信息，将符合所述头部信息匹配规则的第一请求路由至对应目标规则的标签信息为新版本的目标子集，将不符合所述头部信息匹配规则的第一请求路由至对应目标规则的标签信息为旧版本的目标子集；

所述虚拟服务确定第一请求的网关对应的版本信息为新版本时，将第一请求路由至对应目标规则的标签信息为新版本的目标子集。

进一步地，当第一流量路由规则包括第一分发规则和第三分发规则时，所述虚拟服务根据预设的第一流量路由规则将所述第一请求路由至对应目标规则的目标子集，具体为：

所述虚拟服务确定第一请求的网关对应的版本信息为旧版本时，按照预设的新版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为新版本的目标子集，按照预设的旧版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为旧版本的目标子集；

所述虚拟服务确定第一请求的网关对应的版本信息为新版本时，将第一请求路由至对应目标规则的标签信息为新版本的目标子集。

进一步地，当第一流量路由规则包括第一分发规则、第二分发规则和第三分发规则时，所述虚拟服务根据预设的第一流量路由规则将所述第一请求路由至对应目标规则的目标子集，包括以下步骤：

所述虚拟服务确定第一请求的网关对应的版本信息为旧版本时，获取所述请求的头部信息，将符合所述头部信息匹配规则的第一请求路由至对应目标规则的标签信息为新版本的目标子集；将不符合所述头部信息匹配规则的请求，按照预设的新版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为新版本的目标子集，按照预设的旧版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为旧版本的目标子集；

所述虚拟服务确定第一请求的网关对应的版本信息为新版本时，将第一请求路由至对应目标规则的标签信息为新版本的目标子集。

进一步地，通过虚拟服务接收来自微服务的第二请求，根据所述第二请求的头部信息中的版本标记信息确定所述第二请求对应访问的版本信息为新版本时，并将所述第二请求路由至对应目标规则的标签信息为新版本的目标子集；所述微服务透传带有版本标记信息的头部信息；

根据所述第二请求的头部信息中的版本标记信息确定所述第二请求对应访问的版本信息为旧版本时，并将所述第二请求路由至对应目标规则的标签信息为旧版本的目标子集；所述微服务透传带有版本标记信息的头部信息。

进一步地，将每个微服务的目标规则的目标子集的版本信息设置为新版本，以完成新版本上线；将每个微服务的目标规则的目标子集的版本信息设置为旧版本，以完成新版本下线。

本发明的实施例，具有如下有益效果：

本发明提供了一种基于容器云和服务网格的应用发布方法，通过人工在应用发布模板中设置应用发布的参数后，自动生成容器云的第一资源配置和服务网格的第二资源配置，生成的所述第一资源配置和第二资源配置为灰度发布的资源配置；生成所述第一资源配置和第二资源配置后，形成虚拟服务和目标规则的第一流量路由规则、所述目标规则和微服务的第二流量路由规则以及各个微服务之间的调用关系，实现了由程序自动生成资源配置，而无需人工编写复杂的专业性较强的资源配置文件，从而降低了人工通过容器云和服务网格采用灰度发布方式发布不同版本的应用的门槛。

本发明还提供了一种基于容器云和服务网格的流量路由方法，针对已经配置好的第一资源配置和第二资源配置进行引流，以实现根据设置的应用发布需求，对不同版本的应用的访问。进一步地，本申请根据第一请求的网关对应的版本信息确定当前请求对应访问的目标规则、目标子集、服务和部署集，以实现应用版本的蓝绿发布；根据虚拟服务中设置的流量比例确定当前请求对应访问的目标规则、目标子集、服务和部署集，实现应用版本的金丝雀发布；通过根据当前请求的头部信息是否符合头部信息匹配规则确定当前请求对应访问的目标规则、目标子集、服务和部署集，实现应用版本的AB测试；因此，本申请同时实现了蓝绿发布、金丝雀发布和AB测试，进而同时满足了应用版本发布时的多种发布需求。

附图说明

图1是本发明一实施例提供的基于容器云和服务网格的应用发布方法的流程图；

图2是本发明一实施例提供的基于容器云和服务网格的流量路由方法的流程图；

图3是本发明一实施例提供的基于容器云和服务网格的流量路由方法的流量指向图；

图4是本发明一实施例提供的基于容器云和服务网格的流量路由方法的又一流量指向图；

图5是本发明一实施例提供的基于容器云和服务网格的流量路由方法的又一流量指向图；

图6是本发明一实施例提供的基于容器云和服务网格的流量路由方法的又一流量指向图；

图7是本发明一实施例提供的基于容器云和服务网格的流量路由方法的又一流量指向图。

具体实施方式

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

如图1所示，本发明一实施例提供的一种基于容器云和服务网格的应用发布方法，包括以下步骤：

步骤S101：通过应用发布模板设置用于发布不同版本的第一应用的参数；所述参数包括：新版本域名、旧版本域名、新版本流量比例、旧版本流量比例、各个微服务的服务名、各个微服务的标签版本信息、各个微服务的头部信息的匹配规则、各个微服务访问路径前缀，以及各个微服务是否为默认入口微服务。

在设置所述新版本域名、旧版本域名、新版本流量比例和旧版本流量比例时，针对整个微服务的调用链进行统一设置。在设置各个微服务的服务名、各个微服务的标签版本信息、各个微服务的头部信息的匹配规则、各个微服务访问路径前缀，以及各个微服务是否为默认入口微服务时，针对各个微服务单独进行设置。

步骤S102：根据所述应用发布模板和参数生成容器云的第一资源配置和服务网格的第二资源配置；生成所述第一资源配置和第二资源配置后，形成虚拟服务和目标规则的第一流量路由规则、所述目标规则和微服务的第二流量路由规则以及各个微服务之间的调用关系。

步骤S103：发布所述不同版本的第一应用，所述不同版本的第一应用部署在容器云中，并通过访问微服务的部署集来访问不同版本的第一应用。

作为其中一种实施例，通过应用发布模板设置用于发布不同版本的第一应用的参数，所述参数具体包括：

所述版本域名包括新版本域名和旧版本域名；所述新版本域名用于设置蓝绿发布时，访问新版本应用的域名信息；所述旧版本域名用于设置蓝绿发布时，访问旧版本应用的域名信息；

所述版本流量比例包括新版本流量比例和旧版本流量比例；所述新版本流量比例用于设置金丝雀发布时，访问新版本应用的流量比例；所述旧版本流量比例用于设置金丝雀发布时，访问旧版本应用的流量比例；

所述各个微服务的服务名，用于设置目标规则所指向的微服务；

所述各个微服务的标签版本信息，用于设置目标规则中的目标子集的标签上的版本信息，所述版本信息包括新版本信息和旧版本信息；

所述网关入口配置信息，用于配置虚拟服务和网关的连接关系；

所述关入口配置信息包括所述各个微服务的头部信息的匹配规则、各个微服务访问路径前缀，以及各个微服务是否为默认入口微服务。

所述各个微服务的头部信息的匹配规则，用于设置所述头部信息中的版本标记信息的匹配规则；所述头部信息为HTTP header；

所述各个微服务访问路径前缀，用于设置访问微服务的访问路径前缀的匹配规则；访问微服务的当前请求的路径前缀符合所述匹配规则时，可以访问到相应的微服务；具体地，所述匹配规则为路径前缀为Example.com/a，所述当前请求的路径为Example.com/a/xxx，那么当前请求符合所述匹配规则，进而可以访问到service-A。

所述各个微服务是否为默认入口微服务，用于设置在默认的情况下是否访问当前网关的本地微服务；具体地，当前请求的路径前缀不符合所述各个微服务访问路径前缀的匹配规则时，访问默认入口微服务，即所述当前请求的路径为Example.com/cccc/xxx，则访问service-C；

作为其中一种实施例，通过应用发布模板调整虚拟服务的金丝雀发布的流量比例。本实施例支持同时部署多个应用，以及多个应用的不同版本。

本发明实施例具有如下有益效果：

1、简化了通过容器云和服务网格发布应用时的操作流程:只需要配置灰度发布的模板，便可以自动生成相关微服务调用的服务网格；

2、降低了服务网格的应用门槛:用户无需手工编写服务网格的相关资源，而是自动生成发布配置文件，同时相较于手工编写发布配置文件，本实施例所采用的应用发布模板直观、简单和容易理解；

3、同时支持多种灰度发布模式:同时支持蓝绿发布、金丝雀发布、AB测试三种模式的灰度发布，本申请可以在应用发布模板同时针对三种灰度发布的参数进行设置；

4、无需多个环境:由于本实施例的新版本和旧版本的部署集在同一个kubernetes集群中，相当于新版本和旧版本的应用运行在同一个环境中，无需多个环境分别部署集新版本和旧版本应用，只需要在同一个环境运行新版本和旧版本应用，即可实现灰度发布；同时，通过在目标子集中更换新版本和旧版本的标签信息，以及在虚拟服务中逐步调整新版本和旧版本的流量比例，使得版本升级以及流量切换更加平滑；

5、结合了复杂的微服务调用:可针对多个微服务的复杂的调用链实施灰度发布，相较于现有技术中的不同微服务只能独立处理版本升级，不能实现微服务之间的不同版本的访问；本实施例的复杂的微服务调用实现了将访问微服务A的旧版本的请求，路由至服务B的新版本，进而可以访问到服务B的新版本；

6、应用的灰度发布与应用的部署集之间协同配合简单:本实施例通过服务网格实现新版本和旧版本的流量切换，通过容器云实现新版本和旧版本应用的上线与下线，服务网格和容器云的协同配合简单，进一步简化和便利了应用发布的操作流程。

如图2所示，本发明另一实施例提供了一种基于容器云和服务网格的流量路由方法，包括以下步骤：

步骤S201：通过虚拟服务接收来自网关的第一请求，所述虚拟服务根据预设的第一流量路由规则，将所述第一请求路由至对应目标规则中的目标子集；所述目标规则包括标签信息为新版本的目标子集和标签信息为旧版本的目标子集；

步骤S202：根据所述目标子集的标签信息上的版本信息将所述第一请求路由至对应版本的微服务的部署集；

步骤S203：根据所述部署集上运行的版本信息和所述微服务和其他微服务之间的调用关系，将所述第一请求路由至其他微服务的部署集。

作为其中一种实施例，步骤S201的所述第一流量路由规则包括以下分发规则中的一种或多种组合：

第一分发规则为：将从不同网关进入的请求，根据所述不同网关各自对应的版本信息，将进入的请求路由至对应目标规则的目标子集；所述从不同网关进入的请求，在进入网关之前，根据域名和网关的对应关系，将请求路由至相应的网关；

第二分发规则为：针对从同一网关进入的请求，根据预设的头部信息匹配规则，将符合所述头部信息匹配规则的进入的请求和不符合所述头部信息匹配规则的进入的请求，分别路由至对应目标规则的目标子集；

第三分发规则为：针对从同一网关进入的请求，按照预设的新版本的流量比例和旧版本的流量比例，将进入的请求随机路由至对应目标规则的目标子集。

所述第一分发规则为蓝绿发布，所述第二分发规则为AB测试，所述第三分发规则为金丝雀发布。

作为其中一种实施例，当所述第一流量路由规则包括分发规则中的多种组合时，所述虚拟网格按照分发规则的优先级执行流量路由规则；所述分发规则的优先级为：所述第一分发规则的优先级高于所述第二分发规则的优先级高于所述第三分发规则的优先级。

作为其中一种实施例，当第一流量路由规则包括第一分发规则和第二分发规则时，所述虚拟服务根据预设的第一流量路由规则将所述第一请求路由至对应目标规则的目标子集，具体为：

所述虚拟服务确定第一请求的网关对应的版本信息为旧版本时，获取所述第一请求的头部信息，将符合所述头部信息匹配规则的第一请求路由至对应目标规则的标签信息为新版本的目标子集，将不符合所述头部信息匹配规则的第一请求路由至对应目标规则的标签信息为旧版本的目标子集；

所述虚拟服务确定第一请求的网关对应的版本信息为新版本时，将第一请求路由至对应目标规则的标签信息为新版本的目标子集。

作为其中一种实施例，当第一流量路由规则包括第一分发规则和第三分发规则时，所述虚拟服务根据预设的第一流量路由规则将所述第一请求路由至对应目标规则的目标子集，具体为：

所述虚拟服务确定第一请求的网关对应的版本信息为旧版本时，按照预设的新版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为新版本的目标子集，按照预设的旧版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为旧版本的目标子集；

所述虚拟服务确定第一请求的网关对应的版本信息为新版本时，将第一请求路由至对应目标规则的标签信息为新版本的目标子集。

作为其中一种实施例，当第一流量路由规则包括第一分发规则、第二分发规则和第三分发规则时，所述虚拟服务根据预设的第一流量路由规则将所述第一请求路由至对应目标规则的目标子集，包括以下步骤：

所述虚拟服务确定第一请求的网关对应的版本信息为旧版本时，获取所述请求的头部信息，将符合所述头部信息匹配规则的第一请求路由至对应目标规则的标签信息为新版本的目标子集；将不符合所述头部信息匹配规则的请求，按照预设的新版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为新版本的目标子集，按照预设的旧版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为旧版本的目标子集；

所述虚拟服务确定第一请求的网关对应的版本信息为新版本时，将第一请求路由至对应目标规则的标签信息为新版本的目标子集。

作为其中一种实施例，如图3所示，服务网格的入口网关(istio-ingressgateway)根据第一请求的域名和网关的对应关系，将所述第一请求路由至网关1(gateway-v1)或网关2(gateway-v2)；根据所述第一请求的域名www.example.com确定该访问路径前缀对应访问的微服务1(service app-svc1)；或根据所述第一请求的域名test.example.com确定该访问路径前缀对应访问的微服务2(service app-svc2)；

虚拟服务(virtualservice)接收来自网关1(gateway-v1)和网关2(gateway-v2)的第一请求；所述虚拟服务(virtualservice)确定第一请求对应的网关1(gateway-v1)的版本信息为旧版本且第一请求的域名为www.example.com时，获取从网关1(gateway-v1)进入的第一请求的头部信息，判断所述头部信息中的user-agent是否包含chrome(表示用户使用chrome浏览器进行访问)：

若是，则符合所述各个微服务的头部信息的匹配规则，并将符合所述头部信息匹配规则的第一请求路由至对应目标规则(destinationrule app-dr1)的标签信息为新版本的目标子集(subset new)，从而实现AB测试的符合特定条件用户能够访问到新版本；

若否，则不符合所述各个微服务的头部信息的匹配规则，并将不符合所述头部信息匹配规则的第一请求，按照预设的新版本的流量比例路由10％的第一请求至对应目标规则(destinationrule app-dr1)的标签信息为新版本的目标子集(subset new)，并根据所述目标子集的标签信息上的版本信息将所述第一请求路由至对应版本的微服务(serviceapp-svc1)的部署集(deployment app-dp1-v2)；并将不符合所述头部信息匹配规则的第一请求，按照预设的旧版本的流量比例路由90％的第一请求至对应目标规则(destinationrule app-dr1)的标签信息为旧版本的目标子集(subset old)，并根据所述目标子集的标签信息上的版本信息将所述第一请求路由至对应版本的微服务(serviceapp-svc1)的部署集(deployment app-dp1-v1)。

所述虚拟服务(virtualservice)确定第一请求对应的网关2(gateway-v2)的版本信息为新版本且第一请求的域名为test.example.com时，将第一请求路由至对应目标规则(destinationrule app-dr2)的标签信息为新版本的目标子集(subset new)，并根据所述目标子集的标签信息上的版本信息将所述第一请求路由至对应版本的微服务(serviceapp-svc2)的部署集(deployment app-dp2-v2)；

根据所述部署集上运行的版本信息和微服务之间的调用关系，将所述第一请求路由至其他微服务的部署集；作为其中一种实施例，根据所述部署集(deployment app-dp2-v2)上运行的版本信息和所述微服务(service app-svc2)和其他微服务之间的调用关系，将所述第一请求路由至其他微服务的部署集(deployment app-dp3)。

需要说明的是，本实施例与图3的对应关系为：网关对应gateway(包括gateway-v1、gateway-v2)、虚拟服务对应virtualservice、目标规则对应destinationrule(包括destinationrule app-dr1、destinationrule app-dr2)、目标子集对应subset(包括subset old、subset new)、服务对应service(包括service app-svc1、service app-svc2)、部署集对应deployment(包括deployment app-dp3、deployment app-dp2-v1等)。

本实施例中，每个微服务对应需要一个服务(service)和多个部署集(deployment)，虚拟服务在进行新版本和旧版本的切换时，只需要将第一请求和第二请求指向目标规则的标签信息为新版本的目标子集(subset new)或标签信息为旧版本的目标子集(subset old)即可；目标规则(destinationrule)用于对服务(service)进行细分，并可以设置目标服务的连接池配置以及负载均衡算法配置等。目标规则(destinationrule)上可以设置多个目标子集(subset)，每个目标子集(subset)有一个label过滤器；未针对目标规则(destinationrule)的目标子集进行设置时，服务(service)的部署集(deployment)会被同时访问到；当针对目标规则(destinationrule)的目标子集的label过滤器设置为version＝v1或者v2时,那么在服务网格中，通过访问不同的目标规则的不同目标子集就可以访问到不同版本的应用，所述不同版本的应用运行在不同的部署集(deployment)上。虚拟服务(virtualservice)用于控制服务网格流量的分发规则，虚拟服务(virtualservice)对接网关、目标规则以及其他虚拟服务(virtualservice)。虚拟服务(virtualservice)的流量可以来源于网关,也可以来源于其他部署集了流量代理边车的pod(即受服务网格控制流量的pod)。

因此，本发明实施例通过根据第一请求的网关对应的版本信息确定当前请求对应访问的目标规则、目标子集、服务和部署集，以实现应用版本的蓝绿发布；根据虚拟服务中设置的流量比例确定当前请求对应访问的目标规则、目标子集、服务和部署集，实现应用版本的金丝雀发布；通过根据当前请求的头部信息是否符合头部信息匹配规则确定当前请求对应访问的目标规则、目标子集、服务和部署集，实现应用版本的AB测试；可见，本申请可以同时实现蓝绿发布、金丝雀发布和AB测试，即实现了三种混合发布策略，进而同时满足了应用版本发布时的多种发布需求。

作为其中一种实施例，通过虚拟服务接收来自微服务的第二请求，根据所述第二请求的头部信息中的版本标记信息确定所述第二请求对应访问的版本信息为新版本时，并将所述第二请求路由至对应目标规则的标签信息为新版本的目标子集；所述微服务透传带有版本标记信息的头部信息；

根据所述第二请求的头部信息中的版本标记信息确定所述第二请求对应访问的版本信息为旧版本时，并将所述第二请求路由至对应目标规则的标签信息为旧版本的目标子集；所述微服务透传带有版本标记信息的头部信息。

作为其中一种实施例，微服务透传第一请求和第二请求的带有版本标记信息的头部信息。具体地，所述虚拟服务、目标规则、服务和部署集均透传第一请求和第二请求的带有版本标记信息的头部信息；作为其中一种实施例，所述虚拟服务针对接收到的第一请求和第二请求，在所述第一请求和第二请求的头部信息中添加新版本的标记或旧版本的标记，例如：在http的header中添加old作为旧版本的标记，添加new作为新版本的标记，并将添加版本标记后的第一请求和第二请求的头部信息透传至目标规则。通过微服务程序实现header透传,进而实现了服务网格内部的微服务之间可以通过header识别出流量来源于新版本的网关还是旧版本的网关。

所述微服务在实现透传功能时，从第一请求和第二请求中获取特定http header，那么该微服务调用其他微服务的时候将所述特定http header作为请求体发送至其他微服务；所述微服务在实现透传功能时，由开发人员对微服务进行改造以支持所述透传功能的实现。

作为其中一种实施例，如图4所示，微服务(app-dp2-v1-x)针对访问新版本应用的第二请求，在第二请求的头部信息header中插入new作为新版本的标记并将标记后的所述第二请求透传至虚拟服务(virtualservice app-vs3)；所述虚拟服务(virtualserviceapp-vs3)匹配到所述第二请求中的新版本的标记信息时，将所述第二请求路由至目标规则(destinationrule app-dr3)的新版本的目标子集(subset new)，所述新版本的目标子集(subset new)路由至对应的服务(service app-sv3)和部署集(deployment app-dp3-v2)；

微服务(app-dp1-v1-x)针对访问旧版本应用的第二请求，在第二请求的头部信息(header)中插入old作为旧版本的标记并将标记后的所述第二请求透传至虚拟服务(virtualservice app-vs3)；所述虚拟服务(virtualservice app-vs3)匹配到所述第二请求中的旧版本的标记信息时，将所述第二请求路由至目标规则(destinationrule app-dr3)的旧版本的目标子集(subset old)，所述新版本的目标子集(subset new)路由至对应的服务(service app-sv3)和部署集(deployment app-dp3-v1)。

需要说明的是，本实施例与图4的对应关系为：虚拟服务对应virtualservice(包括virtualservice app-vs3)、目标规则对应destinationrule(包括destinationruleapp-dr3)、目标子集对应subset(包括subset old、subset new)、服务对应service(包括service app-svc3)、部署集对应deployment(包括deployment app-dp3-v1、deploymentapp-dp3-v2等)；图4中的app-dp1-v1-x、app-dp1-v2-x、app-dp2-v1-x表示来自微服务的请求。

作为其中一种实施例，完成新版本上线时，只需要在每个微服务的目标规则中设置新版本和旧版本的目标子集，具体地，在目标子集的label过滤器中将旧版本更改为新版本。那么访问新旧版本域名的时候，所有流量都会指向新版本。将所有目标子集的label过滤器的旧版本更改为新版本后，下线所有微服务的旧版本，即完成新版本的上线。

完成新版本下线时，只需要在每个微服务的目标规则中设置新版本和旧版本目标子集，具体地，在目标子集的label过滤器中将新版本更改为旧版本。那么访问新旧版本域名的时候，所有流量都会指向旧版本。将所有目标子集的label过滤器的新版本更改为旧版本后，下线所有微服务的新版本，即完成新版本的下线。

本发明实施例的部分名词说明如下：

pod为容器运行的最小单元，即一个应用程序的实例在kubernetes中部署集的最小容器单元，一个pod相当于一个应用程序的运行进程，pod有ip地址，有pod名字(类似主机名)，可以通过pod的ip地址和名字监测这个pod的内存和cpu资源消耗。

部署集即deployment，为kubernetes容器云中的一种资源和应用的部署集方式，一个部署集可以启动多个实例，每个实例即一个pod；部署集可以进行水平扩容和水平缩容，即扩容或缩容部署集的启动实例的数量。

服务即kubernetes中的service，在kubernetes容器云中的pod应用进程被容器云或其他应用访问时，需要创建service来指向这些pod；如图5所示，service的selector(选择器)通过deployment和pod上的label(标签)，来决定service指向哪些pod。例如两个deployment:demo-app-v1和demo-app-v2是demo-app的两个版本，这两个deployment都分别创建了两个pod,并且这些pod上都有两个标签:app＝demo-app以及version＝v1/v2。那么service就会匹配label(标签)包含app＝demo-app的pod,也就是说service会以轮询的方式访问到demo-app-v1的两个pod以及demo-app-v2的两个pod。

ingress即入口流量设置，用于指定从kubernetes集群外部通过域名方式进入的请求，可以访问哪些service；如图6所示，在kubernetes集群之外，通过访问www.example.com或者test.example.com这两个域名，都能够访问到demo-app的v1和v2版本的pod。

服务网格即Istio，用于描述组成应用程序的微服务网络以及它们之间的交互。随着服务网格的大小和复杂程度不断增加，可能会变得难以理解和管理。可能出现包括服务发现、负载平衡、故障恢复、度量和监控，以及更复杂的需求，如A/B测试、金丝雀发布、速率限制、访问控制和端到端身份验证。lstio提供了一个完整的解决方案，通过对整个服务网格提供行为分析和操作控制来满足微服务应用程序的各种需求。如图7所示，lstio通常部署集在kubernetes集群中，通过sidecar(边车模式)，在pod中部署集流量sidecar proxy(边车代理)，边车代理使用envoy,实现pod的进出流量的控制。所有部署集了流量代理边车的pod的进出流量，受服务网格的流量控制。

网关即gateway，用于控制进入istio(服务网格)的ingress(入口流量设置)。例如，从kubernetes集群外，访问www.example.com和test.example.com域名会通过ingress进入kubernetes集群，并指向istio-ingress gateway(istio入口网关)，并通过istio-ingress gateway进入istio服务网格，这里创建gateway-v1和gateway-v2两个gateway,分别用于接收来自www.example.com和test.example.com的流量。

目标规则即destinationrule，用于对service进行细分,并可以设置目标服务的连接池配置以及负载均衡算法配置等。destinationrule上可以设置多个subset(目标子集)，每个subset(目标子集)有一个label过滤器。未针对目标规则(destinationrule)的目标子集进行设置时，服务(service)的部署集(deployment)会被同时访问到，即可以同时访问到服务指向的部署集上所有版本；当针对目标规则(destinationrule)的目标子集的label过滤器设置为版本version＝v1或者v2时,那么在服务网格中，通过访问不同的目标规则的不同目标子集就可以访问到不同版本的应用，即通过访问v1版本的目标规则的目标子集就可以访问到v1版本的应用，通过访问v2版本的目标规则的目标子集就可以访问到v2版本的应用。

虚拟服务即virtualservice用于控制服务网格流量的分发规则，虚拟服务对接网关、目标规则以及其他虚拟服务。虚拟服务的流量可以来源于网关,也可以来源于其他部署集了流量代理边车的pod(即受服务网格控制流量的pod)。

本发明实施例具有如下有益效果：

1、简化了通过容器云和服务网格发布应用时的操作流程:只需要配置灰度发布的模板，便可以自动生成相关微服务调用的服务网格；

2、降低了服务网格的应用门槛:用户无需手工编写服务网格的相关资源，而是自动生成发布配置文件，同时相较于手工编写发布配置文件，本实施例所采用的应用发布模板直观、简单和容易理解；

3、同时支持多种灰度发布模式:同时支持蓝绿发布、金丝雀发布、AB测试三种模式的灰度发布，本申请可以在应用发布模板同时针对三种灰度发布的参数进行设置；

4、无需多个环境:由于本实施例的新版本和旧版本的部署集在同一个kubernetes集群中，相当于新版本和旧版本的应用运行在同一个环境中，无需多个环境分别部署集新版本和旧版本应用，只需要在同一个环境运行新版本和旧版本应用，即可实现灰度发布；同时，通过在目标子集中更换新版本和旧版本的标签信息，以及在虚拟服务中逐步调整新版本和旧版本的流量比例，使得版本升级以及流量切换更加平滑；

5、结合了复杂的微服务调用:可针对多个微服务的复杂的调用链实施灰度发布，相较于现有技术中的不同微服务只能独立处理版本升级，不能实现微服务之间的不同版本的访问；本实施例的复杂的微服务调用实现了将访问微服务A的旧版本的请求，路由至服务B的新版本，进而可以访问到服务B的新版本；

6、应用的灰度发布与应用的部署集之间协同配合简单:本实施例通过服务网格实现新版本和旧版本的流量切换，通过容器云实现新版本和旧版本应用的上线与下线，服务网格和容器云的协同配合简单，进一步简化和便利了应用发布的操作流程。

本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。本领域普通技术人员可以理解实现上述实施例中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

Claims (10)

1.一种基于容器云和服务网格的应用发布方法，应用于kubernetes中，其特征在于，包括以下步骤：

通过应用发布模板设置用于发布不同版本的第一应用的参数；所述参数包括：新版本域名、旧版本域名、新版本流量比例、旧版本流量比例、各个微服务的服务名、各个微服务的标签版本信息、各个微服务的头部信息的匹配规则、各个微服务访问路径前缀，以及各个微服务是否为默认入口微服务；

根据所述应用发布模板和参数生成容器云的第一资源配置和服务网格的第二资源配置；生成所述第一资源配置和第二资源配置后，形成虚拟服务和目标规则的第一流量路由规则、所述目标规则和微服务的第二流量路由规则以及各个微服务之间的调用关系；

发布所述不同版本的第一应用，所述不同版本的第一应用部署在容器云中，并通过访问微服务的部署集来访问不同版本的第一应用。

2.根据权利要求1所述的基于容器云和服务网格的应用发布方法，其特征在于，所述新版本域名用于设置蓝绿发布时，访问新版本应用的域名信息；

所述旧版本域名用于设置蓝绿发布时，访问旧版本应用的域名信息；

所述新版本流量比例用于设置金丝雀发布时，访问新版本应用的流量比例；

所述旧版本流量比例用于设置金丝雀发布时，访问旧版本应用的流量比例；

所述各个微服务的服务名，用于设置目标规则所指向的微服务；

所述各个微服务的标签版本信息，用于设置目标规则中的目标子集的标签上的版本信息，所述版本信息包括新版本信息和旧版本信息；

所述各个微服务的头部信息的匹配规则，用于设置所述头部信息中的版本标记信息的匹配规则；所述头部信息为HTTP header；

所述各个微服务访问路径前缀，用于设置访问微服务的访问路径前缀的匹配规则；

所述各个微服务是否为默认入口微服务，用于设置在默认情况下是否访问当前网关的默认微服务，所述默认情况指访问路径不符合所述各个微服务访问路径前缀的匹配规则。

3.一种基于容器云和服务网格的流量路由方法，适用于如权利要求1所述的基于容器云和服务网格的应用发布方法发布的第一应用，其特征在于，包括以下步骤：

通过虚拟服务接收来自网关的第一请求，所述虚拟服务根据预设的第一流量路由规则，将所述第一请求路由至对应目标规则中的目标子集；所述目标规则包括标签信息为新版本的目标子集和标签信息为旧版本的目标子集；

根据所述目标子集的标签信息上的版本信息将所述第一请求路由至对应版本的微服务的部署集；

根据所述部署集上运行的版本信息和所述微服务和其他微服务之间的调用关系，将所述第一请求路由至其他微服务的部署集，以使所述第一请求访问对应版本的第一应用。

4.根据权利要求3所述的基于容器云和服务网格的流量路由方法，其特征在于，所述第一流量路由规则包括以下分发规则中的一种或多种组合：

第一分发规则为：将从不同网关进入的请求，根据所述不同网关各自对应的版本信息，将进入的请求路由至对应目标规则的目标子集；所述从不同网关进入的请求，在进入网关之前，根据域名和网关的对应关系，将请求路由至相应的网关；

第二分发规则为：针对从同一网关进入的请求，根据预设的头部信息匹配规则，将符合所述头部信息匹配规则的进入的请求和不符合所述头部信息匹配规则的进入的请求，分别路由至对应目标规则的目标子集；所述头部信息为HTTP header；

第三分发规则为：针对从同一网关进入的请求，按照预设的新版本的流量比例和旧版本的流量比例，将进入的请求随机路由至对应目标规则的目标子集。

5.根据权利要求4所述的基于容器云和服务网格的流量路由方法，其特征在于，当所述第一流量路由规则包括分发规则中的多种组合时，所述虚拟服务按照分发规则的优先级执行流量路由规则；所述分发规则的优先级为：所述第一分发规则的优先级高于所述第二分发规则的优先级高于所述第三分发规则的优先级。

6.根据权利要求5所述的基于容器云和服务网格的流量路由方法，其特征在于，当第一流量路由规则包括第一分发规则和第二分发规则时，所述虚拟服务根据预设的第一流量路由规则将所述第一请求路由至对应目标规则的目标子集，具体为：

所述虚拟服务确定第一请求的网关对应的版本信息为旧版本时，获取所述第一请求的头部信息，将符合所述头部信息匹配规则的第一请求路由至对应目标规则的标签信息为新版本的目标子集，将不符合所述头部信息匹配规则的第一请求路由至对应目标规则的标签信息为旧版本的目标子集；

所述虚拟服务确定第一请求的网关对应的版本信息为新版本时，将第一请求路由至对应目标规则的标签信息为新版本的目标子集。

7.根据权利要求5所述的基于容器云和服务网格的流量路由方法，其特征在于，当第一流量路由规则包括第一分发规则和第三分发规则时，所述虚拟服务根据预设的第一流量路由规则将所述第一请求路由至对应目标规则的目标子集，具体为：

所述虚拟服务确定第一请求的网关对应的版本信息为旧版本时，按照预设的新版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为新版本的目标子集，按照预设的旧版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为旧版本的目标子集；

所述虚拟服务确定第一请求的网关对应的版本信息为新版本时，将第一请求路由至对应目标规则的标签信息为新版本的目标子集。

8.根据权利要求5所述的基于容器云和服务网格的流量路由方法，其特征在于，当第一流量路由规则包括第一分发规则、第二分发规则和第三分发规则时，所述虚拟服务根据预设的第一流量路由规则将所述第一请求路由至对应目标规则的目标子集，包括以下步骤：

所述虚拟服务确定第一请求的网关对应的版本信息为旧版本时，获取所述请求的头部信息，将符合所述头部信息匹配规则的第一请求路由至对应目标规则的标签信息为新版本的目标子集；将不符合所述头部信息匹配规则的请求，按照预设的新版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为新版本的目标子集，按照预设的旧版本的流量比例路由相应比例的第一请求至对应目标规则的标签信息为旧版本的目标子集；

所述虚拟服务确定第一请求的网关对应的版本信息为新版本时，将第一请求路由至对应目标规则的标签信息为新版本的目标子集。

9.根据权利要求3至8任一项所述的基于容器云和服务网格的流量路由方法，其特征在于，通过虚拟服务接收来自微服务的第二请求，根据所述第二请求的头部信息中的版本标记信息确定所述第二请求对应访问的版本信息为新版本时，并将所述第二请求路由至对应目标规则的标签信息为新版本的目标子集；所述微服务透传带有版本标记信息的头部信息；

根据所述第二请求的头部信息中的版本标记信息确定所述第二请求对应访问的版本信息为旧版本时，并将所述第二请求路由至对应目标规则的标签信息为旧版本的目标子集；所述微服务透传带有版本标记信息的头部信息。

10.根据权利要求9所述的基于容器云和服务网格的流量路由方法，其特征在于，将每个微服务的目标规则的目标子集的版本信息设置为新版本，以完成新版本上线；将每个微服务的目标规则的目标子集的版本信息设置为旧版本，以完成新版本下线。

Images