CN113722070A - 基于服务网格架构的微服务系统中的数据处理方法和装置 - Google Patents

Abstract

本申请提供了一种基于服务网格架构的微服务系统中的数据处理方法和装置，有利于提升使用服务网格架构的微服务系统的性能，该微服务系统包括多个微服务节点，该多个微服务节点和多个代理节点一一关联，每个代理节点维护对应的环形队列，包括第一环形队列和第二环形队列，第一环形队列用于存储系统调用结果，第二环形队列用于存储待处理的系统调用请求，所述方法包括：第一微服务节点关联的代理节点依次遍历第一环形队列中的每个系统调用结果，根据每个系统调用结果，生成待处理的系统调用请求，存入第二环形队列；在第一环形队列遍历完毕后，第一微服务节点关联的代理节点提交第二环形队列中的系统调用请求。

Description

基于服务网格架构的微服务系统中的数据处理方法和装置

技术领域

本发明涉及计算机技术领域，并且更具体地，涉及基于服务网格架构的微服务系统中的数据处理方法和装置。

背景技术

为了方便软件开发迭代与可维护性的需求，越来越多的应用引入了微服务架构，服务网格给微服务带来了微服务组件之间调用的灵活性与可观测性，同时也对系统性能也带来一定的影响，经测试显示采用服务网格架构会带来28％～83％的吞吐下降，57～552％的额外延迟，因此，如何提升使用服务网格架构的微服务系统的性能是一项亟需解决的问题。

发明内容

本申请提供了一种基于服务网格架构的微服务系统中的数据处理方法和装置，有利于提升使用服务网格架构的微服务系统的性能。

第一方面，提供了一种基于服务网格架构的微服务系统中的数据处理方法，其中，所述微服务系统包括多个微服务节点，所述多个微服务节点和多个代理节点一一关联，每个代理节点维护对应的环形队列，其中，所述环形队列包括第一环形队列和第二环形队列，所述第一环形队列用于存储系统调用结果，所述第二环形队列用于存储待处理的系统调用请求，所述方法包括：第一微服务节点关联的代理节点依次遍历所述第一环形队列中的每个系统调用结果，根据所述每个系统调用结果，生成待处理的系统调用请求，存入所述第二环形队列；在所述第一环形队列遍历完毕后，所述第一微服务节点关联的代理节点提交所述第二环形队列中的系统调用请求。

第二方面，提供了一种基于服务网格架构的微服务系统中的数据处理方法，所述方法包括：获取所述微服务系统在使用服务网格架构和不使用服务网格架构情况下的额外网络延迟；获取使用服务网格架构的微服务系统的多条关键路径上的时间开销；根据所述额外网络延迟，对所述多条关键路径中的每条关键路径上的时间开销进行建模，得到使用服务网格架构的微服务系统的时间开销模型，其中，所述时间开销模型用于表征所述微服务系统中的所述每条关键路径上的时间开销权重。

第三方面，提供了一种基于服务网格架构的微服务系统中的数据处理方法，其中，所述微服务系统包括多个微服务节点，所述多个微服务节点和多个代理节点一一关联，所述方法包括：第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给第二微服务节点关联的代理节点。

第四方面，提供了一种基于服务网格架构的微服务系统中的数据处理装置，用于执行上述第一方面或其各实现方式中的方法。

具体地，该装置包括用于执行上述第一方面或其各实现方式中的方法的功能模块。

第五方面，提供了一种基于服务网格架构的微服务系统中的数据处理装置，用于执行上述第二方面或其各实现方式中的方法。

具体地，该装置包括用于执行上述第二方面或其各实现方式中的方法的功能模块。

第六方面，提供了一种基于服务网格架构的微服务系统中的数据处理装置，用于执行上述第二方面或其各实现方式中的方法。

具体地，该装置包括用于执行上述第三方面或其各实现方式中的方法的功能模块。

第七方面，提供了一种基于服务网格架构的微服务系统中的数据处理装置，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述第一方面或其各实现方式中的方法。

第八方面，提供了一种基于服务网格架构的微服务系统中的数据处理装置，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述第二方面或其各实现方式中的方法。

第九方面，提供了一种基于服务网格架构的微服务系统中的数据处理装置，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述第三方面或其各实现方式中的方法。

第十方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序使得计算机执行上述第一方面至第三方面中的任一方面或其各实现方式中的方法。

基于上述技术方案，服务网格架构中的代理节点通过维护对应的用于存储系统调用结果的第一环形队列和用于存储待处理的系统调用请求的第二环队列，这样，代理节点可以基于这两个环形队列对系统调用结果进行批量处理，从而能够提升系统的效率。并且，微服务节点可以通过关联的代理节点使用零拷贝的方式与其他微服务节点进行通信，有利于降低进程间通信带来的CPU开销，提升系统性能。

另外，通过对使用服务网格架构的微服务系统的关键路径上的时间开销进行建模，确定使用服务网格架构的微服务系统的时间开销的主要来源，进一步对该关键路径上的性能进行改进，从而能够提升微服务系统的整体性能。

附图说明

图1是本申请实施例提供的一种基于服务网格架构的微服务系统的示意性结构图。

图2是本申请实施例提供的基于服务网格架构的微服务系统中的数据处理方法的示意性流程图。

