CN113285885B - 基于服务网格的边缘流量控制方法、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种基于服务网格的边缘流量控制方法、设备及存储介质。其中，中心节点可通过服务网格中的控制面组件获取目标服务的服务实例与用户域名的对应关系；根据该对应关系，可为服务实例在边缘节点上对应的容器添加属性标签，并确定流量路由规则。该流量路由规则可下发至边缘节点，供边缘节点对针对目标服务的访问请求进行流量控制。在这种实施方式中，无需在部署服务实例时对容器进行打标，降低了对容器发布系统的配合度要求。除此之外，对容器进行打标的过程由服务网格的控制面组件执行，因而无需对容器管理平台进行修改，可有效降低对容器管理平台的入侵性。

Description

基于服务网格的边缘流量控制方法、设备及存储介质

技术领域

本申请涉及边缘计算技术领域，尤其涉及一种基于服务网格的边缘流量控制方法、设备及存储介质。

背景技术

在边缘计算场景下，可在边缘节点提供FAAS（functions-as-a-service，功能即服务）产品供用户使用。应用程序运行在FAAS产品提供的沙箱里，边缘节点可对运行在沙箱里的应用程序进行流量管控。

现有的流量管控方式存在灵活性较差的缺陷。因此，有待提出一种新的解决方案。

发明内容

本申请的多个方面提供一种基于服务网格的边缘流量控制方法、设备及存储介质，用以提升边缘侧流量管控的灵活性。

本申请实施例提供一种基于服务网格的边缘流量控制方法，适用于中心节点，包括：通过服务网格中的控制面组件获取目标服务的服务实例与用户域名的对应关系；为所述服务实例在边缘节点上对应的容器添加属性标签，并确定所添加的属性标签与用户域名的对应关系；根据所述属性标签与用户域名的对应关系，确定流量路由规则；将所述流量路由规则发送至所述边缘节点，以使所述边缘节点根据所述流量路由规则以及访问请求对应的用户域名，将针对所述目标服务的访问请求路由至对应容器。

本申请实施例提供一种基于服务网格的边缘流量控制方法，适用于边缘节点，包括：通过服务网格中的数据面组件接收中心节点发送的流量路由规则；所述流量路由规则由所述服务网格中的控制面组件根据获取到的目标服务的服务实例与用户域名的对应关系生成；所述流量路由规则包括：用户域名与边缘节点上运行有服务实例的容器的属性标签的对应关系；接收针对所述服务实例对应的目标服务的访问请求并确定所述访问请求对应的用户域名；根据所述流量路由规则，从所述边缘节点上的容器中，确定属性标签与所述用户域名对应的目标容器；将所述访问请求路由至所述目标容器，以访问所述目标容器中运行的服务实例。

本申请实施例还提供一种基于服务网格的边缘流量控制方法，适用于中心节点，包括：通过服务网格中的控制面组件获取动态配置的流量策略；将所述流量策略发送至边缘节点，以使所述边缘节点从所述流量策略中解析到服务实例与用户域名的对应关系，并根据所述服务实例与用户域名的对应关系以及访问请求对应的用户域名，将针对所述服务实例对应的目标服务的访问请求路由至对应容器。

本申请实施例还提供一种基于服务网格的边缘流量控制方法，适用于边缘节点，包括：通过服务网格中的数据面组件接收中心节点发送的流量策略；对所述流量策略进行解析，得到多个服务实例与用户域名的对应关系；根据所述多个服务实例与用户域名的对应关系以及访问请求对应的用户域名，将针对所述多个服务实例对应的目标服务的访问请求路由至对应容器。

本申请实施例还提供一种服务器，包括：存储器和处理器；所述存储器用于存储一条或多条计算机指令；所述处理器用于执行所述一条或多条计算机指令以用于：执行本申请实施例提供的方法中的步骤。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被处理器执行时能够执行本申请实施例提供的方法中的步骤。

本申请实施例提供的基于服务网格的边缘流量控制系统中，中心节点可通过服务网格中的控制面组件获取目标服务的服务实例与用户域名的对应关系；根据该对应关系。基于该服务实例与用户域名的对应关系，可为服务实例在边缘节点上对应的容器添加属性标签，并所添加的属性标签与用户域名的对应关系，确定流量路由规则。该流量路由规则可下发至边缘节点，以供边缘节点对针对目标服务的访问请求进行流量控制。在这种实施方式中，无需在部署服务实例时对容器进行打标，降低了对容器发布系统的配合度要求。除此之外，在这种实施方式中，对容器进行打标的过程由服务网格的控制面组件执行，因而无需对容器管理平台进行修改，可有效降低对容器管理平台的入侵性，提升边缘侧流量管控的灵活性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一示例性实施例提供的基于服务网格的边缘流量控制系统的结构示意图；

图2为本申请一示例性实施例提供的动态打标过程的示意图；

图3是本申请一示例性实施例提供的流量控制方法在中心节点侧的流程示意图；

图4是本申请另一示例性实施例提供的流量控制方法在边缘节点侧的流程示意图；

