Method, System, and Program for Managing Communication between Microservices

Abstract

The present invention provides a method, system, and program for managing communication between microservices, by monitoring traffic between multiple microservices, determining a nature of the traffic, and relocating each of the multiple microservices from its individual origin resource to a shared resource based on the determined nature of the monitored traffic.

Description

Technical Field

[0001] The present invention generally relates to communication between microservices, and more particularly to the management of communication between multiple microservices.

Background Art

[0002] Conventional microservices are a software development technique, specifically a variant of the structural style of service-oriented architecture (SOA) that prepares an application as a set of services. Therefore, microservices (i.e., microservice architecture) use a cloud-native architecture approach in which a single application is composed of many loosely coupled, independently deployable small-scale components or services. These services usually have their own stack including a database and a data model, and communicate with each other through a combination of representational state transfer application programming interface (REST API), event streaming, and message broker. Services are also usually organized by business capability, and the lines separating services are often called bounded contexts.

[0003] Micro-services deployed in a cloud environment typically communicate with each other using cloud APIs. Such APIs are typically implemented as REST calls such as HyperText Transfer Protocol (HTTP) REST calls. For simple REST functionality, most of the processing required to service this functionality involves the marshalling, sending, and unmarshalling of requests used to make the API calls. Marshalling refers to the process of converting the memory representation of an object into a data format suitable for storage or transmission, which is typically used when data has to move between different parts of a computer program / service or from one program / service to another. Unmarshalling refers to unpacking a data format by converting it back to its original memory representation.

[0004] Servicing the functionality may also involve encrypting and decrypting the API calls when they are made over the network. As a result, most of the processing executed to make an HTTP REST function call is performed by extra or indirect or both computing time, memory, bandwidth, or other resources required to execute the task (i.e., computing overhead), rather than using application logic.

[0005] Cloud applications can minimize network traffic by restricting the nodes on which pods (i.e., objects representing a set of running containers within a cluster) can be scheduled based on the labels associated with the nodes, using node (i.e., worker machines in a cloud environment) affinity. However, the overhead of marshaling and unmarshaling data to / from HTTP messages remains. Additionally, the security requirements of an organization may require that HTTP traffic pass through the network encrypted as HyperText Transfer Protocol Secure (HTTPS), which further increases the necessary processing overhead. SUMMARY OF THE INVENTION

[0006] The present invention attempts to provide a computer-implemented method for managing communication between a plurality of microservices.

[0007] The present invention further attempts to provide a computer program product including computer program code for implementing the method proposed to be executed by a processing unit.

[0008] The present invention also attempts to provide a processing system configured to execute this computer program code.

[0009] The present invention also attempts to provide a system for managing communication between a plurality of microservices.

[0010] According to one aspect of the present invention, a computer-implemented method is provided. The method includes monitoring traffic between a plurality of microservices to determine the nature of the traffic. The method includes relocating each of the plurality of microservices from its individual origin resource to a shared resource based on the determined nature of the monitored traffic.

[0011] According to yet another aspect of the present invention, a computer system is provided. The system includes a monitoring unit configured to monitor traffic among a plurality of microservices and determine the nature of the traffic. The system further includes a relocation unit configured to relocate each of the plurality of microservices from its respective origin resource to a shared resource based on the determined nature of the monitored traffic.

[0012] According to another aspect of the present invention, a computer program product is provided. The computer program product includes a computer-readable storage medium having program instructions embodied therewith, and the program instructions executable by a processing unit cause the processing unit to implement a method according to the proposed embodiments.

[0013] According to another aspect of the present invention, a processing system is provided that includes at least one processor and a computer program product according to an embodiment. The at least one processor is configured to execute the computer program code of the computer program product.

[0014] Next, by way of mere example, preferred embodiments of the present invention will be described with reference to the following drawings.

Brief Description of the Drawings

[0015]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Embodiments for Carrying Out the Invention

[0016] It should be understood that the drawings are only schematic and not drawn to scale. It should also be understood that the same reference numerals are used throughout the drawings to indicate the same or similar parts.

[0017] In the context of the present application where embodiments of the present invention constitute a method, it should be understood that such a method can be a process for execution by a computer, that is, a computer-implemented method. Therefore, the various steps of the method may reflect various parts of a computer program, for example, various parts of one or more algorithms.

