CN112988394B - 基于云原生容器的业务服务发布方法、装置、介质和设备 - Google Patents

Abstract

本公开涉及基于云原生容器的业务服务发布方法、装置、介质和电子设备，方法包括：在PaaS平台的容器编排平台部署服务，创建服务对应的第一业务；服务向平台的服务注册中心注册时，创建服务的路由地址与第一业务的第一路由地址之间的映射关系；在部署服务对应的新版本服务时，创建新版本服务对应的第二业务；新版本服务注册时，创建新版本服务的路由地址与第二业务的第二路由地址之间的映射关系，新版本服务的路由地址与服务的路由地址相同；接收到多个服务请求时，基于映射关系以及预设负载均衡策略，将多个服务请求转发至第一业务和第二业务。该方案对Kubernetes原生集群无侵入性，集群运行稳定性高，也使后续运维难度显著降低。

Description

基于云原生容器的业务服务发布方法、装置、介质和设备

技术领域

本公开实施例涉及通信技术领域，尤其涉及一种基于云原生容器的业务服务发布方法，基于云原生容器的业务服务发布装置，以及实现基于云原生容器的业务服务发布方法的计算机可读存储介质和电子设备。

背景技术

以Kubernetes为核心的平台即服务PaaS(Platform-as-a-Service)云平台能够方便的部署管理运维容器化的应用。一个服务(Service)通常可包含多个微服务(Microservice)。而微服务的实体一般就是一个容器化的应用，这也是PaaS云平台能够独立部署的功能实体。基于云原生容器技术实现一套保证上层业务在不断流的同时去更新PaaS云平台上业务服务如一个微服务版本的方法是一个重点且关键的技术方向。

相关技术中，基于Kubernetes插件扩展机制实现监听器去监听业务服务的状态变化，同时对Kubernetes源代码做一定修改以支持基于原生yaml文件配置路由规则、以及流量负载均衡比例等来实现业务服务灰度发布。

但是，目前的技术方案会对Kubernetes原生集群有侵入性，源代码修改后存在一定的不稳定性可能和Kubernetes后续版本升级的不兼容性，导致后续的运维难度提升。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开实施例提供了一种基于云原生容器的业务服务发布方法，基于云原生容器的业务服务发布装置，以及实现基于云原生容器的业务服务发布方法的计算机可读存储介质和电子设备。

第一方面，本公开实施例提供了一种基于云原生容器的业务服务发布方法，该方法应用于平台即服务PaaS平台，该方法包括：

在所述PaaS平台的容器编排平台上部署服务，并创建所述服务对应的第一业务；

所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系；

在所述容器编排平台上部署所述服务对应的新版本服务时，创建所述新版本服务对应的第二业务；

所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，所述新版本服务的路由地址与所述服务的路由地址相同；

接收到多个服务请求时，基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务。

在本公开的一些实施例中，所述容器编排平台是kubernetes，所述方法还包括：

在所述kubernetes上部署所述服务时，创建所述服务对应的第一部署组件deployment；

所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系，包括：

所述服务的第一deployment向所述服务注册中心发送所述服务的路由地址，以及所述第一业务的业务名称和第一业务路由地址；

基于所述业务名称和第一业务路由地址构建所述第一路由地址；

建立所述第一路由地址与所述服务的路由地址之间的映射关系。

在本公开的一些实施例中，所述方法还包括：

在所述kubernetes上部署所述新版本服务时，创建所述新版本服务对应的第二部署组件deployment；

所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，包括：

所述新版本服务的第二deployment向所述服务注册中心发送所述新版本服务的路由地址，以及所述第二业务的业务名称和第二业务路由地址；其中，所述第二业务的业务名称与所述第一业务的业务名称相同；

基于所述业务名称和第二业务路由地址构建所述第二路由地址；

建立所述第二路由地址与所述新版本服务的路由地址之间的映射关系。

在本公开的一些实施例中，在所述PaaS平台的容器编排平台上部署服务，包括：

获取预设的yaml配置文件，所述yaml配置文件中至少携带服务镜像地址，所述服务镜像地址指示所述服务的代码镜像所在的镜像仓库；

