CN117221260A - 多平台微服务连接技术 - Google Patents

Abstract

微服务间通信通过内存内连接路由管理。发送微服务通过与所述连接相关联的端口写入消息。所述消息被直接路由到一个或多个接收微服务，所述一个或多个接收微服务通过它们的与所述连接相关联的端口与所述连接相关联。当通过所述发送微服务端口接收所述消息时，并且在通过所述接收微服务端口路由转变消息之前，所述消息可以通过处理的插件转变成不同的格式或多种不同的格式。所述微服务间通信与硬件和平台无关或对硬件和平台不可知，使得与所述连接相关联的所述微服务可以在彼此不同的硬件和不同的平台上处理。

Description

多平台微服务连接技术

本申请是申请日为2021年6月28日、申请号为202110724138.6、发明名称为“多平台微服务连接技术”的中国发明专利申请的分案申请。

背景技术

微服务与计算架构相关联，该计算架构将单个应用/服务构建为松散耦合服务的集合。这允许独立部署表示单个应用/服务的微服务中的每一个微服务，即使在整体单个应用/服务很复杂的情况下。微服务也易于维护和测试。每个微服务提供与单个应用/服务的一部分相关联的细粒度功能性。每个微服务与其他微服务松散地耦合，因为与单个应用/服务相关联的微服务之间的依赖程度较小并且相比于与原始单个应用/服务的原始功能之间的耦合/依赖性相关联的微服务显著更小。

企业正在迁移其应用/服务架构和新近提供的服务，以通过网络作为微服务提供给其客户，这不足为奇。

关于微服务的一个问题是实现微服务之间快速且高效通信的能力，因为以前在单一设备上执行的单个/应用或服务，现在已成为一系列个别服务，每一种服务可以在网络上的不同设备上执行。因此，微服务通信可以通过网络跨越多个设备，而单个单块应用/服务在单个设备的内存内通信。

因此，微服务通常利用基于管道的通信，这样将打开服务器/设备上的微服务之间的存储器中的连接，其中数据可以由微服务读取、写入并且被路由到微服务。

现有的基于管道的实用程序的问题在于它们是平台特定的(例如，操作系统(OS)特定的)，这意味着必须同时在相同的平台上处理需要彼此通信的两个微服务。现有的基于管道的实用程序的另一个问题是，管道只能通过一个插件处理一种数据格式。也就是说，微服务之间的任何数据格式变化必须通过具有在存储器管道内调用的单个插件的管道来处理；单个插件将处于发送微服务的格式的消息转换为接收微服务的所需格式。因此，现有的基于管道的实用程序是特定于平台和消息数据格式转换的实用程序，因为只有单个插件才能够在服务器/设备上的任何给定实例化管道中使用。

对于希望迁移到微服务架构的任何企业来说，这是行业中的一个问题，因为企业可能拥有许多不同的平台和许多不同的应用或数据格式，需要利用这些来有效且高效地向其客户提供其服务。

发明内容

在各种实施方案中，呈现了用于多平台微服务连接技术的方法和系统。

根据一个实施方案，呈现了一种用于多平台微服务连接技术的方法。例如，在与多个平台相关联的微服务之间建立内存内连接。在连接期间，从与第一平台相关联的发送微服务接收消息。调用与至少一个第二平台相关联的至少一个插件以将消息从第一格式转换为至少一个第二格式。通过内存内连接将至少一个第二格式的消息路由到与至少一个第二平台相关联的至少一个接收微服务。

附图说明

图1A是根据示例性实施方案的用于多平台微服务连接技术的系统的图。

图1B是根据示例性实施方案的示出图1A的系统的处理流程的图。

图2是根据示例性实施方案的用于多平台微服务连接技术的方法的图。

图3是根据示例性实施方案的用于多平台微服务连接技术的另一种方法的图。

具体实施方式

图1A是根据示例性实施方案的用于多平台微服务连接技术的系统100的图。应注意，组件以大大简化的形式示意性地示出，其中仅示出了与对实施方案的理解相关的那些组件。

此外，仅出于说明的目的，示出了各种组件(标识于图1中)并且呈现了所述各种组件的布置。应注意，在不脱离本文和下文所呈现的多平台微服务连接技术的教导内容的情况下，具有更多或更少组件的其他布置也是可能的。

如本文和下文将更详细地讨论的，系统100准许跨多个不同平台(例如，操作系统(OS)、虚拟机(VM)、容器等)通过内存内路由来进行微服务间通信。这样快速且高效。此外，所发送的每一个消息可通过多个插件转变成微服务之间的任何期望或所需的自定义输出。

系统100呈现在交易期间提供给交易终端142的交易服务的上下文内。这是零售行业中的许多潜在应用之一，仅出于说明的目的呈现；因为要指出的是，也可使用其他应用，诸如但不限于财务应用、旅游应用、酒店应用、餐厅应用，等等。

如本文和下文所论述，“微服务”是与特定服务分离的一个或多个功能/操作。特定服务由多个微服务定义的多个功能/操作组成，所述多个微服务彼此协作以提供特定服务的整体功能/操作。特定服务可以是交易服务、忠诚度服务、预订服务、支付服务和/或安全服务。特定服务由销售点(POS)终端、自助服务终端(SST)、自动柜员机(ATM)和/或信息亭处理或发起。将特定服务分解成包括协作微服务的松散耦合的操作。每个微服务可以在与微服务的组合中的其余计算装置相同或不同的计算装置上处理。处理微服务中的一个或多个微服务的每个设备可以为服务器、VM、容器、发起特定服务的终端，或任何其他计算设备。以此方式，特定服务的功能/操作由协作微服务在多个设备、相同设备或这些设备的组合上分配。此外，每个微服务可以在与微服务中的其余微服务相同或不同的平台上本机执行。以此方式，微服务与设备和平台无关或对设备和平台不可知。

系统100包括1到N个设备(110、120)、服务器130和交易终端140。110、120、130和140各自包括对应的处理器(111、121、131和141)和对应的非暂态计算机可读存储介质(112、122、132和142)，所述对应的非暂态计算机可读存储介质具有用于OS1 113、微服务(MS)1 114、MS2 115、OS N 123、MS N 124、MS N+1 124、管道连接管理器133、插件1 134、插件N 135和交易管理器/代理143的可执行指令。当对应的处理器(111、121、131和141)从对应的介质(112、122、132和142)执行对应的可执行指令时，这使得对应的处理器(111、121、131和141)针对OS1 113、微服务(MS)1 114、MS2 115、OS N 123、MS N 124、MS N+1 124、管道连接管理器133、插件1 134、插件N 135和交易管理器/代理143执行本文和下文所讨论的操作。

交易终端140为在终端140上发起的交易提供一项或多项服务。每个服务包括MS(114、115、124和/或125)的一些组合。例如，交易可包括安全服务、交易服务、忠诚度服务和支付服务。为了为每个服务提供操作，MS(114、115、124和/或125)中的多个MS需要彼此通信。也就是说，消息在MS(114、115、124和/或125)之间被发送为输出，并且其他消息由MS(114、115、124和/或125)读取为输入。

管道连接管理器133在交易期间建立并且管理来自服务器130的MS(114、115、124和/或125)之间的内存内管道连接。管道连接管理器133接收通过针对给定连接建立的写入MS的端口写入的消息，并且将所述写入消息直接路由到针对给定连接建立的接收MS的端口。管道连接管理器133可以将内存内连接管理为MS(114、115、124和/或125)之间的1-1连接、1-多连接和/或多对多连接。

