Multi-platform microservice connection technology

Abstract

Inter-microservice communication is managed through in-memory connection routing. A sending microservice writes a message through a port associated with the connection. The message is routed directly to one or more receiving microservices that are associated with the connection through their ports associated with the connection. As the message is received through the sending microservice port, and before the message is routed through the receiving microservice port, the message can be transformed through a plugin of processing into a different format or multiple different formats. The inter-microservice communication is hardware and platform agnostic or un-aware, such that the microservices associated with the connection can be processed on different hardware and different platforms from each other.

Description

[0001] This application is a divisional application of Chinese invention patent application filed on June 28, 2021, with application number 202110724138.6 and invention title "Multi-platform microservice connection technology". Background Technology

[0002] Microservices are associated with a computing architecture that builds a single application / service as a loosely coupled collection of services. This allows each microservice within a single application / service to be deployed independently, even when the overall single application / service is complex. Microservices are also easier to maintain and test. Each microservice provides fine-grained functionality associated with a part of the single application / service. Each microservice is loosely coupled with other microservices because the dependencies between microservices associated with the single application / service are smaller and significantly less coupled / dependent than the coupling / dependencies between microservices associated with the original functionality of the original single application / service.

[0003] It is not surprising that enterprises are migrating their application / service architectures and newly offered services to deliver them to their customers as microservices over the web.

[0004] One challenge with microservices is the ability to enable fast and efficient communication between them, because what were previously single applications or services executing on a single device are now a series of individual services, each capable of executing on different devices across the network. Therefore, microservice communication can span multiple devices over the network, while a single monolithic application / service communicates within the memory of a single device.

[0005] Therefore, microservices typically utilize pipe-based communication, which opens up in-memory connections between microservices on a server / device, where data can be read, written, and routed between microservices.

[0006] The problem with existing pipelining utilities is that they are platform-specific (e.g., OS-specific), meaning that two microservices that need to communicate with each other must be handled simultaneously on the same platform. Another problem with existing pipelining utilities is that a pipe can only handle one data format with a single plugin. That is, any data format changes between microservices must be handled by a pipe with a single plugin invoked within the memory pipe; this single plugin transforms the message in the format sent by the microservice into the desired format for the receiving microservice. Therefore, existing pipelining utilities are platform-specific and message data format conversion-specific because only a single plugin can be used on any given instantiated pipe on a server / device.

[0007] This is an industry issue for any enterprise looking to migrate to a microservices architecture, as enterprises may have many different platforms and many different applications or data formats that they need to leverage to deliver their services to their customers effectively and efficiently. Summary of the Invention

[0008] Various implementation schemes present methods and systems for multi-platform microservice connectivity technologies.

[0009] According to one implementation, a method for multi-platform microservice connectivity is presented. For example, an in-memory connection is established between microservices associated with multiple platforms. During the connection, a message is received from a sending microservice associated with a first platform. At least one plugin associated with at least one second platform is invoked to convert the message from a first format to at least one second format. The message in the at least one second format is routed to at least one receiving microservice associated with the at least one second platform via the in-memory connection. Attached Figure Description

[0010] Figure 1A This is a diagram of a system for multi-platform microservice connectivity technology according to an exemplary implementation.

[0011] Figure 1B This is an illustration based on an exemplary implementation. Figure 1A A diagram of the system's processing flow.

[0012] Figure 2 This is a diagram of a method for multi-platform microservice connectivity technology according to an exemplary implementation.

[0013] Figure 3 This is a diagram of another method for multi-platform microservice connectivity technology according to an exemplary implementation. Detailed Implementation

[0014] Figure 1A This is a diagram of a system 100 for multi-platform microservice connectivity technology according to an exemplary embodiment. It should be noted that the components are shown schematically in a greatly simplified form, with only those components relevant to understanding the embodiment shown.

[0015] Furthermore, for illustrative purposes only, various components (identified in Figure 1) are shown and their arrangement is illustrated. It should be noted that other arrangements with more or fewer components are possible without departing from the teachings of multi-platform microservice connectivity presented herein and below.