[0018] Also, in the context of the present application, the system may be a single device or a set of distributed devices configured to execute one or more embodiments of the method of the present invention. For example, the system may be a personal computer (PC), a server or a set of PCs, or a server connected via a network such as a local area network or the Internet, or a combination thereof, for cooperatively executing at least one embodiment of the method of the present invention.

[0019] Concepts for managing communication between multiple microservices are proposed. Such concepts can optimize microservices as autonomous load-responsive transport and topology operations. Thus, embodiments can facilitate dynamic reduction of processing overhead for communication between multiple microservices based on the actual performance of the application, rather than requiring changes to the application. Embodiments can further facilitate the automatic migration of microservices around a cluster.

[0020] Such concepts can involve the concept of taking microservices "down" and "up" (i.e., shutting down and restarting the microservices), while reconfiguring the microservices. Microservices may use APIs common to communication between microservices, which can be reconfigured based on network traffic moving between microservices. By reconfiguring the microservices, communication can be exchanged between HyperText Transfer Protocol Secure (HTTPS), HyperText Transfer Protocol (HTTP), inter-process communication, and direct function call communication.

[0021] Embodiments may be implemented in conjunction with an API layer for abstracting a function call between services, a monitoring service (i.e., a monitoring unit) that monitors traffic occurring on the generated APIs, and a configuration service (i.e., a rearrangement unit) that reconfigures how services communicate while taking the services "down" and "up". The API layer may be generated as documentation including interface specifications in another high-level specification language. The generated API layer can include multiple APIs and may be used for calls between services. The generated APIs can automatically report usage (i.e., traffic) to the monitoring service.

[0022] Embodiments may be further implemented in conjunction with the concept of generating REST calls as an API layer and the concept of analyzing the resulting inter-service traffic within a distributed microservices environment running within a cloud environment. If a significant amount of traffic movement between services is identified, the microservices may be reconfigured by shutting down and starting microservices closer to each other (or scaling down and scaling up).

[0023] The proposed embodiments can adopt the concept of adapting services to use a specifically generated API layer instead of making direct REST calls. As a result, the generated API layer can change how API calls are made. By relocating services to the same machine, the processes of encryption and decryption can be removed from communication. Relocating services to the same container can change communication to inter-process calls. Relocating services to the same process can change communication to plain function calls. In each case, the services can be treated as "black boxes" so that the specific information requirements for each service are reduced.

[0024] Embodiments of the present invention recognize that information from messages being sent between microservices is obtained and then used to redistribute each of the microservices (e.g., by reducing the distance required for microservice - to - microservice communication). Thus, embodiments of the present invention can bring such microservices closer together by moving them from their original resources (i.e., origin resources) to resources shared by the microservices (i.e., shared resources). By sharing resources, embodiments of the present invention reduce the complexity of microservice - to - microservice communication, based on information obtained from the communication. As such, information that does not require a complex method of microservice - to - microservice communication can be transmitted by a simpler distributed technique by bringing the microservices closer together.

[0025] Proposed embodiments may further adopt the concept of moving two or more containers into a single shared pod, or the concept of moving two or more microservices into a shared container, or both, in order to use inter - process communication instead of using the network when two or more microservices interact frequently.

[0026] In proposed embodiments, rearranging each of a plurality of microservices may include restarting the microservices with shared resources and shutting down the microservices at their origin resources, for each of the plurality of microservices. In this way, the plurality of microservices may be brought closer together such that the resources used by each of the plurality of microservices are shared across the plurality of microservices as a whole. Consequently, this can reduce the processing overhead required for communication between the plurality of microservices, and the efficiency of the communication may be improved.

[0027] In some embodiments, relocating each of a plurality of microservices involves reconfiguring inter-microservice communication by gathering the plurality of microservices from their respective individual origin resources to shared resources. In this way, the communication may be reconfigured to reduce the processing overhead associated with a microservice invoking the function of another microservice among the plurality of microservices.

[0028] In the proposed embodiments, the nature of the traffic to be monitored may include at least one of the amount of data moving between a plurality of microservices, the type of data moving between a plurality of microservices, and the flow rate of data moving between a plurality of microservices. In this way, the scope of the various natures of the monitored traffic used to determine whether to relocate each of the plurality of microservices may be increased. As a result, the information regarding the monitored traffic used as a basis for relocating each of the plurality of microservices is enhanced, and thus the effectiveness and reliability of relocating each of the plurality of microservices based on the determined nature of the monitored traffic may be improved.