解析所述yaml配置文件得到服务镜像地址，基于所述服务镜像地址，从所述镜像仓库拉取服务的代码镜像；

基于所述服务的代码镜像在所述容器编排平台上部署所述服务。

在本公开的一些实施例中，在所述容器编排平台上部署所述服务对应的新版本服务，包括：

获取预设的yaml配置文件，所述yaml配置文件中至少携带新版本服务镜像地址，所述新版本服务镜像地址指示所述新版本服务的代码镜像所在的镜像仓库；

解析所述yaml配置文件得到新版本服务镜像地址，基于所述新版本服务镜像地址，从所述镜像仓库拉取新版本服务的代码镜像；

基于所述新版本服务的代码镜像在所述容器编排平台上部署所述新版本服务。

在本公开的一些实施例中，所述预设负载均衡策略至少包括以下任意一项或多项：

在所述容器编排平台上部署所述服务对应的新版本服务之前，将接收的多个所述服务请求全部转发至所述第一业务；

在所述新版本服务正常启动后，在第一时长内基于预设权重将多个所述服务请求中的部分服务请求转发至所述第二业务，剩余服务请求转发至所述第一业务；

在所述第一时长结束后的第二时长内，逐渐增大所述预设权重直至全部服务请求转发至所述第二业务。

在本公开的一些实施例中，每个所述服务请求携带指定路由地址；所述基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务，包括：

解析获取每个所述服务请求中携带的指定路由地址；

在所述映射关系中查找每个所述指定路由地址对应的第一路由地址和第二路由地址；

基于查找到的第一路由地址和第二路由地址，以及所述预设负载均衡策略将多个所述服务请求转发至对应的所述第一业务和第二业务。

第二方面，本公开实施例提供一种基于云原生容器的业务服务发布装置，该装置应用于平台即服务PaaS平台，包括：

第一部署模块，用于在所述PaaS平台的容器编排平台上部署服务，并创建所述服务对应的第一业务；

第一注册模块，用于所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系；

第二部署模块，用于在所述容器编排平台上部署所述服务对应的新版本服务时，创建所述新版本服务对应的第二业务；

第二注册模块，用于所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，所述新版本服务的路由地址与所述服务的路由地址相同；

路由模块，用于接收到多个服务请求时，基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务。

第三方面，本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一实施例所述基于云原生容器的业务服务发布方法的步骤。

第四方面，本公开实施例提供一种电子设备，包括：

处理器；以及

存储器，用于存储计算机程序；

其中，所述处理器配置为经由执行所述计算机程序来执行上述任一实施例所述基于云原生容器的业务服务发布方法的步骤。

本公开实施例提供的技术方案与现有技术相比具有如下优点：

本公开实施例提供的业务服务发布方法、装置、介质和电子设备，在PaaS平台的容器编排平台上部署服务，并创建所述服务对应的第一业务，所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系；在所述容器编排平台上部署所述服务对应的新版本服务时，创建所述新版本服务对应的第二业务；所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，所述新版本服务的路由地址与所述服务的路由地址相同；接收到多个服务请求时，基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务。这样，本实施例中基于PaaS平台的服务注册中心，在服务部署后注册时建立服务以及新版本服务的路由地址与后台各自对应的业务的路由地址之间的映射关系，这样打通了业务层的服务与容器层运行业务的Pod之间的路由，基于此可以实现服务的灰度发布，其仅需在逻辑层面配置即可实现，无需插件以及修改Kubernetes源代码等，对Kubernetes原生集群无侵入性，集群运行稳定性高，也使后续的运维难度显著降低。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本公开实施例基于云原生容器的业务服务发布方法流程图；

图2为本公开示例性实施例示出的PaaS平台示意图；

图3为本公开另一实施例基于云原生容器的业务服务发布方法流程图；

图4为本公开实施例基于云原生容器的业务服务发布装置示意图；

图5为本公开实施例实现基于云原生容器的业务服务发布方法的电子设备示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

应当理解，在下文中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

