CN117768542A - 一种服务网格***以及基于服务网格***的信息传输方法 - Google Patents

Abstract

本申请公开了一种服务网格***以及信息传输方法，可令代表用户需求的服务请求被及时且顺利地处理，从而提高用户体验。本申请的***包括：第一代理，用于接收客户端发送的服务请求，若确定自身不适合完成针对服务请求的流量治理，则从N个代理中确定第二代理，并向第二代理发送服务请求，第一代理与客户端位于第一网格节点，第二代理位于第二网格节点；第二代理，用于对服务请求进行流量治理，得到第一治理结果，并基于第一治理结果向第三代理发送服务请求；第三代理，用于若确定自身适合完成针对服务请求的流量治理，则对服务请求进行流量治理，得到第二治理结果，并基于第二治理结果向服务端发送服务请求，第三代理与服务端位于第三网格节点。

Description

一种服务网格***以及基于服务网格***的信息传输方法

技术领域

本申请实施例涉及云技术领域，尤其涉及一种服务网格***以及基于服务网格***的信息传输方法。

背景技术

服务网格(service mesh，SM)***可由多个相互连接的网格节点构成，网格节点通常部署有微服务以及与微服务绑定的边车(sidecar)代理，微服务的所有流量均由代理接管，从而实现灵活、精细的微服务流量管理。

目前的服务网格***中，若第一网格节点中的第一微服务需要调用第二网格节点中的第二微服务，且第一网格节点还包含第一代理，第二网格节点还包括第二代理，则第一微服务和第二微服务的通信流程为：第一微服务向第一代理发送服务请求，第一代理对服务请求进行解码、流量治理以及编码等等后，可向第二代理发送服务请求，第二代理再向第二微服务发送服务请求，以使得第二微服务对服务请求进行处理，得到服务响应。

然而，第一代理在转发服务请求时，需要进行解码、流量治理以及编码等一系列操作，这些操作需耗费大量的中央处理器(central processing unit，CPU)资源，若此时CPU资源不够使用，所需转发的服务请求往往会被第一代理暂缓处理或拒绝处理，而服务请求往往代表着用户的需求，这样会导致用户体验不佳。

发明内容

本申请实施例提供了一种服务网格***以及基于服务网格***的信息传输方法，可以令代表用户需求的服务请求被及时且顺利地处理，从而提高用户体验。

本申请实施例的第一方面提供了一种服务网格***，该***包括：第一网格节点、第二网格节点、第三网格节点以及代理管理中心，第一网格节点包括第一代理以及客户端，第二网格节点包含第二代理，第三网格节点包括第三代理以及服务端。

当存在用户所要求处理的待处理数据时，客户端可生成包含待处理数据的服务请求，并将服务请求发送至第一代理。接收客户端发送的服务请求后，第一代理可检测自身是否适合完成针对服务请求的流量治理。

若确定自身不适合完成针对服务请求的流量治理，第一代理则向代理管理中心发送第一查询请求，代理管理中心可基于第一查询请求向第一代理提供N个辅助代理(这N个辅助代理已在代理管理中心处完成注册)。那么，第一代理可在这N个辅助代理中，选择一个辅助代理作为第二代理，并将服务请求发送至第二代理，N为大于或等于1的正整数。

接收到服务请求后，第二代理可对服务请求进行流量治理，得到第一治理结果。然后，第二代理可基于第一治理结果，向第三代理发送服务请求。接收到第二代理发送的服务请求后，第三代理可检测自身是否适合完成针对服务请求的流量治理。

若确定自身适合完成针对服务请求的流量治理，第三代理则对服务请求进行流量治理，得到第二治理结果，并基于第二治理结果向服务端发送服务请求，以使得服务端对服务请求进行处理。

从上述***可以看出：在接收到客户端发送的服务请求后，第一代理若确定自身不适合完成针对服务请求的流量治理后，可从代理管理中心提供的多个代理中选择第二代理，由第二代理来替代完成针对服务请求的流量治理，并及时将服务请求发送至第三代理，进而使得第三代理及时将服务请求发送至服务端。由此可见，即使第一代理所在的第一节点的CPU资源紧张，第一代理对来自客户端的服务请求所需执行的操作可以拉远到第二代理来执行，以使得服务请求及时达到第三代理以及服务端，从而在服务端处完成处理，也就是说，用户的需求可被及时且顺利满足，故可有效提高用户体验。

在一种可能实现的方式中，第一代理，用于若确定满足预置条件，则确定自身不适合完成针对服务请求的流量治理，预置条件包含以下至少一项：服务请求的接收时刻与当前时刻之间的差值大于第一阈值，第一节点的CPU使用率大于第二阈值，以及客户端发送的先前服务请求的处理时长大于第三阈值。前述实现方式中，第一代理判断是否满足预置条件，若满足预置条件，说明第一节点的CPU已超负荷，第一代理则确定自身不适合完成针对服务请求的流量治理，若不满足预置条件，说明第一节点的CPU未超负荷，第一代理则确定自身适合完成针对服务请求的流量治理。其中，预置条件包含以下至少一项：客户端发送的服务请求的接收时刻与当前时刻之间的差值大于第一阈值；第一节点在当前时刻的CPU使用率大于第二阈值；客户端之前发送的服务请求的处理时长大于第三阈值。由此可见，第一代理若确定满足以上所有预置条件中的至少一项，则可确定自身不适合完成针对服务请求的流量治理，第一代理若确定不满足以上所有预置条件，则可确定自身适合完成针对服务请求的流量治理。

在一种可能实现的方式中，第一代理，用于从代理管理中心提供的N个代理中，将可用资源最大的代理确定为第二代理，可用资源包含以下至少一项：可用计算资源、可用存储资源以及可用通信资源。前述实现方式中，代理管理中心接收到第一代理发送的第一查询请求后，可向第一代理提供N个辅助代理的地址以及N个辅助代理的可用资源的大小，故第一代理可将可用资源最大的代理确定为第二代理，并与基于第二代理的地址与第二代理构建通信连接。

在一种可能实现的方式中，第一代理，还用于将自身完成流量治理所需要的配置信息，发送至第二代理；第二代理，用于基于配置信息对服务请求进行流量治理，得到第一治理结果，并基于第一治理结果向第三代理发送服务请求。前述实现方式中，第一代理与第二代理在通信连接的过程中，第一代理可将自身完成解码、流量治理以及编码所需要的配置信息，下发给第二代理，以使得第二代理存储这些配置信息。那么，第二代理接收第一代理发送的服务请求后，可基于这些配置信息来对服务请求进行流量治理，从而得到第一治理结果。

在一种可能实现的方式中，第一代理，还用于若确定自身适合完成针对服务请求的流量治理，则对服务请求进行流量治理，得到第一治理结果。第一代理，还用于基于第一治理结果向第三代理发送服务请求。前述实现方式中，若确定自身适合完成针对服务请求的流量治理，第一代理则对服务请求进行流量治理，得到第一治理结果，并基于第一治理结果向第三代理发送服务请求。

在一种可能实现的方式中，第三代理，还用于若确定自身不适合完成针对服务请求的流量治理，在代理管理中心提供的M个代理中确定***理，并将向***理发送服务请求，***理位于第四网格节点，M≥1；***理，用于对服务请求进行流量治理，得到第二治理结果，并基于第二治理结果向服务端发送服务请求。前述实现方式中，若确定自身不适合完成针对服务请求的流量治理，第三代理则向代理管理中心发送第二查询请求，代理管理中心可基于第二查询请求向第三代理提供M个辅助代理(这M个辅助代理已在代理管理中心处完成注册)。那么，第三代理可在这M个辅助代理中，选择一个辅助代理作为***理，并将服务请求发送至第四网格节点中的***理，M为大于或等于1的正整数。接收到服务请求后，***理可对服务请求进行流量治理，得到第二治理结果。然后，***理可基于第二治理结果，向服务端发送服务请求，以使得服务端对服务请求进行处理。