[0029] In some embodiments, at least one of the origin resources and the shared resources may include virtual resources. In this way, the microservices may be located within a cloud environment, which can improve availability and ease of recovery in the event of software failures. This may further enable improving the centralization of microservice management and the compatibility between applications. Additionally, this enables improving the utilization of hardware by reducing the amount of physical equipment used, thereby reducing labor costs, power, and cooling, and by reducing hardware sharing by virtual machines to idle equipment.

[0030] In some embodiments, the virtual resource may include one of a node, a pod of nodes, a container, a pod of containers, a process, and a process of a container. In this way, the communication between multiple microservices may be reconfigured by relocating the multiple microservices closer to each other. The various virtual resources used by each of the multiple microservices can represent a series of abstractions with reduced latency as the multiple microservices move closer. By relocating the multiple microservices from separate origin resources to shared virtual resources, the amount of processing overhead required for communication between microservices can be reduced.

[0031] In some embodiments, reconfiguring each of the multiple microservices may include determining whether the nature of the monitored traffic satisfies a predetermined requirement. The step may further include, in response to the nature of the monitored traffic satisfying the predetermined requirement, relocating each of the multiple microservices from its individual origin resource to a shared resource. In this way, the ease of control for reconfiguring each of the multiple microservices can be improved. As a result, the efficiency and reliability of relocating each of the multiple microservices from its individual origin resource to a shared resource can be enhanced.

[0032] In some embodiments, the predetermined requirement may include at least one of the amount of data being equal to or greater than a predetermined threshold, the type of data being a predetermined type, and the flow rate of the data being equal to or greater than a predetermined threshold. In this way, the scope of the various predetermined requirements used to determine whether to reconfigure each of the multiple microservices may be broadened. As a result, the effectiveness and reliability of reconfiguring each of the multiple microservices based on the determined nature of the monitored traffic may be improved.

[0033] In the proposed embodiment, monitoring traffic among a plurality of microservices may include receiving requests communicated among the plurality of microservices and then monitoring the traffic associated with the received requests. In this way, the traffic among the plurality of microservices may be monitored based on the received requests communicated among the plurality of microservices. This enables the collection of information necessary for monitoring traffic to be directly collected from the source of the traffic (i.e., the requests communicated among the plurality of microservices). As a result, the reliability and efficiency of monitoring traffic may be improved.

[0034] In some embodiments, relocating each of a plurality of microservices may include, for each of the plurality of microservices, maintaining a first instance of the microservice at its origin resource, restarting a second instance of the microservice on shared resources, and shutting down the second instance of the microservice at its origin resource. In this way, each of the plurality of microservices may be relocated temporarily, rather than permanently or requiring further relocation to return the microservice to its origin resource. Additionally, each of the plurality of microservices may be relocated with respect to its interaction (i.e., communication) with a first microservice without affecting its interaction with a second microservice. As a result, this reduces the time and processing required to relocate each of the plurality of microservices, and thus the efficiency of relocating each of the plurality of microservices may be improved.

[0035] FIG. 1 is a diagrammatic representation of an exemplary distributed system that can implement aspects of the exemplary embodiments. The distributed system 100 may include a network of computers that can implement aspects of the exemplary embodiments. The distributed system 100 includes at least one network 102, which is a medium used to provide communication links between various devices and computers interconnected within the distributed data processing system 100. The network 102 may include connections such as wired, wireless communication links, or fiber optic cables.

[0036] In the example depicted, the first server 104 and the second server 106 are connected to the network 102 along with the storage unit 108. Additionally, clients 110, 112, and 114 are also connected to the network 102. The clients 110, 112, and 114 may be, for example, personal computers, network computers, and the like. In the example depicted, the first server 104 provides data such as boot files, operating system images, and applications to the clients 110, 112, and 114. The clients 110, 112, and 114 are clients to the first server 104 in the example depicted. The distributed processing system 100 may include additional servers, clients, and other devices not shown.

[0037] In the example depicted, the distributed system 100 is the Internet with a network 102 representing a worldwide collection of networks and gateways that communicate with each other using the Transmission Control Protocol / Internet Protocol (TCP / IP) suite of protocols. The core of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational, and other computer systems that route data and messages. Of course, the distributed system 100 may also be implemented to include multiple different types of networks, such as, for example, an intranet, a local area network (LAN), a wide area network (WAN), etc. As described above, FIG. 1 is intended as an example, not as an architectural limitation on various embodiments of the present invention, and thus the specific elements shown in FIG. 1 should not be considered as limitations regarding the environment in which exemplary embodiments of the present invention are implemented.