图1为本公开实施例示出的基于云原生容器的业务服务发布方法流程图，该方法应用于平台即服务PaaS平台，如图2中所示PaaS平台至少可以包括路由网关、服务注册中心等，这些单元或组件以及其余未示出的部分可以参考现有技术理解，此处不再赘述。该方法可以包括以下步骤：

步骤S101：在所述PaaS平台的容器编排平台上部署服务，并创建所述服务对应的第一业务。

示例性的，容器编排平台可以是Kubernetes。服务可以是PaaS平台上的一个微服务。通常部署的服务并没有暴露给外界使用，在PaaS平台中真正提供给外部使用的是业务，业务是PaaS平台中对一个或者一组具有相同功能服务的抽象，运行在Pod上。为了将服务对外提供使用，需要在PaaS平台中创建对应的业务，也可以理解为一个服务对应的服务实例。具体的，可以在Kubernetes部署服务A，并创建服务A对应的业务A。

步骤S102：所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系。

示例性的，在微服务的架构中，服务注册中心是一个核心的概念，服务注册中心是服务发现中不可缺少的一部分，其具体内容可以参考现有技术理解，此处不再赘述。服务的路由地址即一个服务对外提供的路由地址，第一业务的第一路由地址即PaaS平台内该服务对应的第一业务的路由地址，其一般不对外提供，存储于服务注册中心。

具体的，在一实施例中，映射关系中的服务A的路由地址例如是“/a/b/c”，对应的业务A的第一路由地址例如是“业务1-svc-v1”。

步骤S103：在所述容器编排平台上部署所述服务对应的新版本服务时，创建所述新版本服务对应的第二业务。

示例性的，新版本服务A’是服务A的新版本，可以认为属于同一服务。具体的，可以在Kubernetes部署服务A对应的新版本服务A’，创建新版本服务A’对应的第二业务如业务B。

步骤S104：所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，所述新版本服务的路由地址与所述服务的路由地址相同。

示例性的，新版本服务A’与服务A是属于同一个服务，所以新版本服务A’的路由地址与服务A的路由地址相同如都是“/a/b/c”，也即，新版本服务A’对应的后台的业务B和服务A对应后台的业务A，对外提供的服务的路由地址均是“/a/b/c”。而在PaaS平台内部，新版本服务A’与服务A各自对应的业务B和业务A的路由地址是不同的。

具体的，新版本服务A’向所述服务注册中心注册时，也可以在服务注册中心创建所述新版本服务的路由地址如“/a/b/c”与第二业务如业务B的第二路由地址如“业务1-svc-v2”之间的映射关系。

步骤S105：接收到多个服务请求时，基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务。

具体的，客户端（Client）发送业务请求到PaaS平台时，PaaS平台的路由网关接收业务请求，获取业务请求携带的路由地址如“/a/b/c”。服务注册中心中存储的映射关系中的服务A的路由地址例如是“/a/b/c”，对应的业务A的第一路由地址例如是“业务1-svc-v1”。路由网关可以从服务注册中心拉取映射关系，在映射关系匹配到该业务请求的路由地址“/a/b/c”指示该业务请求是属于该服务A的，其对应的业务A的路由地址是“业务1-svc-v1”，则可以将该业务请求转发至服务A对应的第一业务如业务A，由该第一业务响应处理该业务请求。同理，与上述过程相同，业务请求携带的路由地址是“/a/b/c”时，路由网关也可以将业务请求转发至新版本服务A’对应的业务B。本实施例中，可以基于预设负载均衡策略，将多个服务请求转发至业务A和业务B，例如在正是启动新版本服务A’之前，携带的路由地址是“/a/b/c”的所有服务请求全部转发至业务A。

本实施例中基于PaaS平台的服务注册中心，在服务部署后注册时建立服务以及新版本服务的路由地址与后台各自对应的业务的路由地址之间的映射关系，这样打通了业务层的服务与容器层运行业务的Pod之间的路由，基于此可以实现服务的灰度发布，其仅需在逻辑层面配置即可实现，无需插件以及修改Kubernetes源代码等，对Kubernetes原生集群无侵入性，集群运行稳定性高，也使后续的运维难度显著降低。

可选的，在本公开的一些实施例中，所述容器编排平台是kubernetes，所述方法还可以包括以下步骤：