图3是本申请实施例提供的另一种基于服务网格架构的微服务系统中的数据处理方法的示意性流程图。

图4是本申请实施例提供的又一种基于服务网格架构的微服务系统中的数据处理方法的示意性流程图。

图5是根据本申请实施例提供的一种基于服务网格架构的微服务系统中的数据处理装置的示意性框图。

图6是根据本申请实施例提供的另一种基于服务网格架构的微服务系统中的数据处理装置的示意性框图。

图7是根据本申请实施例提供的又一种基于服务网格架构的微服务系统中的数据处理装置的示意性框图。

图8是根据本申请实施例提供的一种基于服务网格架构的微服务系统中的计算机设备的示意性框图。

具体实施方式

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

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本申请。在此使用的术语"包括"、"包含"等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中的至少一个这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

图1示意性示出了根据本申请一个实施例的基于服务网格架构的微服务系统的示意性结构图。

如图1所示，微服务系统100可以用于将复杂的系统或应用程序切分为多个微服务程序(或称，微服务节点)，每个微服务程序可以实现一个独立的业务逻辑。例如，多个微服务程序包括微服务程序101A、微服务程序102A、微服务程序103A等等。其中，多个微服务程序例如分别实现在多个计算设备上，也可以实现在一个计算设备上。

微服务系统100通过分离每个微服务程序中的业务逻辑和通信逻辑，即对每个微服务程序的通信逻辑进行抽象和归纳形成针对每个微服务程序的代理程序。代理程序负责代理与之关联的微服务程序进行数据通信。用于代理多个微服务程序进行数据通信的多个代理程序形成一个服务网格(ServiceMesh)。

如图1所示，代理程序例如可以包括与微服务程序101A相关联的代理程序101B、与微服务程序102A相关联的代理程序102B、与微服务程序103A相关联的代理程序103B等等。每个代理程序用于代理相关联的微服务程序进行数据通信。例如，代理程序101B用于代理微服务程序101A进行数据通信，代理程序102B用于代理微服务程序102A进行数据通信，代理程序103B用于代理微服务程序103A进行数据通信。

在一些实施例中，微服务系统可以应用于数据库，浏览器等领域。例如，浏览器应用程序可以用于接收用户请求，并处理用户请求生成请求结果以返回给用户。具体地，浏览器应用程序被划分为多个微服务程序，每个微服务程序可以实现一个独立的业务逻辑，通过多个微服务程序相互配合来处理用户请求，多个微服务程序可以通过各自的代理程序进行数据通信。

在一些实施例中，微服务对应的服务器的硬件设备可以包括网卡和硬盘等，在硬件设备与用户进程之间是Linux内核空间，在该内核空间内的网卡驱动程序之上设置有网络协议找，所述网络协议找给用户进程提供套接字编程接口，所述套接字编程接口主要包括socket、close、sendmsg等系统调用，其中socket用于创建套接字，close用于关闭套接字，sendmsg用于实现零拷贝发送数据。在调用sendmsg时，在内核空间为每一个待发送数据包分配内核缓存结构sk buff。

将微服务程序和代理程序一起部署的方式称为边车(Sidecar)方式。现有的Sidecar使用的是基于linux的epoll技术，该技术会带来大量的网络相关的系统调用的性能开销，并且采用Sidecar的服务网格架构会带来额外的性能开销，因此，如何提升基于服务网格架构的微服务系统的性能是一项亟需解决的问题。

图2是根据本申请实施例的基于服务网格架构的微服务系统中的数据处理方法的示意性流程图，该方法可以应用于图1所示的微服务系统100。

如图2所示，该方法200可以包括如下至少部分步骤：

S210，获取微服务系统在使用服务网格架构和不使用服务网格架构情况下的额外网络延迟；

S220，获取使用服务网格架构的微服务系统的多条关键路径上的时间开销；

S230，根据所述额外网络延迟，对所述多条关键路径中的每条关键路径上的时间开销进行建模，得到使用服务网格架构的微服务系统的时间开销模型，其中，所述时间开销模型用于表征所述微服务系统中的所述每条关键路径上的时间开销权重。

例如，可以运行一个工作日志，记录使用服务网格架构时，客户端发送数据到服务端，以及服务端向客户端回复消息所需花费的时间，以及不使用服务网格架构时，客户端发送数据到服务端，以及服务端向客户端回复消息所需花费的时间。通过对上述时间信息进行多次采样，进一步对采样的时间信息进行统计处理，确定使用服务网格架构的微服务系统的数据传输相对于不使用服务网格架构的微服务系统的数据传输的额外网络延迟。该额外网络延迟可以理解为是服务网格架构带来的延迟。

在一些实施例中，所述获取使用服务网格架构的微服务系统的多条关键路径上的时间开销，包括：

确定使用服务网格架构的微服务系统的多条候选路径，所述多条候选路径包括至少一条内核态函数调用路径和至少一条用户态函数调用路径；

对每条内核态函数调用路径上的函数调度时间进行采样，得到所述每条内核态函数调用路径的时间开销，以及，对每条用户态函数调用路径上的函数调度时间进行采样，得到所述每条用户态函数调用路径的时间开销。

例如，可以将使用服务网格架构的微服务系统相对于不使用服务网格架构的微服务系统多出来的路径作为确定额外网络延迟的候选路径。进一步确定这些候选路径中哪些路径是导致额外网络延迟的关键路径。

例如，可以对内核态函数调用路径上的函数调用时间，调用次数等信息进行采样，确定内核态函数调用路径上的时间开销。

作为示例，可以采用ebpf技术对内核态函数调用路径上的函数调用时间。其中，ebfp技术的具体实现参考相关技术，这里不作赘述。

作为示例，可以采用kprobe技术对readv，wirtev,ep_send_events_proc等内核态函数，确定内核态函数的时间开销。

例如，可以对用户态函数调用路径上的函数调用时间，调用次数等信息进行采样，确定用户态函数调用路径上的时间开销。

作为示例，可以采用uprobe技术对用户态函数的协议解析(parsing)时间进行测量，确定用户态函数的协议解析的时间开销。

进一步地，所述方法200还包括：

根据额外网络延迟和多条候选路径上的时间开销，确定产生所述额外网络延迟的多条关键路径。

例如，可以在多条候选路径上的时间开销的累计和等于额外网络延迟，或多条候选路径上的时间开销的累计和与额外网络延迟的差值小于第一阈值的情况下，确定多条候选路径为多条关键路径。这种情况下，可以认为该额外网络延迟是或基本上是该多条关键路径带来的。

进一步地，可以根据额外网络延迟，对多条关键路径中的每条关键路径上的时间开销进行建模，得到使用服务网格架构的微服务系统的时间开销模型

例如，根据每条关键路径的时间开销和额外网络延迟的比值确定每条关键路径上的时间开销权重，以得到使用服务网格架构的微服务系统的时间开销模型。

至此，基于该时间开销模型可以确定导致该额外网络延迟的各个因素的权值。

经试验，根据时间开销模型指示的权值，可以确定进程间(Inter Progresscommunication，IPC)通信与用户态协议解析是导致额外网络延迟的主要因素，因此，可以从降低IPC通信的时间开销和用户态协议解析的时间开销的角度，提升使用服务网格架构的微服务系统的性能。

在本申请一些实施例中，可以采用上述方式获取使用服务网格架构的不同的微服务系统的额外网络延迟，进一步确定使用服务网格架构的不同的微服务系统的额外网络延迟的主要因素。

应理解，不同的微服务系统可以理解用于提供不同的服务。例如，数据库服务，jrpc，web服务等。通常来说，对于不同的服务，导致延迟的主要因素不同，例如，对于数据库服务，内核态函数调用是导致延迟的主要因素，对于web服务，用户态协议解析是导致延迟的主要因素。因此，针对不同的场景，可以采用相应的解决方案以提升系统的性能。

在相关技术中，发送端向接收端发送数据，则发送端可以首先将用户缓存区中的待发送数据拷贝到内核空间，接收端从内核空间拷贝待该发送数据。发送端将待发送数据拷贝到内核空间后，发送端删除用户缓存区。由此可见，数据发送过程经过了两次拷贝，增大了CPU开销。有鉴于此，本申请实施例提供了一种技术方案，微服务节点之间可以通过零拷贝方式进行数据交互，有利于降低IPC通信带来的性能开销。

图3是根据本申请实施例的基于服务网格架构的微服务系统中的数据处理方法300的示意性流程图。该方法300可以应用于图1中的微服务系统100，该微服务系统包括多个微服务节点，该多个微服务节点和多个代理节点关联，该方法300包括：

S310，第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给所述第二微服务节点关联的代理节点。

在一些实施例中，所述第一微服务节点和所述第二微服务节点可以基于UNIX套接字(socket)机制进行通信。即可以在UNIX套接字机制中增加零拷贝逻辑，从而降低IPC通信的CPU开销。

在一些实施例中，所述零拷贝方式可以通过如下步骤实现：

第一微服务节点将待发送数据发送给关联的代理节点；

所述第一微服务节点关联的代理节点为待发送数据分配物理内存(即在本申请中可以为用户态缓存区显示分配物理内存)；

第一微服务节点关联的代理节点将待发送数据写入所述物理内存；

第一微服务节点关联的代理节点通知第二微服务节点关联的代理节点所述物理内存的地址信息；

所述第二微服务节点关联的代理节点从物理内存获取待发送数据；

所述第一微服务节点关联的代理节点在所述物理内存中的待发送数据发送完毕的情况下，回收所述物理内存。

由于本申请中，第一微服务节点关联的代理节点未将待发送数据拷贝到内核空间，因此需要在数据发送完毕之后，再回收该物理内存，以保证数据传输的可靠性。

在一些实施例中，所述第一微服务节点关联的代理节点通知所述第二微服务节点关联的代理节点所述物理内存的地址，包括：

所述第一微服务节点关联的代理节点的用户态进程通知所述第一微服务节点关联的代理节点的内核态进程所述物理内存的地址信息；

所述第一微服务节点关联的代理节点的内核态进程通知所述第二微服务节点关联的代理节点所述物理内存的地址信息。

例如，第一微服务节点关联的代理节点在调用内核态函数sendmsg时，将物理内存的地址信息赋值给该内核空间为该待发送数据分配的数据结构sk_buff，从而能够使得网卡对该物理内存感知，进一步将该物理内存的地址信息发送给第二微服务节点关联的代理节点，从而所述第二微服务节点关联的代理节点可以从物理内存获取待发送数据。从上述数据传输流程可知，基于本申请实施例的数据传输方法只需要一次拷贝过程，降低了对CPU的消耗。