在一种可能实现的方式中，服务端，用于对服务请求进行处理，得到服务响应，并向第三代理发送服务响应；第三代理，还用于对服务响应进行流量治理，得到第三治理结果，并基于第三治理结果向第二代理发送服务响应；第二代理，还用于对服务响应进行流量治理，得到第四治理结果，并基于第四治理结果向第一代理发送服务响应；第一代理，还用于向客户端发送服务响应。前述实现方式中，接收到服务请求后，服务端可对服务请求中的待处理数据进行处理，从而得到包含处理后的数据的服务响应，并向第三代理发送服务响应。接收到服务响应后，第三代理对服务响应进行流量治理，得到第三治理结果，并基于第三治理结果向第二代理发送服务响应。接收到服务响应后，第二代理对服务响应进行流量治理，得到第四治理结果，并基于第四治理结果向第一代理发送服务响应。接收到服务响应后，第一代理向客户端发送服务响应，以使得客户端将服务响应中的处理后的数据提供给用户使用，从而满足用户的需求。

本申请实施例的第二方面提供了一种基于服务网格***的信息传输方法，该***包含第一网格节点，第二网格节点，第三网格节点以及代理管理中心，第一网格节点包含第一代理以及客户端，第二网格节点包含第二代理，第三网格节点包含第三代理以及服务端，该方法包括：第一代理接收客户端发送的服务请求，若确定自身不适合完成针对服务请求的流量治理，则从代理管理中心提供的N个代理中确定第二代理，并向第二代理发送服务请求，N个代理已在代理管理中心注册，N≥1；第二代理对服务请求进行流量治理，得到第一治理结果，并基于第一治理结果向第三代理发送服务请求；第三代理若确定自身适合完成针对服务请求的流量治理，则对服务请求进行流量治理，得到第二治理结果，并基于第二治理结果向服务端发送服务请求。

从上述方法可以看出：在接收到客户端发送的服务请求后，第一代理若确定自身不适合完成针对服务请求的流量治理后，可从代理管理中心提供的多个代理中选择第二代理，由第二代理来替代完成针对服务请求的流量治理，并及时将服务请求发送至第三代理，进而使得第三代理及时将服务请求发送至服务端。由此可见，即使第一代理所在的第一节点的CPU资源紧张，第一代理对来自客户端的服务请求所需执行的操作可以拉远到第二代理来执行，以使得服务请求及时达到第三代理以及服务端，从而在服务端处完成处理，也就是说，用户的需求可被及时且顺利满足，故可有效提高用户体验。

在一种可能实现的方式中，第一代理若确定自身不适合完成针对服务请求的流量治理包括：第一代理若确定满足预置条件，则确定自身不适合完成针对服务请求的流量治理，预置条件包含以下至少一项：服务请求的接收时刻与当前时刻之间的差值大于第一阈值，第一节点的CPU使用率大于第二阈值，以及客户端发送的先前服务请求的处理时长大于第三阈值。

在一种可能实现的方式中，第一代理从代理管理中心提供的N个代理中确定第二代理包括：第一代理从代理管理中心提供的N个代理中，将可用资源最大的代理确定为第二代理，可用资源包含以下至少一项：可用计算资源、可用存储资源以及可用通信资源。

在一种可能实现的方式中，该方法还包括：第一代理将自身完成流量治理所需要的配置信息，发送至第二代理；则第二代理对服务请求进行流量治理，得到第一治理结果包括：第二代理基于配置信息对服务请求进行流量治理，得到第一治理结果，并基于第一治理结果向第三代理发送服务请求。

在一种可能实现的方式中，该方法还包括：第一代理若确定自身适合完成针对服务请求的流量治理，则对服务请求进行流量治理，得到第一治理结果。

在一种可能实现的方式中，该***还包括第四网格节点，第四网格节点包含***理，该方法还包括：第三代理若确定自身不适合完成针对服务请求的流量治理，在代理管理中心提供的M个代理中确定***理，并将向***理发送服务请求，M≥1；***理对服务请求进行流量治理，得到第二治理结果，并基于第二治理结果向服务端发送服务请求。

在一种可能实现的方式中，该方法还包括：服务端对服务请求进行处理，得到服务响应，并向第三代理发送服务响应；第三代理对服务响应进行流量治理，得到第三治理结果，并基于第三治理结果向第二代理发送服务响应；第二代理对服务响应进行流量治理，得到第四治理结果，并基于第四治理结果向第一代理发送服务响应；第一代理向客户端发送服务响应。

本申请实施例的第三方面提供提供了一种边车代理，该边车代理作为第一代理，第一代理包括：接收模块，用于接收客户端发送的服务请求；处理模块，用于若确定自身不适合完成针对服务请求的流量治理，则从代理管理中心提供的N个代理中确定第二代理；发送模块，用于向第二代理发送服务请求，第一代理与客户端位于第一网格节点，第二代理位于第二网格节点，N个代理已在代理管理中心注册，N≥1。

在一种可能实现的方式中，处理模块，用于若确定满足预置条件，则确定自身不适合完成针对服务请求的流量治理，预置条件包含以下至少一项：服务请求的接收时刻与当前时刻之间的差值大于第一阈值，第一节点的CPU使用率大于第二阈值，以及客户端发送的先前服务请求的处理时长大于第三阈值。

在一种可能实现的方式中，处理模块，用于从代理管理中心提供的N个代理中，将可用资源最大的代理确定为第二代理，可用资源包含以下至少一项：可用计算资源、可用存储资源以及可用通信资源。

在一种可能实现的方式中，发送模块，还用于将自身完成流量治理所需要的配置信息，发送至第二代理。

在一种可能实现的方式中，处理模块，还用于若确定自身适合完成针对服务请求的流量治理，则对服务请求进行流量治理，得到第一治理结果。发送模块，还用于基于第一治理结果向第三代理发送服务请求。

本申请实施例的第四方面提供了一种边车代理，该边车代理作为第二网格节点中的第二代理，第二代理包括：接收模块，用于接收来自第一代理的服务请求，第一代理与客户端位于第一网格节点；处理模块，用于对服务请求进行流量治理，得到第一治理结果；发送模块，用于基于第一治理结果向第三代理发送服务请求，第三代理与服务端位于第三网格节点。

在一种可能实现的方式中，接收模块，还用于接收来自第一代理的自身完成流量治理所需要的配置信息；处理模块，用于基于配置信息对服务请求进行流量治理，得到第一治理结果。

本申请实施例的第五方面提供了一种边车代理，该边车代理作为第三代理，第三代理包括：接收模块，用于接收来自第二代理的服务请求，第二代理位于第二网格节点；处理模块，用于若确定自身适合完成针对服务请求的流量治理，则对服务请求进行流量治理，得到第二治理结果；发送模块，用于基于第二治理结果向服务端发送服务请求，第三代理与服务端位于第三网格节点。

在一种可能实现的方式中，处理模块，还用于若确定自身不适合完成针对服务请求的流量治理，在代理管理中心提供的M个代理中确定***理，并将向***理发送服务请求，以使得***理对服务请求进行流量治理，得到第二治理结果，并基于第二治理结果向服务端发送服务请求，***理位于第四网格节点，M≥1。

本申请实施例的第六方面提供了一种代理管理中心，代理管理中心包括：注册模块，用于供多个代理完成注册；第一提供模块，用于向第一网格节点的第一代理提供N个代理，N≥1。

在一种可能实现的方式中，代理管理中心还包括，第二提供模块，用于向第四网格节点的***理提供M个代理，M≥1。