步骤a)：在所述kubernetes上部署所述服务时，创建所述服务对应的第一部署组件deployment。

具体的，例如创建服务A对应的第一deployment组件，deployment组件用于部署应用的对象，管理Pod等。

相应的，步骤S102中所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系，具体可以包括以下步骤：

步骤b）：所述服务的第一deployment组件向所述服务注册中心发送所述服务的路由地址，以及所述第一业务的业务名称和第一业务路由地址。

示例性的，服务的路由地址例如是“/a/b/c”，第一业务即业务A的业务名称例如是“业务1”，第一业务路由地址例如是“svc-v1”，这些仅为举例说明，本实施例中对此不作限制。

具体的，服务A的deployment组件向服务注册中心发送服务的路由地址“/a/b/c”，以及业务A的业务名称“业务1”和业务路由地址“svc-v1”。

步骤c）：基于所述业务名称和第一业务路由地址构建所述第一路由地址。

具体的，服务注册中心基于业务A的业务名称“业务1”和业务路由地址“svc-v1”构建业务A的第一路由地址如“业务1-svc-v1”。

步骤d）：建立所述第一路由地址与所述服务的路由地址之间的映射关系。

具体的，服务注册中心建立第一路由地址如“业务1-svc-v1”与服务的路由地址“/a/b/c”之间的映射关系。

本实施例中，通过上述方式可以简单高效地建立映射关系即PaaS平台上的业务A与服务A的绑定关联关系。

进一步可选的，在本公开的一些实施例中，所述方法还可以包括以下步骤：

步骤e）：在所述kubernetes上部署所述新版本服务时，创建所述新版本服务对应的第二部署组件deployment。

具体的，在kubernetes上部署新版本服务A’对应的第二deployment组件。

相应的，步骤S104中所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，具体可以包括以下步骤：

步骤f）：所述新版本服务的第二deployment组件向所述服务注册中心发送所述新版本服务的路由地址，以及所述第二业务的业务名称和第二业务路由地址；其中，所述第二业务的业务名称与所述第一业务的业务名称相同。

示例性的，新版本服务A’的路由地址例如也是“/a/b/c”，第二业务即业务B的业务名称例如是“业务1”，即与业务A的业务名称相同，标识是同一业务，只是版本不同，第二业务路由地址即业务B的路由地址例如是“svc-v2”，这些仅为举例说明，本实施例中对此不作限制。

具体的，新版本服务A’的deployment组件向服务注册中心发送新版本服务A’的路由地址“/a/b/c”，以及业务B的业务名称如“业务1”和业务路由地址“svc-v2”。新版本服务A’在向服务注册中心注册时使用的业务名称仍和之前业务A的业务名称保持一致，这样PaaS平台就可以识别到这是同一个业务的服务，只是版本的区别。

步骤g）：基于所述业务名称和第二业务路由地址构建所述第二路由地址。

具体的，服务注册中心基于业务B的业务名称如“业务1”和业务路由地址“svc-v2”构建业务B的第二路由地址如“业务1-svc-v2”。

步骤h）：建立所述第二路由地址与所述新版本服务的路由地址之间的映射关系。

具体的，服务注册中心建立第二路由地址如“业务1-svc-v2”与新版本服务A’的路由地址“/a/b/c”之间的映射关系。

可选的，在本公开的一些实施例中，结合图3中所示，步骤S101中在所述PaaS平台的容器编排平台上部署服务，具体可以包括以下步骤：

步骤S301：获取预设的yaml配置文件，所述yaml配置文件中至少携带服务镜像地址，所述服务镜像地址指示所述服务的代码镜像所在的镜像仓库。

具体的，对打包好的服务的代码文件构建代码镜像，然后将服务的代码镜像推入指定的镜像仓库。yaml配置文件可以预先写好并存储，PaaS平台会调用Kubernetes的应用程序接口API将yaml文件部署到kubernetes中，yaml配置文件携带服务镜像地址，该服务镜像地址指示服务的代码镜像所在的镜像仓库。

