微服务之间的数据传输方法及装置、电子设备与流程

本申请涉及通信技术领域，特别涉及一种微服务之间的数据传输方法及装置、电子设备、计算机非暂态可读存储介质。

背景技术：

单体应用随着需求的不断增加，项目维护变得越来越困难，更多应用开始采用微服务架构。微服务是每个服务运行在自己的进程中，服务间通信采用轻量级通信机制，通常用http(超文本传输协议)资源api(applicationprogramminginterface，应用程序接口)。微服务架构的优势是正好是弥补单体应用的缺点，比如单个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单；局部修改容易部署，单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题，一般来说，对某个微服务进行修改只需要重新部署这个服务即可。

但是微服务架构也面临很多挑战，比如接口调整成本高，微服务之间通过接口进行通信，如果修改某一个微服务的api，可能所有使用了该接口的微服务都需要做调整。

技术实现要素：

本申请实施例的目的在于提供一种微服务之间的数据传输方法，用以降低接口调整成本。

本申请实施例提供了一种微服务之间的数据传输方法，所述微服务包括第一微服务和第二微服务；所述方法包括：

汇聚多个第一微服务的业务数据；

将每个所述第一微服务的业务数据，写入消息队列中所述第一微服务对应的分区；

根据所述第二微服务对应的目标微服务，从所述消息队列中所述目标微服务对应的分区，获取所述第二微服务所需的业务数据。

在一实施例中，所述业务数据包括待处理数据，将每个所述第一微服务的业务数据，写入消息队列中所述第一微服务对应的分区之后，所述方法还包括：

启用计算引擎对指定分区的所述待处理数据进行过滤和标准化处理；

将过滤和标准化处理后的数据重新写入所述指定分区。

在一实施例中，所述从所述消息队列中所述目标微服务对应的分区获取所述第二微服务所需的业务数据之后，所述方法还包括：

在所述第二微服务本地，存储所述第二微服务从所述消息列队获取数据的获取记录。

在一实施例中，所述从所述消息队列中所述目标微服务对应的分区获取所述第二微服务所需的业务数据之后，所述方法还包括：

在所述消息队列的日志系统中，存储每个第二微服务从所述消息列队获取数据的记录。

在一实施例中，在所述消息队列的日志系统中，存储每个第二微服务从所述消息列队获取数据的记录之后，所述方法还包括：

在所述第二微服务的本地，当获取记录丢失或需要修正时，从所述日志系统提取所述第二微服务获取数据的记录。

在一实施例中，所述业务数据包括简单消息，从所述消息队列中所述目标微服务对应的分区获取所述第二微服务所需的业务数据，包括：

根据所述分区中简单消息的批次，按照批次从所述分区中获取所述第二微服务所需的简单消息。

本申请实施例还提供了一种微服务之间的数据传输装置，所述微服务包括第一微服务和第二微服务；所述装置包括：

数据汇聚模块，用于汇聚多个第一微服务的业务数据；

数据中转模块，用于将每个所述第一微服务的业务数据，写入消息队列中所述第一微服务对应的分区；

数据获取模块，用于根据所述第二微服务对应的目标微服务，从所述消息队列中所述目标微服务对应的分区获取所述第二微服务所需的业务数据。

在一实施例中，所述业务数据包括待处理数据，所述装置还包括：

数据处理模块，用于启用计算引擎对指定分区的所述待处理数据进行过滤和标准化处理，并将过滤和标准化处理后的数据重新写入所述指定分区。

进一步的，本申请实施例还提供了一种电子设备，所述电子设备包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行上述微服务之间的数据传输方法。

进一步的，本申请实施例还提供了一种计算机非暂态可读存储介质，所述存储介质存储有计算机程序，所述计算机程序可由处理器执行以完成上述微服务之间的数据传输方法。

本申请上述实施例提供的技术方案，将第一微服务的数据存储在消息队列中第一微服务对应的分区，从而第二微服务无需访问第一微服务，即可获取第一微服务的数据，通过消息队列优化了数据传输和处理效率，即使第一微服务的接口发生改变，也无需调整第二微服务，降低了微服务的调整成本。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的微服务之间的数据传输方法的应用场景示意图；

图2是本申请实施例提供的一种微服务之间的数据传输方法的流程示意图；

图3是本申请一实施例提供的一种微服务之间的数据传输方法的流程示意图；

图4是本申请另一实施例提供的一种微服务之间的数据传输方法的流程示意图；

图5是本申请一实施例提供的服务间消息同步的分类示意图；

图6是本申请实施例提供的一种微服务之间的数据传输装置的框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

图1为本申请实施例提供的微服务之间的数据传输方法的应用场景示意图。如图1所示，该应用场景包括服务端10，服务端10可以是一个或多个服务器。微服务可以认为是服务端10运行的进程，用于实现某种功能。服务端10可以有多种微服务，实现不同的功能，为进行区分，假设存在多个第一微服务和多个第二微服务。微服务之间的数据传输可以认为是第一微服务与第二微服务之间的数据传输。