[0016] As will be discussed in more detail below, System 100 allows for inter-microservice communication across multiple different platforms (e.g., operating systems (OS), virtual machines (VMs), containers, etc.) via in-memory routing. This is fast and efficient. Furthermore, each message sent can be transformed into any desired or required custom output between microservices through multiple plugins.

[0017] System 100 is presented within the context of the transaction services provided to transaction terminal 142 during the transaction. This is one of many potential applications in the retail industry, presented for illustrative purposes only; it should be noted that other applications may also be used, such as, but not limited to, financial applications, travel applications, hotel applications, restaurant applications, and so on.

[0018] As discussed herein and below, a “microservice” is one or more functions / operations separated from a specific service. A specific service consists of multiple functions / operations defined by multiple microservices that collaborate with each other to provide the overall functionality / operation of the specific service. A specific service may be a transaction service, loyalty service, reservation service, payment service, and / or security service. A specific service is processed or initiated by a point-of-sale (POS) terminal, self-service terminal (SST), automated teller machine (ATM), and / or kiosk. A specific service is decomposed into loosely coupled operations comprising collaborating microservices. Each microservice may be processed on the same or different computing devices as the rest of the combination of microservices. Each device processing one or more microservices within a microservice may be a server, VM, container, terminal initiating the specific service, or any other computing device. In this way, the functionality / operation of a specific service is distributed by collaborating microservices across multiple devices, the same devices, or a combination of these devices. Furthermore, each microservice may execute natively on the same or different platforms as the rest of the microservices within a microservice. In this way, microservices are device and platform independent or agnostic to devices and platforms.

[0019] System 100 includes 1 to N devices (110, 120), server 130, and transaction terminal 140. Each of 110, 120, 130, and 140 includes a corresponding processor (111, 121, 131, and 141) and a corresponding non-transitory computer-readable storage medium (112, 122, 132, and 142), the corresponding non-transitory computer-readable storage medium having executable instructions for OS1 113, microservice (MS)1 114, MS2 115, OS N 123, MS N 124, MS N+1 124, pipeline connection manager 133, plug-in 1 134, plug-in N 135, and transaction manager / agent 143. When the corresponding processors (111, 121, 131, and 141) execute the corresponding executable instructions from the corresponding media (112, 122, 132, and 142), this causes the corresponding processors (111, 121, 131, and 141) to perform the operations discussed herein and below for OS1 113, Microservices (MS)1 114, MS2 115, OS N 123, MS N 124, MS N+1 124, Pipeline Connection Manager 133, Plugin 1 134, Plugin N 135, and Transaction Manager / Agent 143.

[0020] Transaction terminal 140 provides one or more services for transactions initiated on terminal 140. Each service includes some combination of MSs (114, 115, 124, and / or 125). For example, a transaction may include security services, transaction services, loyalty services, and payment services. In order to provide operation for each service, multiple MSs (114, 115, 124, and / or 125) need to communicate with each other. That is, messages are sent as output between MSs (114, 115, 124, and / or 125), and other messages are read as input by MSs (114, 115, 124, and / or 125).

[0021] The pipe connection manager 133 establishes and manages in-memory pipe connections between MSs (114, 115, 124, and / or 125) from server 130 during a transaction. The pipe connection manager 133 receives messages written through the port of the writing MS established for a given connection and routes the write messages directly to the port of the receiving MS established for the given connection. The pipe connection manager 133 can manage in-memory connections as 1-1 connections, 1-to-many connections, and / or many-to-many connections between MSs (114, 115, 124, and / or 125).