图5是本申请另一示例性实施例提供的流量控制方法在中心节点侧的流程示意图；

图6是本申请另一示例性实施例提供的流量控制方法在边缘节点侧的流程示意图；

图7是本申请另一示例性实施例提供的服务器的结构示意图。

具体实施方式

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

在边缘计算场景下，可在边缘节点提供FAAS（functions-as-a-service，功能即服务）产品供用户使用。应用程序运行在FAAS产品提供的沙箱里，边缘节点可对运行在沙箱里的应用程序的访问请求进行流量管控。

现有的一种常用的流量管控方式中，将不同用户使用的服务部署为Kubernetes（用于容器管理的一种应用，可称为容器管理平台）维度的不同的服务实例，并在接入层网关配置路由规则来控制流量路由。另一种常用的流量管控方式中，在部署服务实例时，为不同用户使用的服务实例打上对应的标签，并通过在接入层网关配置路由规则来控制流量路由。上述流量管控方式中，需在部署服务实例时对服务实例进行编排，且需要服务发布系统的配合，灵活度较差。当流量管控策略改变时，必须重新部署服务实例或者对服务实例重新打标，因而对Kubernetes具有较强的侵入，且频繁对Kubernetes中的pod（Kubernetes中的最小管理、部署单元）进行写操作具有一定的有稳定性风险。同时，若服务实例的状态改变，则服务实例的注册中心需要重新同步服务实例改变后的状态，这种同步操作导致整体更新链路变长，增加了针对访问请求的响应时延。

针对上述技术问题，在本申请一些实施例中，提供了一种解决方案，该解决方案基于服务网格（Service Mesh）实现。其中，服务网格为微服务中用于处理服务间通信的基础设施层，可在云原生应用复杂的拓扑中实现可靠的请求传递。以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请一示例性实施例提供的基于服务网格的边缘流量控制系统的结构示意图，如图1所示，该流量控制系统100包括中心节点10以及边缘节点20。

其中，中心节点10以及边缘节点20可分别由一台或者多台服务器设备实现，该服务器设备可以实现为常规服务器、云服务器、云主机、虚拟中心等服务器等设备。

其中，中心节点10包括：容器管理平台101以及服务网格中的控制面组件102。容器管理平台101可实现为运行在服务器设备上的容器管理应用Kubernetes，Kubernetes可提供数据库etcd以及入口组件APIServer（Application Programming Interface Server，应用程序接口服务端）。

其中，etcd是一个分布式的、高可用的、一致的key-value（键值对）存储数据库,主要用于共享配置和服务发现。其中，APIServer是Kubernetes系统中用于对象的增、删、查、改、盯（监听）的服务端。数据存储在分布式一致的etcd中，APIServer可提供etcd中存储的数据的认证鉴权、缓存、API版本适配转换等一系列的功能。中心节点中的其他模块可通过API Server查询或修改etcd中的数据。同时，APIServer也可作为资源配额控制的入口。

其中，边缘节点20用于基于位于边缘的服务器设备，提供边缘节点服务（EdgeNode Service，ENS）。ENS可基于运营商边缘节点和网络构建，一站式提供靠近终端用户的、全域覆盖的、弹性分布式算力资源，通过终端数据就近计算和处理，优化响应时延、中心负荷和整体成本。边缘节点20可基于服务网格中的数据面组件201进行服务发现，并与其他模块或者设备进行通信。其中，服务网格基于Istio（一种开源的服务网格框架）体系结构实现时，数据面组件201可实现为服务网格中的MOSN（Modular Open Smart Network-proxy，模块化开放智能网络-代理）组件。

在基于服务网格的边缘流量控制系统中，服务网格中的控制面组件102位于中心节点10。服务网格基于Istio体系结构实现时，该控制面组件102可实现为图中示意的pilot组件。pilot组件用于提供策略配置API（Application Programming Interface，应用程序接口），并与数据网格中的数据面通信，以下发策略配置。

在本实施例中，中心节点10主要用于：通过服务网格中的控制面组件102获取目标服务的服务实例与用户域名的对应关系。该目标服务的服务实例与用户域名的对应关系可由容器管理平台101提供。在一些实施例中，通过容器管理平台101部署目标服务时，可对目标服务的服务实例与用户域名的对应关系进行规划，以使得控制面组件102从容器管理平台101获取目标服务的服务实例与用户域名的对应关系。

在另一些实施例中，中心节点10可通过容器管理平台101获取动态配置的流量策略。该流量策略用于描述目标服务的服务实例与用户域名的对应关系，以用于指示将来自不同用户域名的针对目标服务的访问请求路由至该目标服务的不同的服务实例。例如，针对一些访问量较大且访问频次较高的用户而言，为满足用户对服务实例的使用需求，可设置单个客户独享目标服务的某些服务实例。在配置流量策略时，可设置单个用户域名与服务实例的对应关系。针对一些访问量较小且访问频次较低的用户，为合理利用服务资源，可设置多个用户共享某些服务实例。在配置流量策略时，可设置多个用户域名与服务实例的对应关系。

在本实施例中，该流量策略，可由用户根据实际的流量控制需求进行个性化动态配置，并通过指定的方式导入控制面组件102。例如，在一些实施例中，该流量策略，可以是通过控制面组件102的策略配置API配置的。例如，用户可通过调用控制面组件102的策略配置API，向控制面组件102导入流量策略。在另一些实施例中，该流量策略，可以是控制面组件从容器管理平台101获取的，本实施例包含但不限于此。

获取到流量策略后，控制面组件102可对该流量策略进行解析，得到目标服务的服务实例与用户域名的对应关系。其中，对策略资源进行解析，可包括：对流量策略进行反序列化，并将反序列化的结果转化为指定的数据结构，以便于对流量策略中的服务实例和用户域名的对应关系进行识别。

其中，控制面组件102可通过容器管理平台101获取到边缘节点部署的服务实例与容器的相关信息。例如，如图1所示，ectd中保存有服务实例与pods的对应关系，控制面组件102可从etcd中同步pods/service(部署单元/服务实例)信息至pods/service 控制器。基于此，确定服务实例和用户域名的对应关系后，控制面组件102可为服务实例在边缘节点上对应的容器添加属性标签，并确定所添加的属性标签与用户域名的对应关系。

在本实施例中，容器管理平台101基于Kubernetes实现时，对容器添加属性标签的操作，可以实现为对Kubernetes中的最小单元pod进行打标签的操作。容器包含在pod中，对服务实例对应的容器进行打标签的操作，可实现为对服务实例所在的容器对应的pod进行打标签的操作，本实施例包含但不限于此。

以下将结合具体的例子进行说明。

例如，边缘节点上提供的某服务A具有以下服务实例Service1、Service2以及Service3。其中，Service1、Service2以及Service3分别运行在pod1、pod2以及pod3中。控制面组件102解析流量策略得到的服务A的服务实例Service1、Service2以及Service3与用户域名的对应关系为：

Service1>域名1

Service2>域名2、域名3

Service3>域名4

基于上述对应关系对边缘节点上的容器添加属性标签时，可对Service1所在的pod1添加属性标签V1，对Service2所在的pod2添加属性标签V2，对Service3所在的pod3添加属性标签V3。上述属性标签与用户域名的对应关系为：[V1：域名1]、[V2：域名2、域名3]、[V3：域名4]。

上述流量策略解析操作以及容器打标操作可由控制面组件102中的调度插件执行。基于调度插件，可在对控制面组件102实现较小入侵的情况下，为控制面组件102新增特定功能。一方面，可减少对控制面组件102原有的基于XDS(一类发现服务)协议的转换和下发逻辑进行改动。另一方面，对控制面组件102新增的调度插件对数据面组件是相对透明的，从而可在数据面组件无感知、无改动的情况下执行上述动态解析和容器的打标操作。

控制面组件102可根据上述属性标签与用户域名的对应关系，确定流量路由规则，该流量路由规则用于指示将来自不同用户域名的针对请求路由至不同的容器。确定流量路由规则后，控制面组件102可将该流量路由规则发送至边缘节点20。如图1所示，数据网格基于XDS协议进行数据传输时，控制面组件102可将流量路由规则转化为XDS协议,并通过XDSServer下发至边缘节点。

在本实施例中，采用数据网格传递数据时，流量路由规则可由数据网格中的数据面组件201接收。边缘节点20接收到流量路由规则后，可通过数据面组件201根据该流量路由规则以及访问请求对应的用户域名，将针对目标服务的访问请求路由至对应容器。

以针对任一服务的访问请求为例。边缘节点20接收到针对任一服务的访问请求后，边缘节点20对应的数据面组件201可确定该访问请求对应的用户域名；根据该流量路由规则，从边缘节点上的容器中，确定属性标签与该用户域名对应的目标容器，并将该访问请求路由至该目标容器。

承接上述例子。例如，边缘节点20接收到一针对目标服务ServiceA的访问请求，该访问请求对应的用户域名为域名1，域名1与标签V1对应，因此可将该访问请求路由至属性标签为V1的pod1。例如，边缘节点20接收到一针对ServiceA的两个访问请求，两个访问请求对应的用户域名分别为域名2以及域名3，域名2以及域名3均与标签V2对应，因此将该访问请求路由至属性标签为V2的pod2。

在一些实施例中，数据面组件201实现为服务网格中的MOSN组件时，为使得MOSN组件对用户域名信息进行识别，控制面组件102可根据解析得到的用户域名，生成包含用户域名信息的请求头，例如HTTP header（Hyper Text Transfer Protocol header，基于超文本传输协议的消息的请求头）。容器的属性标签与用户域名的关系，可以体现为包含用户域名的请求头与属性标签的对应关系。进而，MOSN组件可在接收到请求后，根据请求头，将请求路由至具有对应属性标签的容器，不再赘述。