在一些实施例中，在所述物理内存中的待发送数据发送完毕的情况下，所述第一微服务节点关联的代理节点的内核态进程向所述第一微服务节点关联的代理节点的用户态进程发送EPOLLERR信号，所述EPOLLERR信号用于指示所述物理内存中的数据发送完毕。第一微服务节点关联的代理节点的用户态进程接收到该EPOLLERR信号的情况下，再回收该物理内存，有利于保证数据传输的可靠性。

综上，微服务节点可以通过关联的代理节点通过零拷贝的方式进行通信，有利于降低对CPU的消耗，进一步提升使用服务网格架构的微服务系统的性能。

在相关技术中，Sidecar使用基于linux的epoll技术实现，基于该技术带来了大量的网络相关的系统调用的性能开销。有鉴于此，在本申请中，将iouring的技术应用到了服务网格架构中，重新实现服务网格架构中的sidecar，从而将系统调用批量处理，从而提升了系统的使用效率。

图4是根据本申请实施例的基于服务网格架构的微服务系统中的数据处理方法400的示意性流程图。该方法400可以应用于图1中的微服务系统100。

在本申请实施例中，该微服务系统包括多个微服务节点，该多个微服务节点和多个代理节点关联，其中，每个代理节点维护对应的环形队列，其中，所述环形队列包括第一环形队列和第二环形队列，所述第一环形队列用于存储系统调用结果，所述第二环形队列用于存储待处理的系统调用请求。即所述第一环形队列可以为完成队列(CompletionQueue，CQ)，第二环形队列为提交队列(Submission Queue，SQ)。

可选地，所述每个代理节点对于每个线程维护对应的环形队列。

如图4所示，该方法400可以包括如下步骤：

S410，第一微服务节点关联的代理节点依次遍历所述第一环形队列中的每个系统调用结果，根据所述每个系统调用结果，生成待处理的系统调用请求，存入所述第二环形队列；

S420，在所述第一环形队列遍历完毕后，所述第一微服务节点关联的代理节点提交所述第二环形队列中的系统调用请求。

代理节点负责微服务节点之间的数据通信，该第一环形队列中的系统调用结果可以是数据通信中的发送端(即源端)通过系统调用方式将待发送数据发送给代理节点的结果，进一步地，代理节点根据该系统调用结果生成系统调用请求，然后批量提交该系统调用结果，可以用于实现数据通信中代理节点通过系统调用的方式将从发送端接收的数据发送给该数据的接收端(即目的端)的目的。

例如，所述第一环形队列中包括消息接收函数(sendmsg)的系统调用结果，所述消息接收函数的系统调用结果包括待发送数据的目的端标识和所述消息接收函数的返回值，该代理节点可以将该消息接收函数的系统调用结果，生成消息发送函数的系统调用请求，并存入第二环形队列，其中，所述消息发送函数的系统调用请求包括所述待发送消息的目的端标识和所述消息接收函数的返回值。这样在批量提交第二环形队列中的系统调用请求后，内核可以执行这些系统调用请求，从而能够将待发送数据发送到目的端。

因此，本申请通过采用IO_URING技术替换服务网格架构中的epoll技术，代理节点可以基于环形队列，批量提交系统调用请求，能够减少单次系统调用带来的开销，例如TLBflush开销，用户态和内核态切换的开销。

应理解，上述方法200，方法300和方法400可以单独实施，或者也可以结合实施，例如，根据方法200确定性能开销的主要原因是进程间通信后，可以基于方法300中的技术方案降低进程间通信带来的性能开销，或者，在确定单次系统调用带来额外的系统开销后，可以基于方法400中的技术方案降低系统调用带来的开销。

上文结合图2至图4，详细描述了本申请的方法实施例，下文结合图5至图8，详细描述本申请的装置实施例，应理解，装置实施例与方法实施例相互对应，类似的描述可以参照方法实施例。

图5示出了根据本申请实施例的基于服务网格架构的微服务系统中的数据处理装置500的示意性框图。该装置500可以用于实现前述方法200中的相应流程。

如图5所示，该装置500包括：

第一获取模块501，用于获取微服务系统在使用服务网格架构和不使用服务网格架构情况下的额外网络延迟；

第二获取模块502，用于获取使用服务网格架构的微服务系统的多条关键路径上的时间开销；

建模模块503，用于根据所述额外网络延迟，对所述多条关键路径中的每条关键路径上的时间开销进行建模，得到使用服务网格架构的微服务系统的时间开销模型，其中，所述时间开销模型用于表征所述微服务系统中的所述每条关键路径上的时间开销权重。

在一些实施例中，所述第一获取模块501还用于：

确定使用服务网格架构的微服务系统的多条候选路径，所述多条候选路径包括至少一条内核态函数调用路径和至少一条用户态函数调用路径；

对每条内核态函数调用路径上的函数调度时间进行采样，得到所述每条内核态函数调用路径的时间开销，以及对每条用户态函数调用路径上的函数调度时间进行采样，得到所述每条用户态函数调用路径的时间开销。

在一些实施例中，所述装置500还包括