[0038] FIG. 2 is a block diagram of an exemplary system 200 that can implement aspects of the exemplary embodiments. System 200 is an example of a computer, such as client 110 of FIG. 1, that can have instructions disposed thereon that implement a computer-usable code or process for exemplary embodiments of the present invention. For example, system 200 may be configured to implement a monitoring unit and a relocation unit in accordance with an embodiment.

[0039] In the example illustrated, system 200 employs a hub architecture that includes a North Bridge and Memory Controller Hub (NB / MCH) 202, as well as a South Bridge and Input / Output (I / O) Controller Hub (SB / ICH) 204. A processing unit 206, a main memory 208, and a graphics processor 210 are connected to the NB / MCH 202. The graphics processor 210 may be connected to the NB / MCH 202 through an Accelerated Graphics Port (AGP).

[0040] In the illustrated example, the local area network (LAN) adapter 212 is connected to the SB / ICH 204. The audio adapter 216, the keyboard and mouse adapter 220, the modem 222, the read-only memory (ROM) 224, the hard disk drive (HDD) 226, the CD-ROM drive 230, the universal serial bus (USB) ports and other communication ports 232, and the PCI / PCIe devices 234 are connected to the SB / ICH 204 through the first bus 238 and the second bus 240. Examples of PCI / PCIe devices include, for example, an Ethernet (R) adapter, an add-in card, and a PC card for a notebook computer. PCI uses a card bus controller, while PCIe does not. The ROM 224 may be, for example, a flash basic input / output system (BIOS).

[0041] The HDD 226 and the CD-ROM drive 230 are connected to the SB / ICH 204 through the second bus 240. The HDD 226 and the CD-ROM drive 230 can use, for example, an integrated drive electronics (IDE) or a serial advanced technology attachment (SATA) interface. The super I / O (SIO) device 236 may be connected to the SB / ICH 204.

[0042] The operating system is executed by the processing unit 206. The operating system realizes control by causing various components within the system 200 of FIG. 2 to cooperate. As the client, the operating system may be a commercially available operating system. An object-oriented programming system such as the Java(R)(TM) programming system may be executed in conjunction with the operating system, and a call is given to the operating system from a Java(R)(TM) program or application being executed in the system 200.

[0043] As the server, the system 200 may be, for example, an IBM(R) eServer(TM) System p(R) computer system executed by an Advanced Interactive Executive (AIX(R)) operating system or a LINUX(R) operating system. The system 200 may be a symmetric multi-processor (SMP) system including a plurality of processors within the processing unit 206. Alternatively, a single-processor system may be employed.

[0044] Instructions for the operating system, programming system, and application or program may be arranged in a storage device such as the HDD 226 and loaded into the main memory 208 for execution by the processing unit 206. Similarly, one or more message processing programs according to one embodiment may be configured to be stored by the storage device or the main memory 208 or both.

[0045] The process for an exemplary embodiment of the present invention may be implemented by the processing unit 206 using computer-usable program code arranged in a memory such as the main memory 208, ROM 224, or one or more peripheral devices 226 and 230.

[0046] A bus system, such as the first bus 238 or the second bus 240 shown in FIG. 2, may include one or more buses. Of course, the bus system can be implemented using any type of communication fabric or architecture that realizes data transfer between different components or devices attached to the communication fabric or architecture. A communication unit, such as the modem 222 or the network adapter 212 in FIG. 2, may include one or more devices used for transmitting and receiving data. Examples of memory include main memory 208, ROM 224, or a cache such as that in the NB / MCH 202 in FIG. 2.

[0047] Those skilled in the art will understand that the hardware in FIGS. 1 and 2 may vary depending on the implementation form. In addition to or instead of the hardware illustrated in FIGS. 1 and 2, other internal hardware or peripheral devices such as flash memory, equivalent non-volatile memory, or an optical disk drive may be used. Also, the processes of the exemplary embodiments may be applied to multi-processor data processing systems other than the aforementioned systems without departing from the spirit and scope of the present invention.