[0022] The pipe connection manager 133 maintains a unique identifier for each instance or thread of each MS (114, 115, 124, and 125). During a given connection, a port number is assigned to each unique identifier for communication. The pipe connection manager 133 maintains an in-memory map or database that allows for the rapid discovery of the port numbers required for a given connection. In this way, when a sending MS (114, 115, 124, and 125) writes output to the connection, that output is quickly routed to the appropriate receiving MS (114, 115, 124, and 125) via the port associated with the connection. Furthermore, the in-memory map or database can identify plugin identifiers (134 and / or 135) for required plugins. The pipe connection manager 133 invokes any plugins (134 and / or 135) required by a particular receiving MS (114, 115, 124, and 125) during the connection. The output of any invoked plugin (134 and / or 135) includes the raw output message generated by the sending MS (114, 115, 124, and 125), which has been converted or transformed from the original data format associated with the output message to a different data format. The different data formats generated by each invoked plugin (134 and / or 135) represent the target data format required by the corresponding receiving MS (114, 115, 124, and 125). The output from any invoked plugin (134 and / or 135) is routed by the pipe connection manager 133 to the appropriate port number that the corresponding receiving MS is listening on during the transaction.

[0023] Traditionally, existing pipe-based utilities can only invoke a single plugin. System 100 allows the integration of 1, 2, or N plugins (134 to 135), where N is any desired number of plugins without an upper limit.

[0024] Furthermore, the pipe connection manager 133 is OS-agnostic, meaning that some MSs (114 and 115) can utilize a first OS 1113 associated with a first type of OS, while other MSs (124 and 125) can utilize a second OS N associated with a second type of OS. The different OSs 113 and 123 can have different types, or they can have the same type but different forms / versions of the same type of OS. It should be noted that in some cases and implementations, OS1 113 and OS N 123 can have the same type and form / version as the OS. In this way, the platform of the MSs (114, 115, 124, and 125) is agnostic, and the pipe connection manager 133 can establish and manage connections between the MSs (114, 115, 124, and 125) regardless of the platform associated with each MS (114, 115, 124, and 125).

[0025] In one implementation, the pipe connection manager 133 is written in code as follows The script can run on any existing OS platform and is extensible through a community-based npm repository. Only the pipe connection manager needs to be added to the registry settings of server 130 once. Adding plugins (134 and 135) can be handled via the config.json file as follows:

[0026]

[0027] System 100 allows simultaneous acceptance and application of multiple plugins (134 and 135) for inter-platform MS communication. New plugins (134 or 135) can be easily added. In one implementation, a command-line interpreter is provided that enables the sending of test messages from the command prompt to test message transmission between MSs (114, 115, 124, and 125). In one implementation, a configurable post-load command is provided that can be invoked after any test message is sent, allowing for script customization using the results of the test messages.

[0028] Figure 1B This is an illustration based on an exemplary implementation. Figure 1A The system's processing flow is shown in Figure 150.

[0029] Transaction manager / agent 143 initiates a transaction on terminal 140 for a specific service or set of services required for the transaction. This causes multi-platform pipeline connection manager 131 to instantiate instances of the required MSs (114, 115, 124, 125), each instance having a unique TCP / IP address or identifier, which is maintained in memory by the pipeline connection manager 131 in an in-memory mapping or in-memory database, which assigns port numbers for communication with each of the MSs (114, 115, 124, and 125) having each address or identifier. As each MS (114, 115, 124, and 125) processes to deliver the specific service or set of services for the transaction, output messages generated by each MS (114, 115, 124, and 125) are sent through the connection maintained by the pipeline connection manager 131. The output messages are written to memory through the ports assigned to each sending MS (114, 115, 124, and 125). The pipe connection manager 131 utilizes an in-memory database or mapping to route output messages to the corresponding ports of the receiving MSs (114, 115, 124, and 125). Before routing to the receiving MSs (114, 115, 124, and 125), any plugins used to transform the output message format are invoked. Plugins (133 and 134) can include a gRPC plugin, a socket_IO plugin, a redis plugin, a REST API plugin, or any custom plugin. Furthermore, the pipe connection manager 131 can integrate and invoke N plugins (133 and 134). There is no predefined upper limit to N.