以往，第一微服务的接口调整，与第一微服务的该接口进行数据传输的第二微服务均需做修改。如果与第一微服务进行通信的第二微服务数据较多，则对第二微服务进行修改的工作量较大，耗费较多的时间。在第一微服务数量也较多时，无疑微服务的调整成本呈指数上升。

本申请实施例中，服务端10可以采用本申请实施例提供的方法，实现第一微服务与第二微服务之间的数据传输，即使第一微服务的接口改变，也无需对第二微服务进行调整。

在一实施例中，如图1所示，服务端10运行的微服务可以包括汇聚服务11、多个业务服务12、标准化服务13和处理服务14。汇聚服务11可以汇聚多个业务服务12的业务数据，并将每个业务服务12的业务数据写入消息队列15中该业务服务12对应的分区。标准化服务13可以对分区中的业务数据进行脏数据过滤和标准化处理后，写回该分区。处理服务14可以是一个或多个，每个处理服务14可以根据与其配对的业务服务12，从消息队列15中该业务服务12所对应的分区中获取业务数据。从而处理服务14无需访问业务服务12，即可获取到所需的数据，即使业务服务12的接口改变，也不影响处理服务14的运行，由此可以降低了微服务的调整成本。

本申请实施例还提供了一种电子设备。该电子设备可以是图1所示的服务端10。电子设备可以包括处理器；用于存储处理器可执行指令的存储器；其中，该处理器被配置为执行本申请实施例提供的微服务之间的数据传输方法。

存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(staticrandomaccessmemory，简称sram)，电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，简称eeprom)，可擦除可编程只读存储器(erasableprogrammablereadonlymemory，简称eprom)，可编程只读存储器(programmablered-onlymemory，简称prom)，只读存储器(read-onlymemory，简称rom)，磁存储器，快闪存储器，磁盘或光盘。

本申请还提供了一种计算机非暂态可读存储介质，存储介质存储有计算机程序，计算机程序可由处理器执行以完成本申请实施例提供的微服务之间的数据传输方法。

图2是本申请实施例提供的一种微服务之间的数据传输方法的流程示意图。如图2所示，该方法可以包括以下步骤。

在步骤210中，汇聚多个第一微服务的业务数据。

为进行区分，提供数据的微服务可以称为第一微服务，消费数据的微服务可以称为第二微服务。采用本申请实施例提供的方法，第二微服务可以不需要访问第一微服务即可获取到第一微服务的数据。

在一实施例中，第一微服务可以是图1所示实施例中的业务服务。第二微服务可以是图1所示实施例中的处理服务。服务端可以通过运行汇聚服务，获取多个第一微服务的业务数据。在第一微服务的接口改变时，只需对汇聚服务进行调整。

在步骤220中，将每个所述第一微服务的业务数据，写入消息队列中所述第一微服务对应的分区。

其中，消息队列可以是kafka(一种分布式的消息系统)消息队列。消息队列可以实现多个分区，每个分区都是一个topic(主题)，每个微服务指定一个topic。需要消费某个微服务的数据可以去对应的分区获取。故第一微服务的业务数据，可以写入消息队列中该第一微服务对应的分区。

根据kafka消息队列自身存储机制，所有数据可以默认存储一周。根据不同的获取情况，有的topic只会被消费一次，有的topic则会被多个微服务多次消费。

在步骤230中，根据所述第二微服务对应的目标微服务，从所述消息队列中所述目标微服务对应的分区获取所述第二微服务所需的业务数据。

举例来说，第二微服务可以是bi(businessintelligence，商业智能)系统、模型系统或接口服务。其中，目标微服务是指第二微服务需要消费的数据来源，可以根据实际数据需求提前配置好。目标微服务属于多个第一微服务中的一个或若干个。

服务端根据每个第一微服务对应的分区，可以从消息队列中目标微服务对应的分区中提取业务数据。该业务数据可以认为是第二微服务所需的数据。

本申请上述实施例提供的技术方案，将第一微服务的数据存储在消息队列中第一微服务对应的分区，从而第二微服务无需访问第一微服务，即可获取第一微服务的数据，通过消息队列优化了数据传输和处理效率，即使第一微服务的接口发生改变，也无需调整第二微服务，降低了微服务的调整成本。

在一实施例中，上述业务数据可以包括待处理数据，如图3所示，在步骤220之后，本申请实施例提供的方法还可以包括步骤221和步骤222。

在步骤221中，启用计算引擎对指定分区的所述待处理数据进行过滤和标准化处理。

为进行区分，进行过滤和标准化处理的可以是服务端的第三微服务。计算引擎可以是sparkstreaming(sparkstreaming是spark核心api的一个扩展，可以实现高吞吐量的，具备容错机制的实时流数据处理)或者flink(一个框架和分布式处理引擎)等其他流式计算引擎，第三微服务可以对指定分区的待处理数据进行脏数据过滤和标准化处理。标准化处理可以认为是按照预设的规则对待处理数据进行格式转换。