[0048] Furthermore, the system 200 may take any form of several different data processing systems, including client computing devices, server computing devices, tablet computers, laptop computers, telephones or other communication devices, personal digital assistants (PDAs), etc. In some of the illustrated examples, the system 200 may be a portable computing device composed of flash memory so as to realize non-volatile memory for storing, for example, an operating system file or user-generated data or both. Therefore, the system 200 may essentially be any known or later-developed data processing system without architectural limitations.

[0049] Next, referring to FIG. 3, a flowchart of a computer-implemented method for managing communication between multiple microservices is depicted.

[0050] Step 310 includes monitoring the traffic between multiple microservices and determining the nature of the traffic.

[0051] Here, step 310 includes steps 312 and 314. Step 312 includes receiving requests communicated between multiple microservices. Step 314 includes monitoring the traffic associated with the received requests.

[0052] Specifically, the nature of the monitored traffic includes at least one of the amount of data moving between multiple microservices, the type of data moving between multiple microservices, and the flow rate of data moving between multiple microservices.

[0053] Step 320 includes reallocating each of the multiple microservices from its individual origin resources to shared resources based on the determined nature of the monitored traffic.

[0054] In this embodiment, step 320 includes steps 322 and 324. Step 322 includes determining whether the nature of the monitored traffic satisfies a predetermined requirement. Step 324 includes reallocating each of the multiple microservices from its individual origin resources to shared resources in response to the nature of the monitored traffic satisfying a predetermined requirement.

[0055] As an example, the predetermined requirement includes at least one of the amount of data being equal to or greater than a predetermined threshold, the type of data being a predetermined type, and the flow rate of data being equal to or greater than a predetermined threshold.

[0056] Step 320 includes restarting the microservices with shared resources and shutting down the microservices with their original resources, for each of the plurality of microservices.

[0057] In this embodiment, step 320 further includes reconfiguring the communication between the plurality of microservices by gathering the plurality of microservices from their respective original resources to shared resources.

[0058] In this embodiment, step 320 includes maintaining a first instance of the microservice with its original resources, restarting a second instance of the microservice with shared resources, and shutting down the second instance of the microservice with its original resources, for each of the plurality of microservices. For example, multiple instances of the plurality of microservices are executed in different modes. Each instance of the plurality of microservices is relocated from its respective original resources to shared resources. In one example, a first instance of a first microservice and an instance of a second microservice are in the same process, but a second instance of the first microservice remains alone in a separate node to share the load of service requests from a third microservice. In another example, the interaction between services is represented by routes. Route AB includes a route from microservice A to microservice B, and route CB includes a route from microservice C to microservice B. In this example, route AB is heavily used (i.e., includes a high level of traffic), and route CB is less used (i.e., includes a low level of traffic). In this scenario, a second instance of microservice B is restarted with shared resources with microservice A and shut down with its original resources. The first instance of microservice B (i.e., the original instance) is left (i.e., maintained) in its original resources so that route CB is not affected.

[0059] Here, at least one of the origin resource and the shared resource includes a virtual resource.

[0060] As an example, the virtual resource includes one of a node, a pod of a node, a container, a container of a pod, a process, and a process of a container. For example, two microservices on two separate nodes are shut down and restarted on a shared node. In another example, two microservices on the same node can be shut down and brought up inside a shared pod. In another example, two microservices on the same pod are shut down and can be brought up in a shared container as two processes. In another example, two microservices in two separate processes can be shut down and brought up inside a shared process.

[0061] For example, the list of virtual resources disclosed above represents a series of abstractions where resources are placed close to each other, thus reducing latency. In one example, communication between two microservices placed on two separate nodes includes network traffic between separate servers. In one example, communication between two microservices placed in two separate containers includes network traffic on a shared server. In one example, communication between two microservices placed in two separate processes includes an inter-process call. In one example, communication between two microservices placed in a shared process includes a direct call. The degree to which the microservices are relocated depends on the infrastructure of the cloud environment and the runtime of the microservices (i.e., whether the microservices include a managed, dynamic, or compiled runtime).

[0062] In another embodiment, the individual origin resources of each of the plurality of microservices include the shared origin resources of the plurality of microservices. In this example, the plurality of microservices were previously unavailable, and now each of the plurality of microservices is expanded by relocating from its individual origin resources (i.e., the shared origin resources of the plurality of microservices that were previously unavailable) to shared resources (i.e., shared destination resources). For example, the shared resources include the origin resources of the plurality of microservices. As such, the plurality of microservices are distributed from the origin resources shared by the plurality of microservices to the shared resources where at least one of the plurality of microservices was previously located.