确定模块，用于根据所述额外网络延迟和所述多条候选路径上的时间开销，确定产生所述额外网络延迟的多条关键路径。

在一些实施例中，所述确定模块还用于：

在所述多条候选路径上的时间开销的累计和等于所述额外网络延迟，或所述多条候选路径上的时间开销的累计和与所述额外网络延迟的差值小于第一阈值的情况下，确定所述多条候选路径为所述多条关键路径。

在一些实施例中，所述建模模块503还用于：

根据所述每条关键路径的时间开销和所述额外网络延迟的比值确定所述每条关键路径上的时间开销权重，以得到使用服务网格架构的所述微服务系统的时间开销模型。

图6示出了根据本申请实施例的基于服务网格架构的微服务系统中的数据处理装置600的示意性框图。该装置600可以用于实现前述方法300中的相应流程。

如图6所示，该装置600包括：代理模块601，与微服务系统中的微服务模块关联，所述代理模块601用于采用零拷贝方式将关联的微服务模块的待发送数据发送给所述待发送数据的目标微服务模块关联的代理模块。

在一些实施例中，所述代理模块601具体用于：

待发送数据分配物理内存，并将所述待发送数据写入所述物理内存。

在一些实施例中，所述代理模块601，用于通知目标微服务模块关联的代理模块所述物理内存的地址信息，以使所述目标微服务模块关联的代理模块从所述物理内存获取所述待发送数据。

在一些实施例中，所述代理模块601还用于：

在所述物理内存中的待发送数据发送完毕的情况下，回收所述物理内存。

在一些实施例中，所述代理模块601的用户态进程通知所述代理模块601的内核态进程所述物理内存的地址信息。

所述代理模块601的内核态进程通知所述目标服务模块关联的代理模块所述物理内存的地址信息。

在一些实施例中，在所述物理内存中的待发送数据发送完毕的情况下，所述代理模块601的内核态进程向代理模块601的用户态进程发送EPOLLERR信号，所述EPOLLERR信号用于指示所述物理内存中的数据发送完毕；所述代理模块601的用户态进程在接收到所述EPOLLERR信号的情况下，确定所述物理内存中的待发送数据发送完毕。

在一些实施例中，所述代理模块601还用于：

在待发送数据的数据量大于预设阈值的情况下，采用零拷贝方式将待发送数据发送给所述目标微服务模块关联的代理模块。

图7示出了根据本申请实施例的基于服务网格架构的微服务系统中的数据处理装置700的示意性框图。该装置700可以用于实现前述方法400中的相应流程。

如图7所示，该装置700包括：代理模块701，维护对应的环形队列，其中，所述环形队列包括第一环形队列和第二环形队列，所述第一环形队列用于存储系统调用结果，所述第二环形队列用于存储待处理的系统调用请求。

所述代理模块701具体用于：

依次遍历所述第一环形队列中的每个系统调用结果，根据所述每个系统调用结果，生成待处理的系统调用请求，存入所述第二环形队列；

在所述第一环形队列遍历完毕后，提交所述第二环形队列中的系统调用请求。

在一些实施例中，所述代理模块701具体用于：

将所述第一环形队列中的消息接收函数的系统调用结果，生成消息发送函数的系统调用请求，其中，所述消息接收函数的系统调用结果包括待发送数据的目的端标识和所述消息接收函数的返回值，所述消息发送函数的系统调用请求包括所述待发送数据的目的端标识和所述消息接收函数的返回值。

应理解的是，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，该基于服务网格的微服务系统中的数据处理装置可以执行上述方法实施例，并且该基于服务网格的微服务系统中的数据处理装置中的各个模块的前述和其它操作和/或功能分别为了上述方法实施例中的各个方法中的相应流程，为了简洁，在此不再赘述。

上文中结合附图从功能模块的角度描述了本申请实施例的基于服务网格的微服务系统中的数据处理装置。应理解，该功能模块可以通过硬件形式实现，也可以通过软件形式的指令实现，还可以通过硬件和软件模块组合实现。具体地，本申请实施例中的方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路和/或软件形式的指令完成，结合本申请实施例公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。可选地，软件模块可以位于随机存储器，闪存、只读存储器、可编程只读存储器、电可擦写可编程存储器、寄存器等本领域的成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法实施例中的步骤。

图8是根据本申请实施例的基于服务网格的微服务系统中的电子设备的示意性框图。该电子设备800旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。该计算机设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图8所示，该电子设备800包括：一个或多个处理器810、存储器820，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备800内存储的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，相合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。

存储器820为本申请所提供的计算机可读存储介质。其中，存储器存储有可由至少一个处理器执行的指令，以使至少一个处理器执行本申请所提供的基于服务网格架构的微服务系统中的数据处理方法。本申请的计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的基于服务网格架构的微服务系统中的数据处理方法。

存储器820作为一种计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的基于服务网格架构的微服务系统中的数据处理方法200至方法400对应的程序指令/模块。处理器810通过运行存储在存储器820中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的基于服务网格架构的微服务系统中的数据处理方法200至方法400。

在一些实施例中，存储器820可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序：存储数据区可存储根据基于服务网格架构的微服务系统中的数据处理方法200至方法400的电子设备800的使用所创建的数据等。此外，存储器820可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。