[0030] It should be noted that Figure 1A The total number of MSs (114, 115, 124, and 125) presented herein is not intended to limit the implementations discussed herein. That is, a device may have only 1 MS, or a device may have N MSs. Furthermore, server 130 and / or terminal 140 may include some or all of the MSs. Moreover, the total number of devices required for the MSs (114, 115, 124, and 125) is for illustrative purposes only, as fewer or more devices may exist than depicted. It should be emphasized that the devices and platforms of the MSs (114, 115, 124, and 125) do not change the teachings presented herein, because managing inter-MS communication is hardware-independent and platform-independent of the implementations provided herein.

[0031] Now for reference Figures 2 to 3 Discuss these and other implementation schemes.

[0032] Figure 2This is a diagram of a method 200 for multi-platform microservice connectivity technology according to an exemplary embodiment. The software module implementing method 200 is referred to as a "microservice pipeline connection manager". The microservice pipeline connection manager is implemented as executable instructions, which are programmed and reside in memory and / or a non-transitory computer-readable (processor-readable) storage medium, and are executed by one or more processors of a device. The processor of the device executing the microservice pipeline connection manager is specifically configured and programmed to process the microservice pipeline connection manager. The microservice pipeline connection manager can access one or more network connections during its processing. The network connections can be wired, wireless, or a combination of wired and wireless.

[0033] In one implementation, the device that performs the device microservice pipeline connection manager is server 130. In one implementation, server 130 is one of several servers that logically collaborate as a cloud processing environment (cloud) over a network.

[0034] In one implementation, the microservice pipeline connection manager is all or some combination of 133 to 135.

[0035] At 210, the microservice pipeline connection manager establishes in-memory connections between MSs associated with multiple platforms.

[0036] In one implementation, at 211, the microservice pipeline connection manager establishes in-memory connections between 2MS or more MS.

[0037] In one implementation, at 212, the microservice pipeline connection manager creates an in-memory mapping between an address or identifier associated with the MS used for in-memory connections. In one implementation, the address or identifier is thread-specific or processing context-specific.

[0038] In the implementation at 212 and at 213, the microservice pipeline connection manager allocates a communication port for each MS to use during in-memory connections, and the microservice pipeline connection manager adds the port allocation for each MS to the in-memory mapping.

[0039] In the implementation at 213 and at 214, the microservice pipeline connection manager adds a plugin identifier to the plugin and selectively associates the plugin identifier with the MS. Furthermore, the microservice pipeline connection manager adds plugin assignments for selective MSs within the in-memory mapping.

[0040] At 220, the microservice pipeline connection manager receives messages from the sending MS associated with the first platform during in-memory connections.

[0041] In one implementation of 214 and 220, at 221, when a message appears on a specified port associated with the sending MS as defined in an in-memory mapped port allocation, the microservice pipeline connection manager monitors the communication port associated with the port allocation and identifies the sending MS.

[0042] At 230, the microservice pipeline connection manager invokes at least one plugin associated with at least one second platform to convert the first format of the message into at least one second format of the message.

[0043] In the implementations of 221 and 230, at 231, the microservice pipeline connection manager will receive the MS identified as the remaining port associated with the port allocation, which is not the allocated port associated with sending the MS as defined in the in-memory mapped port allocation.

[0044] In the implementation of 231 and at 232, the microservice pipeline connection manager obtains the corresponding plugin identifier for each receiving MS from the in-memory mapping.

[0045] At position 240, the microservice pipeline connection manager routes messages of the second format to at least one receiving MS associated with the second platform via in-memory connections.

[0046] In the implementations of 232 and 240, at 241, the microservice pipeline connection manager obtains a message in a second format as output from the plugin and provides the message in the second format to the corresponding receiving MS through the corresponding remaining ports.

[0047] In one implementation, at point 250, when a transaction is initiated on a transaction terminal (POS terminal, ATM, SST, or kiosk), the microservice pipeline connection manager is initiated and processed.

[0048] In implementation 250 and at 251, the microservice pipeline connection manager provides in-memory connections for interaction between MSs during a transaction, so as to provide one or more of the following for the transaction: transaction service, security service, reservation service, financial service, payment service, and loyalty service.