本申请实施例的第七方面提供了一种网格节点，网格节点包括存储器和处理器；所述存储器存储有代码，处理器被配置为执行代码，当代码被执行时，网格节点执行如第二方面或第二方面中任意一种可能实现的方式所述的方法中所述第一网格节点、所述第二网格节点、所述第三网格节点或所述第四网格节点实现的步骤。

本申请实施例的第八方面提供了一种代理管理中心，代理管理中心包括存储器和处理器；存储器存储有代码，处理器被配置为执行代码，当代码被执行时，代理管理中心执行如第二方面或第二方面中任意一种可能实现的方式所述的方法中代理管理中心实现的步骤。

本申请实施例的第九方面提供了一种计算机存储介质，计算机存储介质存储有一个或多个指令，指令在由一个或多个计算机执行时使得一个或多个计算机实施权利如第二方面或第二方面中任意一种可能实现的方式所述的方法。

本申请实施例的第十方面提供了一种计算机程序产品，计算机程序产品存储有指令，指令在由计算机执行时，使得计算机实施如第二方面或第二方面中任意一种可能实现的方式所述的方法。

本申请实施例中，在接收到客户端发送的服务请求后，第一代理若确定自身不适合完成针对服务请求的解码、流量治理以及编码后，可从代理管理中心提供的多个代理中选择第二代理，由第二代理来替代完成针对服务请求的解码、流量治理以及编码，并及时将服务请求发送至第三代理，进而使得第三代理及时将服务请求发送至服务端。由此可见，即使第一代理所在的第一节点的CPU资源紧张，第一代理对来自客户端的服务请求所需执行的操作可以拉远到第二代理来执行，以使得服务请求及时达到第三代理以及服务端，从而在服务端处完成处理，也就是说，用户的需求可被及时且顺利满足，故可有效提高用户体验。

附图说明

图1为本申请实施例提供的服务网格***的一个结构示意图；

图2为本申请实施例提供的基于服务网格***的信息传输方法的一个流程示意图；

图3为本申请实施例提供的基于服务网格***的信息传输方法的一个应用例示意图；

图4为本申请实施例提供的基于服务网格***的信息传输方法的另一流程示意图；

图5为本申请实施例提供的基于服务网格***的信息传输方法的另一应用例示意图；

图6为本申请实施例提供的边车代理的一个结构示意图；

图7为本申请实施例提供的边车代理的另一结构示意图；

图8为本申请实施例提供的边车代理的另一结构示意图；

图9为本申请实施例提供的代理管理中心的一个结构示意图；

图10为本申请实施例提供的边车代理的另一结构示意图；

图11为本申请实施例提供的代理管理中心的另一结构示意图。

具体实施方式

本申请实施例提供了一种服务网格***以及基于服务网格***的信息传输方法，可以令代表用户需求的服务请求被及时且顺利地处理，从而提高用户体验。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、***、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

服务网格***可由多个相互连接的网格节点(也可以称为服务网格节点)构成，网格节点通常部署有微服务以及与微服务绑定的边车代理(下文将简称为代理)，微服务的所有流量均由代理接管，从而实现灵活、精细的微服务流量管理。

目前的服务网格***中，若第一网格节点中的第一微服务需要调用第二网格节点中的第二微服务，且第一网格节点还包含第一代理，第二网格节点还包括第二代理，则第一微服务和第二微服务的通信流程为：第一微服务向第一代理发送服务请求，第一代理对服务请求进行解码、流量治理以及编码等等后，可向第二代理发送服务请求，第二代理再向第二微服务发送服务请求，以使得第二微服务对服务请求进行处理，得到服务响应。

然而，第一代理在转发服务请求时，需要进行解码、流量治理以及编码等一系列操作，这些操作需耗费大量的CPU资源，若此时CPU资源不够使用，所需转发的服务请求往往会被第一代理暂缓处理或拒绝处理，而服务请求往往代表着用户的需求，用户的需求无法及时或顺利地被满足，这样会导致用户体验不佳。

为了解决上述问题，本申请实施例提供了一种新的服务网格***。图1为本申请实施例提供的服务网格***的一个结构示意图，如图1所示，该***包含多个网格节点以及代理管理中心。为了便于介绍，下文将这多个网格节点包含三类网格节点进行示意性介绍。

第一类网格节点也可以理解为客户端网格节点，客户端网格节点均部署有用于实现某种微服务(也可以称为源微服务)的客户端(例如，可以发送待处理数据的软件，待处理数据可以待处理的文字、待处理的图片、待处理的视频、待处理的音频等等各类数据)以及与客户端绑定的客户端代理，客户端代理可管控客户端发出的包含待处理数据的服务请求以及发送向客户端的包含处理后的数据的服务响应，例如，由自身来对服务请求和服务响应进行一系列操作(例如，解码、流量治理以及编码等等，此处先不做展开)，又如，将服务请求和服务响应拉远至辅助代理处，由辅助代理来代替完成这一系列操作。

第二类网格节点也可以理解为服务端网格节点，服务端网格节点均部署有用于实现另一种微服务(也可以称为目标微服务)的服务端(例如，可以接收待处理数据，并对待处理数据进行处理从而得到处理后的数据的软件，处理后的数据可以处理后的文字、处理后的图片、处理后的视频、处理后的音频等等各类数据)以及与服务端绑定的服务端代理，服务端代理可管控发送向服务端的包含待处理数据的服务请求以及服务端发出的包含处理后的数据的服务响应，例如，由自身来对服务请求和服务响应进行一系列操作(例如，解码、流量治理以及编码等等，此处先不做展开)，又如，将服务请求和服务响应拉远至辅助代理处，由辅助代理来代替完成这一系列操作。

第三类网格节点也可以理解为辅助网格节点，辅助网格节点均部署有起到辅助功能的辅助代理，辅助代理可以在客户端代理或服务端代理的请求下，替代客户端代理或服务端代理执行客户端代理或服务端代理所需执行的操作。

代理管理中心可以为一个独立的物理节点，用于统筹管理所有的辅助网格节点。一般地，辅助网格节点启动时，辅助网格节点中的辅助代理可将自身的地址在代理管理中心处注册。那么，代理管理中心可获取已注册的辅助网格节点的可用资源大小以及地址，并将可供选择的所有辅助网格节点的地址提供给客户端代理或服务端代理进行选择，以实现操作转移。

需要说明的是，上述的客户端网格节点、服务端网格节点以及辅助网格节点均为物理节点，而客户端以及客户端代理可以为部署于客户端网格节点上的容器，服务端以及服务端代理可以为部署于服务端网格节点上的容器，辅助代理可以为部署于辅助网格节点上的容器。

为了进一步理解上述服务网格***的工作流程，下文对该工作流程做进一步的介绍。为了便于说明，下文将某个客户端网格节点称为第一网格节点，该客户端网格节点上的客户端代理称为第一代理，并将某个辅助网格节点称为第二网格节点，该辅助网格节点上的辅助代理称为第二代理，并将某个服务端网格节点称为第三网格节点，该服务端网格节点上的服务端代理称为第三代理，并将另一个辅助网格节点称为第四网格节点，该辅助网格节点上的辅助代理称为***理。图2为本申请实施例提供的基于服务网格***的信息传输方法的一个流程示意图，如图2所示，该方法包括：

201、客户端向第一代理发送服务请求，客户端和第一代理位于第一网格节点中。

本实施例中，当存在用户所要求处理的待处理数据时，第一网格节点的客户端可生成包含待处理数据的服务请求。此外，待处理数据往往需要调用某种微服务(后续称为目标微服务)来处理，那么，客户端还可获取目标微服务的标识。

需要说明的是，客户端得到服务请求以及目标微服务的标识等等这些信息后，这些信息在客户端本地是以非字节流形式(即原始形式)存在的，但在客户端将这些信息发送至第一网格节点的第一代理的过程中，这些信息则是以字节流形式(即传输形式)进行传输的。