步骤S302：解析所述yaml配置文件得到服务镜像地址，基于所述服务镜像地址，从所述镜像仓库拉取服务的代码镜像。

步骤S303：基于所述服务的代码镜像在所述容器编排平台上部署所述服务。

在一个实施例中，登陆PaaS平台后，用户可以通过web图形页面基于写好的Kubernetes 的yaml配置文件进行服务部署。具体的，解析yaml配置文件得到服务镜像地址，基于服务镜像地址从相应的镜像仓库拉取服务的代码镜像。然后基于服务的代码镜像在容器编排平台Kubernetes上部署服务A。需要说明的是，服务部署的具体细节过程可以参考现有技术理解，此处不再赘述。

可选的，与上述实施例相同，在本公开的一些实施例中，步骤S103中在所述容器编排平台上部署所述服务对应的新版本服务，具体可以包括以下步骤：

步骤1）：获取预设的yaml配置文件，所述yaml配置文件中至少携带新版本服务镜像地址，所述新版本服务镜像地址指示所述新版本服务的代码镜像所在的镜像仓库。

步骤2）：解析所述yaml配置文件得到新版本服务镜像地址，基于所述新版本服务镜像地址，从所述镜像仓库拉取新版本服务的代码镜像。

步骤3）：基于所述新版本服务的代码镜像在所述容器编排平台上部署所述新版本服务。

需要说明的是，上述步骤1）至步骤3）的具体实施过程可以参考步骤S301~S303中的对应详细描述，两者除了yaml配置文件中的服务镜像地址不同，其余过程基本相同，此处不再赘述。

可选的，在本公开的一些实施例中，所述预设负载均衡策略至少包括但不限于以下任意一项或多项：

1）在所述容器编排平台上部署所述服务对应的新版本服务之前，将接收的多个所述服务请求全部转发至所述第一业务如业务A。也即是说，保证100%的流量路由到v1版本的服务A上，这样即使上线了v2版本的新版本服务A’，也不会有任何业务请求路由到新版本服务A’。

2）在所述新版本服务正常启动后，在第一时长内基于预设权重将多个所述服务请求中的部分服务请求转发至所述第二业务，剩余服务请求转发至所述第一业务；在所述第一时长结束后的第二时长内，逐渐增大所述预设权重直至全部服务请求转发至所述第二业务。

示例性的，第一时长和第二时长可以根据需要设置，对此不作限制。也即是说，v2版本的新版本服务A’正常启动后，可以在PaaS平台通过例如web页面配置路由到v2版本的新版本服务A’对应的业务B的负载均衡权重，示例性的，结合图2所示，刚开始可以为业务B配置如5%左右的权重，在经过一段时间的观测确认新版本服务A’没有问题之后，可以逐步增大v2版本的新版本服务A’的权重，直到权重达到最后的100%，即切换全部流量到新版本服务A’ 对应的业务B，经过一段时间的全流量测试后，就可以逐步关闭v1版本的服务A对应的业务A，这样就完成了整个灰度发布如金丝雀发布方式的服务发布过程。

本实施例的上述方案通过动态即时配置路由权重策略避免了系统服务新旧版本更替带来的流量间歇断流问题，保证上层业务在不断流的同时更新PaaS云平台上业务服务，可以较为精准地控制流量方向，同时，对上层的流量和业务感知较敏感，易于扩展维护。

可选的，在本公开的一些实施例中，每个所述服务请求携带指定路由地址。步骤S105中基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务，包括以下步骤：

步骤i）：解析获取每个所述服务请求中携带的指定路由地址。

示例性的，例如业务请求携带指定路由地址如“/a/b/c”，可以解析业务请求获得指定路由地址“/a/b/c”。

步骤ii）：在所述映射关系中查找每个所述指定路由地址对应的第一路由地址和第二路由地址。

示例性的，基于上述示例的映射关系，可以查找到指定路由地址“/a/b/c”对应的第一路由地址“业务1-svc-v1”和第二路由地址“业务1-svc-v2”

步骤iii）：基于查找到的第一路由地址和第二路由地址，以及所述预设负载均衡策略将多个所述服务请求转发至对应的所述第一业务和第二业务。

具体的，路由网关可以基于第一路由地址“业务1-svc-v1”和第二路由地址“业务1-svc-v2”，以及上述预设负载均衡策略将多个服务请求转发至对应的第一业务如业务A和第二业务如业务B，具体过程可以参考前述实施例中的描述，此处不再赘述。

需要说明的是，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。另外，也易于理解的是，这些步骤可以是例如在多个模块/进程/线程中同步或异步执行。

基于同一发明构思，如图4中所示，本公开实施例提供一种基于云原生容器的业务服务发布装置，该装置应用于平台即服务PaaS平台，包括：

第一部署模块401，用于在所述PaaS平台的容器编排平台上部署服务，并创建所述服务对应的第一业务；

第一注册模块402，用于所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系；

第二部署模块403，用于在所述容器编排平台上部署所述服务对应的新版本服务时，创建所述新版本服务对应的第二业务；

第二注册模块404，用于所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，所述新版本服务的路由地址与所述服务的路由地址相同；

路由模块405，用于接收到多个服务请求时，基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务。

本实施例中基于PaaS平台的服务注册中心，在服务部署后注册时建立服务以及新版本服务的路由地址与后台各自对应的业务的路由地址之间的映射关系，这样打通了业务层的服务与容器层运行业务的Pod之间的路由，基于此可以实现服务的灰度发布，其仅需在逻辑层面配置即可实现，无需插件以及修改Kubernetes源代码等，对Kubernetes原生集群无侵入性，集群运行稳定性高，也使后续的运维难度显著降低。

可选的，在本公开的一些实施例中，所述容器编排平台是kubernetes，所述装置还包括创建模块，用于在所述kubernetes上部署所述服务时，创建所述服务对应的第一deployment组件。相应的，第一注册模块具体可用于所述服务向所述PaaS平台的服务注册中心注册时，所述服务的第一deployment组件向所述服务注册中心发送所述服务的路由地址，以及所述第一业务的业务名称和第一业务路由地址；基于所述业务名称和第一业务路由地址构建所述第一路由地址；建立所述第一路由地址与所述服务的路由地址之间的映射关系。

可选的，在本公开的一些实施例中，所述装置还包括第二创建模块，用于在所述kubernetes上部署所述新版本服务时，创建所述新版本服务对应的第二deployment组件。相应的，所述第二注册模块具体可用于所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，具体可包括以下方式：

所述新版本服务的第二deployment组件向所述服务注册中心发送所述新版本服务的路由地址，以及所述第二业务的业务名称和第二业务路由地址；其中，所述第二业务的业务名称与所述第一业务的业务名称相同；

基于所述业务名称和第二业务路由地址构建所述第二路由地址；

建立所述第二路由地址与所述新版本服务的路由地址之间的映射关系。

可选的，在本公开的一些实施例中，第一部署模块在所述PaaS平台的容器编排平台上部署服务，具体可包括：获取预设的yaml配置文件，所述yaml配置文件中至少携带服务镜像地址，所述服务镜像地址指示所述服务的代码镜像所在的镜像仓库；解析所述yaml配置文件得到服务镜像地址，基于所述服务镜像地址，从所述镜像仓库拉取服务的代码镜像；基于所述服务的代码镜像在所述容器编排平台上部署所述服务。

可选的，在本公开的一些实施例中，第一部署模块在所述容器编排平台上部署所述服务对应的新版本服务，具体可包括：获取预设的yaml配置文件，所述yaml配置文件中至少携带新版本服务镜像地址，所述新版本服务镜像地址指示所述新版本服务的代码镜像所在的镜像仓库；解析所述yaml配置文件得到新版本服务镜像地址，基于所述新版本服务镜像地址，从所述镜像仓库拉取新版本服务的代码镜像；基于所述新版本服务的代码镜像在所述容器编排平台上部署所述新版本服务。

可选的，在本公开的一些实施例中，所述预设负载均衡策略至少包括以下任意一项或多项：在所述容器编排平台上部署所述服务对应的新版本服务之前，将接收的多个所述服务请求全部转发至所述第一业务；在所述新版本服务正常启动后，在第一时长内基于预设权重将多个所述服务请求中的部分服务请求转发至所述第二业务，剩余服务请求转发至所述第一业务；在所述第一时长结束后的第二时长内，逐渐增大所述预设权重直至全部服务请求转发至所述第二业务。