在步骤222中，将过滤和标准化处理后的数据重新写入所述指定分区。

第三微服务可以将经过脏数据过滤和标准化处理后的数据重新写入指定分区。

图4是本申请另一实施例提供的一种微服务之间的数据传输方法的流程示意图。如图4所示，服务a可以汇聚多个第一微服务的业务数据，并将数据存储在kafka消息队列中。服务b可以对数据进行标准化处理，并写回kafka消息队列相应的topic。服务c可以在该topic拿到标准化后的数据进行相应的数据处理。

假设服务c是bi系统，bi系统可以将部分数据存入mysql等关系型数据库，生成准实时报表；假设服务c是模型系统，模型系统可以将数据存入es或者图数据库进行建模；假设服务c是接口服务，接口服务可以将数据存入hbase或者关系型数据继续给后端其他服务提供数据支持。

如此一来，每个微服务只需要专注于自身所处理的部分，将本应该是庞大的数据处理系统进行解耦，实现多个微服务专注自己的领域，不仅可以更好的完成自身的处理要求，也可以通过kafka这样的消息队列完成服务间的合作，真正实现一条完整的数据链路的流动。

在一实施例中，上述业务数据可以是不需要进行数据处理的简单消息。上述步骤230可以包括：根据所述分区中简单消息的批次，按照批次从所述分区中获取所述第二微服务所需的简单消息。

如图5所示，对于不需要大量处理的简单消息，可以根据批次直接获取数据，批次可以按照topic_日期_时间_批次进行定义。举例来说，批次可以是converge_20190624_23_2，即汇聚服务2019年6月24日23点第二批次。

对于需要处理的待处理数据，则需要将待处理的数据发送到指定的topic，需要处理数据的服务提交spark或flink等任务将数据处理后发送到指定topic，需要继续处理数据的服务去指定topic获取数据或继续处理。

对于不需要大量处理的简单消息，服务直接消费取回本地有以下几种情况：某个topic只有一个服务去消费且每条消息仅消费一次；某个topic只有一个服务去消费且每条数据可能会被多次消费；某个topic被多个服务消费且仅消费一次；某个topic被多个服务消费多次。

对于不需要大量处理的简单消息，每条消息不管是被消费多次还是只消费一次，或者被多个服务同时消费，都可以在消费数据的服务侧本地维护自己的偏移量(即消费记录)，以保证多个服务在重复消费数据的时候不会导致偏移量的错乱。也就是说，在第二微服务本地，存储第二微服务从消息列队获取数据的获取记录。

为了维护偏移量，不仅可以在消费端进行维护，还可以在所述消息队列的日志系统中，存储每个第二微服务从所述消息列队获取数据的记录。为了充分保障数据消费记录的一致性，在第二微服务的本地，当获取记录丢失或需要修正时，可以从所述日志系统提取所述第二微服务获取数据的记录。从而避免数据的重复消费或者未消费到数据，保障偏移量的完善稳定运行。

通过本申请上述实施例提供的技术方案，大大提高了数据在多个微服务之间的传输效率，减少了数据落地的次数，提高了数据处理的效率。无论是需要处理的数据还是可以直接消费的数据，都大大减小数据存储以及传输的压力。

图6是本申请一实施例提供的一种微服务之间的数据传输装置的框图。如图6所示，该装置可以包括：数据汇聚模块610、数据中转模块620以及数据获取模块630。

数据汇聚模块610，用于汇聚多个第一微服务的业务数据。

数据中转模块620，用于将每个所述第一微服务的业务数据，写入消息队列中所述第一微服务对应的分区。

数据获取模块630，用于根据所述第二微服务对应的目标微服务，从所述消息队列中所述目标微服务对应的分区获取所述第二微服务所需的业务数据。

在一实施例中，业务数据可以包括待处理数据，上述装置还可以包括：

数据处理模块，用于启用计算引擎对指定分区的所述待处理数据进行过滤和标准化处理，并将过滤和标准化处理后的数据重新写入所述指定分区。

在一实施例中，上述装置还可以包括：记录存储模块，用于在所述第二微服务本地，存储所述第二微服务从所述消息列队获取数据的获取记录。

在一实施例中，上述装置还可以包括：日志记录模块，用于在所述消息队列的日志系统中，存储每个第二微服务从所述消息列队获取数据的记录。

在一实施例中，上述装置还可以包括：记录修正模块，用于在所述第二微服务的本地，当获取记录丢失或需要修正时，从所述日志系统提取所述第二微服务获取数据的记录。

在一实施例中，业务数据可以包括简单消息，上述数据获取模块630包括：按批获取单元，用于根据所述分区中简单消息的批次，按照批次从所述分区中获取所述第二微服务所需的简单消息。

上述装置中各个模块的功能和作用的实现过程具体详见上述微服务之间的数据传输方法中对应步骤的实现过程，在此不再赘述。

在本申请所提供的几个实施例中，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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