[0063] Referring now to FIG. 4, a simplified block diagram of an exemplary embodiment of a system for managing communication between a plurality of microservices is depicted.

[0064] The system includes a monitoring unit 410 configured to monitor traffic between the plurality of microservices to determine the nature of the traffic. The system further includes a relocation unit 420 configured to relocate each of the plurality of microservices from its individual origin resources to shared resources based on the determined nature of the monitored traffic.

[0065] Here, the monitoring unit 410 includes a receiving unit 412 configured to receive requests communicated between the microservices. The monitoring unit 410 is further configured to monitor the traffic associated with the received requests.

[0066] By way of example, the nature of the monitored traffic includes at least one of the amount of data moving between the plurality of microservices, the type of data moving between the plurality of microservices, and the flow rate of data moving between the plurality of microservices.

[0067] Here, the relocation unit 420 includes a restart unit 422 configured to restart a microservice with shared resources and shut down the microservice with its origin resources for each of the plurality of microservices.

[0068] The relocation unit 420 includes a reconfiguration unit 424 configured to reconfigure the communication between the plurality of microservices by gathering the plurality of microservices from their respective individual origin resources to shared resources.

[0069] In this embodiment, the relocation unit 420 is further configured to determine whether the nature of the monitored traffic satisfies a predetermined requirement, and in response to the nature of the monitored traffic satisfying the predetermined requirement, relocate each of the plurality of microservices from its individual origin resources to shared resources.

[0070] As an example, the predetermined requirement includes at least one of the amount of data being equal to or greater than a predetermined threshold, the type of data being a predetermined type, and the data flow rate being equal to or greater than a predetermined threshold.

[0071] In this embodiment, the restart unit 422 is further configured to maintain a first instance of the microservice with its origin resources, restart a second instance of the microservice with shared resources, and shut down the second instance of the microservice with its origin resources for each of the plurality of microservices.

[0072] Specifically, at least one of the origin resources and the shared resources includes virtual resources.

[0073] As an example, the virtual resources include one of a node, a pod of the node, a container, a container of the pod, a process, and a process of the container.

[0074] Next, referring to FIGS. 5(A) to 5(E), a simplified block diagram of an example of communication between a plurality of microservices is depicted.

[0075] In one example, service A520 and service B522 provide two different microservices within an application distributed within a container orchestration system. Service A520 frequently calls service B522 over a published application programming interface (API), such as OpenAPI. Both service A520 and service B522 are implemented as open source, cross-platform runtime environments as applications. The application is built on a standard-based operating system (OS) image in a file that includes multiple layers used to execute code within a container, that is, the operating system, executable files, and any data files related to programs on the operating system (e.g., system images, disk images, or process images). Once built, the application is deployed as a container within a pod in a container orchestration system.

[0076] During development, Service A520 is developed (i.e., generated) using an application programming interface generated from the published application programming interface definition of Service B522 (e.g., an OpenAPI definition). In one embodiment, this is generated by a scaffolding tool for client-side web applications to create a package manager that can later be included in Service A520 as a normal dependency. The generated code of Service A520 handles calls from Service A520 to Service B522. The generated code determines an appropriate transport based on at least one of build-time settings parameters, deployment-time settings parameters, and runtime settings parameters. For example, at build time, both Service A520 and Service B522 are packaged in the same container. For example, at deployment time, container instances are started using settings parameters (e.g., environment variables) that specify which of Service A520 and Service B522 is started by an instance. For example, at runtime, instances of both Service A520 and Service B522 report their loads to the monitoring unit 410.

[0077] Figure 5(A) depicts the inter-node communication between Service A520 and Service B522. For the services to communicate between nodes 510, Service A520 is at the first node 510 and Service B522 is at the second node 510. Hypertext Transfer Protocol (HTTP) includes message marshalling, encryption, networking, decryption, and unmarshalling between Service A520 and Service B522. Figure 5(B) depicts the inter-pod communication (i.e., intra-node communication) between Service A520 and Service B522. For the services to communicate between pods 512, Service A520 is at the first pod 512 and Service B522 is at the second pod 512. Both pods are within the same node 510. Hypertext Transfer Protocol (HTTP) includes message marshalling, encryption, decryption, and unmarshalling between Service A520 and Service B522. Figure 5(C) depicts the inter-container communication (i.e., intra-pod communication) between Service A520 and Service B522. For the services to communicate between containers 514, Service A520 is at the first container 514 and Service B522 is at the second container 514. Both containers 514 are within the same pod 512. Hypertext Transfer Protocol (HTTP) includes message marshalling and unmarshalling between Service A520 and Service B522. Figure 5(D) depicts the inter-process communication (i.e., intra-container communication) between Service A520 and Service B522. For the services to communicate between processes, Service A520 is at the first process and Service B522 is at the second process. Both processes are within the same container 514. Hypertext Transfer Protocol is not involved in inter-process communication. Figure 5(E) depicts the in-process function call between Service A520 and Service B522. For the services to communicate within the shared process, Service A520 and Service B522 are within the shared process.Hypertext Transfer Protocol is not involved in inter-process communication.