例如，如图3所示(图3为本申请实施例提供的基于服务网格***的信息传输方法的一个应用例示意图)，在网格节点1中，应用程序(application，APP)可将包含待处理数据的服务请求(buffer)以及目标微服务的标识(SVC)发送，以字节流形式传输至sidecar1。

202、第一代理检测自身是否适合完成针对服务请求的流量治理。

第一代理接收到服务请求以及目标微服务的标识等等这些信息后，会先检测自身是否适合完成针对这些信息的解码(例如，将这些信息从字节流形式转换为非字节流形式)、流量治理(例如，得到非字节流形式的服务请求后，对服务请求进行负载均衡、安全验证等操作)以及编码(例如，经过流量治理后，可将这些信息从非字节流形式转换为字节流形式)。

具体地，第一代理可通过以下方式来检测自身是否适合完成针对这些信息的解码、流量治理以及编码：

第一代理判断是否满足预置条件，若满足预置条件，说明第一节点的CPU已超负荷，第一代理则确定自身不适合完成针对这些信息的解码、流量治理以及编码，若不满足预置条件，说明第一节点的CPU未超负荷，第一代理则确定自身适合完成针对这些信息的解码、流量治理以及编码。其中，预置条件包含以下至少一项：

(1)客户端发送的服务请求的接收时刻与当前时刻之间的差值大于第一阈值(第一阈值的大小可根据实际需求进行设置，此处不做限制)。需要说明的是，第一代理接收到客户端发送的服务请求后，可立即记录服务请求的接收时刻。当检测自身是否适合完成针对这些信息的解码、流量治理以及编码时，第一代理可计算服务请求的接收时刻与当前时刻之间的差值，若该差值大于第一阈值，说明第一节点的CPU已超负荷，第一代理则确定自身不适合完成针对这些信息的解码、流量治理以及编码，若该差值小于或等于第一阈值，说明第一节点的CPU未超负荷，第一代理则确定自身适合完成针对这些信息的解码、流量治理以及编码。

(2)第一节点的CPU使用率大于第二阈值(第二阈值的大小可根据实际需求进行设置，此处不做限制)。需要说明的是，当检测自身是否适合完成针对这些信息的解码、流量治理以及编码时，第一代理还可获取第一节点在当前时刻的CPU使用率，若第一节点在当前时刻的CPU使用率大于第二阈值，说明第一节点的CPU已超负荷，第一代理则确定自身不适合完成针对这些信息的解码、流量治理以及编码，若第一节点在当前时刻的CPU使用率小于或等于第二阈值，说明第一节点的CPU未超负荷，第一代理则确定自身适合完成针对这些信息的解码、流量治理以及编码。

(3)客户端发送的先前服务请求的处理时长大于第三阈值(第三阈值的大小可根据实际需求进行设置，此处不做限制)。需要说明的是，当检测自身是否适合完成针对这些信息的解码、流量治理以及编码时，第一代理还可获取客户端之前向第一代理发送的服务请求的处理时长(客户端之前向第一代理发送的服务请求的处理时长指，这些服务请求从被第一代理接收到的时刻与这些服务请求对应的服务响应被第一代理接收到的时刻之间的差值)，若处理时长大于第三阈值，说明第一节点的CPU已超负荷，第一代理则确定自身不适合完成针对这些信息的解码、流量治理以及编码，若处理时长小于或等于第三阈值，说明第一节点的CPU未超负荷，第一代理则确定自身适合完成针对这些信息的解码、流量治理以及编码。

由此可见，第一代理若确定满足以上所有预置条件中的至少一项，则可确定自身不适合完成针对这些信息的解码、流量治理以及编码，第一代理若确定不满足以上所有预置条件，则可确定自身适合完成针对这些信息的解码、流量治理以及编码。

203、第一代理若确定自身不适合完成针对服务请求的流量治理，则从代理管理中心提供的N个代理中确定第二代理，并向第二代理发送服务请求，第二代理位于第二网格节点中，N个代理已在代理管理中心注册，N≥1。

第一代理若确定自身不适合完成针对这些信息的解码、流量治理以及编码后，则向代理管理中心发送第一查询请求，代理管理中心可基于第一查询请求向第一代理提供N个辅助代理(这N个辅助代理已在代理管理中心处完成注册，且N为大于或等于1的正整数)。接着，第一代理可在这N个辅助代理中，选择一个辅助代理作为第二代理，第二代理位于第二网格节点中。然后，第一代理可与第二代理建立通信连接，故第一代理可将客户端的地址、对外输出的标识、目标微服务的标识以及服务请求，以字节流形式发送至第二代理。

具体地，第一代理可通过以下方式来确定第二代理，并连接第二代理：

(1)代理管理中心接收到第一代理发送的第一查询请求后，可基于第一查询请求向第一代理发送N个辅助代理的地址以及这N个辅助代理的可用资源(例如，可用计算资源、可用存储资源以及可用通信资源等等)的大小。

(2)第一代理接收到N个辅助代理的地址以及这N个辅助代理的可用资源的大小后，在这N个辅助代理中，第一代理可将可用资源最大的代理确定为第二代理，并基于第一代理的地址以及第二代理的地址，与第二代理构建通信连接。值得注意的是，第一代理与第二代理在通信连接的过程中，第一代理可将自身完成解码、流量治理以及编码所需要的配置信息(即第一代理完成这些操作所需要的二进制插件等等)，下发给第二代理，以使得第二代理存储这些配置信息。

(3)与第二代理完成连接后，第一代理可将客户端的地址、对外输出的标识、目标微服务的标识以及服务请求，以字节流形式发送至第二代理。

依旧如上述例子，sidecar1确定网格节点1的CPU超负荷后，则从代理管理中心获取N个sidecar的QP地址以及这N个sidecar的可用资源信息，从而将可用资源最大的sidecar确定为sidecar2。接着，sidecar1基于sidecar1的QP地址(QP1)以及sidecar2的QP地址(QP2)，与sidecar2完成远程直接数据存取(remote direct memory access，RDMA)连接。在RDMA连接过程中，sidecar1可将其完成解码、流量治理、编码所需要的二进制插件下发到sidecar2。

完成RDMA连接后，sidecar1可将APP的IP地址(SIP)，对外输出的标识(outbound)，目标微服务的标识(SVC)以及服务请求(buffer)，以字节流形式发送至sidecar2。

204、第二代理对服务请求进行流量治理，得到第一治理结果，并基于第一治理结果向第三代理发送服务请求。

接收到客户端的地址、对外输出的标识、目标微服务的标识以及服务请求这些信息后，由于这些信息是以字节流形式被第二代理接收到的，故第二代理可先将这些信息从字节流形式转换为非字节流形式(即解码)。得到非字节流形式的这些信息后，第二代理可对这些信息进行安全验证，从而得到安全验证结果，且第二代理还可从用于实现目标微服务的多个服务端中选择一个可以充分处理服务请求的服务端，该服务端所在的服务端网格节点可视为第三网格节点，通过查询可得到第三网格节点的第三代理的地址以及第三网格节点的服务端的地址。若安全验证结表明这些信息是可用的后，由于对外输出的标识的存在，第二代理可基于第二代理的地址以及第三代理的地址，与第三代理建立通信连接，并将客户端的地址、服务端的地址以及服务请求，从非字节流形式转换为字节流形式(即编码)，从而发送到第三代理。

需要说明的是，上述的安全验证操作以及确定服务端的操作(即负载均衡操作)可视为第二代理所执行的流量治理，相应地，上述的安全验证结果、第三代理的地址、服务端的地址可视为第二代理所得到的第一治理结果。可以理解的是，在实际应用中，流量治理还可以包含更多操作，第一治理结果也可相应包含更多信息，此处不做展开。