管道连接管理器133维护每个MS(114、115、124和125)的每个实例或线程的唯一标识符。在给定连接期间，为每个唯一标识符分配一个端口号用于通信。管道连接管理器133维护准许快速发现给定连接所需的端口号的内存内映射或数据库。以此方式，当发送MS(114、115、124和125)将输出写入连接时，该输出通过适当的接收MS(114、115、124和125)的与连接相关联的端口被快速路由到所述适当的接收MS。此外，内存内映射或数据库可以标识所需插件的插件标识符(134和/或135)。管道连接管理器133调用特定接收MS(114、115、124和125)在连接期间所需的任何插件(134和/或135)。任何被调用的插件(134和/或135)的输出包括由发送MS(114、115、124和125)产生的原始输出消息，该原始输出消息从原始的与输出消息相关联的数据格式被转换或转变成不同的数据格式。由每个调用的插件(134和/或135)产生的不同数据格式表示对应的接收MS(114、115、124和125)所需的目标数据格式。来自任何被调用的插件(134和/或135)的输出由管道连接管理器133路由到对应的接收MS在交易期间收听的适当的端口号。

传统上，现有的基于管道的实用程序仅能够调用单个插件。系统100准许集成1、2或N个插件(134到135)，其中N为任何所需数量的未设置上限的插件。

另外，管道连接管理器133对OS不可知，这意味着一些MS(114和115)可以利用与第一类型的OS相关联的第一OS1113，其中其他MS(124和125)可以利用与第二类型的OS相关联的第二OS N。不同OS的113和123可以具有不同类型，或者可以具有相同类型，但是为相同类型OS的不同型式/版本。应注意，在一些情况和实施方案中，OS1 113和OS N 123可具有与OS相同的类型和型式/版本。以此方式，MS的平台(114、115、124和125)是不可知的，并且管道连接管理器133可以建立和管理MS(114、115、124和125)之间的连接，而不管与每个MS(114、115、124和125)相关联的平台如何。

在一个实施方案中，管道连接管理器133以代码形式编写为脚本，该脚本能够在任何现有OS平台中运行，并且可通过基于社区的npm文库进行扩展。只需要将管道连接管理器添加到服务器130的注册表设置一次。插件(134和135)的添加可通过config.json文件按如下所述进行处理：

系统100准许同时接受和应用多个插件(134和135)的多平台MS间通信。可轻松添加新的插件(134或135)。在一个实施方案中，提供命令行解释器，该命令行解释器使得能够从命令提示发送测试消息以测试MS(114、115、124和125)之间的消息发送。在一个实施方案中，提供可在发送任何测试消息之后调用的可配置后加载命令，这准许使用测试消息的结果来自定义脚本。

图1B是根据示例性实施方案的示出图1A的系统的处理流程150的图。

交易管理器/代理143在终端140上针对交易所需的特定服务或一组服务发起交易。这致使多平台管道连接管理器131实例化所需MS(114、115、124、125)的实例，每个实例具有唯一的TCP/IP地址或标识符，所述唯一的TCP/IP地址或标识符在内存内由管道连接管理器131在内存内映射或内存内数据库内维护，所述内存内映射或内存内数据库分配端口号以用于与具有每个地址或标识符的MS(114、115、124和125)中的每一者进行通信。当每个MS(114、115、124和125)处理以递送用于交易的特定服务或一组服务时，由每个MS(114、115、124和125)产生的输出消息通过由管道连接管理器131维护的连接发送。输出消息通过分配给每个发送MS(114、115、124和125)的端口写入存储器。管道连接管理器131利用内存内数据库或映射来路由输出消息以连接到接收MS(114、115、124和125)的对应的端口，在执行路由到接收MS(114、115、124和125)之前，调用用于转变输出消息格式的任何插件。插件(133和134)可包括一个gRPC插件、socket_IO插件、redis插件、REST API插件或任何自定义插件。此外，管道连接管理器131可以集成并且调用N个插件(133和134)。N没有预定义的上限。