[0049] Figure 3This is a diagram of another method 300 for multi-platform microservice connectivity technology according to an exemplary embodiment. The software module implementing method 300 is referred to as a "microservice communication router". The microservice communication router is implemented as executable instructions, which are programmed and reside in memory and / or a non-transitory computer-readable (processor-readable) storage medium, and are executed by one or more processors of the device. The processor executing the microservice communication router is specifically configured and programmed to process the microservice communication router. The microservice communication router can access one or more network connections during its processing. The network connections can be wired, wireless, or a combination of wired and wireless.

[0050] In one implementation, the device that acts as the inter-microservice communication router is server 130. In one implementation, server 130 is one of multiple servers that logically cooperate as a cloud processing environment (cloud).

[0051] In one implementation, the inter-microservice communication router is 133 to 135 and / or all or some combination of method 200.

[0052] Inter-service communication routers present another approach compared to the one mentioned above. Figure 2 A processing perspective that is enhanced in some way compared to method 200.

[0053] At 310, the inter-service communication router receives messages from the sending MS via an in-memory connection associated with the first platform and one or more receiving MSs associated with one or more second platforms.

[0054] In one implementation, at point 311, the inter-microservice communication router detects messages presented via the first port assigned to the sending MS for in-memory connections.

[0055] At 320, the inter-microservice communication router converts the message from the first format to one or more second formats corresponding to the receiving MS.

[0056] In the implementations of 311 and 320, at 321, the inter-service communication router invokes a custom plugin accessible from the in-memory connection with the message and receives a message in a second format as output from the plugin.

[0057] In the implementation of 321 and at 322, the inter-microservice communication router selectively invokes plugins based on the identifier associated with the receiving MS.

[0058] At position 330, the inter-service communication router routes the corresponding second-format message to the corresponding receiving MS via an in-memory connection.

[0059] In embodiments 322 and 330, at 331, the inter-service communication router provides the corresponding receiving MS with a message of the corresponding second format through one or more second ports assigned to the corresponding receiving MS for in-memory connection.

[0060] In one implementation, at 332, the inter-service communication router routes messages of the first format to at least one additional receiving MS associated with the in-memory connection.

[0061] In one implementation, the inter-microservice communication router facilitates communication between microservices that are platform and hardware agnostic or independent of the platform and hardware, processes transactions during transactions, and provides one or more services to transaction endpoints through processing.

[0062] It should be understood that describing software in a specific form (such as components or modules) is merely for the purpose of aiding understanding and is not intended to limit how the software implementing those functions can be architected or constructed. For example, while a module may be shown as a separate module, it may be implemented as source code, as an individual component, some but not all of these modules may be combined, or the described functionality may be implemented in software constructed in any other convenient manner.

[0063] Furthermore, although the software module is shown to execute on a single piece of hardware, the software can be distributed across multiple processors or in any other convenient manner.

[0064] The above description is illustrative and non-limiting. Those skilled in the art will understand many other embodiments upon reviewing the above description. Therefore, the scope of the embodiments should be determined by referring to the complete scope of the appended claims together with the equivalents to which those claims are entitled.

[0065] In the foregoing description of the embodiments, various features have been grouped together into a single embodiment for the purpose of simplification. This method of disclosure should not be construed as reflecting more features of the claimed embodiments than those expressly stated in the claims. In fact, as reflected in the appended claims, the subject matter of the invention lies in less than all the features of a single disclosed embodiment. Therefore, the following claims are incorporated herein by reference, wherein each claim itself represents a separate exemplary embodiment.

Claims

1. A method for multi-platform microservice connectivity technology, comprising: In-memory mapping is used to provide internal communication between microservices on different platforms. The in-memory mapping includes port allocation and plugins for the microservices to handle the internal communication. Receive internal communication messages from the first microservice of the first platform; as well as The in-memory mapping is used to route the internal communication messages to a second microservice on the second platform and activate a specific plugin on the second platform.

2. The method of claim 1, wherein receiving further includes monitoring a port and identifying the first microservice attempting to send the internal communication message based on a specific port from the in-memory mapping.