在基于服务网格的边缘流量控制系统100中，为实现中心节点10和边缘节点20之间的上述数据交互过程，中心节点10和边缘节点20可建立通信连接，具体的通信连接方式可视实际的应用场景而定。

在一些示例性实施方式中，中心节点10和边缘节点20之间可采用有线通信方式无线通信方式进行通信。其中，无线通信方式包括蓝牙、ZigBee、红外线、WiFi（WIreless-Fidelity，无线保真技术）等短距离通信方式，也包括LORA等远距离无线通信方式，还可包括基于移动网络的无线通信方式。其中，当通过移动网络通信连接时，移动网络的网络制式可以为2G（GSM）、2.5G（GPRS）、3G（WCDMA、TD-SCDMA、CDMA2000、UTMS）、4G（LTE）、4G+（LTE+）、5G、WiMax等中的任意一种。

在本实施例中，中心节点可通过服务网格中的控制面组件获取动态配置的流量策略，并通过控制面组件对流量策略进行解析，得到目标服务的服务实例与用户域名的对应关系。基于该服务实例与用户域名的对应关系，可为服务实例在边缘节点上对应的容器添加属性标签，并所添加的属性标签与用户域名的对应关系，确定流量路由规则。该流量路由规则可下发至边缘节点，以供边缘节点对针对目标服务的访问请求进行流量控制。在这种实施方式中，流量策略可以动态配置，有利于灵活地根据实际需求进行流量控制。同时，这种方式无需在部署服务实例时对容器进行打标，降低了对容器发布系统的配合度要求。除此之外，在这种实施方式中，对容器进行动态打标的过程由服务网格的控制面组件执行，因而无需对容器管理平台进行修改，可有效降低对容器管理平台的入侵性。

在一些示例性的实施例中，中心节点10通过服务网格中的控制面组件获取动态配置的流量策略时，可通过控制面组件102监听中心节点10中的容器管理平台101的指定接口，该指定接口可以是前述实施例记载的APIServer。若通过该接口监听到容器管理平台101的资源更新事件，则可向容器管理平台101发送资源获取请求。容器管理平台101可根据该资源获取请求向控制面组件102下发流量策略。

控制面组件102接收容器管理平台101根据资源获取请求返回的流量策略后，可对流量策略进行解析，并根据解析结果生成可供边缘节点使用的流量路由规则。

容器管理平台101基于Kubernetes实现时，Kubernetes可提供一种自定义新的资源的方式，即：用户可通过CRD（CustomResourceDefinitions，用户资源自定义）的方式对Kubernetes进行功能扩展。通过CRD配置的文件又可称为CR（CustomResource，用户资源）文件。

基于此，在一些实施例中，用户可根据为边缘节点定制的流量策略生成CR文件，并根据该CR文件对Kubernetes进行功能扩展，即：将流量策略作为一种用户资源，从而动态地对边缘节点的流量策略进行配置。

其中，Kubernetes可对外提供OpenAPI(开放接口)以供用户（例如研发人员）调用。如图1所示，用户可通过OpenAPI将流量策略导入服务网格中的存储空间（mesh Server）。Kubernetes中的APIServer可从mesh Server中获取导入的流量策略，并对流量策略进行格式转换，生成流量策略对应的CR文件。该流量策略对应的CR文件可被写入etcd中，作为更新的用户资源。

流量策略写入etcd后，Kubernetes发生资源更新事件，该资源更新事件被控制面组件102监听到后，可通过APIServer向etcd发送资源获取请求，并通过APIServer接收流量策略。

在一些示例性的实施例中，流量策略的生效范围可以是与中心节点10连接的所有边缘节点，也可以是与中心节点10连接的部分节点。也就是说，基于流量策略，可以实现边缘节点这一粒度级别的流量管控。

其中，需要针对部分边缘节点进行流量控制时，可在配置流量策略时，在流量策略中添加边缘节点的标识。控制面组件102获取到流量策略后，可进一步解析该流量策略携带的边缘节点标识，并从边缘侧的节点中确定与解析到的该边缘节点标识对应的节点，作为位于流量路由规则的生效范围内的边缘节点。以下将结合不同的例子进行示例性说明。

例如，如图2所示，服务A分别部署在第一边缘节点以及第二边缘节点中，第一边缘节点和第二边缘节点分别位于不同的地理位置（例如位于不同的城市），以方便不同地理位置范围内的用户就近访问。在第一边缘节点上，服务A的服务实例Service1、Service2、Service3以及Service4分别运行在的pod1、pod2、pod3以及pod4中。在第二边缘节点上，服务A的服务实例Service1、Service2、Service3以及Service4分别运行在第二边缘节点的pod1、pod2、pod3以及pod4中。

当需要对第一边缘节点的访问请求进行流量控制时，可在第一边缘节点的流量策略中配置Service1、Service2、Service3以及Service4与用户域名的对应关系。控制面组件102可基于该对应关系，对第一边缘节点中的pod1、pod2、pod3以及pod4进行动态打标，并将打标结果与用户域名的对应关系下发至数据面组件，以使得数据面组件对第一边缘节点上针对服务A的访问请求进行流量控制。例如，如图2所示，对第一边缘节点上的pod打标的结果可以为：pod1以及pod2对应属性标签V11,pod3对应属性标签V12, pod4对应属性标签V13。