[0078] When the load on the entire container orchestration system changes, the way Service A520 and Service B communicate changes (i.e., by the relocation unit 420). For example, the communication changes from inter-pod communication using Transport Layer Security (TLS) (Figure 5(B)) to intra-pod communication between containers without using TLS (Figure 5(C)). As a result, the overhead required to encrypt and decrypt messages is no longer needed and is saved.

[0079] In another example, individual containers are instructed to start and stop their in-process instances of Service A520 and Service B522. Since Service A520 and Service B522 are both packaged within a shared container, the running instance of Service A520 can start its own instance of Service B522 so that it changes from making an actual function call (Figure 5(E)) because the API layer makes an HTTP REST call.

[0080] In one example, the monitoring unit counts API calls, uses sophisticated known metrics such as profiling or other instrumentation, or both, to report communication-related processing overhead (i.e., monitors traffic between multiple microservices to determine the nature of the traffic). The rearrangement unit uses heuristic techniques to determine how to organize the services. For example, the rearrangement unit has rules regarding whether to prioritize overall response time, minimize the number of containers in use, or maintain how many independent instances for redundancy to reduce the memory charges to be billed. Such techniques can be defined as different profiles. For example, a development profile is defined that scales the number of containers in use to a minimum value when running on a local system of a software developer.

[0081] As a further example, as illustrated in FIG. 6, an embodiment may include a computer system 70, which may form part of a networked system 7. For example, the rearrangement unit is implemented by the computer system 70. The components of the computer system / server 70 can include one or more processing arrangements, including, but not limited to, a processor or processing unit 71, a system memory 74, and a bus 90 that couples various system components including the system memory 74 to the processing unit 71.

[0082] System memory 74 can include a computer system readable medium in the form of volatile memory such as random access memory (RAM) 75 or cache memory 76 or both. Computer system / server 70 can further include other removable / non-removable, volatile / non-volatile computer system storage media. In such instances, each can be connected to bus 90 by one or more data media interfaces. Memory 74 can include at least one program product having a set (e.g., at least one) of program modules configured to execute the functions of the proposed embodiments. For example, memory 74 may include a computer program product having a program executable by processing unit 71 that causes the system to execute a method for managing communication between multiple microservices.

[0083] A program / utility 78 having a set (e.g., at least one) of program modules 79 may be stored in memory 74. Program modules 79 generally execute the functions or methods or both of the proposed embodiments for managing communication between multiple microservices.

[0084] The computer system / server 70 can also communicate with one or more external devices 80 such as a keyboard, a pointing device, a display 85, one or more devices that enable a user to interact with the computer system / server 70, or any device that enables the computer system / server 70 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.), or a combination thereof. Such communication can be performed via an input / output (I / O) interface 72. Additionally, the computer system / server 70 can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet) via a network adapter 73 or a combination thereof (e.g., for communicating the recreated content to a system or a user).

[0085] In the context of the present application, although embodiments of the present invention constitute a method, it should be understood that such a method is a process for computer execution, that is, a computer-implemented method. Thus, the various steps of the method reflect the various parts of a computer program, such as the various parts of one or more algorithms.

[0086] The present invention may be a system, a method, or a computer program product or a combination thereof. The computer program product can include a computer-readable storage medium having computer-readable program instructions for causing a processor to execute aspects of the present invention.

[0087] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing, without limitation. A non-exhaustive listing of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), storage class memory (SCM), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy (R) disk, mechanically encoded devices such as punch cards or structures engraved in grooves in which instructions are recorded, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium shall not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through an electrical wire.

[0088] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a separate computing / processing device or to an external computer or an external storage device via a network, such as, for example, the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. Each computing / processing device's network adapter card or network interface receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within the separate computing / processing device.