应注意，图1A中呈现的MS(114、115、124和125)的总数并不旨在对本文所讨论的实施方案作出任何限制。也就是说，设备可以仅具有1MS，或者设备可以具有N MS。更进一步地，服务器130和/或终端140可以包括MS的一些或全部。此外，MS(114、115、124和125)所需的设备总数仅旨在进行说明，因为可能存在比所描绘的更少或更多的设备。需要强调的是，MS(114、115、124和125)的设备和平台不会改变本文所呈现的教导内容，因为管理MS间通信与本文所提供的实施方案的硬件无关并且与平台无关。

现在参考图2至图3讨论这些和其他实施方案。

图2是根据示例性实施方案的用于多平台微服务连接技术的方法200的图。实施方法200的软件模块被称为“微服务管道连接管理器”。微服务管道连接管理器被实施为可执行指令，所述可执行指令被编程并且驻留在存储器和/或非暂态计算机可读(处理器可读)存储介质内，并且由设备的一或多个处理器执行。执行微服务管道连接管理器的设备的处理器被专门配置和编程为处理微服务管道连接管理器。微服务管道连接管理器在其处理期间可访问一个或多个网络连接。网络连接可以是有线的、无线的或有线与无线的组合。

在一个实施方案中，执行设备微服务管道连接管理器的设备为服务器130。在一个实施方案中，服务器130是通过作为云处理环境(云)的网络逻辑协作的若干服务器之一。

在一个实施方案中，微服务管道连接管理器是133至135的全部或某种组合。

在210处，微服务管道连接管理器在与多个平台相关联的MS之间建立内存内连接。

在一个实施方案中，在211处，微服务管道连接管理器在2MS或2个以上的MS之间建立内存内连接。

在一个实施方案中，在212处，微服务管道连接管理器创建与用于内存内连接的MS相关联的地址或标识符之间的内存内映射。在一个实施方案中，地址或标识符是特定于线程或特定于处理上下文的。

在212的实施方案中并且在213处，微服务管道连接管理器为每个MS分配通信端口以在内存内连接期间使用，并且微服务管道连接管理器将每个MS的端口分配添加到内存内映射。

在213的实施方案中并且在214处，微服务管道连接管理器为插件添加插件标识符，并且选择性地将插件标识符与MS相关联。此外，微服务管道连接管理器为内存内映射内的选择性的MS添加插件分配。

在220处，微服务管道连接管理器在内存内连接期间从与第一平台相关联的发送MS接收消息。

在214和220的一个实施方案中，在221处，当消息出现在如内存内映射的端口分配中所定义的与发送MS相关联的指定端口上时，微服务管道连接管理器监测与端口分配相关联的通信端口并且标识发送MS。

在230处，微服务管道连接管理器调用与至少一个第二平台相关联的至少一个插件，以将消息的第一格式转换为消息的至少一个第二格式。

在221和230的实施方案中，在231处，微服务管道连接管理器将接收MS标识为与端口分配相关联的其余端口，所述其余端口不是如内存内映射的端口分配中定义的与发送MS相关联的分配端口。

在231的实施方案中并且在232处，微服务管道连接管理器从内存内映射获得每个接收MS的对应的插件标识符。

在240处，微服务管道连接管理器通过内存内连接将第二格式的消息路由到与第二平台相关联的至少一个接收MS。

在232和240的实施方案中，在241处，微服务管道连接管理器获得作为来自插件的输出的第二格式的消息，并且通过对应的其余端口将第二格式的消息提供给对应的接收MS。

在一个实施方案中，在250处，当在交易终端(POS终端、ATM、SST或信息亭)上发起交易时，发起和处理微服务管道连接管理器。

在250的实施方案中并且在251处，微服务管道连接管理器提供用于交易期间MS之间的交互的内存内连接，以便为交易提供以下各项中的一个或多个：交易服务、安全服务、预订服务、金融服务、支付服务和忠诚度服务。