当需要对第二边缘节点的访问请求进行流量控制时，可在第二边缘节点的流量策略中配置Service1、Service2、Service3以及Service4与用户域名的对应关系。控制面组件102可基于该对应关系，对第二边缘节点中的pod1、pod2、pod3以及pod4进行动态打标，并将打标结果与用户域名的对应关系下发至数据面组件，以使得数据面组件对第二边缘节点上针对服务A的访问请求进行流量控制。例如，如图2所示，对第二边缘节点上的pod打标的结果可以为：pod1、pod2 以及pod3对应属性标签V21,pod4对应属性标签V22。

在这种实施方式中，流量路由规则与边缘节点具有对应关系，边缘节点接收到针对服务的访问请求后，可根据自身对应的流量路由规则将访问请求路由至对应的容器，不再赘述。

相对于现有的在部署服务实例时对容器进行固定打标的方案而言，基于本实施例提供的流量管控方法，可在边缘节点侧实现节点维度的流量控制，使得流量控制的粒度更小、更精细，满足不同边缘节点的不同流量控制要求。除此之外，基于动态配置的流量策略，可缩短流量路由配置生效的整体链路，降低响应时延。

值得说明的是，控制面组件102根据解析到的属性标签与用户域名的对应关系，确定流量路由规则之后，可确定待写入的存储系统，并为该存储系统添加分布式锁。其中，该存储系统可以为图1所示的存储系统Redis（一种数据结构服务器）或者也可实现为其他的存储系统，本实施例不做限制。添加分布式锁后，控制面组件102可将该流量路由规则写入该存储系统，以保存流量规划结果，供边缘节点读取。在结束写操作后，控制面组件102可释放该分布式锁。基于这种实施方式，可避免其他边缘节点对该存储系统中的流量路由规则进行修改，从而破坏流量路由规则的一致性。

除前述实施例之外，边缘流量控制系统100中，中心节点10通过服务网格中的控制面组件102获取动态配置的流量策略后，可将该流量策略发送至边缘节点20。即，控制面组件102不执行流量策略的解析操作。在这种实施方式中，边缘侧的每个边缘节点20上可部署有用于解析流量策略的调度插件。边缘节点20，通过服务网格中的数据面组件201接收中心节点10发送的流量策略后，可对该流量策略进行解析，得到多个服务实例与用户域名的对应关系。根据该多个服务实例与用户域名的对应关系以及访问请求对应的用户域名，边缘节点20可将针对多个服务实例的访问请求路由至对应容器。

图3是本申请一示例性实施例提供的基于服务网格的边缘流量控制方法的流程示意图，该方法在中心节点侧执行时，可包括如图3所示的步骤：

步骤301、通过服务网格中的控制面组件获取目标服务的服务实例与用户域名的对应关系。

步骤302、为所述服务实例在边缘节点上对应的容器添加属性标签，并确定所添加的属性标签与用户域名的对应关系。

步骤303、根据所述属性标签与用户域名的对应关系，确定流量路由规则。

步骤304、将所述流量路由规则发送至所述边缘节点，以使所述边缘节点根据所述流量路由规则以及访问请求对应的用户域名，将针对所述目标服务的访问请求路由至对应容器。

进一步可选地，通过服务网格中的控制面组件，获取目标服务的服务实例与用户域名的对应关系的一种方式，包括：通过所述控制面组件，获取动态配置的流量策略；对所述流量策略进行解析，得到所述目标服务的服务实例与用户域名的对应关系。

进一步可选地，通过服务网格中的控制面组件获取动态配置的流量策略的一种方式，包括：通过所述控制面组件监听所述中心节点中的容器管理平台的指定接口；若监听到所述容器管理平台的资源更新事件，则向所述容器管理平台发送资源获取请求；接收所述容器管理平台根据所述资源获取请求返回的所述流量策略。

进一步可选地，还包括：解析所述流量策略携带的边缘节点标识；从边缘侧的节点中确定与所述边缘节点标识对应的节点，作为所述边缘节点；所述边缘节点位于所述流量路由规则的生效范围内。

进一步可选地，根据所述属性标签与用户域名的对应关系，确定流量路由规则之后，还包括：确定待写入的存储系统；为所述存储系统添加分布式锁；将所述流量路由规则写入所述存储系统，并释放所述分布式锁。