[0089] The computer-readable program instructions for carrying out the operations of the present invention may be written in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or object-oriented programming languages such as Smalltalk(R), C++, and conventional procedural programming languages such as the "C" programming language or similar programming languages, and may be either source code or object code. The computer-readable program instructions may be executed entirely on the user's computer, partly on the user's computer as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may implement aspects of the present invention by utilizing the state information of the computer-readable program instructions to execute the computer-readable program instructions to customize the electronic circuit.

[0090] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0091] These computer-readable program instructions, when executed via a processor of a computer or other programmable data processing apparatus, are provided to the processor of the general purpose computer, special purpose computer, or other programmable data processing apparatus to create a means for implementing the functions / operations specified in one or more blocks of a flowchart, a block diagram, or both, and thus may make a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium storing instructions for a manufacturing article that includes the computer-readable storage medium storing instructions for implementing the aspects of the functions / operations specified in one or more blocks of a flowchart, a block diagram, or both, such that the computer, programmable data processing apparatus, or other device or combination thereof is instructed to function in a particular manner.

[0092] The computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other device to create a computer-implemented process such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / operations specified in one or more blocks of a flowchart, a block diagram, or both, by performing a series of operational steps on the computer, other programmable data processing apparatus, or other device.

[0093] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram can represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions shown in the blocks may occur in a different order than shown in the drawings. For example, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may be executed in the reverse order depending on the functions involved. It should also be noted that each block of the block diagram or flowchart diagram, or both, and combinations of blocks of the block diagram or flowchart diagram, or both, can be implemented by a special purpose hardware-based system that performs the specified function or operation, or that executes a combination of special purpose hardware and computer instructions.

[0094] The various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, practical application, or technical improvement over technologies found in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for computer information processing, comprising: determining the nature of traffic by monitoring the traffic among a plurality of microservices in response to receiving a request for communication among the plurality of microservices; relocating each of the plurality of microservices from its respective origin resource to a shared resource based on the determined nature of the monitored traffic; relocating each of the plurality of microservices comprises, for each of the plurality of microservices, maintaining a first instance of the microservice at its origin resource, restarting a second instance of the microservice on the shared resource, and shutting down the second instance of the microservice at its origin resource; the plurality of instances of the plurality of microservices are executed in different modes, a first instance of a first microservice among the plurality of microservices and an instance of a second microservice among the plurality of microservices are in the same process, and a second instance of the first microservice remains at the origin resource of the second instance to share the load of service requests from a third microservice among the plurality of microservices; A method comprising the above steps.

2. Relocating each of the plurality of microservices comprises: for each of the plurality of microservices, restarting the microservice on the shared resource and shutting down the microservice at its origin resource. The method according to claim 1, comprising the above steps.

3. Relocating each of the plurality of microservices comprises: reconfiguring the communication among the plurality of microservices by gathering the plurality of microservices from their respective origin resources to the shared resource. The method according to claim 1, comprising the above steps.

4. The nature of the monitored traffic includes at least one of: the amount of data moving among the plurality of microservices, the type of the data moving among the plurality of microservices, and the flow rate of the data moving among the plurality of microservices. The method according to claim 1, comprising the above steps.

5. The method according to claim 1, wherein at least one of the origin resource and the shared resource includes a virtual resource.

6. The virtual resource is a node, a pod of a node, a container, a container of a pod, a process, and a process of a container The method according to claim 5, including one of them.

7. Relocating each of the plurality of microservices is determining whether the nature of the monitored traffic satisfies a predetermined requirement, and in response to the nature of the monitored traffic satisfying the predetermined requirement, relocating each of the plurality of microservices from its respective origin resource to the shared resource The method according to claim 1, including.

8. The predetermined requirement is the amount of data is equal to or greater than a predetermined threshold, the type of the data is a predetermined type, and the flow rate of the data is equal to or greater than a predetermined threshold The method according to claim 7, including at least one of them.

9. Monitoring the traffic between the plurality of microservices is receiving a request communicated between the plurality of microservices, and monitoring the traffic associated with the received request The method according to claim 1, including.

10. A computer program for causing a computer to execute the method according to any one of claims 1 to 9.

11. A storage medium storing the computer program according to claim 10 in a computer-readable storage medium.

12. A computer system that executes the method according to any one of claims 1 to 9 by computer hardware.

Images