图3是根据示例性实施方案的用于多平台微服务连接技术的另一种方法300的图。实施方法300的软件模块被称为“微服务间通信路由器”。微服务间通信路由器被实施为可执行指令，所述可执行指令被编程并且驻留在存储器和/或非暂态计算机可读(处理器可读)存储介质内，并且由设备的一或多个处理器执行。执行微服务间通信路由器的处理器被专门配置和编程为处理微服务间通信路由器。微服务间通信路由器在其处理期间可访问一个或多个网络连接。网络连接可以是有线的、无线的或有线与无线的组合。

在一个实施方案中，执行微服务间通信路由器的设备为服务器130。在一个实施方案中，服务器130为逻辑上协作为云处理环境(云)的多个服务器之一。

在一个实施方案中，微服务间通信路由器为133至135和/或方法200的全部或某种组合。

微服务间通信路由器呈现了另一种与上面参考图2和方法200相比以某种方式增强的处理视角。

在310处，微服务间通信路由器通过与第一平台相关联的内存内连接和与一个或多个第二平台相关联的一个或多个接收MS从发送MS接收消息。

在一个实施方案中，在311处，微服务间通信路由器检测通过分配给用于内存内连接的发送MS的第一端口呈现的消息。

在320处，微服务间通信路由器将消息从第一格式转换为对应于接收MS的一个或多个第二格式。

在311和320的实施方案中，在321处，微服务间通信路由器调用可从与消息的内存内连接访问的自定义插件，并且接收作为来自插件的输出的第二格式的消息。

在321的实施方案中并且在322处，微服务间通信路由器基于接收MS的与接收MS相关联的标识符而选择性地调用插件。

在330处，微服务间通信路由器通过内存内连接将对应的第二格式的消息路由到对应的接收MS。

在322和330的实施方案中，在331处，微服务间通信路由器通过被分配给用于内存内连接的对应的接收MS的一个或多个第二端口将对应的第二格式的消息提供给对应的接收MS。

在一个实施方案中，在332处，微服务间通信路由器将第一格式的消息路由到与内存内连接相关联的至少一个附加的接收MS。

在一个实施方案中，微服务间通信路由器通过向对平台和硬件不可知或与平台和硬件无关的微服务提供相互通信，在交易期间处理并且通过处理向交易终端提供一个或多个服务。

应当理解，以特定形式(诸如组件或模块)描述软件仅为了辅助理解，且并非旨在限制实施那些功能的软件可被架构或构建的方式。例如，虽然模块被示出为单独的模块，但可实施为同源代码、实施为个别组件，这些模块中的一些但并非所有可以进行组合，或所述功能可以在以任何其他方便方式构建的软件中实施。

此外，尽管软件模块示出为在一件硬件上执行，但软件可跨越多个处理器或以任何其他方便方式分布。

以上描述是说明性且非限制性的。所属领域的技术人员在查阅以上描述后将会明白许多其他实施方案。因此，实施方案的范围应参考随附的权利要求书连同此些权利要求书有权拥有的等效物的完整范围加以确定。

在实施方案的前述描述中，出于简化本公开的目的而将各种特征一并归到单个实施方案中。这种公开方法不应理解为反映所要求实施方案的特征比各权利要求中明确表述的特征要多。实际上，如所附权利要求书所反映，本发明主题在于单个公开实施方案的不到全部的特征。因此，以下权利要求书在此并入具体实施方式，其中每项权利要求自身代表单独的示范性实施方案。

Claims (20)

1.一种方法，包括：

使用内存内映射在不同的平台的微服务之间提供内部通信，所述内存内映射包括用于所述微服务的端口分配和插件以处理所述内部通信；

从第一平台的第一微服务接收内部通信消息；以及

使用所述内存内映射将所述内部通信消息路由到第二平台的第二微服务并且激活所述第二平台的特定插件。

2.如权利要求1所述的方法，其中接收还包括监测端口并基于来自所述内存内映射的特定端口来标识尝试发送所述内部通信消息的所述第一微服务。

3.如权利要求2所述的方法，其中路由还包括基于来自所述内存内映射的所述特定端口来标识所述特定插件和所述第二微服务。

4.如权利要求3所述的方法，其中路由还包括响应于所述内部通信消息从所述特定插件接收输出并将所述输出递送至所述第二微服务。

5.如权利要求3所述的方法，其中路由还包括以第一格式将所述内部通信消息提供到所述特定插件，从所述特定插件接收第二格式的所述内部通信消息，以及将所述第二格式的所述内部通信消息提供到所述第二微服务。

6.如权利要求1所述的方法，还包括将所述微服务之间的所述内部通信作为通过云处理环境提供的单个服务来提供和管理，其中每个微服务提供所述单个服务的至少一个操作或至少一个功能。

7.如权利要求6所述的方法，其中提供和管理还包括将所述单个服务作为交易服务、忠诚度服务、预订服务、支付服务或安全服务来提供。

8.如权利要求7所述的方法，其中提供所述单个服务还包括当所述单个服务在交易终端上发起时激活来自所述云处理环境的所述单个服务。

9.如权利要求8所述的方法，其中激活还包括将所述交易终端作为自动柜员机、自助服务终端、销售点终端或信息亭来标识。

10.如权利要求1所述的方法，其中提供还包括维护每个微服务和给定微服务的每个线程或实例的唯一标识符来标识每个微服务和用于访问与所述内存内映射相关联的给定端口的所述给定微服务的每个线程或实例。

11.如权利要求1所述的方法，其中路由还包括基于所述内存内映射激活一个或多个附加的插件。

12.一种方法，包括：

提供在不同的处理环境内进行处理的微服务，每个微服务能在不同的环境内作为单独的实例或单独的线程进行处理，每个微服务和每个微服务对应的单独的实例或单独的线程中的任一者处理从云处理环境提供的单个服务的至少一个操作或至少一个功能；

维护每个微服务和每个微服务对应的单独的实例或单独的线程中的任一者的唯一标识符；

维护用于微服务间通信的所述微服务之间的映射；以及

使用所述映射在处理来自所述云处理环境的所述单个服务期间路由所述微服务间通信。

13.如权利要求12所述的方法，其中维护所述映射还包括基于所述唯一标识符维护所述映射内的用于所述微服务间通信的端口分配。

14.如权利要求13所述的方法，其中维护所述映射还包括维护插件以在所述微服务间通信期间激活，以用于所述映射内的所述端口分配。

15.如权利要求14所述的方法，其中维护所述映射还包括维护用于所述映射内的所述微服务间通信的具有多个插件的至少一个端口分配。

16.如权利要求12所述的方法，其中提供还包括当所述单个服务从终端调用时发起在所述不同的处理环境内的所述微服务和给定微服务的任何实例或线程。

17.如权利要求16所述的方法，其中发起还包括将所述终端标识为正被启动的自动柜员机、正被启动的自助服务终端、正被启动的销售点终端或正被启动的信息亭。

18.如权利要求12所述的方法，还包括将来自所述云处理环境的所述单个服务作为交易服务、安全服务、预订服务、金融服务、支付服务或忠诚度服务来提供。

19.一种系统，包括：

至少一个服务，所述至少一个服务包括至少一个处理器；

所述至少一个处理器执行指令以使得所述至少一个处理器执行操作，所述操作包括：

提供在不同的处理环境内进行处理的微服务，每个微服务执行交易服务的至少一个操作或至少一个功能；

向交易终端提供对云处理环境上的所述交易服务的访问；

发起用于在所述交易终端上发起的交易的所述微服务；

在用于所述交易的所述微服务的操作期间维护用于微服务间通信的内存内映射；以及

使用所述内存内映射在所述交易期间路由所述微服务间通信以代表来自所述云处理环境的所述交易终端作为所述交易服务来处理所述交易。

20.如权利要求19所述的系统，其中所述交易终端是自动柜员机、自助服务终端、销售点终端和信息亭中的一个或多个。