在本实施例中，中心节点可通过服务网格中的控制面组件获取动态配置的流量策略，并通过控制面组件对流量策略进行解析，得到目标服务的服务实例与用户域名的对应关系。基于该服务实例与用户域名的对应关系，可为服务实例在边缘节点上对应的容器添加属性标签，并所添加的属性标签与用户域名的对应关系，确定流量路由规则。该流量路由规则可下发至边缘节点，以供边缘节点对针对目标服务的访问请求进行流量控制。在这种实施方式中，流量策略可以动态配置，有利于灵活地根据实际需求进行流量控制。同时，这种方式无需在部署服务实例时对容器进行打标，降低了对容器发布系统的配合度要求。除此之外，在这种实施方式中，对容器进行动态打标的过程由服务网格的控制面组件执行，因而无需对容器管理平台进行修改，可有效降低对容器管理平台的入侵性。

图4是本申请另一示例性实施例提供的基于服务网格的边缘流量控制方法的流程示意图，该方法在边缘节点侧执行时，可包括如图4所示的步骤：

步骤401、通过服务网格中的数据面组件接收中心节点发送的流量路由规则；所述流量路由规则由所述服务网格中的控制面组件根据获取到的目标服务的服务实例与用户域名的对应关系生成；所述流量路由规则包括：用户域名与边缘节点上运行有服务实例的容器的属性标签的对应关系。

步骤402、接收针对所述服务实例对应的目标服务的访问请求并确定所述访问请求对应的用户域名。

步骤403、根据所述流量路由规则，从所述边缘节点上的容器中，确定属性标签与所述用户域名对应的目标容器。

步骤404、将所述访问请求路由至所述目标容器，以访问所述目标容器中运行的服务实例。

进一步可选地，所述目标服务的服务实例与用户域名的对应关系由所述控制面组件从动态配置的流量策略中获取；所述流量策略携带所述边缘节点的标识，以使所述边缘节点位于所述流量路由规则的生效范围内。

在本实施例中，中心节点可通过服务网格中的控制面组件获取动态配置的流量策略，并通过控制面组件对流量策略进行解析，得到目标服务的服务实例与用户域名的对应关系。基于该服务实例与用户域名的对应关系，可为服务实例在边缘节点上对应的容器添加属性标签，并所添加的属性标签与用户域名的对应关系，确定流量路由规则。该流量路由规则可下发至边缘节点，以供边缘节点对针对目标服务的访问请求进行流量控制。在这种实施方式中，流量策略可以动态配置，有利于灵活地根据实际需求进行流量控制。同时，这种方式无需在部署服务实例时对容器进行打标，降低了对容器发布系统的配合度要求。除此之外，在这种实施方式中，对容器进行动态打标的过程由服务网格的控制面组件执行，因而无需对容器管理平台进行修改，可有效降低对容器管理平台的入侵性。

在一些可选的实例中，服务网格中位于中心节点的控制面组件在获取到流量策略后，可将流量策略直接下发至位于边缘节点的数据面组件，以使得数据面组件对流量策略进行解析，并根据解析结果对边缘节点上的访问请求进行流量控制。以下将进行示例性说明。

图5为本申请又一示例性实施例提供的基于服务网格的边缘流量控制方法，该方法在中心节点侧执行时，可包括如下的步骤：

步骤501、通过服务网格中的控制面组件获取动态配置的流量策略。

步骤502、将所述流量策略发送至边缘节点，以使所述边缘节点从所述流量策略中解析到服务实例与用户域名的对应关系，并根据所述服务实例与用户域名的对应关系以及访问请求对应的用户域名，将针对所述服务实例对应的目标服务的访问请求路由至对应容器。

在本实施例中，中心节点可通过服务网格中的控制面组件获取动态配置的流量策略，该流量策略可被下发到边缘节点，边缘节点可通过数据面组件对流量策略进行解析，得到目标服务的服务实例与用户域名的对应关系。基于该服务实例与用户域名的对应关系，可对边缘节点上的来自不同用户域名的访问请求进行流量控制。在这种实施方式中，流量策略可以动态配置，有利于灵活地根据实际需求进行流量控制。同时，这种方式无需在部署服务实例时对容器进行打标，降低了对容器发布系统的配合度要求。除此之外，在这种实施方式中，无需对容器管理平台进行修改，可有效降低对容器管理平台的入侵性。

图6为本申请又一示例性实施例提供的基于服务网格的边缘流量控制方法，该方法在边缘节点侧执行时，可包括如下的步骤：

步骤601、通过服务网格中的数据面组件接收中心节点发送的流量策略。

步骤602、对所述流量策略进行解析，得到多个服务实例与用户域名的对应关系。

步骤603、根据所述多个服务实例与用户域名的对应关系以及访问请求对应的用户域名，将针对所述多个服务实例对应的目标服务的访问请求路由至对应容器。

在本实施例中，中心节点可通过服务网格中的控制面组件获取动态配置的流量策略，该流量策略可被下发到边缘节点，边缘节点可通过数据面组件对流量策略进行解析，得到目标服务的服务实例与用户域名的对应关系。基于该服务实例与用户域名的对应关系，可对边缘节点上的来自不同用户域名的访问请求进行流量控制。在这种实施方式中，流量策略可以动态配置，有利于灵活地根据实际需求进行流量控制。同时，这种方式无需在部署服务实例时对容器进行打标，降低了对容器发布系统的配合度要求。除此之外，在这种实施方式中，无需对容器管理平台进行修改，可有效降低对容器管理平台的入侵性。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤301至步骤304的执行主体可以为设备A；又比如，步骤301和302的执行主体可以为设备A，步骤303的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如301、302等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。