可选的，在本公开的一些实施例中，每个所述服务请求携带指定路由地址；所述路由模块基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务，具体可包括：解析获取每个所述服务请求中携带的指定路由地址；在所述映射关系中查找每个所述指定路由地址对应的第一路由地址和第二路由地址；基于查找到的第一路由地址和第二路由地址，以及所述预设负载均衡策略将多个所述服务请求转发至对应的所述第一业务和第二业务。

关于上述实施例中的装置，其中各个模块执行操作的具体方式以及带来的相应技术效果已经在有关该方法的实施例中进行了对应的详细描述，此处将不做详细阐述说明。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。作为模块或单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现木公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本公开实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一项实施例所述基于云原生容器的业务服务发布方法的步骤。

示例性的，该可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

所述计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

本公开实施例还提供一种电子设备，如图5所示包括处理器501以及存储器502，存储器502用于存储计算机程序。其中，所述处理器501配置为经由执行所述计算机程序来执行上述任一项实施例中所述基于云原生容器的业务服务发布方法的步骤。示例性的，所述电子设备可以是但不限于服务器或服务器集群。

所描述的实施例中的各方面、实施方式、实现或特征能够单独使用或以任意组合的方式使用。所描述的实施例中的各方面可由软件、硬件或软硬件的结合实现。所描述的实施例也可以由存储有计算机可读代码的计算机可读介质体现，该计算机可读代码包括可由至少一个计算装置执行的指令。所述计算机可读介质可与任何能够存储数据的数据存储装置相关联，该数据可由计算机系统读取。用于举例的计算机可读介质可以包括只读存储器、随机存取存储器、CD-ROM、HDD、DVD、磁带以及光数据存储装置等。所述计算机可读介质还可以分布于通过网络联接的计算机系统中，这样计算机可读代码就可以分布式存储并执行。

上述技术描述可参照附图，这些附图形成了本申请的一部分，并且通过描述在附图中示出了依照所描述的实施例的实施方式。虽然这些实施例描述的足够详细以使本领域技术人员能够实现这些实施例，但这些实施例是非限制性的；这样就可以使用其它的实施例，并且在不脱离所描述的实施例的范围的情况下还可以做出变化。比如，流程图中所描述的操作顺序是非限制性的，因此在流程图中阐释并且根据流程图描述的两个或两个以上操作的顺序可以根据若干实施例进行改变。作为另一个例子，在若干实施例中，在流程图中阐释并且根据流程图描述的一个或一个以上操作是可选的，或是可删除的。另外，某些步骤或功能可以添加到所公开的实施例中，或两个以上的步骤顺序被置换。所有这些变化被认为包含在所公开的实施例以及权利要求中。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (9)

1.一种基于云原生容器的业务服务发布方法，其特征在于，该方法应用于平台即服务PaaS平台，该方法包括：

在所述PaaS平台的容器编排平台上部署服务，并创建所述服务对应的第一业务；

所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系；

在所述容器编排平台上部署所述服务对应的新版本服务时，创建所述新版本服务对应的第二业务；

所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，所述新版本服务的路由地址与所述服务的路由地址相同；

接收到多个服务请求时，基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务；

所述预设负载均衡策略至少包括以下任意一项或多项：

在所述容器编排平台上部署所述服务对应的新版本服务之前，将接收的多个所述服务请求全部转发至所述第一业务；

在所述新版本服务正常启动后，在第一时长内基于预设权重将多个所述服务请求中的部分服务请求转发至所述第二业务，剩余服务请求转发至所述第一业务；

在所述第一时长结束后的第二时长内，逐渐增大所述预设权重直至全部服务请求转发至所述第二业务。

2.根据权利要求1所述的发布方法，其特征在于，所述容器编排平台是kubernetes，所述方法还包括：

在所述kubernetes上部署所述服务时，创建所述服务对应的第一部署组件deployment；

所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系，包括：

所述服务的第一deployment向所述服务注册中心发送所述服务的路由地址，以及所述第一业务的业务名称和第一业务路由地址；

基于所述业务名称和第一业务路由地址构建所述第一路由地址；

建立所述第一路由地址与所述服务的路由地址之间的映射关系。

3.根据权利要求2所述的发布方法，其特征在于，所述方法还包括：

在所述kubernetes上部署所述新版本服务时，创建所述新版本服务对应的第二部署组件deployment；

所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，包括：

所述新版本服务的第二deployment向所述服务注册中心发送所述新版本服务的路由地址，以及所述第二业务的业务名称和第二业务路由地址；其中，所述第二业务的业务名称与所述第一业务的业务名称相同；

基于所述业务名称和第二业务路由地址构建所述第二路由地址；

建立所述第二路由地址与所述新版本服务的路由地址之间的映射关系。

4.根据权利要求2或3所述的发布方法，其特征在于，在所述PaaS平台的容器编排平台上部署服务，包括：

获取预设的yaml配置文件，所述yaml配置文件中至少携带服务镜像地址，所述服务镜像地址指示所述服务的代码镜像所在的镜像仓库；

解析所述yaml配置文件得到服务镜像地址，基于所述服务镜像地址，从所述镜像仓库拉取服务的代码镜像；

基于所述服务的代码镜像在所述容器编排平台上部署所述服务。

5.根据权利要求2或3所述的发布方法，其特征在于，在所述容器编排平台上部署所述服务对应的新版本服务，包括：

获取预设的yaml配置文件，所述yaml配置文件中至少携带新版本服务镜像地址，所述新版本服务镜像地址指示所述新版本服务的代码镜像所在的镜像仓库；

解析所述yaml配置文件得到新版本服务镜像地址，基于所述新版本服务镜像地址，从所述镜像仓库拉取新版本服务的代码镜像；

基于所述新版本服务的代码镜像在所述容器编排平台上部署所述新版本服务。

6.根据权利要求1所述的发布方法，其特征在于，每个所述服务请求携带指定路由地址；所述基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务，包括：

解析获取每个所述服务请求中携带的指定路由地址；

在所述映射关系中查找每个所述指定路由地址对应的第一路由地址和第二路由地址；

基于查找到的第一路由地址和第二路由地址，以及所述预设负载均衡策略将多个所述服务请求转发至对应的所述第一业务和第二业务。

7.一种基于云原生容器的业务服务发布装置，其特征在于，该装置应用于平台即服务PaaS平台，包括：

第一部署模块，用于在所述PaaS平台的容器编排平台上部署服务，并创建所述服务对应的第一业务；

第一注册模块，用于所述服务向所述PaaS平台的服务注册中心注册时，在所述服务注册中心创建所述服务的路由地址与所述第一业务的第一路由地址之间的映射关系；

第二部署模块，用于在所述容器编排平台上部署所述服务对应的新版本服务时，创建所述新版本服务对应的第二业务；

第二注册模块，用于所述新版本服务向所述服务注册中心注册时，在所述服务注册中心创建所述新版本服务的路由地址与所述第二业务的第二路由地址之间的映射关系，所述新版本服务的路由地址与所述服务的路由地址相同；

路由模块，用于接收到多个服务请求时，基于所述映射关系以及预设负载均衡策略，将多个所述服务请求转发至所述第一业务和第二业务；

所述预设负载均衡策略至少包括以下任意一项或多项：

在所述容器编排平台上部署所述服务对应的新版本服务之前，将接收的多个所述服务请求全部转发至所述第一业务；

在所述新版本服务正常启动后，在第一时长内基于预设权重将多个所述服务请求中的部分服务请求转发至所述第二业务，剩余服务请求转发至所述第一业务；

在所述第一时长结束后的第二时长内，逐渐增大所述预设权重直至全部服务请求转发至所述第二业务。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1~6任一项所述基于云原生容器的业务服务发布方法的步骤。

9.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储计算机程序；

其中，所述处理器配置为经由执行所述计算机程序来执行权利要求1~6任一项所述基于云原生容器的业务服务发布方法的步骤。

Images