还需要说明的是，第二代理可基于来自第一代理的配置信息，来完成前述的解码、流量治理以及编码等操作。

依旧如上述例子，sidecar2接收到为字节流形式的APP的IP地址(SIP)，对外输出的标识(outbound)，目标微服务的标识(SVC)以及服务请求(buffer)后，可对其进行解码，从而得到非字节流形式的APP的IP地址(SIP)，对外输出的标识(outbound)，目标微服务的标识(SVC)以及服务请求(buffer)。在通过这些信息的安全验证后，sidecar2基于目标微服务的标识(SVC)，sidecar2可确认用于实现目标微服务的某个backend(即服务端)，并查询得到该backend的IP地址(DIP)以及该backend所在网格节点3的sidecar3的IP地址(Node3)。接着，由于对外输出的标识(outbound)的存在，sidecar2可基于sidecar2的IP地址(Node2)与sidecar3的IP地址(Node3)，与sidecar3完成传输控制协议(transmissioncontrol protocol，TCP)连接。

完成TCP连接后，sidecar3可对APP的IP地址(SIP)、backend的IP地址(DIP)以及服务请求(buffer)进行编码，从而将这些信息以字节流形式发送至sidecar3。

205、第三代理检测自身是否适合完成针对服务请求的流量治理。

接收到客户端的地址、服务端的地址以及服务请求这些信息后，第三代理会先检测自身是否适合完成针对这些信息的解码、流量治理以及编码。

关于第三代理的检测过程的介绍，可参考步骤202中第一代理的检测过程的相关说明部分，此处不再赘述。

206、第三代理若确定自身适合完成针对服务请求的流量治理，则对服务请求进行流量治理，得到第二治理结果，并基于第二治理结果向服务端发送服务请求，第三代理和服务端位于第三网格节点中。

第三代理若确定自身适合完成针对这些信息的解码、流量治理以及编码后，由于这些信息是以字节流形式被第三代理接收到的，故第三代理可先将这些信息从字节流形式转换为非字节流形式(即解码)。得到非字节流形式的这些信息后，第二代理可对这些信息进行安全验证，从而得到安全验证结果。若安全验证结果表明这些信息是可用的，第三代理可将客户端的地址以及服务请求，从非字节流形式转换为字节流形式(即编码)，从而发送到服务端。

需要说明的是，上述的安全验证操作可视为第三代理所执行的流量治理，相应地，上述的安全验证结果可视为第三代理所得到的第二治理结果。可以理解的是，在实际应用中，流量治理还可以包含更多操作，第二治理结果也可相应包含更多信息，此处不做展开。

依旧如上述例子，sidecar3与backend为TPROXY模式的TCP连接。sidecar3接收到字节流形式的APP的IP地址(SIP)、backend的IP地址(DIP)以及服务请求(buffer)后，可对其进行解码，从而得到非字节流形式的APP的IP地址(SIP)、backend的IP地址(DIP)以及服务请求(buffer)。在通过这些信息的安全验证后，sidecar3可对APP的TPROXY模式的标签、IP地址(SIP)以及服务请求(buffer)进行编码，从而将这些信息以字节流形式发送至backend。

207、服务端对服务请求进行处理，得到服务响应，并向第三代理发送服务响应。

得到客户端的地址以及服务请求后，由于这些信息是以字节流形式被服务端接收到的，故服务端可先将这些信息从字节流形式转换为非字节流形式(即解码)。得到非字节流形式的这些信息后，服务端可先对这些信息进行解析，以确定客户端有需要处理的待处理数据，故服务端可对服务请求中的待处理数据进行处理，可得到包含处理后的数据的服务响应。那么，服务端可将服务响应从非字节流形式转换为字节流形式(即编码)，从而发送到第三代理。

依旧如上述例子，backend接收到字节流形式的TPROXY模式的标签、APP的IP地址(SIP)、以及服务请求(buffer)后，可对其进行解码，从而得到非字节流形式的APP的IP地址(SIP)以及服务请求(buffer)。接着，backend可对服务请求中的待处理数据进行处理，以得到包含处理后的数据的服务响应(response buffer)。值得注意的是，此时backend不以APP的IP地址(SIP)来回包(即不以APP为目的地来回包)，由于存在TPROXY模式的标签，backend则以sidecar3为目的地来回包，故backend可服务响应(response buffer)进行编码，从而将该信息以字节流形式发送至sidecar3。

208、第三代理对服务响应进行流量治理，得到第三治理结果，并基于第三治理结果向第二代理发送服务响应。

得到服务响应后，由于该信息是以字节流形式被第三代理接收到的，故第三代理可先将该信息从字节流形式转换为非字节流形式(即解码)。得到非字节流形式的该信息后，第三代理可先对该进行安全验证，从而得到安全验证结果。若安全验证结果表明这些信息是可用的，第三代理可将服务响应从非字节流形式转换为字节流形式(即编码)，从而发送到第二代理。

需要说明的是，上述的安全验证操作可视为第三代理所执行的流量治理，相应地，上述的安全验证结果可视为第三代理所得到的第三治理结果。可以理解的是，在实际应用中，流量治理还可以包含更多操作，第三治理结果也可相应包含更多信息，此处不做展开。

209、第二代理对服务响应进行流量治理，得到第四治理结果，并基于第四治理结果向第一代理发送服务响应。

得到服务响应后，由于该信息是以字节流形式被第二代理接收到的，故第二代理可先将该信息从字节流形式转换为非字节流形式(即解码)。得到非字节流形式的该信息后，第二代理可先对该进行安全验证，从而得到安全验证结果。若安全验证结果表明这些信息是可用的，第二代理可将服务响应从非字节流形式转换为字节流形式(即编码)，从而发送到第一代理。

需要说明的是，上述的安全验证操作可视为第二代理所执行的流量治理，相应地，上述的安全验证结果可视为第二代理所得到的第四治理结果。可以理解的是，在实际应用中，流量治理还可以包含更多操作，第四治理结果也可相应包含更多信息，此处不做展开。

210、第一代理向客户端发送服务响应。

得到服务响应后，第一代理不需要对字节流形式的该信息进行解码和流量治理，可直接将字节流形式的该信息发送给客户端，由客户端对其进行解码得到非字节流形式的服务响应，故客户端可对服务响应进行解析，得到处理后的数据，以提供给用户使用。

本申请实施例中，在接收到客户端发送的服务请求后，第一代理若确定自身不适合完成针对服务请求的解码、流量治理以及编码后，可从代理管理中心提供的多个代理中选择第二代理，由第二代理来替代完成针对服务请求的解码、流量治理以及编码，并及时将服务请求发送至第三代理，进而使得第三代理及时将服务请求发送至服务端。由此可见，即使第一代理所在的第一节点的CPU资源紧张，第一代理对来自客户端的服务请求所需执行的操作可以拉远到第二代理来执行，以使得服务请求及时达到第三代理以及服务端，从而在服务端处完成处理，也就是说，用户的需求可被及时且顺利满足，故可有效提高用户体验。

图4为本申请实施例提供的基于服务网格***的信息传输方法的另一流程示意图，如图4所示，该方法包括：

401、客户端向第一代理发送服务请求，客户端和第一代理位于第一网格节点中。

402、第一代理检测自身是否适合完成针对服务请求的流量治理。

403、第一代理若确定自身不适合完成针对服务请求的流量治理，则从代理管理中心提供的N个代理中确定第二代理，并向第二代理发送服务请求，第二代理位于第二网格节点中，N个代理已在代理管理中心注册，N≥1。

404、第二代理对服务请求进行流量治理，得到第一治理结果，并基于第一治理结果向第三代理发送服务请求。

405、第三代理检测自身是否适合完成针对服务请求的流量治理。

关于步骤401至步骤405的相关说明部分，可参考图2所示实施例中步骤201至步骤205的相关说明部分，此处不再赘述。

406、第三代理若确定自身不适合完成针对服务请求的流量治理，则在代理管理中心提供的M个代理中确定***理，并将向***理发送服务请求，M≥1。

第三代理若确定自身不适合完成针对这些信息的解码、流量治理以及编码后，则向代理管理中心发送第二查询请求，代理管理中心可基于第二查询请求向第一代理提供M个辅助代理(这M个辅助代理已在代理管理中心处完成注册，且M为大于或等于1的正整数)。接着，第三代理可在这M个辅助代理中，选择一个辅助代理作为***理，***理位于第四网格节点中。然后，第三代理可与***理建立通信连接，故第三代理可将客户端的地址、服务端的地址、对内输入的标识以及服务请求，以字节流形式发送至***理。

关于第三代理确定并连接***理的过程的介绍，可参考图2实施例的步骤203中第一代理确定并连接第二代理的相关说明部分，此处不再赘述。

例如，如图5所示(图5为本申请实施例提供的基于服务网格***的信息传输方法的另一应用例示意图)，sidecar3确定网格节点3的CPU超负荷后，则从代理管理中心获取M个sidecar的QP地址以及这M个sidecar的可用资源信息，从而将可用资源最大的sidecar确定为sidecar4。接着，sidecar3基于sidecar3的QP地址(QP3)以及sidecar4的QP地址(QP4)，与sidecar4完成RDMA连接。在RDMA连接过程中，sidecar3可将其完成解码、流量治理、编码所需要的二进制插件下发到sidecar4。

完成RDMA连接后，sidecar3可将APP的IP地址(SIP)，backend的IP地址(DIP),对内输入的标识(inbound)以及服务请求(buffer)，以字节流形式发送至sidecar4。

407、***理对服务请求进行流量治理，得到第二治理结果，并基于第二治理结果向服务端发送服务请求。

接收到客户端的地址、服务端的地址、对内输入的标识以及服务请求后，由于这些信息是以字节流形式被***理接收到的，故***理可先将这些信息从字节流形式转换为非字节流形式(即解码)。得到非字节流形式的这些信息后，***理可对这些信息进行安全验证，从而得到安全验证结果，若安全验证结表明这些信息是可用的后，由于对内输入的标识的存在，***理可基于***理的地址以及服务端的地址，与服务端建立通信连接，并将客户端的地址以及服务请求，从非字节流形式转换为字节流形式(即编码)，从而发送到服务端。

需要说明的是，上述的安全验证操作可视为***理所执行的流量治理，相应地，上述的安全验证结果可视为***理所得到的第二治理结果。可以理解的是，在实际应用中，流量治理还可以包含更多操作，第二治理结果也可相应包含更多信息，此处不做展开。

还需要说明的是，***理可基于来自第三代理的配置信息，来完成前述的解码、流量治理以及编码等操作。

依旧如上述例子，sidecar4接收到为字节流形式的APP的IP地址(SIP)，backend的IP地址(DIP),对内输入的标识(inbound)以及服务请求(buffer)后，可对其进行解码，从而得到非字节流形式的APP的IP地址(SIP)，backend的IP地址(DIP),对内输入的标识(inbound)以及服务请求(buffer)。在通过这些信息的安全验证后，由于对内输入的标识(inbound)的存在，sidecar4可基于sidecar4的IP地址(Node4)与backend的IP地址(DIP)，与backend完成连接，需要说明的是，sidecar4与backend之间的连接既可以是TPROXY模式的TCP连接，也可以是tcp地址选项(tcp option address，TOA)连接。

若sidecar4与backend之间完成的是TPROXY模式的TCP连接，sidecar4可对TPROXY模式的标签、APP的IP地址(SIP)以及服务请求(buffer)进行编码，从而将这些信息以字节流形式发送至backend。值得注意的是，由于sidecar4和backend位于不同的网格节点，TPROXY模式的标签在传输过程中会被丢弃，导致backend仅接收到字节流形式的APP的IP地址(SIP)以及服务请求(buffer)。

若sidecar4与backend之间完成的是TOA连接，sidecar4可对sidecar4的IP地址(Node4)、APP的IP地址(SIP)以及服务请求(buffer)进行编码，从而将这些信息以字节流形式发送向backend。值得注意的是，网格节点3的操作***会拦截这些信息，操作***仅将APP的IP地址(SIP)以及服务请求(buffer)发送给backend，这样可以令backend认为服务请求(buffer)来源于APP，并以APP为目的地来回包。

408、服务端对服务请求进行处理，得到服务响应，并向***理发送服务响应。

得到客户端的地址以及服务请求后，由于这些信息是以字节流形式被服务端接收到的，故服务端可先将这些信息从字节流形式转换为非字节流形式(即解码)。得到非字节流形式的这些信息后，服务端可先对这些信息进行解析，以确定客户端有需要处理的待处理数据，故服务端可对服务请求中的待处理数据进行处理，可得到包含处理后的数据的服务响应。那么，服务端可将服务响应从非字节流形式转换为字节流形式(即编码)，从而发送到***理。

依旧如上述例子，若sidecar4与backend之间完成的是TPROXY模式的TCP连接,backend接收到APP的IP地址(SIP)、以及服务请求(buffer)后，可对其进行解码，从而得到非字节流形式的APP的IP地址(SIP)以及服务请求(buffer)。接着，backend可对服务请求中的待处理数据进行处理，以得到包含处理后的数据的服务响应(response buffer)。值得注意的是，此时backend不以APP的IP地址(SIP)来回包(即不以APP为目的地来回包)，且由于不存在TPROXY模式的标签，backend则以sidecar4为目的地来回包，故backend可服务响应(response buffer)进行编码，从而将该信息以字节流形式发送至sidecar4。

若sidecar4与backend之间完成的是TOA连接，backend接收到APP的IP地址(SIP)以及服务请求(buffer)后，可对其进行解码，从而得到非字节流形式的APP的IP地址(SIP)以及服务请求(buffer)。接着，backend可对服务请求中的待处理数据进行处理，以得到包含处理后的数据的服务响应(response buffer)。值得注意的是，此时backend以APP的IP地址(SIP)来回包(即以APP为目的地来回包)，故backend可服务响应(response buffer)进行编码，从而将该信息以字节流形式发送向APP，但是服务响应(response buffer)会被网格节点3的操作***拦截，并将服务响应(response buffer)的目的地从APP修改为sidecar4，故网格节点3的操作***将服务响应(response buffer)，以字节流形式发送向sidecar4。

409、***理对服务响应进行流量治理，得到第三治理结果，并基于第三治理结果向第三代理发送服务响应。

得到服务响应后，由于该信息是以字节流形式被***理接收到的，故***理可先将该信息从字节流形式转换为非字节流形式(即解码)。得到非字节流形式的该信息后，***理可先对该进行安全验证，从而得到安全验证结果。若安全验证结果表明这些信息是可用的，***理可将服务响应从非字节流形式转换为字节流形式(即编码)，从而发送到第三代理。

需要说明的是，上述的安全验证操作可视为***理所执行的流量治理，相应地，上述的安全验证结果可视为***理所得到的第三治理结果。可以理解的是，在实际应用中，流量治理还可以包含更多操作，第三治理结果也可相应包含更多信息，此处不做展开。

410、第三代理向第二代理发送服务响应。

得到服务响应后，第三代理不需要对字节流形式的该信息进行解码和流量治理，可直接将字节流形式的该信息发送给第二代理。

411、第二代理对服务响应进行流量治理，得到第四治理结果，并基于第四治理结果向第一代理发送服务响应。

得到服务响应后，由于该信息是以字节流形式被第二代理接收到的，故第二代理可先将该信息从字节流形式转换为非字节流形式(即解码)。得到非字节流形式的该信息后，第二代理可先对该进行安全验证，从而得到安全验证结果。若安全验证结果表明这些信息是可用的，第二代理可将服务响应从非字节流形式转换为字节流形式(即编码)，从而发送到第一代理。