在一些实施例中，存储器820可选包括相对于处理器810远程设置的存储器，这些远程存储器可以通过网络连接至基于服务网格架构的微服务系统中的数据处理方法的电子设备800。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

在一些实施例中，电子设备800还可以包括：输入装置830和输出装置840。处理器810、存储器820、输入装置830和输出装置840可以通过总线或者其他方式连接，图8中以通过总线连接为例。

在一些实施例中，输入装置830可接收输入的数字或字符信息，以及产生与电子设备800的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。

在一些实施例中，输出装置840可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。

在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语"机器可读介质"和"计算机可读介质"指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD)，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，阴极射线管(CRT)或者液晶显示器(LCD)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、昕觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

应理解，计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端一服务器关系的计算机程序来产生客户端和服务器的关系。

根据本公开的一个或多个实施例，提供了一种基于服务网格架构的微服务系统中的数据处理方法，其中，微服务系统包括多个微服务节点，多个微服务节点和多个代理节点一一关联，每个代理节点维护对应的环形队列，其中，环形队列包括第一环形队列和第二环形队列，第一环形队列用于存储系统调用结果，第二环形队列用于存储待处理的系统调用请求，该方法包括：第一微服务节点关联的代理节点依次遍历第一环形队列中的每个系统调用结果，根据每个系统调用结果，生成待处理的系统调用请求，存入第二环形队列；在第一环形队列遍历完毕后，第一微服务节点关联的代理节点提交第二环形队列中的系统调用请求。

根据本公开的一个或多个实施例，根据每个系统调用结果，生成待处理的系统调用请求，包括：将第一环形队列中的消息接收函数的系统调用结果，生成消息发送函数的系统调用请求，其中，消息接收函数的系统调用结果包括待发送数据的目的端标识和消息接收函数的返回值，消息发送函数的系统调用请求包括待发送数据的目的端标识和消息接收函数的返回值。

根据本公开的一个或多个实施例，每个代理节点对于每个线程维护对应的环形队列。

根据本公开的一个或多个实施例，还包括：在第一微服务节点有数据待发送给第二微服务节点的情况下，该第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给该第二微服务节点关联的代理节点。

根据本公开的一个或多个实施例，该第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给该第二微服务节点关联的代理节点，包括：

在该第一微服务节点有数据待发送给第二微服务节点的情况下，该第一微服务节点将待发送数据发送给关联的代理节点；

该第一微服务节点关联的代理节点为待发送数据分配物理内存，并将该待发送数据写入该物理内存；

该第一微服务节点关联的代理节点通知该第二微服务节点关联的代理节点该物理内存的地址信息，以使该第二微服务节点关联的代理节点从该物理内存获取该待发送数据；

该第一微服务节点关联的代理节点在该物理内存中的待发送数据发送完毕的情况下，回收该物理内存。

根据本公开的一个或多个实施例，还包括：在物理内存中的待发送数据发送完毕的情况下，第一微服务节点的内核态进程向第一微服务节点的用户态进程发送EPOLLERR信号，EPOLLERR信号用于指示物理内存中的数据发送完毕；第一微服务节点关联的代理节点根据EPOLLERR信号，确定物理内存中的待发送数据发送完毕。

根据本公开的一个或多个实施例，该第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给该第二微服务节点关联的代理节点，包括：

在待发送数据的数据量大于预设阈值的情况下，该第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给该第二微服务节点关联的代理节点。

根据本公开的一个或多个实施例，提供了一种基于服务网格架构的微服务系统中的数据处理方法，包括：获取微服务系统在使用服务网格架构和不使用服务网格架构情况下的额外网络延迟；获取使用服务网格架构的微服务系统的多条关键路径上的时间开销；根据额外网络延迟，对多条关键路径中的每条关键路径上的时间开销进行建模，得到使用服务网格架构的微服务系统的时间开销模型，其中，时间开销模型用于表征微服务系统中的每条关键路径上的时间开销权重。

根据本公开的一个或多个实施例，所述获取使用服务网格架构的微服务系统的多条关键路径上的时间开销，包括：确定使用服务网格架构的微服务系统的多条候选路径，多条候选路径包括至少一条内核态函数调用路径和至少一条用户态函数调用路径；对每条内核态函数调用路径上的函数调度时间进行采样，得到每条内核态函数调用路径的时间开销，以及对每条用户态函数调用路径上的函数调度时间进行采样，得到每条用户态函数调用路径的时间开销。

根据本公开的一个或多个实施例，还包括：在多条候选路径上的时间开销的累计和等于额外网络延迟，或多条候选路径上的时间开销的累计和与额外网络延迟的差值小于第一阈值的情况下，确定多条候选路径为多条关键路径。

根据本公开的一个或多个实施例，所述根据额外网络延迟，对多条关键路径中的每条关键路径上的时间开销进行建模，包括：根据每条关键路径的时间开销和额外网络延迟的比值确定每条关键路径上的时间开销权重，以得到使用服务网格架构的微服务系统的时间开销模型。

根据本公开的一个或多个实施例，提供了一种基于服务网格架构的微服务系统中的数据处理装置，包括：第一获取模块，用于获取微服务系统在使用服务网格架构和不使用服务网格架构情况下的额外网络延迟；第二获取模块，用于获取使用服务网格架构的微服务系统的多条关键路径上的时间开销；建模模块，用于根据该额外网络延迟，对该多条关键路径中的每条关键路径上的时间开销进行建模，得到使用服务网格架构的微服务系统的时间开销模型，其中，该时间开销模型用于表征该微服务系统中的该每条关键路径上的时间开销权重。

根据本公开的一个或多个实施例，该第一获取模块还用于：确定使用服务网格架构的微服务系统的多条候选路径，该多条候选路径包括至少一条内核态函数调用路径和至少一条用户态函数调用路径；对每条内核态函数调用路径上的函数调度时间进行采样，得到该每条内核态函数调用路径的时间开销，以及对每条用户态函数调用路径上的函数调度时间进行采样，得到该每条用户态函数调用路径的时间开销。

根据本公开的一个或多个实施例，该数据处理装置还包括：确定模块，用于根据该额外网络延迟和该多条候选路径上的时间开销，确定产生该额外网络延迟的多条关键路径。

根据本公开的一个或多个实施例，该确定模块还用于：在该多条候选路径上的时间开销的累计和等于该额外网络延迟，或该多条候选路径上的时间开销的累计和与该额外网络延迟的差值小于第一阈值的情况下，确定该多条候选路径为该多条关键路径。

根据本公开的一个或多个实施例，该建模模块还用于：根据该每条关键路径的时间开销和该额外网络延迟的比值确定该每条关键路径上的时间开销权重，以得到使用服务网格架构的该微服务系统的时间开销模型。

根据本公开的一个或多个实施例，提供了一种基于服务网格架构的微服务系统中的数据处理装置，包括：代理模块，与微服务系统中的微服务模块关联，该代理模块用于采用零拷贝方式将关联的微服务模块的待发送数据发送给该待发送数据的目标微服务模块关联的代理模块。

根据本公开的一个或多个实施例，该代理模块具体用于：待发送数据分配物理内存，并将该待发送数据写入该物理内存。

根据本公开的一个或多个实施例，该代理模块还用于：通知目标微服务模块关联的代理模块该物理内存的地址信息，以使该目标微服务模块关联的代理模块从该物理内存获取该待发送数据。

根据本公开的一个或多个实施例，该代理模块还用于：在该物理内存中的待发送数据发送完毕的情况下，回收该物理内存。

根据本公开的一个或多个实施例，该代理模块的用户态进程通知该代理模块的内核态进程该物理内存的地址信息；该代理模块的内核态进程通知该目标服务模块关联的代理模块该物理内存的地址信息。

根据本公开的一个或多个实施例，该代理模块的内核态进程还用于：在该物理内存中的待发送数据发送完毕的情况下，向代理模块的用户态进程发送EPOLLERR信号，该EPOLLERR信号用于指示该物理内存中的数据发送完毕；该代理模块的用户态进程，用于在接收到该EPOLLERR信号的情况下，确定该物理内存中的待发送数据发送完毕。

根据本公开的一个或多个实施例，该代理模块还用于：在待发送数据的数据量大于预设阈值的情况下，采用零拷贝方式将待发送数据发送给该目标微服务模块关联的代理模块。

根据本公开的一个或多个实施例，提供了一种基于服务网格架构的微服务系统中的数据处理装置，包括：代理模块，维护对应的环形队列，其中，该环形队列包括第一环形队列和第二环形队列，该第一环形队列用于存储系统调用结果，该第二环形队列用于存储待处理的系统调用请求。

根据本公开的一个或多个实施例，该代理模块具体用于：依次遍历该第一环形队列中的每个系统调用结果，根据该每个系统调用结果，生成待处理的系统调用请求，存入该第二环形队列；在该第一环形队列遍历完毕后，提交该第二环形队列中的系统调用请求。

根据本公开的一个或多个实施例，该代理模块具体用于：将该第一环形队列中的消息接收函数的系统调用结果，生成消息发送函数的系统调用请求，其中，该消息接收函数的系统调用结果包括待发送数据的目的端标识和该消息接收函数的返回值，该消息发送函数的系统调用请求包括该待发送数据的目的端标识和该消息接收函数的返回值。

根据本公开的一个或多个实施例，提供一种电子设备，包括：处理器和存储器，存储器用于存储计算机程序，处理器用于调用并运行存储器中存储的计算机程序，以执行上述基于服务网格架构的微服务系统中的数据处理方法。

根据本公开的一个或多个实施例，提供一种计算机可读存储介质，用于存储计算机程序，计算机程序使得计算机执行上述基于服务网格架构的微服务系统中的数据处理方法。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和苔代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。

Claims (15)

1.一种基于服务网格架构的微服务系统中的数据处理方法，其中，所述微服务系统包括多个微服务节点，所述多个微服务节点和多个代理节点一一关联，其特征在于，每个代理节点维护对应的环形队列，其中，所述环形队列包括第一环形队列和第二环形队列，所述第一环形队列用于存储系统调用结果，所述第二环形队列用于存储待处理的系统调用请求，所述方法包括：

第一微服务节点关联的代理节点依次遍历所述第一环形队列中的每个系统调用结果，根据所述每个系统调用结果，生成待处理的系统调用请求，存入所述第二环形队列；

在所述第一环形队列遍历完毕后，所述第一微服务节点关联的代理节点提交所述第二环形队列中的系统调用请求。

2.根据权利要求1所述的方法，其特征在于，所述根据所述每个系统调用结果，生成待处理的系统调用请求，包括：

将所述第一环形队列中的消息接收函数的系统调用结果，生成消息发送函数的系统调用请求，其中，所述消息接收函数的系统调用结果包括待发送数据的目的端标识和所述消息接收函数的返回值，所述消息发送函数的系统调用请求包括所述待发送数据的目的端标识和所述消息接收函数的返回值。

3.根据权利要求1所述的方法，其特征在于，所述每个代理节点对于每个线程维护对应的环形队列。

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

在所述第一微服务节点有数据待发送给第二微服务节点的情况下，所述第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给所述第二微服务节点关联的代理节点。

5.根据权利要求4所述的方法，其特征在于，所述第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给所述第二微服务节点关联的代理节点，包括：

在所述第一微服务节点有数据待发送给第二微服务节点的情况下，所述第一微服务节点将待发送数据发送给关联的代理节点；

所述第一微服务节点关联的代理节点为待发送数据分配物理内存，并将所述待发送数据写入所述物理内存；

所述第一微服务节点关联的代理节点通知所述第二微服务节点关联的代理节点所述物理内存的地址信息，以使所述第二微服务节点关联的代理节点从所述物理内存获取所述待发送数据；

所述第一微服务节点关联的代理节点在所述物理内存中的待发送数据发送完毕的情况下，回收所述物理内存。

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

在所述物理内存中的待发送数据发送完毕的情况下，所述第一微服务节点的内核态进程向所述第一微服务节点的用户态进程发送EPOLLERR信号，所述EPOLLERR信号用于指示所述物理内存中的数据发送完毕；

所述第一微服务节点关联的代理节点根据所述EPOLLERR信号，确定所述物理内存中的待发送数据发送完毕。

7.根据权利要求4-6中任一项所述的方法，其特征在于，所述第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给所述第二微服务节点关联的代理节点，包括：

在待发送数据的数据量大于预设阈值的情况下，所述第一微服务节点通过关联的代理节点采用零拷贝方式将待发送数据发送给所述第二微服务节点关联的代理节点。

8.一种基于服务网格架构的微服务系统中的数据处理方法，其特征在于，所述方法包括：

获取所述微服务系统在使用服务网格架构和不使用服务网格架构情况下的额外网络延迟；

获取使用服务网格架构的微服务系统的多条关键路径上的时间开销；

根据所述额外网络延迟，对所述多条关键路径中的每条关键路径上的时间开销进行建模，得到使用服务网格架构的微服务系统的时间开销模型，其中，所述时间开销模型用于表征所述微服务系统中的所述每条关键路径上的时间开销权重。

9.根据权利要求8所述的方法，其特征在于，所述获取使用服务网格架构的微服务系统的多条关键路径上的时间开销，包括：

确定使用服务网格架构的微服务系统的多条候选路径，所述多条候选路径包括至少一条内核态函数调用路径和至少一条用户态函数调用路径；

对每条内核态函数调用路径上的函数调度时间进行采样，得到所述每条内核态函数调用路径的时间开销，以及对每条用户态函数调用路径上的函数调度时间进行采样，得到所述每条用户态函数调用路径的时间开销。

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

在所述多条候选路径上的时间开销的累计和等于所述额外网络延迟，或所述多条候选路径上的时间开销的累计和与所述额外网络延迟的差值小于第一阈值的情况下，确定所述多条候选路径为所述多条关键路径。

11.根据权利要求8-10中任一项所述的方法，其特征在于，所述根据所述额外网络延迟，对所述多条关键路径中的每条关键路径上的时间开销进行建模，包括：

根据所述每条关键路径的时间开销和所述额外网络延迟的比值确定所述每条关键路径上的时间开销权重，以得到使用服务网格架构的所述微服务系统的时间开销模型。

12.一种基于服务网格架构的微服务系统中的数据处理装置，其特征在于，所述装置包括代理模块，所述代理模块与所述微服务系统中的微服务节点关联，所述代理模块维护对应的环形队列，其中，所述环形队列包括第一环形队列和第二环形队列，所述第一环形队列用于存储系统调用结果，所述第二环形队列用于存储待处理的系统调用请求；

所述代理模块具体用于：

依次遍历所述第一环形队列中的每个系统调用结果，根据所述每个系统调用结果，生成待处理的系统调用请求，存入所述第二环形队列；

在所述第一环形队列遍历完毕后，提交所述第二环形队列中的系统调用请求。

13.一种基于服务网格架构的微服务系统中的数据处理装置，其特征在于，所述装置包括：

第一获取模块，用于获取微服务系统在使用服务网格架构的系统和不使用服务网格架构情况下的额外网络延迟；

第二获取模块，获取使用服务网格架构的微服务系统的多条关键路径上的时间开销；

建模模块，用于根据所述额外网络延迟，对所述多条关键路径中的每条关键路径上的时间开销进行建模，得到使用服务网格架构的微服务系统的时间开销模型，其中，所述时间开销模型用于表征所述微服务系统中的所述每条关键路径上的时间开销权重。

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

处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，以执行权利要求1至7中任一项所述的方法，或权利要求8至11中任一项所述的方法。

15.一种计算机可读存储介质，其特征在于，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求1至7中任一项所述的方法，或权利要求8至11中任一项所述的方法。

Images