需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图7示意了本申请一示例性实施例提供的服务器的结构示意图，该服务器适用于前述实施例提供的基于服务网格的边缘流量控制系统。如图7所示，该服务器包括：存储器701、处理器702以及通信组件703。

存储器701，用于存储计算机程序，并可被配置为存储其它各种数据以支持在服务器上的操作。这些数据的示例包括用于在服务器上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

其中，存储器701可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

处理器702，与存储器701耦合，用于执行存储器701中的计算机程序，以用于执行设定的流量控制方法。服务器的部署形态不同时，可执行不同的流量控制逻辑，以下将结合不不同的部署形态进行示例性说明。

其中，图7示意的服务器可部署为边缘计算系统的中心节点。

在一些实施例中，当被部署为中心节点时，处理器702用于：通过服务网格中的控制面组件获取目标服务的服务实例与用户域名的对应关系；为所述服务实例在边缘节点上对应的容器添加属性标签，并确定所添加的属性标签与用户域名的对应关系；根据所述属性标签与用户域名的对应关系，确定流量路由规则；将所述流量路由规则发送至所述边缘节点，以使所述边缘节点根据所述流量路由规则以及访问请求对应的用户域名，将针对所述目标服务的访问请求路由至对应容器。

进一步可选地，处理器702在通过服务网格中的控制面组件，获取目标服务的服务实例与用户域名的对应关系时，具体用于：通过所述控制面组件，获取动态配置的流量策略；对所述流量策略进行解析，得到所述目标服务的服务实例与用户域名的对应关系。

进一步可选地，处理器702在通过服务网格中的控制面组件获取动态配置的流量策略时，具体用于：通过所述控制面组件监听所述中心节点中的容器管理平台的指定接口；若监听到所述容器管理平台的资源更新事件，则向所述容器管理平台发送资源获取请求；接收所述容器管理平台根据所述资源获取请求返回的所述流量策略。

进一步可选地，处理器702还用于：解析所述流量策略携带的边缘节点标识；从边缘侧的节点中确定与所述边缘节点标识对应的节点，作为所述边缘节点；所述边缘节点位于所述流量路由规则的生效范围内。

进一步可选地，处理器702在根据所述属性标签与用户域名的对应关系，确定流量路由规则之后，还用于：确定待写入的存储系统；为所述存储系统添加分布式锁；将所述流量路由规则写入所述存储系统，并释放所述分布式锁。

在上述实施方式中，中心节点可通过服务网格中的控制面组件获取动态配置的流量策略，并通过控制面组件对流量策略进行解析，得到目标服务的服务实例与用户域名的对应关系。基于该服务实例与用户域名的对应关系，可为服务实例在边缘节点上对应的容器添加属性标签，并所添加的属性标签与用户域名的对应关系，确定流量路由规则。该流量路由规则可下发至边缘节点，以供边缘节点对针对目标服务的访问请求进行流量控制。

在另一些实施例中，当被部署为中心节点时，处理器702用于：通过服务网格中的控制面组件获取动态配置的流量策略；将所述流量策略发送至边缘节点，以使所述边缘节点从所述流量策略中解析到服务实例与用户域名的对应关系，并根据所述服务实例与用户域名的对应关系以及访问请求对应的用户域名，将针对所述服务实例对应的目标服务的访问请求路由至对应容器。

在这种实施方式中，中心节点可通过服务网格中的控制面组件获取动态配置的流量策略，该流量策略可被下发到边缘节点，边缘节点可通过数据面组件对流量策略进行解析，得到目标服务的服务实例与用户域名的对应关系。基于该服务实例与用户域名的对应关系，可对边缘节点上的来自不同用户域名的访问请求进行流量控制。

其中，图7示意的服务器可部署为边缘计算系统的边缘节点。

在一些实施例中，当被部署为边缘节点时，处理器702用于：通过服务网格中的数据面组件接收中心节点发送的流量路由规则；所述流量路由规则由所述服务网格中的控制面组件根据获取到的目标服务的服务实例与用户域名的对应关系生成；所述流量路由规则包括：用户域名与边缘节点上运行有服务实例的容器的属性标签的对应关系；接收针对所述服务实例对应的目标服务的访问请求并确定所述访问请求对应的用户域名；根据所述流量路由规则，从所述边缘节点上的容器中，确定属性标签与所述用户域名对应的目标容器；将所述访问请求路由至所述目标容器，以访问所述目标容器中运行的服务实例。

进一步可选地，所述目标服务的服务实例与用户域名的对应关系由所述控制面组件从动态配置的流量策略中获取；所述流量策略携带所述边缘节点的标识，以使所述边缘节点位于所述流量路由规则的生效范围内。