需要说明的是，上述的安全验证操作可视为第二代理所执行的流量治理，相应地，上述的安全验证结果可视为第二代理所得到的第四治理结果。可以理解的是，在实际应用中，流量治理还可以包含更多操作，第四治理结果也可相应包含更多信息，此处不做展开。

412、第一代理向客户端发送服务响应。

得到服务响应后，第一代理不需要对字节流形式的该信息进行解码和流量治理，可直接将字节流形式的该信息发送给客户端，由客户端对其进行解码得到非字节流形式的服务响应，故客户端可对服务响应进行解析，得到处理后的数据，以提供给用户使用。

本申请实施例中，在接收到第二代理发送的服务请求后，第三代理若确定自身不适合完成针对服务请求的解码、流量治理以及编码后，可从代理管理中心提供的多个代理中选择***理，由***理来替代完成针对服务请求的解码、流量治理以及编码，以使得服务请求可以及时发送至服务端。由此可见，即使第三代理所在的第三节点的CPU资源紧张，第三代理对来自第二代理的服务请求所需执行的操作可以拉远到***理来执行，以使得服务请求顺利达到服务端，从而在服务端处完成处理，也就是说，用户的需求可被及时且顺利满足，故可有效提高用户体验。

此外，基于图2或图4所示的实施例，第一代理若确定自身适合完成针对服务请求以及目标微服务的标识等等这些信息的解码、流量治理以及编码后，则可由自身来对这些信息进行解码、流量治理以及编码，在这种情况下，则不存在第二代理，相应地，针对服务响应的解码、流量治理以及编码也由第一代理来完成。

以上是对本申请实施例提供的基于服务网格***的信息传输方法所进行的详细说明，以下对本申请实施例提供的边车代理以及代理管理中心进行介绍。图6为本申请实施例提供的边车代理的一个结构示意图，如图6所示，该边车代理作为第一代理，第一代理包括：

接收模块601，用于接收客户端发送的服务请求；例如，接收模块601可实现图2所示实施例中的步骤201。

处理模块602，用于若确定自身不适合完成针对服务请求的流量治理，则从代理管理中心提供的N个代理中确定第二代理；例如，处理模块602可实现图2所示实施例中的步骤203。

发送模块603，用于向第二代理发送服务请求，第一代理与客户端位于第一网格节点，第二代理位于第二网格节点，N个代理已在代理管理中心注册，N≥1。例如，发送模块603可实现图2所示实施例中的步骤203。

在一种可能实现的方式中，处理模块602，用于若确定满足预置条件，则确定自身不适合完成针对服务请求的流量治理，预置条件包含以下至少一项：服务请求的接收时刻与当前时刻之间的差值大于第一阈值，第一节点的CPU使用率大于第二阈值，以及客户端发送的先前服务请求的处理时长大于第三阈值。

在一种可能实现的方式中，处理模块602，用于从代理管理中心提供的N个代理中，将可用资源最大的代理确定为第二代理，可用资源包含以下至少一项：可用计算资源、可用存储资源以及可用通信资源。

在一种可能实现的方式中，发送模块603，还用于将自身完成流量治理所需要的配置信息，发送至第二代理。

在一种可能实现的方式中，处理模块602，还用于若确定自身适合完成针对服务请求的流量治理，则对服务请求进行流量治理，得到第一治理结果。

发送模块603，还用于基于第一治理结果向第三代理发送服务请求。

图7为本申请实施例提供的边车代理的另一结构示意图，如图7所示，该边车代理作为第二网格节点中的第二代理，第二代理包括：

接收模块701，用于接收来自第一代理的服务请求，第一代理与客户端位于第一网格节点；例如，接收模块701可实现图2所示实施例中的步骤203。

处理模块702，用于对服务请求进行流量治理，得到第一治理结果；例如，处理模块702可实现图2所示实施例中的步骤204。

发送模块703，用于基于第一治理结果向第三代理发送服务请求，第三代理与服务端位于第三网格节点。例如，发送模块703可实现图2所示实施例中的步骤204。

在一种可能实现的方式中，接收模块701，还用于接收来自第一代理的自身完成流量治理所需要的配置信息；

处理模块702，用于基于配置信息对服务请求进行流量治理，得到第一治理结果。

图8为本申请实施例提供的边车代理的另一结构示意图，如图8所示，该边车代理作为第三代理，第三代理包括：

接收模块801，用于接收来自第二代理的服务请求，第二代理位于第二网格节点；例如，接收模块801可实现图2所示实施例中的步骤204。

处理模块802，用于若确定自身适合完成针对服务请求的流量治理，则对服务请求进行流量治理，得到第二治理结果；例如，处理模块802可实现图2所示实施例中的步骤206。

发送模块803，用于基于第二治理结果向服务端发送服务请求，第三代理与服务端位于第三网格节点。例如，发送模块803可实现图2所示实施例中的步骤206。

在一种可能实现的方式中，处理模块802，还用于若确定自身不适合完成针对服务请求的流量治理，在代理管理中心提供的M个代理中确定***理，并将向***理发送服务请求，以使得***理对服务请求进行流量治理，得到第二治理结果，并基于第二治理结果向服务端发送服务请求，***理位于第四网格节点，M≥1。

图9为本申请实施例提供的代理管理中心的一个结构示意图，如图9所示，代理管理中心包括：

注册模块901，用于供多个代理完成注册；

第一提供模块902，用于向第一网格节点的第一代理提供N个代理，N≥1。

在一种可能实现的方式中，代理管理中心还包括，第二提供模块，用于向第四网格节点的***理提供M个代理，M≥1。

图10为本申请实施例提供的边车代理的另一结构示意图。如图10所示，边车代理的一个实施例可以包括一个或一个以***处理器1001，存储器1002，输入输出接口1003，有线或无线网络接口1004，电源1005。

存储器1002可以是短暂存储或持久存储。更进一步地，中央处理器1001可以配置为与存储器1002通信，在云管理平台上执行存储器1002中的一系列指令操作。

本实施例中，中央处理器1001可以执行前述图2或图4所示实施例中第一代理、第二代理、第三代理或***理所执行的方法步骤，具体此处不再赘述。

本实施例中，中央处理器1001中的具体功能模块划分可以与前述图6、图7或图8中所描述的模块的划分方式类似，此处不再赘述。

本申请实施例还涉及一种计算机存储介质，该计算机可读存储介质中存储有用于进行信号处理的程序，当其在计算机上运行时，使得计算机执行如图2或图4所示实施例中第一代理、第二代理、第三代理或***理所执行的步骤。

本申请实施例还涉及一种计算机程序产品，该计算机程序产品存储有指令，该指令在由计算机执行时使得计算机执行如图2或图4所示实施例中第一代理、第二代理、第三代理或***理所执行的步骤。

图11为本申请实施例提供的代理管理中心的另一结构示意图。如图11所示，代理管理中心的一个实施例可以包括一个或一个以***处理器1101，存储器1102，输入输出接口1103，有线或无线网络接口1104，电源1105。

存储器1102可以是短暂存储或持久存储。更进一步地，中央处理器1101可以配置为与存储器1102通信，在云管理平台上执行存储器1102中的一系列指令操作。

本实施例中，中央处理器1101可以执行前述图2或图4所示实施例中代理管理中心所执行的方法步骤，具体此处不再赘述。

本实施例中，中央处理器1101中的具体功能模块划分可以与前述图9中所描述的模块的划分方式类似，此处不再赘述。

本申请实施例还涉及一种计算机存储介质，该计算机可读存储介质中存储有用于进行信号处理的程序，当其在计算机上运行时，使得计算机执行如图2或图4所示实施例中第一代理、第二代理、第三代理、***理或代理管理中心所执行的步骤。