3. The method of claim 2, wherein routing further includes identifying the specific plugin and the second microservice based on the specific port from the in-memory mapping.

4. The method of claim 3, wherein routing further includes receiving output from the specific plugin in response to the internal communication message and delivering the output to the second microservice.

5. The method of claim 3, wherein routing further includes providing the internal communication message in a first format to the specific plugin, receiving the internal communication message in a second format from the specific plugin, and providing the internal communication message in the second format to the second microservice.

6. The method of claim 1, further comprising providing and managing the internal communication between the microservices as a single service provided through a cloud processing environment, wherein each microservice provides at least one operation or at least one function of the single service.

7. The method of claim 6, wherein providing and managing further includes providing the individual service as a transaction service, loyalty service, booking service, payment service, or security service.

8. The method of claim 7, wherein providing the single service further comprises activating the single service from the cloud processing environment when the single service is initiated on the transaction terminal.

9. The method of claim 8, wherein activation further includes identifying the transaction terminal as an ATM, self-service terminal, point-of-sale terminal, or kiosk.

10. The method of claim 1, wherein providing further includes maintaining a unique identifier for each microservice and each thread or instance of a given service to identify each microservice and each thread or instance of a given microservice for accessing a given port associated with the in-memory mapping.

11. The method of claim 1, wherein the routing further includes activating one or more additional plugins based on the in-memory mapping.

12. A method for multi-platform microservice connectivity technology, comprising: Provide microservices that can be processed in different processing environments. Each microservice can be processed as a separate instance or a separate thread in different environments. Each microservice and its corresponding separate instance or separate thread can process at least one operation or at least one function of a single service provided from the cloud processing environment. Maintain a unique identifier for each microservice and either the individual instance or the individual thread corresponding to each microservice; Maintain in-memory mappings between the microservices for inter-microservice communication, wherein the in-memory mappings include port allocations and plugins for the microservices to handle inter-microservice communication; as well as The in-memory mapping is used to route inter-microservice communication during the processing of the individual service from the cloud processing environment.

13. The method of claim 12, wherein maintaining the in-memory mapping further includes maintaining port allocations within the in-memory mapping for inter-microservice communication based on the unique identifier.

14. The method of claim 13, wherein maintaining the in-memory mapping further includes maintaining a plugin to be activated during inter-microservice communication for use with the port allocation within the in-memory mapping.

15. The method of claim 14, wherein maintaining the in-memory mapping further comprises maintaining at least one port allocation with multiple plugins for inter-microservice communication within the in-memory mapping.

16. The method of claim 12, wherein the provision further includes initiating the microservice and any instance or thread of the given microservice within the different processing environment when the individual service is invoked from the terminal.

17. The method of claim 16, wherein initiation further includes identifying the terminal as an ATM being activated, a self-service terminal being activated, a point-of-sale terminal being activated, or an information kiosk being activated.

18. The method of claim 12, further comprising providing the individual service from the cloud processing environment as a transaction service, security service, reservation service, financial service, payment service, or loyalty service.

19. A system for multi-platform microservice connectivity technology, comprising: At least one service, wherein the at least one service includes at least one processor; The at least one processor executes instructions to cause the at least one processor to perform an operation, the operation including: Provide microservices that perform processing in different processing environments, each microservice performing at least one operation or at least one function of the transaction service; Provide the transaction terminal with access to the transaction service on the cloud processing environment; The microservice that initiates transactions on the transaction terminal; During the operation of the microservice used for the transaction, an in-memory mapping for inter-microservice communication is maintained, wherein the in-memory mapping includes port allocation and plugins for the microservice to handle the inter-microservice communication; and The in-memory mapping is used to route the inter-service communication during the transaction to process the transaction on behalf of the transaction terminal from the cloud processing environment as the transaction service.

20. The system of claim 19, wherein the transaction terminal is one or more of an ATM, a self-service terminal, a point-of-sale terminal, and an information kiosk.

Images