在这种实施方式中，中心节点根据动态配置的流量策略生成的流量路由规则可下发至边缘节点，边缘节点可动态实现流量控制。在这种实施方式中，流量策略可以动态配置，有利于灵活地根据实际需求进行流量控制。

在一些实施例中，当被部署为边缘节点时，处理器702用于：通过服务网格中的数据面组件接收中心节点发送的流量策略；对所述流量策略进行解析，得到多个服务实例与用户域名的对应关系；根据所述多个服务实例与用户域名的对应关系以及访问请求对应的用户域名，将针对所述多个服务实例对应的目标服务的访问请求路由至对应容器。

在本实施例中，中心节点可通过服务网格中的控制面组件获取动态配置的流量策略，该流量策略可被下发到边缘节点，边缘节点可通过数据面组件对流量策略进行解析，得到目标服务的服务实例与用户域名的对应关系。基于该服务实例与用户域名的对应关系，可对边缘节点上的来自不同用户域名的访问请求进行流量控制。

在上述各实施方式中，流量策略可以动态配置，有利于灵活地根据实际需求进行流量控制。同时，这种方式无需在部署服务实例时对容器进行打标，降低了对容器发布系统的配合度要求。除此之外，在这种实施方式中，无需对容器管理平台进行修改，可有效降低对容器管理平台的入侵性。

进一步，如图7所示，该服务器还包括：电源组件704等其它组件。图7中仅示意性给出部分组件，并不意味着服务器只包括图7所示组件。

其中，通信组件703被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G或5G，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件可基于近场通信（NFC）技术、射频识别（RFID）技术、红外数据协会（IrDA）技术、超宽带（UWB）技术、蓝牙（BT）技术和其他技术来实现。

其中，电源组件704，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由服务器执行的各步骤。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器 (CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM) 和/或非易失性内存等形式，如只读存储器 (ROM) 或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘 (DVD) 或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体 (transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (9)

1.一种基于服务网格的边缘流量控制方法，适用于中心节点，其特征在于，包括：

通过服务网格中的控制面组件，获取目标服务的服务实例与用户域名的对应关系；

为所述服务实例在边缘节点上对应的容器添加属性标签，并确定所添加的属性标签与用户域名的对应关系；

根据所述属性标签与用户域名的对应关系，确定流量路由规则；

将所述流量路由规则发送至所述边缘节点，以使所述边缘节点根据所述流量路由规则以及访问请求对应的用户域名，将针对所述目标服务的访问请求路由至对应容器。

2.根据权利要求1所述的方法，其特征在于，通过服务网格中的控制面组件，获取目标服务的服务实例与用户域名的对应关系，包括：

通过所述控制面组件，获取动态配置的流量策略；

对所述流量策略进行解析，得到所述目标服务的服务实例与用户域名的对应关系。

3.根据权利要求2所述的方法，其特征在于，通过所述控制面组件获取动态配置的流量策略，包括：

通过所述控制面组件监听所述中心节点中的容器管理平台的指定接口；

若监听到所述容器管理平台的资源更新事件，则向所述容器管理平台发送资源获取请求；

接收所述容器管理平台根据所述资源获取请求返回的所述流量策略。

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

解析所述流量策略携带的边缘节点标识；

从边缘侧的节点中确定与所述边缘节点标识对应的节点，作为所述边缘节点；所述边缘节点位于所述流量路由规则的生效范围内。

5.根据权利要求1-4任一项所述的方法，其特征在于，根据所述属性标签与用户域名的对应关系，确定流量路由规则之后，还包括：

确定待写入的存储系统；

为所述存储系统添加分布式锁；

将所述流量路由规则写入所述存储系统，并释放所述分布式锁。

6.一种基于服务网格的边缘流量控制方法，适用于边缘节点，其特征在于，包括：

通过服务网格中的数据面组件接收中心节点发送的流量路由规则；所述流量路由规则由所述服务网格中的控制面组件根据获取到的目标服务的服务实例与用户域名的对应关系生成；所述流量路由规则包括：用户域名与边缘节点上运行有服务实例的容器的属性标签的对应关系；

接收针对所述服务实例对应的目标服务的访问请求，并确定所述访问请求对应的用户域名；

根据所述流量路由规则，从所述边缘节点上的容器中，确定属性标签与所述用户域名对应的目标容器；

将所述访问请求路由至所述目标容器，以访问所述目标容器中运行的服务实例。

7.根据权利要求6所述的方法，其特征在于，所述目标服务的服务实例与用户域名的对应关系由所述控制面组件从动态配置的流量策略中获取；所述流量策略携带所述边缘节点的标识，以使所述边缘节点位于所述流量路由规则的生效范围内。

8.一种服务器，其特征在于，包括：存储器和处理器；

所述存储器用于存储一条或多条计算机指令；

所述处理器用于执行所述一条或多条计算机指令以用于：执行权利要求1-7任一项所述的方法中的步骤。

9.一种存储有计算机程序的计算机可读存储介质，其特征在于，计算机程序被处理器执行时能够实现权利要求1-7任一项所述的方法中的步骤。

Images