本申请实施例还涉及一种计算机程序产品，该计算机程序产品存储有指令，该指令在由计算机执行时使得计算机执行如图2或图4所示实施例中第一代理、第二代理、第三代理、***理或代理管理中心所执行的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (18)

1.一种服务网格***，其特征在于，所述***包括：

第一代理，用于接收客户端发送的服务请求，若确定自身不适合完成针对所述服务请求的流量治理，则从代理管理中心提供的N个代理中确定第二代理，并向所述第二代理发送所述服务请求，所述第一代理与所述客户端位于第一网格节点，所述第二代理位于第二网格节点，所述N个代理已在所述代理管理中心注册，N≥1；

所述第二代理，用于对所述服务请求进行流量治理，得到第一治理结果，并基于所述第一治理结果向第三代理发送所述服务请求；

所述第三代理，用于若确定自身适合完成针对所述服务请求的流量治理，则对所述服务请求进行流量治理，得到第二治理结果，并基于所述第二治理结果向服务端发送所述服务请求，所述第三代理与所述服务端位于第三网格节点。

2.根据权利要求1所述的***，其特征在于，所述第一代理，用于若确定满足预置条件，则确定自身不适合完成针对所述服务请求的流量治理，所述预置条件包含以下至少一项：所述服务请求的接收时刻与当前时刻之间的差值大于第一阈值，所述第一节点的CPU使用率大于第二阈值，以及所述客户端发送的先前服务请求的处理时长大于第三阈值。

3.根据权利要求1或2所述的***，其特征在于，所述第一代理，用于从代理管理中心提供的N个代理中，将可用资源最大的代理确定为第二代理，所述可用资源包含以下至少一项：可用计算资源、可用存储资源以及可用通信资源。

4.根据权利要求1至3任意一项所述的***，其特征在于，所述第一代理，还用于将自身完成流量治理所需要的配置信息，发送至所述第二代理；

所述第二代理，用于基于所述配置信息对所述服务请求进行流量治理，得到第一治理结果，并基于所述第一治理结果向第三代理发送所述服务请求。

5.根据权利要求1至4任意一项所述的***，其特征在于，所述第一代理，还用于若确定自身适合完成针对所述服务请求的流量治理，则对所述服务请求进行流量治理，得到第一治理结果；

所述第一代理，还用于基于所述第一治理结果向所述第三代理发送所述服务请求。

6.根据权利要求1至5任意一项所述的***，其特征在于，所述第三代理，还用于若确定自身不适合完成针对所述服务请求的流量治理，在所述代理管理中心提供的M个代理中确定***理，并将向所述***理发送所述服务请求，所述***理位于第四网格节点，M≥1；

所述***理，用于对所述服务请求进行流量治理，得到第二治理结果，并基于所述第二治理结果向所述服务端发送所述服务请求。

7.根据权利要求1所述的***，其特征在于，所述服务端，用于对所述服务请求进行处理，得到服务响应，并向所述第三代理发送所述服务响应；

所述第三代理，还用于对所述服务响应进行流量治理，得到第三治理结果，并基于所述第三治理结果向所述第二代理发送所述服务响应；

所述第二代理，还用于对所述服务响应进行流量治理，得到第四治理结果，并基于所述第四治理结果向所述第一代理发送所述服务响应；

所述第一代理，还用于向所述客户端发送所述服务响应。

8.一种基于服务网格***的信息传输方法，其特征在于，所述***包含第一网格节点，第二网格节点，第三网格节点以及代理管理中心，所述第一网格节点包含第一代理以及客户端，所述第二网格节点包含第二代理，所述第三网格节点包含第三代理以及服务端，所述方法包括：

所述第一代理接收所述客户端发送的服务请求，若确定自身不适合完成针对所述服务请求的流量治理，则从所述代理管理中心提供的N个代理中确定所述第二代理，并向所述第二代理发送所述服务请求，所述N个代理已在所述代理管理中心注册，N≥1；

所述第二代理对所述服务请求进行流量治理，得到第一治理结果，并基于所述第一治理结果向第三代理发送所述服务请求；

所述第三代理若确定自身适合完成针对所述服务请求的流量治理，则对所述服务请求进行流量治理，得到第二治理结果，并基于所述第二治理结果向所述服务端发送所述服务请求。

9.根据权利要求8所述的方法，其特征在于，所述第一代理若确定自身不适合完成针对所述服务请求的流量治理包括：

所述第一代理若确定满足预置条件，则确定自身不适合完成针对所述服务请求的流量治理，所述预置条件包含以下至少一项：所述服务请求的接收时刻与当前时刻之间的差值大于第一阈值，所述第一节点的CPU使用率大于第二阈值，以及所述客户端发送的先前服务请求的处理时长大于第三阈值。

10.根据权利要求8或9所述的方法，其特征在于，所述第一代理从代理管理中心提供的N个代理中确定第二代理包括：

所述第一代理从代理管理中心提供的N个代理中，将可用资源最大的代理确定为第二代理，所述可用资源包含以下至少一项：可用计算资源、可用存储资源以及可用通信资源。

11.根据权利要求8至10任意一项所述的方法，其特征在于，所述方法还包括：

所述第一代理将自身完成流量治理所需要的配置信息，发送至所述第二代理；

则所述第二代理对所述服务请求进行流量治理，得到第一治理结果包括：

所述第二代理基于所述配置信息对所述服务请求进行流量治理，得到第一治理结果，并基于所述第一治理结果向第三代理发送所述服务请求。

12.根据权利要求8至11任意一项所述的方法，其特征在于，所述方法还包括：

所述第一代理若确定自身适合完成针对所述服务请求的流量治理，则对所述服务请求进行流量治理，得到第一治理结果；

所述第一代理基于所述第一治理结果向所述第三代理发送所述服务请求。

13.根据权利要求8至12任意一项所述的方法，其特征在于，所述***还包括第四网格节点，所述第四网格节点包含***理，所述方法还包括：

所述第三代理若确定自身不适合完成针对所述服务请求的流量治理，在所述代理管理中心提供的M个代理中确定所述***理，并将向所述***理发送所述服务请求，M≥1；

所述***理对所述服务请求进行流量治理，得到第二治理结果，并基于所述第二治理结果向所述服务端发送所述服务请求。

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

所述服务端对所述服务请求进行处理，得到服务响应，并向所述第三代理发送所述服务响应；

所述第三代理对所述服务响应进行流量治理，得到第三治理结果，并基于所述第三治理结果向所述第二代理发送所述服务响应；

所述第二代理对所述服务响应进行流量治理，得到第四治理结果，并基于所述第四治理结果向所述第一代理发送所述服务响应；

所述第一代理向所述客户端发送所述服务响应。

15.一种网格节点，其特征在于，所述网格节点包括存储器和处理器；所述存储器存储有代码，所述处理器被配置为执行所述代码，当所述代码被执行时，所述网格节点执行如权利要求8至14任意一项所述的方法中所述第一网格节点、所述第二网格节点、所述第三网格节点或所述第四网格节点实现的步骤。

16.一种代理管理中心，其特征在于，所述代理管理中心包括存储器和处理器；所述存储器存储有代码，所述处理器被配置为执行所述代码，当所述代码被执行时，所述代理管理中心执行如权利要求8至14任意一项所述的方法中所述代理管理中心实现的步骤。

17.一种计算机存储介质，其特征在于，所述计算机存储介质存储有一个或多个指令，所述指令在由一个或多个计算机执行时使得所述一个或多个计算机实施权利要求8至14任一所述的方法。

18.一种计算机程序产品，其特征在于，所述计算机程序产品存储有指令，所述指令在由计算机执行时，使得所述计算机实施权利要求8至14任意一项所述的方法。