US20210208956A1 - Automated identification of service boundaries based on system focus optimization using distributed tracing data - Google Patents
Automated identification of service boundaries based on system focus optimization using distributed tracing data Download PDFInfo
- Publication number
- US20210208956A1 US20210208956A1 US17/083,168 US202017083168A US2021208956A1 US 20210208956 A1 US20210208956 A1 US 20210208956A1 US 202017083168 A US202017083168 A US 202017083168A US 2021208956 A1 US2021208956 A1 US 2021208956A1
- Authority
- US
- United States
- Prior art keywords
- application request
- service
- request message
- type
- services
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000005457 optimization Methods 0.000 title claims abstract description 6
- 238000000034 method Methods 0.000 claims abstract description 23
- 238000012545 processing Methods 0.000 claims description 15
- 230000004044 response Effects 0.000 abstract description 39
- 238000003860 storage Methods 0.000 description 17
- 230000008569 process Effects 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 238000012546 transfer Methods 0.000 description 6
- 238000011161 development Methods 0.000 description 4
- ZLIBICFPKPWGIZ-UHFFFAOYSA-N pyrimethanil Chemical compound CC1=CC(C)=NC(NC=2C=CC=CC=2)=N1 ZLIBICFPKPWGIZ-UHFFFAOYSA-N 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 238000012384 transportation and delivery Methods 0.000 description 3
- 230000002411 adverse Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/147—Signalling methods or messages providing extensions to protocols defined by standardisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
Definitions
- SMA Software microservices architecture
- SOA service-oriented architecture
- software service design, development, delivery, and deployment are based on modules that each may be developed and deployed as independent systems.
- the modules in the SOA therefore, offer the benefit of software agility because each module may be developed, deployed, and operated independently from other modules. Additionally, versioning and scaling of the modules based on changed requirements may be addressed independently without affecting other modules.
- SMA is a collection of loosely coupled services.
- the loosely coupled services may use protocols that are lightweight. Since each service is a module capable of being developed and deployed independently, the SMA may improve parallel development. Thus, it reduces time from lab to market.
- the SMA often requires various services to communicate over a network using protocols such as hypertext transfer protocol (HTTP), etc. Therefore, the performance of the network and the microservices may be adversely affected due to network latency and message processing time in comparison with services implemented as a monolithic service process. Accordingly, if services were deployed without reviewing how various services interact with each other, a messaging overhead over the network and network latency would severely degrade the network performance. Thus, it is important to know which microservices should be coupled together and which microservices should be decoupled to reduce the messaging overhead and network latency to increase performance of the microservices and the network.
- HTTP hypertext transfer protocol
- FIG. 1 illustrates an exemplary microservices flow in software microservices architecture, in accordance with some embodiments.
- FIG. 2 illustrates an exemplary microservices development flow, in accordance with some embodiments.
- FIG. 3 illustrates a flow chart of method steps for automatic identification of service boundaries based on system optimization using distributed tracing data, in accordance with some embodiments.
- FIG. 4 illustrates an exemplary computer system, in accordance with some embodiments.
- SMA software microservices architecture
- FIG. 1 illustrates an exemplary microservices flow in software microservices architecture, in accordance with some embodiments.
- exemplary software microservices architecture (SMA) 100 may include microservices 102 a , 102 b , 102 c , and 102 d .
- the SMA 100 shown in FIG. 1 is exemplary and does not limit the number of microservices.
- Each microservice of the microservices 102 a - 102 d may be assigned a service-id.
- the service-id identifies the microservice in the SMA.
- the microservices 102 a , 102 b , 102 c , and 102 d may be assigned service-ids Service 126 a , Service 126 b , Service 126 c , and Service 126 d respectively.
- the service-ids 126 a - 126 d may be numeric or alphanumeric.
- a microservice is a module implementing business functionality with interfaces to communicate with other microservices as well as entities outside the SMA network.
- the microservices are loosely coupled services, with each microservice providing or implementing a different functionality. Therefore, a first microservice may be a client of a second microservice where the first microservice is provided a service by the second microservice.
- a second microservice may provide database related services. Accordingly, any microservice that may require access to the database would be a client of the second microservice.
- a call flow i.e., a flow of messages exchanged between a client sending a request message to a microservice of the SMA and receiving a response from the microservice of the SMA would also include messages exchanged between the microservices of the SMA. Therefore, each microservice in a call flow may be identified based on the service-id assigned to the microservice, when the messages exchanged between the microservices include service-id information in the messages.
- microservices 102 a - 102 d may be implemented using different programming languages and may use different infrastructure.
- the microservices 102 a - 102 d may use various mechanisms or protocols to communicate with each other.
- the microservices may use hypertext transfer (HTTP) protocol.
- HTTPS hypertext transfer
- HTTPS secure version of the HTTP protocol
- the microservices may use the HTTP/HTTPS protocol to exchange web services messages using, for example, service oriented architecture protocol (SOAP), representational state transfer (REST), etc.
- SOAP service oriented architecture protocol
- REST representational state transfer
- messages exchanged between the microservices using the SOAP/REST over the HTTP/HTTPS protocol may have various headers that may identify a source endpoint and a destination endpoint, a user agent, timestamp, a source and a destination IP address or a fully qualified domain name (FQDN) etc.
- FQDN fully qualified domain name
- microservices in SMA, many microservices together provide a required service or functionality. Therefore, the microservices providing the required service or functionality may be either grouped together or distributed to achieve the best performance. In some embodiments, the microservices are called together. If the client device is required to make multiple requests to collect complete information from the microservices, it may result in inefficient and slow network performance. This is because making multiple network round trips is more time consuming and error prone than making a single request. Further, aggregating the results from multiple service requests requires additional time and computing resources. Accordingly, if the microservices share common entities, the microservices may be grouped together in order to provide better bulk processing capabilities.
- the microservice should be split to improve response time.
- the microservices may be grouped together or distributed and may be installed on one or more servers. In other words, not all microservices required for the service or functionality may be required to be installed or deployed on a single server. The microservices may be distributed to achieve best performance.
- one or more microservices may be designated as a gateway microservice.
- the gateway microservice may provide one or more endpoints to which a client device may send a request message to receive a service provided by the microservices.
- the one or more endpoints then may process the received request message to forward one or more messages to other microservices.
- the one or more messages to the other microservices may be generated by the gateway microservice based on the received request message from the client device.
- the client device may be a smart phone, a mobile phone, a laptop, a tablet, a personal computer, a desktop, a server, etc.
- the microservices may be installed, for example, on a web server or an application server.
- the web server or the application server may be an Apache Tomcat server, a WebLogic server, etc.
- an application request message 110 may be originated from a client device (not shown in FIG. 1 ) and received at the microservice service 102 a .
- the microservice 102 a may be a gateway service and may provide one or more endpoints to receive application request messages from client devices.
- a gateway service is a microservice between client devices sending application request messages to the microservices of the SMA.
- Application request messages from the client devices to the gateway service are received via a channel, which may have two or more endpoints.
- An endpoint is thus controlled by the microservice to which it is connected. Characteristics of the endpoint may include schema of the messages being received or sent through the endpoint, and an address such as an IP address used to receive or send messages.
- the application request message 110 may be a web service message according to Service Oriented Architecture Protocol (SOAP), or Representational State Transfer (REST).
- SOAP Service Oriented Architecture Protocol
- REST Representational State Transfer
- the application request message may also use hypertext transfer protocol (HTTP) or hypertext transfer protocol secure (HTTPS).
- HTTP hypertext transfer protocol
- HTTPS hypertext transfer protocol secure
- Application request message 110 using the HTTP, HTTPS, SOAP, and/or REST may include various message headers, for example, Host, Content-Type, Content-Length, etc. Accordingly, the application request message 110 may include various headers. Additionally, new headers may also be added to the messages that are being exchanged between various microservices and with the client devices.
- An example of a request message and a response message with various headers, including the TraceId header, is shown below.
- a portion of an exemplary HTTP request message is shown below.
- a new customized header, TraceId may be added to the message while sending the HTTP request message to other microservices.
- a portion of an exemplary HTTP response message is shown below.
- a new customized header, TraceId may be added to the message while sending the HTTP response message to other microservices and/or the client devices.
- the application request message 110 from the client device may be received at one endpoint of the one or more endpoints of the microservice service 102 a .
- the application request message 110 may include various headers as described above.
- the application request message 110 may include other data identifying a service requested by the client device from the SMA 100 .
- the gateway service i.e., the microservice service 102 a , may process the application request message 110 and identify that microservice 102 b may be invoked.
- the microservice service 102 a therefore may build another request message 112 based on the application request message 110 .
- the microservice service 102 a may add a new customized header to a client request message 112 .
- a new customized header named TraceId may be added to client request message 112 .
- the TraceId header's value may be set to an identification of the microservice that processed the application request message and/or the client request message.
- microservices may add the TraceId header while building a response message to the application request message and/or client request message with the value of the TraceId header set to the identification of the microservice.
- the microservice 102 a may add the TraceId header to the client request message 112 with the value set to an identification of the microservice 102 a 126 a to indicate that microservice 102 a is required for the service or functionality requested by the client device.
- the microservice service 102 b may process the client request message 112 .
- the microservice 102 c may be a service providing database related services. Accordingly, while processing the client request message 112 , if the microservice 102 b requires database related services, the microservice 102 b may invoke the microservice 102 c . Accordingly, the microservice 102 b may build a client request message 114 to send to the microservice 102 c . The client request message 114 may therefore be based on the client request message 112 .
- the microservice 102 b may include TraceId header 112 a with its value from the client request message 112 in the client request message 114 , and also update the value of the TraceId header in the client request message 114 to further include identification of the microservice 102 b 126 b .
- the TraceId header 114 a may have a value set to “ServiceId1,ServiceId2” in the client request message 114 .
- the identification of the microservice 102 a 126 a and the identification of the microservice 102 b 126 b may be comma separated.
- the microservice 102 c may process the client request message 114 and return a client response message 116 to the microservice 102 b .
- the microservice 102 c may include TraceId header from the client request message 114 in the response message 116 .
- the TraceId header 116 a in the client response message 116 may therefore include the identification of the microservice 102 a 126 a and the identification of the microservice 102 b 126 b .
- the microservice 102 c may further include the identification of the microservice 102 c 126 c in the client response message 116 .
- the microservice 102 b may extract value of the TraceId header 116 a from the client response message 116 , which may include the identification of the microservices 102 a , 102 b , and 102 c , which are 126 a , 126 b , and 126 c .
- the microservice 102 b may build the client response message 122 that may include the TraceId header with its (not shown in FIG.
- the client response message 122 may then be forwarded to the microservice service 102 a.
- the microservice 102 a may determine that for the particular service or functionality requested corresponding to the application request message 110 , microservices 102 a , 102 b , and 102 c are required services.
- the microservice 102 b may determine, upon receipt of the client response message 116 , that the microservice 102 d is required to be invoked in accordance with a business logic or functionality provided by the microservice 102 b . Accordingly, the microservice 102 b may build a client request message 118 having a TraceId header 118 a with its value set to the value of the TraceId header from the client response message 116 . Because the identification of the microservice 102 b is already present in the value of the TraceId header, the identification of the microservice 102 b 126 b may not be added again to the TraceId header 118 a .
- the microservice 102 d may build a client response message 120 similar to the microservice 102 c . Therefore, similar to the microservice 102 c , the microservice 102 d may include TraceId header 120 a that may include the identification of the microservices 102 a , 102 b , 102 c , and 102 d , which are 126 a , 126 b , 126 c , and 126 d .
- the microservice 102 b may determine that no other microservice is further required to be invoked.
- the microservice 102 b may build the client response message 122 with the TraceId header 122 a with its value set to the identifications of the 102 a , 102 b , 102 c , and 102 d , which are 126 a , 126 b , 126 c , and 126 d .
- the microservice 102 a may therefore determine that for the particular service or functionality requested in the application request message 110 may requires services from the microservices 102 a , 102 b , 102 c , and 102 d .
- the microservice 102 a may then build the application response message 124 with TraceId header 124 a with its value set to the identifications 126 a , 126 b , 126 c , and 126 d.
- the microservice service 102 a may determine the microservices required to be invoked for each application client request message, which may or may not be similar to the application request message 110 .
- each client request message similar to the application request message 110 may differ in the values set for various headers of the application request message. Accordingly, the microservices which are required to provide services according to the application request messages may be deployed together and/or deployed on the same server, which may result in reduced latency and improved performance of the network and the SMA.
- the microservice 102 a may record messages sent to other microservices and received from the other microservices for later analysis to generate a deployment scheme.
- the messages may be recorded in a database or a log file.
- the recorded messages may be analyzed to generate the deployment scheme.
- the deployment scheme may be dependent on application specific criteria discussed below.
- FIG. 2 illustrates an exemplary microservices development flow, in accordance with some embodiments.
- microservices are loosely coupled modules that together provide service or functionality. Since microservices are modules, each module may be developed and deployed independently. Further, each module may be developed for a specific functionality; the modules may be developed faster and deployed faster because each module supports a small piece of the functionality provided by the modules as a collection, which is a substantial advantage of the SMA.
- modular or microservices design in SMA may be domain driven, and technology stack agnostic as shown in FIG. 2 .
- FIG. 2 illustrates four teams, a team A 202 a , a team B 202 b , a team C 202 c , and a team D 202 d are shown in FIG. 2 .
- the team A 202 a , the team B 202 b , the team C 202 c , and the team D 202 d may each be developing a microservice.
- each team 202 a , 202 b , 202 c , and 202 d may be developing one of the microservices from 102 a , 102 b , 102 c , and 102 d .
- Each team may include developers for developing the microservices using different technology, programming language, and/or a framework.
- the team A 202 a may have a sub-team 204 a developing microservices using the C programming language, a sub-team 204 b using the Java Script programming language, and sub-teams 204 c and 204 d using the Java programming language.
- the team B 202 b may have a sub-team 204 e developing microservices using Java Script, a sub-team 204 f using Scala and a sub-team 204 g using Python.
- the team C 202 c may have sub-teams 204 h using the Scala, 204 i and 204 j using the Java programming language, and 204 k using the Java Script programming language.
- the team D 202 d may have sub-teams 204 l , 204 m , and 2004 n using the Java programming language, Scala, and Scala respectively.
- the team C 202 c may depend on software delivery and/or an interface from the team A 202 a
- the team D 202 d may depend on software delivery and/or an interface from the teams A 202 a , B 202 b , and C 202 c . Since microservices are modules, each module or microservice may be scaled up/down independent of the other microservices, and may also be delivered and deployed independent of the other microservices.
- FIG. 3 illustrates a flow chart of method steps for automatic identification of service boundaries based on system optimization using distributed tracing data, in accordance with some embodiments.
- a first application request message may be received by a gateway service.
- the microservice 102 a may be the gateway service as described above.
- the first application request message may be similar to the application request message 110 described above.
- the first application request message being similar to the application request message 110 means that the headers and message content may be different and the value of the headers may be set according to the first application request message received at an endpoint of the gateway service.
- the endpoint is a channel via which the messages are communicated or exchanged between the client and the microservice.
- a first client request message based on the first application request message may be generated.
- the gateway service processes the first application request message according to the business logic corresponding to the requested service or functionality by the first application request message.
- the gateway service may determine that the requested service of functionality requires invocation of service from other microservice(s). Accordingly, the gateway service may generate the first client request message from the first application request message.
- the gateway service may add a new customized header in the first client request message.
- the new customized header may be named TraceId.
- the TraceId header may be set to a value of an identification of the gateway service. Accordingly, the TraceId header may indicate which microservices processed requests and responses corresponding to the first application request message.
- the first application request message and the first client request message may further be associated based on a unique identification.
- the first application request message may include a universal unique identifier (UUID) header.
- UUID universal unique identifier
- the value of the UUID header may uniquely identify the first application request message among plurality of similar other messages received at the endpoint of the gateway service. Accordingly, all request messages and response messages generated by various microservices may include the UUID header with the value set to the value of the UUID header in the first application request message.
- each microservices may record the request and response messages that were received and sent respectively.
- the messages may be recorded in a text file or in a database.
- the text file may be a log file. Accordingly, the messages may be recorded in the log file in the database, which may be local to the microservice or centralized. If the messages are recorded at a centralized database or logging system, the microservice may communicate to the centralized database or logging system over network interface using, for example, TCP/IP, UDP, and/or application programming interface (API) messages.
- TCP/IP Transmission Control Protocol
- UDP User Datagram Protocol
- API application programming interface
- the microservice may record the endpoint of the microservice at which the message is received, a source address, an incoming timestamp corresponding to receipt of the request, an outgoing timestamp corresponding to another request/response message, the UUID header value, the TraceId header value, etc.
- the gateway service may forward the first client request message to a first service of the plurality of services.
- the first service of the plurality of services may be the microservice service 102 b
- the first client request message may be the client request message 112 .
- the client request message 112 may include the TraceId header with its value set to the identification of the gateway service.
- the first service may process the received first client request message 112 .
- the microservice 102 b may determine that no other microservice is required to be invoked based on processing of the first client request message 112 .
- the microservice 102 b then may update the TraceId header value to add identification of the microservice 102 b , and may generate a first client response message 122 at step 310 .
- the microservice 102 b may include the updated TraceId header in the first client response message 122 .
- the first client response message 122 may then be sent by the microservice 102 b to the gateway service 102 a .
- the microservice 102 b may record the received first client request message 112 and the first client response message 122 sent from the microservice 102 b to the gateway service 102 a .
- the gateway service may receive the first client response, and as described above may record the received first client response.
- the gateway service 102 a may generate a deployment scheme for a subset of services of the plurality of services based on the TraceId header value of the first client response message 122 .
- the TraceId header value in the first client response may indicate all the microservices invoked in response to the receipt of the first application request message 110 .
- the deployment scheme may be generated based on application specific criteria as described below.
- the application specific criteria may recommend determining a set of services, which are common to a plurality of application request messages to be deployed together.
- the plurality of application request messages comprise messages of a first application request message type and a second application request message type
- the microservices which are commonly invoked by the first application request message type and the second application request message type may be deployed together.
- the message type may be associated with a service or functionality. Therefore, messages from various client devices requesting the service or the functionality may generate messages that may have similar message structure, but the value assigned to the headers may be different based on the client device requesting the service or the functionality.
- the application specific criteria may recommend determining a set of microservices being called together corresponding to the first application request message to be deployed together.
- the application specific criteria may recommend determining a message load over a configurable time period for a set of services, and generating a recommendation that the set of service be deployed according to the message load over the configurable time period. If the particular set of services is being invoked for all the messages received at endpoints of the gateway service, and which for example consumes substantial processing power, deploying such service with other services may adversely affect performance of the other services. Accordingly, specification of a server, i.e., CPU, memory, and other specification, may be considered in generating a recommendation of how the services may be deployed.
- the endpoint is a channel via which a microservice may exchange messages with the client devices and/or other microservices.
- the microservice may disclose a plurality of endpoints at which requests from the client devices and other microservices may be received. If it may be identified by the gateway service, based on the analysis of the recorded request messages and response by various microservices, at least one endpoint of the plurality of endpoints does not share common resource with other endpoints, the deployment scheme may be generated which may recommend that the at least one endpoint be decoupled from the other endpoints of the plurality of endpoints.
- the application specific criteria thus may include updating the set of services together and/or deploying the set of service together.
- FIG. 4 illustrates an example of a computer system, in accordance with some embodiments.
- FIG. 4 Various embodiments may be implemented, for example, using one or more well-known computer systems, such as a computer system 400 as shown in FIG. 4 .
- One or more computer systems 400 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.
- the computer system 400 may include one or more processors (also called central processing units, or CPUs), such as a processor 404 .
- the processor 404 may be connected to a communication infrastructure or bus 406 .
- the computer system 400 may also include user input/output device(s) 403 , such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 406 through user input/output interface(s) 402 .
- user input/output device(s) 403 such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 406 through user input/output interface(s) 402 .
- processors 404 may be a graphics processing unit (GPU).
- a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications.
- the GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.
- the computer system 400 may also include a main or primary memory 408 , such as random access memory (RAM).
- Main memory 408 may include one or more levels of cache.
- Main memory 408 may have stored therein control logic (i.e., computer software) and/or data.
- the computer system 400 may also include one or more secondary storage devices or memory 410 .
- the secondary memory 410 may include, for example, a hard disk drive 412 and/or a removable storage device or drive 414 .
- the removable storage drive 414 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.
- the removable storage drive 414 may interact with a removable storage unit 418 .
- the removable storage unit 418 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data.
- the removable storage unit 418 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/any other computer data storage device.
- the removable storage drive 414 may read from and/or write to removable storage unit 418 .
- the secondary memory 410 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by the computer system 400 .
- Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 422 and an interface 420 .
- Examples of the removable storage unit 422 and the interface 420 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
- the computer system 400 may further include a communication or network interface 424 .
- the communication interface 424 may enable the computer system 400 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 428 ).
- the communication interface 424 may allow the computer system 400 to communicate with the external or remote devices 428 over communications path 426 , which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from the computer system 400 via the communication path 426 .
- the computer system 400 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.
- PDA personal digital assistant
- the computer system 400 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on-premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.
- “as a service” models e.g., content as a service (CaaS), digital content as a service (DCaaS), software as
- Any applicable data structures, file formats, and schemas in the computer system 400 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination.
- JSON JavaScript Object Notation
- XML Extensible Markup Language
- YAML Yet Another Markup Language
- XHTML Extensible Hypertext Markup Language
- WML Wireless Markup Language
- MessagePack XML User Interface Language
- XUL XML User Interface Language
- a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device.
- control logic software stored thereon
- control logic when executed by one or more data processing devices (such as the computer system 400 ), may cause such data processing devices to operate as described herein.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Debugging And Monitoring (AREA)
Abstract
Description
- This application is a Continuation Application of U.S. patent application Ser. No. 16/699,917, filed on Dec. 2, 2019, the contents of which are incorporated herein in their entirety.
- Software microservices architecture (SMA) is a variant of service-oriented architecture (SOA). In SOA, software service design, development, delivery, and deployment are based on modules that each may be developed and deployed as independent systems. The modules in the SOA, therefore, offer the benefit of software agility because each module may be developed, deployed, and operated independently from other modules. Additionally, versioning and scaling of the modules based on changed requirements may be addressed independently without affecting other modules. Thus, SMA is a collection of loosely coupled services. The loosely coupled services may use protocols that are lightweight. Since each service is a module capable of being developed and deployed independently, the SMA may improve parallel development. Thus, it reduces time from lab to market.
- The SMA often requires various services to communicate over a network using protocols such as hypertext transfer protocol (HTTP), etc. Therefore, the performance of the network and the microservices may be adversely affected due to network latency and message processing time in comparison with services implemented as a monolithic service process. Accordingly, if services were deployed without reviewing how various services interact with each other, a messaging overhead over the network and network latency would severely degrade the network performance. Thus, it is important to know which microservices should be coupled together and which microservices should be decoupled to reduce the messaging overhead and network latency to increase performance of the microservices and the network.
- The accompanying drawings are incorporated herein and form a part of the specification.
-
FIG. 1 illustrates an exemplary microservices flow in software microservices architecture, in accordance with some embodiments. -
FIG. 2 illustrates an exemplary microservices development flow, in accordance with some embodiments. -
FIG. 3 illustrates a flow chart of method steps for automatic identification of service boundaries based on system optimization using distributed tracing data, in accordance with some embodiments. -
FIG. 4 illustrates an exemplary computer system, in accordance with some embodiments. - In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.
- Provided herein are a method, a system, and a computer program product embodiments, and/or combinations and sub-combinations thereof, for automated identification of service boundaries of various services of a software microservices architecture (SMA). In particularly, this disclosure is related to identification of boundaries of services of SMA based on system focus optimization using distributed tracing data.
- Various embodiments of this disclosure will now be discussed with respect to the corresponding figures.
-
FIG. 1 illustrates an exemplary microservices flow in software microservices architecture, in accordance with some embodiments. Shown inFIG. 1 is exemplary software microservices architecture (SMA) 100 that may includemicroservices FIG. 1 is exemplary and does not limit the number of microservices. Each microservice of the microservices 102 a-102 d may be assigned a service-id. The service-id identifies the microservice in the SMA. Themicroservices ids Service 126 a,Service 126 b,Service 126 c, andService 126 d respectively. The service-ids 126 a-126 d may be numeric or alphanumeric. - In SMA, a microservice is a module implementing business functionality with interfaces to communicate with other microservices as well as entities outside the SMA network. The microservices are loosely coupled services, with each microservice providing or implementing a different functionality. Therefore, a first microservice may be a client of a second microservice where the first microservice is provided a service by the second microservice. In one example, a second microservice may provide database related services. Accordingly, any microservice that may require access to the database would be a client of the second microservice. Accordingly, a call flow, i.e., a flow of messages exchanged between a client sending a request message to a microservice of the SMA and receiving a response from the microservice of the SMA would also include messages exchanged between the microservices of the SMA. Therefore, each microservice in a call flow may be identified based on the service-id assigned to the microservice, when the messages exchanged between the microservices include service-id information in the messages.
- In SMA, microservices 102 a-102 d may be implemented using different programming languages and may use different infrastructure. The microservices 102 a-102 d may use various mechanisms or protocols to communicate with each other. By way of non-limiting example, the microservices may use hypertext transfer (HTTP) protocol. A secure version of the HTTP protocol (HTTPS) may also be used. The microservices may use the HTTP/HTTPS protocol to exchange web services messages using, for example, service oriented architecture protocol (SOAP), representational state transfer (REST), etc. Accordingly, messages exchanged between the microservices using the SOAP/REST over the HTTP/HTTPS protocol may have various headers that may identify a source endpoint and a destination endpoint, a user agent, timestamp, a source and a destination IP address or a fully qualified domain name (FQDN) etc.
- In some embodiments, in SMA, many microservices together provide a required service or functionality. Therefore, the microservices providing the required service or functionality may be either grouped together or distributed to achieve the best performance. In some embodiments, the microservices are called together. If the client device is required to make multiple requests to collect complete information from the microservices, it may result in inefficient and slow network performance. This is because making multiple network round trips is more time consuming and error prone than making a single request. Further, aggregating the results from multiple service requests requires additional time and computing resources. Accordingly, if the microservices share common entities, the microservices may be grouped together in order to provide better bulk processing capabilities. Similarly, if a response time to a request from a client for a single microservice varies drastically based on the request or endpoint pattern, the microservice should be split to improve response time. Thus, the microservices may be grouped together or distributed and may be installed on one or more servers. In other words, not all microservices required for the service or functionality may be required to be installed or deployed on a single server. The microservices may be distributed to achieve best performance.
- In some embodiments, in SMA, one or more microservices may be designated as a gateway microservice. The gateway microservice may provide one or more endpoints to which a client device may send a request message to receive a service provided by the microservices. The one or more endpoints then may process the received request message to forward one or more messages to other microservices. The one or more messages to the other microservices may be generated by the gateway microservice based on the received request message from the client device.
- By way of a non-limiting example, the client device may be a smart phone, a mobile phone, a laptop, a tablet, a personal computer, a desktop, a server, etc. The microservices may be installed, for example, on a web server or an application server. The web server or the application server may be an Apache Tomcat server, a WebLogic server, etc.
- As shown in
FIG. 1 , anapplication request message 110 may be originated from a client device (not shown inFIG. 1 ) and received at themicroservice service 102 a. The microservice 102 a may be a gateway service and may provide one or more endpoints to receive application request messages from client devices. A gateway service is a microservice between client devices sending application request messages to the microservices of the SMA. Application request messages from the client devices to the gateway service are received via a channel, which may have two or more endpoints. An endpoint is thus controlled by the microservice to which it is connected. Characteristics of the endpoint may include schema of the messages being received or sent through the endpoint, and an address such as an IP address used to receive or send messages. - In some embodiments, the
application request message 110 may be a web service message according to Service Oriented Architecture Protocol (SOAP), or Representational State Transfer (REST). The application request message may also use hypertext transfer protocol (HTTP) or hypertext transfer protocol secure (HTTPS).Application request message 110 using the HTTP, HTTPS, SOAP, and/or REST may include various message headers, for example, Host, Content-Type, Content-Length, etc. Accordingly, theapplication request message 110 may include various headers. Additionally, new headers may also be added to the messages that are being exchanged between various microservices and with the client devices. An example of a request message and a response message with various headers, including the TraceId header, is shown below. - A portion of an exemplary HTTP request message is shown below. A new customized header, TraceId may be added to the message while sending the HTTP request message to other microservices.
- GET/doc/account.html HTTP/1.1
Host: www.mytestservice.com
Accept: image/gif, image/jpeg, */*
Accept-language: en-us - A portion of an exemplary HTTP response message is shown below. A new customized header, TraceId may be added to the message while sending the HTTP response message to other microservices and/or the client devices.
- Accept-Ranges: bytes
- In some embodiments, the
application request message 110 from the client device may be received at one endpoint of the one or more endpoints of themicroservice service 102 a. Theapplication request message 110 may include various headers as described above. In addition to various headers, theapplication request message 110 may include other data identifying a service requested by the client device from the SMA 100. The gateway service, i.e., themicroservice service 102 a, may process theapplication request message 110 and identify thatmicroservice 102 b may be invoked. Themicroservice service 102 a therefore may build anotherrequest message 112 based on theapplication request message 110. Themicroservice service 102 a may add a new customized header to aclient request message 112. - In some embodiments, for example, a new customized header named TraceId may be added to
client request message 112. The TraceId header's value may be set to an identification of the microservice that processed the application request message and/or the client request message. Similarly, microservices may add the TraceId header while building a response message to the application request message and/or client request message with the value of the TraceId header set to the identification of the microservice. Accordingly, the microservice 102 a may add the TraceId header to theclient request message 112 with the value set to an identification of the microservice 102 a 126 a to indicate that microservice 102 a is required for the service or functionality requested by the client device. - In some embodiments, when the
client request message 112 received by themicroservice 102 b, themicroservice service 102 b may process theclient request message 112. Themicroservice 102 c may be a service providing database related services. Accordingly, while processing theclient request message 112, if themicroservice 102 b requires database related services, themicroservice 102 b may invoke themicroservice 102 c. Accordingly, themicroservice 102 b may build aclient request message 114 to send to themicroservice 102 c. Theclient request message 114 may therefore be based on theclient request message 112. - For example, the
microservice 102 b may include TraceId header 112 a with its value from theclient request message 112 in theclient request message 114, and also update the value of the TraceId header in theclient request message 114 to further include identification of themicroservice 102b 126 b. Accordingly, the TraceId header 114 a may have a value set to “ServiceId1,ServiceId2” in theclient request message 114. In some embodiments, for example, the identification of the microservice 102 a 126 a and the identification of themicroservice 102b 126 b may be comma separated. However, other separator such as “;” or “|” or white-space, or like of it may also be used, e.g., “ServiceId1;ServiceId2” or “ServiceId1|ServiceId2” or “ServiceId1 ServiceId2” or like of it. - The
microservice 102 c may process theclient request message 114 and return aclient response message 116 to themicroservice 102 b. Themicroservice 102 c may include TraceId header from theclient request message 114 in theresponse message 116. The TraceId header 116 a in theclient response message 116 may therefore include the identification of the microservice 102 a 126 a and the identification of themicroservice 102b 126 b. Themicroservice 102 c may further include the identification of themicroservice 102 c 126 c in theclient response message 116. - The
client response message 116 when received by themicroservice 102 b, themicroservice 102 b may determine that no more microservice is required to be invoked. Accordingly, themicroservice 102 b may build theclient response message 122. Themicroservice 102 b may extract value of the TraceId header 116 a from theclient response message 116, which may include the identification of themicroservices microservice 102 b may build theclient response message 122 that may include the TraceId header with its (not shown inFIG. 1 ) set to the identification of themicroservices microservice 102 b is already present in the value of the TraceId header, the identification of themicroservice 102 b may not be added again. Theclient response message 122 may then be forwarded to themicroservice service 102 a. - Based on the value of the TraceId header of the
client response message 122, the microservice 102 a may determine that for the particular service or functionality requested corresponding to theapplication request message 110, microservices 102 a, 102 b, and 102 c are required services. - In some embodiments, for example, the
microservice 102 b may determine, upon receipt of theclient response message 116, that themicroservice 102 d is required to be invoked in accordance with a business logic or functionality provided by themicroservice 102 b. Accordingly, themicroservice 102 b may build aclient request message 118 having a TraceId header 118 a with its value set to the value of the TraceId header from theclient response message 116. Because the identification of themicroservice 102 b is already present in the value of the TraceId header, the identification of themicroservice 102b 126 b may not be added again to the TraceId header 118 a. Themicroservice 102 d may build aclient response message 120 similar to themicroservice 102 c. Therefore, similar to themicroservice 102 c, themicroservice 102 d may include TraceId header 120 a that may include the identification of themicroservices client response message 120 is received by themicroservice 102 b, based on the business logic or functionality provided by themicroservice 102 b, themicroservice 102 b may determine that no other microservice is further required to be invoked. Accordingly, themicroservice 102 b may build theclient response message 122 with the TraceId header 122 a with its value set to the identifications of the 102 a, 102 b, 102 c, and 102 d, which are 126 a, 126 b, 126 c, and 126 d. The microservice 102 a may therefore determine that for the particular service or functionality requested in theapplication request message 110 may requires services from the microservices 102 a, 102 b, 102 c, and 102 d. The microservice 102 a may then build theapplication response message 124 with TraceId header 124 a with its value set to theidentifications - The
microservice service 102 a may determine the microservices required to be invoked for each application client request message, which may or may not be similar to theapplication request message 110. In other words, each client request message similar to theapplication request message 110 may differ in the values set for various headers of the application request message. Accordingly, the microservices which are required to provide services according to the application request messages may be deployed together and/or deployed on the same server, which may result in reduced latency and improved performance of the network and the SMA. - In some embodiments, for example, the microservice 102 a may record messages sent to other microservices and received from the other microservices for later analysis to generate a deployment scheme. The messages may be recorded in a database or a log file. The recorded messages may be analyzed to generate the deployment scheme. The deployment scheme may be dependent on application specific criteria discussed below.
-
FIG. 2 illustrates an exemplary microservices development flow, in accordance with some embodiments. As described earlier, in SMA, microservices are loosely coupled modules that together provide service or functionality. Since microservices are modules, each module may be developed and deployed independently. Further, each module may be developed for a specific functionality; the modules may be developed faster and deployed faster because each module supports a small piece of the functionality provided by the modules as a collection, which is a substantial advantage of the SMA. Thus, modular or microservices design in SMA may be domain driven, and technology stack agnostic as shown inFIG. 2 . Particularly, by way of non-limiting example, four teams, ateam A 202 a, ateam B 202 b, ateam C 202 c, and ateam D 202 d are shown inFIG. 2 . Theteam A 202 a, theteam B 202 b, theteam C 202 c, and theteam D 202 d may each be developing a microservice. For example, eachteam team B 202 b may have a sub-team 204 e developing microservices using Java Script, a sub-team 204 f using Scala and a sub-team 204 g using Python. Theteam C 202 c may have sub-teams 204 h using the Scala, 204 i and 204 j using the Java programming language, and 204 k using the Java Script programming language. Theteam D 202 d may have sub-teams 204 l, 204 m, and 2004 n using the Java programming language, Scala, and Scala respectively. Further, in some embodiments, for example, as shown inFIG. 2 , theteam C 202 c may depend on software delivery and/or an interface from the team A 202 a, and theteam D 202 d may depend on software delivery and/or an interface from the teams A 202 a,B 202 b, andC 202 c. Since microservices are modules, each module or microservice may be scaled up/down independent of the other microservices, and may also be delivered and deployed independent of the other microservices. -
FIG. 3 illustrates a flow chart of method steps for automatic identification of service boundaries based on system optimization using distributed tracing data, in accordance with some embodiments. Atstep 302, a first application request message may be received by a gateway service. For example, the microservice 102 a may be the gateway service as described above. The first application request message may be similar to theapplication request message 110 described above. The first application request message being similar to theapplication request message 110 means that the headers and message content may be different and the value of the headers may be set according to the first application request message received at an endpoint of the gateway service. As described above, the endpoint is a channel via which the messages are communicated or exchanged between the client and the microservice. - In some embodiments, at
step 304, upon receipt of the first application request message at the endpoint of the gateway service, a first client request message based on the first application request message may be generated. The gateway service processes the first application request message according to the business logic corresponding to the requested service or functionality by the first application request message. Upon processing the first application request message, the gateway service may determine that the requested service of functionality requires invocation of service from other microservice(s). Accordingly, the gateway service may generate the first client request message from the first application request message. To identify which other microservices may be invoked corresponding to the first application request message, the gateway service may add a new customized header in the first client request message. - In some embodiments, for example, the new customized header may be named TraceId. The TraceId header may be set to a value of an identification of the gateway service. Accordingly, the TraceId header may indicate which microservices processed requests and responses corresponding to the first application request message. The first application request message and the first client request message may further be associated based on a unique identification. The first application request message may include a universal unique identifier (UUID) header. The value of the UUID header may uniquely identify the first application request message among plurality of similar other messages received at the endpoint of the gateway service. Accordingly, all request messages and response messages generated by various microservices may include the UUID header with the value set to the value of the UUID header in the first application request message.
- In some embodiments, each microservices may record the request and response messages that were received and sent respectively. The messages may be recorded in a text file or in a database. The text file may be a log file. Accordingly, the messages may be recorded in the log file in the database, which may be local to the microservice or centralized. If the messages are recorded at a centralized database or logging system, the microservice may communicate to the centralized database or logging system over network interface using, for example, TCP/IP, UDP, and/or application programming interface (API) messages. By way of a non-limiting example, the microservice may record the endpoint of the microservice at which the message is received, a source address, an incoming timestamp corresponding to receipt of the request, an outgoing timestamp corresponding to another request/response message, the UUID header value, the TraceId header value, etc.
- In some embodiments, at
step 306, the gateway service may forward the first client request message to a first service of the plurality of services. The first service of the plurality of services may be themicroservice service 102 b, and the first client request message may be theclient request message 112. As described above, theclient request message 112 may include the TraceId header with its value set to the identification of the gateway service. - In some embodiments, at
step 308, as described above, the first service may process the received firstclient request message 112. Themicroservice 102 b may determine that no other microservice is required to be invoked based on processing of the firstclient request message 112. Themicroservice 102 b then may update the TraceId header value to add identification of themicroservice 102 b, and may generate a firstclient response message 122 atstep 310. Themicroservice 102 b may include the updated TraceId header in the firstclient response message 122. The firstclient response message 122 may then be sent by themicroservice 102 b to thegateway service 102 a. Themicroservice 102 b may record the received firstclient request message 112 and the firstclient response message 122 sent from themicroservice 102 b to thegateway service 102 a. The gateway service may receive the first client response, and as described above may record the received first client response. - In some embodiments, at
step 312, thegateway service 102 a may generate a deployment scheme for a subset of services of the plurality of services based on the TraceId header value of the firstclient response message 122. As described above, the TraceId header value in the first client response may indicate all the microservices invoked in response to the receipt of the firstapplication request message 110. The deployment scheme may be generated based on application specific criteria as described below. - In some embodiments, the application specific criteria may recommend determining a set of services, which are common to a plurality of application request messages to be deployed together. By way of non-limiting example, if the plurality of application request messages comprise messages of a first application request message type and a second application request message type, the microservices which are commonly invoked by the first application request message type and the second application request message type may be deployed together. The message type may be associated with a service or functionality. Therefore, messages from various client devices requesting the service or the functionality may generate messages that may have similar message structure, but the value assigned to the headers may be different based on the client device requesting the service or the functionality.
- In some embodiments, the application specific criteria may recommend determining a set of microservices being called together corresponding to the first application request message to be deployed together.
- In yet another embodiment, the application specific criteria may recommend determining a message load over a configurable time period for a set of services, and generating a recommendation that the set of service be deployed according to the message load over the configurable time period. If the particular set of services is being invoked for all the messages received at endpoints of the gateway service, and which for example consumes substantial processing power, deploying such service with other services may adversely affect performance of the other services. Accordingly, specification of a server, i.e., CPU, memory, and other specification, may be considered in generating a recommendation of how the services may be deployed.
- As described above, the endpoint is a channel via which a microservice may exchange messages with the client devices and/or other microservices. Accordingly, the microservice may disclose a plurality of endpoints at which requests from the client devices and other microservices may be received. If it may be identified by the gateway service, based on the analysis of the recorded request messages and response by various microservices, at least one endpoint of the plurality of endpoints does not share common resource with other endpoints, the deployment scheme may be generated which may recommend that the at least one endpoint be decoupled from the other endpoints of the plurality of endpoints. The application specific criteria thus may include updating the set of services together and/or deploying the set of service together.
-
FIG. 4 illustrates an example of a computer system, in accordance with some embodiments. - Various embodiments may be implemented, for example, using one or more well-known computer systems, such as a
computer system 400 as shown inFIG. 4 . One ormore computer systems 400 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof. - The
computer system 400 may include one or more processors (also called central processing units, or CPUs), such as aprocessor 404. Theprocessor 404 may be connected to a communication infrastructure orbus 406. - The
computer system 400 may also include user input/output device(s) 403, such as monitors, keyboards, pointing devices, etc., which may communicate withcommunication infrastructure 406 through user input/output interface(s) 402. - One or more of
processors 404 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc. - The
computer system 400 may also include a main orprimary memory 408, such as random access memory (RAM).Main memory 408 may include one or more levels of cache.Main memory 408 may have stored therein control logic (i.e., computer software) and/or data. - The
computer system 400 may also include one or more secondary storage devices ormemory 410. Thesecondary memory 410 may include, for example, ahard disk drive 412 and/or a removable storage device or drive 414. Theremovable storage drive 414 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive. - The
removable storage drive 414 may interact with aremovable storage unit 418. Theremovable storage unit 418 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Theremovable storage unit 418 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/any other computer data storage device. Theremovable storage drive 414 may read from and/or write toremovable storage unit 418. - The
secondary memory 410 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by thecomputer system 400. Such means, devices, components, instrumentalities or other approaches may include, for example, aremovable storage unit 422 and aninterface 420. Examples of theremovable storage unit 422 and theinterface 420 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface. - The
computer system 400 may further include a communication ornetwork interface 424. Thecommunication interface 424 may enable thecomputer system 400 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 428). For example, thecommunication interface 424 may allow thecomputer system 400 to communicate with the external or remote devices 428 overcommunications path 426, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from thecomputer system 400 via thecommunication path 426. - The
computer system 400 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof. - The
computer system 400 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on-premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms. - Any applicable data structures, file formats, and schemas in the
computer system 400 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards. - In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, the
computer system 400, themain memory 408, thesecondary memory 410, and theremovable storage units - Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in
FIG. 4 . In particular, embodiments can operate with software, hardware, and/or operating system implementations other than those described herein. - The present invention has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.
- The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.
- The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
- The claims in the instant application are different than those of the parent application or other related applications. The Applicant therefore rescinds any disclaimer of claim scope made in the parent application or any predecessor application in relation to the instant application. The Examiner is therefore advised that any such previous disclaimer and the cited references that it was made to avoid, may need to be revisited. Further, the Examiner is also reminded that any disclaimer made in the instant application should not be read into or against the parent application.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/083,168 US20210208956A1 (en) | 2019-12-02 | 2020-10-28 | Automated identification of service boundaries based on system focus optimization using distributed tracing data |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/699,917 US10855812B1 (en) | 2019-12-02 | 2019-12-02 | Automated identification of service boundaries based on system focus optimization using distributed tracing data |
US17/083,168 US20210208956A1 (en) | 2019-12-02 | 2020-10-28 | Automated identification of service boundaries based on system focus optimization using distributed tracing data |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/699,917 Continuation US10855812B1 (en) | 2019-12-02 | 2019-12-02 | Automated identification of service boundaries based on system focus optimization using distributed tracing data |
Publications (1)
Publication Number | Publication Date |
---|---|
US20210208956A1 true US20210208956A1 (en) | 2021-07-08 |
Family
ID=73554926
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/699,917 Active US10855812B1 (en) | 2019-12-02 | 2019-12-02 | Automated identification of service boundaries based on system focus optimization using distributed tracing data |
US17/083,168 Pending US20210208956A1 (en) | 2019-12-02 | 2020-10-28 | Automated identification of service boundaries based on system focus optimization using distributed tracing data |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/699,917 Active US10855812B1 (en) | 2019-12-02 | 2019-12-02 | Automated identification of service boundaries based on system focus optimization using distributed tracing data |
Country Status (1)
Country | Link |
---|---|
US (2) | US10855812B1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220398139A1 (en) * | 2021-06-15 | 2022-12-15 | Mastercard Technologies Canada ULC | Lightweight configuration management for application programming interfaces |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20230014233A1 (en) * | 2021-07-14 | 2023-01-19 | International Business Machines Corporation | Serverless Application Function Execution |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080298333A1 (en) * | 2007-06-01 | 2008-12-04 | Lg Electronics Inc. | Scanning procedure in wireless lan, station supporting the same, and frame format therefor |
US8938533B1 (en) * | 2009-09-10 | 2015-01-20 | AppDynamics Inc. | Automatic capture of diagnostic data based on transaction behavior learning |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7017084B2 (en) | 2001-09-07 | 2006-03-21 | Network Appliance Inc. | Tracing method and apparatus for distributed environments |
US8539080B1 (en) * | 2012-12-18 | 2013-09-17 | Microsoft Corporation | Application intelligent request management based on server health and client information |
US9135145B2 (en) | 2013-01-28 | 2015-09-15 | Rackspace Us, Inc. | Methods and systems of distributed tracing |
US9021447B2 (en) | 2013-02-12 | 2015-04-28 | Concurix Corporation | Application tracing by distributed objectives |
US9189355B1 (en) * | 2013-05-21 | 2015-11-17 | Intuit Inc. | Method and system for processing a service request |
US11159599B2 (en) | 2014-10-10 | 2021-10-26 | Dynatrace Llc | Method and system for real-time modeling of communication, virtualization and transaction execution related topological aspects of monitored software applications and hardware entities |
US11855850B2 (en) | 2017-04-25 | 2023-12-26 | Nutanix, Inc. | Systems and methods for networked microservice modeling and visualization |
US10592402B2 (en) * | 2017-11-20 | 2020-03-17 | International Business Machines Corporation | Automated integration testing with mock microservices |
EP3543853A1 (en) * | 2018-03-20 | 2019-09-25 | Siemens Healthcare GmbH | Providing microservice information |
-
2019
- 2019-12-02 US US16/699,917 patent/US10855812B1/en active Active
-
2020
- 2020-10-28 US US17/083,168 patent/US20210208956A1/en active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080298333A1 (en) * | 2007-06-01 | 2008-12-04 | Lg Electronics Inc. | Scanning procedure in wireless lan, station supporting the same, and frame format therefor |
US8938533B1 (en) * | 2009-09-10 | 2015-01-20 | AppDynamics Inc. | Automatic capture of diagnostic data based on transaction behavior learning |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220398139A1 (en) * | 2021-06-15 | 2022-12-15 | Mastercard Technologies Canada ULC | Lightweight configuration management for application programming interfaces |
US11966794B2 (en) * | 2021-06-15 | 2024-04-23 | Mastercard Technologies Canada ULC | Lightweight configuration management for application programming interfaces |
Also Published As
Publication number | Publication date |
---|---|
US10855812B1 (en) | 2020-12-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108306877B (en) | NODE JS-based user identity information verification method and device and storage medium | |
US10904074B2 (en) | Composite event handler for a multi-tenant identity cloud service | |
US20180329644A1 (en) | Data Pipeline Architecture for Analytics Processing Stack | |
US20190132276A1 (en) | Unified event processing for data/event exchanges with existing systems | |
US20130060928A1 (en) | Cloud Service Publishing Method, Cloud Service Publishing Interface Message Packet and Cloud Service Broker | |
US20210208956A1 (en) | Automated identification of service boundaries based on system focus optimization using distributed tracing data | |
US11689626B2 (en) | Transport channel via web socket for ODATA | |
US11463310B2 (en) | Blockchain network management | |
US20230093304A1 (en) | Application Programming Interface Specification Generator | |
US20200111487A1 (en) | Voice capable api gateway | |
US10055266B1 (en) | Dynamic optimization of application workflows | |
Mangas et al. | WOTPY: A framework for web of things applications | |
US9742835B2 (en) | System and method for backend control of frontend user interfaces | |
US9407546B2 (en) | Routing a message using a routing table in a dynamic service mesh | |
US20090055511A1 (en) | Non-programmatic access to data and to data transfer functions | |
Patro et al. | Comparative study of middleware solutions for control and monitoring systems | |
CN113992641A (en) | Data processing method, device, equipment and storage medium | |
US11356298B2 (en) | Access management apparatus and access management method | |
CN110798495B (en) | Method and server for end-to-end message push in cluster architecture mode | |
US9021109B1 (en) | Controlling requests through message headers | |
Kang et al. | Android RMI: a user-level remote method invocation mechanism between Android devices | |
CN112929453B (en) | Method and device for sharing session data | |
US20240193249A1 (en) | Method of processing cross-domain authorization and method of processing cross-domain call | |
US20140101280A1 (en) | Generic serializer framework | |
Elhadi et al. | Functional modeling of IoT protocols |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
AS | Assignment |
Owner name: CAPITAL ONE SERVICES, LLC, VIRGINIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TATSUMI, NORIAKI;REEL/FRAME:060561/0126 Effective date: 20191127 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION COUNTED, NOT YET MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |