CN114928635A - Micro-service calling method and related equipment - Google Patents
Micro-service calling method and related equipment Download PDFInfo
- Publication number
- CN114928635A CN114928635A CN202110143429.6A CN202110143429A CN114928635A CN 114928635 A CN114928635 A CN 114928635A CN 202110143429 A CN202110143429 A CN 202110143429A CN 114928635 A CN114928635 A CN 114928635A
- Authority
- CN
- China
- Prior art keywords
- calling mode
- middleware
- mode
- calling
- micro
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 90
- 230000005540 biological transmission Effects 0.000 claims description 38
- 238000012546 transfer Methods 0.000 claims description 21
- 238000012545 processing Methods 0.000 claims description 8
- 238000001514 detection method Methods 0.000 claims description 5
- 230000008859 change Effects 0.000 claims description 4
- 230000002085 persistent effect Effects 0.000 claims description 3
- 230000001052 transient effect Effects 0.000 claims description 2
- 230000008569 process Effects 0.000 abstract description 33
- 238000004891 communication Methods 0.000 description 8
- 238000004590 computer program Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000008094 contradictory effect Effects 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 239000002699 waste material Substances 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/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
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
Abstract
The embodiment of the application discloses a micro-service calling method, which is used for improving the stability and flexibility of a calling process among micro-services. The embodiment of the application comprises the following steps: determining a first calling mode between the first micro service and the second micro service; under the condition that the first calling mode is based on the middleware, detecting whether the state parameters of the middleware used by the first calling mode meet preset conditions or not; if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware; changing a first calling mode between the first microservice and the second microservice to the second calling mode. By means of the method, the calling mode between the first micro service and the second micro service can be switched under specific conditions, the flexibility of calling between the micro services is improved, the use requirements of users can be better met by calling between the micro services, and the reliability of the whole system is improved.
Description
Technical Field
The embodiment of the application relates to the field of communication, in particular to a micro-service calling method and related equipment.
Background
Microservice (or microservice architecture) is a cloud-native architecture approach, and an independent system architecture can be composed of many loosely-coupled and independently deployable smaller microservices. These microservices typically have their own stack, including databases and data models; multiple micro-services are organized by business capability, and the boundary separating the individual micro-services is often referred to as a bounded context.
The overall architecture composed of a plurality of micro services can realize different functions by using the business capability of each micro service, however, in the running process of the micro services, some data or functions which are related to each other are often required to be used among the micro services so as to meet the requirements of users. Namely, different micro services need to be called mutually, and the calling modes among the different micro services can be set according to the requirements of the micro services.
Several commonly used inter-microservice call patterns for existing microservices: each mode of a transfer control protocol-based calling mode, a message middleware-based calling mode or a hypertext transfer protocol-based calling mode has different advantages and disadvantages, and when only one micro-service calling mode is used for calling between two micro-services, the flexibility is poor, so that the running process of the whole system is influenced to a certain extent.
Disclosure of Invention
The embodiment of the application provides a micro-service calling method, which is used for improving the stability and flexibility of a calling process among micro-services.
A first aspect of an embodiment of the present application provides a method for invoking a micro service, including:
determining a first calling mode between the first micro service and the second micro service;
under the condition that the first calling mode is a calling mode based on a middleware, detecting whether state parameters of the middleware used by the first calling mode meet preset conditions or not;
if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware;
changing a first calling mode between the first microservice and the second microservice to the second calling mode.
Based on the method for invoking micro-services provided in the first aspect of the embodiment of the present application, optionally, the first invocation mode is an invocation mode based on a transmission control protocol;
the detecting whether the state parameter of the middleware used in the first calling mode meets a preset condition includes:
detecting whether the transmission data volume of the middleware used in the first calling mode is larger than a preset range or not;
if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware, including:
and if the transmission data volume of the middleware used in the first calling mode is larger than a preset range, determining the calling mode based on the message middleware as a second calling mode.
Based on the method for invoking micro-services provided in the first aspect of the embodiment of the present application, optionally, the first invocation mode is an invocation mode based on a transmission control protocol or an invocation mode based on a message middleware;
the detecting whether the middleware used by the first calling mode meets a preset condition includes:
detecting whether the middleware used by the first calling mode is in a reliable state;
if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware, including:
and if the middleware is in an unreliable state, determining the calling mode based on the hypertext transfer protocol as a second calling mode.
Based on the method for invoking a micro-service provided in the first aspect of the embodiment of the present application, optionally, the detecting whether the middleware used in the first invocation mode meets a preset condition includes:
if the first calling mode is a calling mode based on a transmission control protocol, detecting whether the transmission data volume of the middleware used by the first calling mode is larger than a preset range;
if the first calling mode is a calling mode based on a transmission control protocol or a calling mode based on message middleware, detecting whether the middleware used by the first calling mode is in a reliable state;
if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware, including:
if the transmission data volume of the middleware used in the first calling mode is larger than a preset range, determining the calling mode based on the message middleware as a second calling mode;
and if the middleware used by the first calling mode is in an unreliable state, determining the calling mode based on the hypertext transfer protocol as a second calling mode.
Based on the method for invoking a micro service provided in the first aspect of the embodiment of the present application, optionally, after changing the first invocation mode between the first micro service and the second micro service to the hypertext transfer protocol-based invocation mode, the method further includes:
and sending prompt information to the running party of the first micro service and/or the second micro service.
Based on the method for invoking micro-services provided in the first aspect of the embodiment of the present application, optionally, the invocation mode based on the transmission control protocol is an invocation mode implemented based on zokeeper and using a thread remote procedure invocation protocol framework.
Based on the method for invoking micro-services provided in the first aspect of the embodiment of the present application, optionally, the invocation mode based on the message middleware includes: any one of an ActiveMQ-based calling pattern, a RabbitMQ-based calling pattern, or a Kafka-based calling pattern.
A second aspect of the embodiments of the present application provides a micro service invoking device, including:
the first calling mode determining unit is used for determining a first calling mode between the first micro service and the second micro service;
the detection unit is used for detecting whether the state parameters of the middleware used in the first calling mode meet preset conditions or not under the condition that the first calling mode is a calling mode based on the middleware;
a second calling mode determining unit, configured to determine a second calling mode based on the state parameter of the middleware if the state parameter of the middleware does not meet a preset condition;
a call mode changing unit configured to change a first call mode between the first microservice and the second microservice to the second call mode.
A third aspect of the embodiments of the present application provides a micro service invocation device, including:
the system comprises a central processing unit, a memory, an input/output interface, a wired or wireless network interface and a power supply;
the memory is a transient storage memory or a persistent storage memory;
the central processing unit is configured to communicate with the memory, and execute the instruction operations in the memory on the micro service invocation device to execute the method according to any one of the first aspect of the embodiments of the present application.
A fourth aspect of embodiments of the present application provides a computer-readable storage medium, including instructions, which, when executed on a computer, cause the computer to perform the method according to any one of the first aspects of embodiments of the present application.
A fifth aspect of embodiments of the present application provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method according to any one of the first aspect of embodiments of the present application.
According to the technical scheme, the embodiment of the application has the following advantages: determining a first calling mode between a first micro service and a second micro service and detecting whether a state parameter of a middleware used by the first calling mode meets a preset condition; and if not, determining a second calling mode based on the state parameters of the middleware and changing the first calling mode into the second calling mode. By means of the method, the calling mode between the first micro service and the second micro service can be switched under specific conditions, the calling flexibility between the micro services is improved, the use requirements of users can be better met by calling between the micro services, and the reliability of the whole system is improved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a flowchart illustrating an embodiment of a microservice calling method of the present application;
FIG. 2 is another schematic flow chart diagram illustrating an embodiment of a microservice calling method of the present application;
FIG. 3 is another flowchart illustrating an embodiment of a microservice calling method of the present application;
FIG. 4 is a schematic structural diagram of an embodiment of a microservice invocation apparatus of the present application;
fig. 5 is another schematic structural diagram of an embodiment of a microservice calling apparatus according to the present application.
Detailed Description
The embodiment of the application provides a micro-service calling method, which is used for improving the stability and flexibility of a calling process among micro-services.
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be implemented in other sequences than those illustrated or described herein. Moreover, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
It should be noted that the descriptions in this application referring to "first", "second", etc. are for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In addition, technical solutions between various embodiments may be combined with each other, but must be realized by a person skilled in the art, and when the technical solutions are contradictory or cannot be realized, such a combination should not be considered to exist, and is not within the protection scope of the present application.
The micro-service architecture is different from a traditional single software architecture, and is a software architecture generated for adapting to the existing internet service requirement. The microservice architecture may update code more easily than traditional software architectures. While teams may use different stacks for different components, the components may be scaled independently of each other, thereby reducing waste and cost associated with having to scale the entire application.
Micro services often need to be matched with each other in the using process, that is, micro services need to be called with each other, and several common micro service calling modes of the existing micro services include: a call mode based on a Transmission Control Protocol (TCP), a call mode based on a Message Middleware (MQ), or a call mode based on a Hypertext Transfer Protocol (HTTP).
For a calling mode based on a Hypertext Transfer Protocol (HTTP), the method has the advantages of simple code and quick development. The disadvantage is that the transmission is based on the HTTP protocol, and the communication efficiency and performance are deficient due to the characteristics of the HTTP protocol in the transmission process.
For a Call mode based on a Transmission Control Protocol (TCP), an existing implementation manner is generally a TCP Call implemented based on a remote Procedure Call Protocol (RPC), and due to the diversity of RPC frames, the Call implementation manner is also various, and when the Call mode based on the Transmission Control Protocol is used, a registration record needs to be performed in a service center corresponding to the Call mode to complete the positioning and Transmission of information, so that the Call mode is an existing micro-service Call mode widely used.
For Message Middleware (MQ) based invocation mode, the existing commonly used Message middleware has RabbitMQ, ActiveMQ, Kafka and so on categories. The calling mode based on the message middleware has the main advantages that the called party can independently select the number of the received messages so as to achieve the advantages of decoupling, reducing the peak value of flow, asynchronization, improving the system throughput and the like, and the calling mode based on the message middleware has the defects of insufficient message reliability and final consistency.
When the two micro services are called, only one micro service calling mode is used, the flexibility is poor, certain influence is caused on the operation process of the whole system, and when the mode is in trouble, no alternative scheme exists and certain unsafe factors exist.
To solve the above problem, the present application provides a method for invoking a micro-service, and referring to fig. 1, an embodiment of the method for invoking a micro-service includes: step 101-step 105.
101. A pattern of invocation between the first microservice and the second microservice is determined.
The first micro service and the second micro service are two micro services which need to be mutually called, in the actual implementation process of the scheme, the first micro service and the second micro service can be any two micro services with a mutual calling relation, such as an order management micro service and a user management micro service, the specific type of the micro service can be determined according to the actual situation, and the specific type is not limited herein.
In the process of executing the scheme, firstly, a currently used calling mode between the first microservice and the second microservice needs to be determined, where the calling mode may be a calling mode using middleware, such as: the calling mode based on the message middleware or the calling mode based on the transmission control protocol can also be a calling mode without using the middleware, such as a calling mode based on the hypertext transfer protocol. And are not specifically limited herein.
102. And detecting whether the state parameter of the middleware used in the first calling mode meets a preset condition or not.
And under the condition that the first calling mode is a calling mode based on the middleware, detecting whether the state parameter of the middleware used by the first calling mode meets a preset condition or not. If the first calling mode is determined to be the calling mode using the middleware, detecting the middleware used in the mode, obtaining a current state parameter of the middleware, and comparing the state parameter with a preset condition, wherein the preset condition is preset for judging whether the calling mode needs to be switched, specifically, the preset condition can be set for the current using state of the middleware, such as setting flow data or reliability parameters of the middleware. If a certain condition is met, it indicates that the current calling mode used by the first microservice and the second microservice may not meet the use requirement, and the calling mode needs to be adjusted.
103. The second invocation mode is determined based on state parameters of the middleware.
And if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware. If the state parameter of the middleware does not meet the preset condition, the current calling mode cannot meet the use requirement between the current first micro service and the second micro service, and the calling mode needs to be adjusted, namely the current used first calling mode is adjusted to the second calling mode. Wherein the determination process of the second calling mode depends on the state parameter of the middleware. The second calling mode adopted after the adjustment is different based on the state parameters of the middleware.
104. And changing the first calling mode between the first micro service and the second micro service into the second calling mode.
And changing the first calling mode between the first micro service and the second micro service into the second calling mode. After the changed second calling mode is determined, the calling mode between the first micro service and the second micro service is adjusted, specifically, a plurality of alternative calling modes can be preset when the first micro service and the second micro service are set, one calling mode is selected as a common first calling mode, and when the calling mode adjustment is needed, the corresponding second calling mode is activated, and the first calling mode paths of the first micro service and the second micro service are closed. And then, completing the switching process of the calling mode, where the specific switching process of the calling mode may be determined according to the actual situation, and is not limited herein.
Determining a first calling mode between a first micro service and a second micro service and detecting whether a state parameter of a middleware used by the first calling mode meets a preset condition or not; and if not, determining a second calling mode based on the state parameters of the middleware and changing the first calling mode into the second calling mode. By means of the method, the calling mode between the first micro service and the second micro service can be switched under specific conditions, the flexibility of calling between the micro services is improved, the use requirements of users can be better met by calling between the micro services, and the reliability of the whole system is improved.
Based on the embodiment described in fig. 1, a detailed embodiment that can be selectively executed in the implementation process of the present solution is provided below, please refer to fig. 2, and an embodiment of the method for invoking micro-services in the present application includes: step 201-step 204.
201. A pattern of invocation between the first microservice and the second microservice is determined.
A first invocation pattern between the first microservice and the second microservice is determined. In this embodiment, the first Call mode is described as an example of a Call mode based on a Transmission Control Protocol (TCP), and specifically, the Call mode based on the TCP may be a Call mode implemented based on zokeeper using a thread Remote Procedure Call (RPC) framework. The thread RPC call mode has high call efficiency and good performance, and is generally set as a call mode used in a general situation.
The ZOOKEEPER is used as a registration center to receive node information generated by the first micro service and the second micro service in each calling process, and the node information comprises information such as an IP address and a port of the micro service. When the first micro service needs to call the second micro service, the node information of the second micro service needs to be obtained from ZOOKEEPER, the IP address and the port information of the second micro service are further obtained from the node information, and then the Thrift communication with the second micro service is established. Through the Thrift communication, barrier-free data communication can be carried out between the first micro service and the second micro service developed based on different languages, and the applicability of the calling process is improved. It is understood that the invocation mode between the first microservice and the second microservice based on the transmission control protocol may also be other types of frameworks or other types of service centers, which may be specific to the actual situation and is not limited herein.
202. And detecting whether the transmission data volume of the middleware used in the first calling mode is larger than a preset range.
And detecting the transmission data volume of the middleware used in the first calling mode, acquiring the information of the current transmission data volume, and comparing the information with a preset range. Because the micro-service calling mode based on the TCP communication protocol directly performs data interaction by two micro-services in the actual calling process, the stability of the condition of concurrent large flow is poor, and the instability of an application program and a database associated with the micro-service is easily caused by excessive requests, so that when the transmission data volume of the middleware is larger than a preset range, the calling mode is adjusted, namely the current calling mode based on the TCP protocol is changed.
203. The message middleware based invocation mode is determined as a second invocation mode.
And when the transmission data volume of the middleware used in the first calling mode is larger than a preset range, determining the calling mode based on the message middleware as a second calling mode. Specifically, the invoking mode based on the message middleware may be a synchronous invoking mode implemented based on an ActiveMQ, and it is understood that the invoking mode based on the message middleware may also be adjusted according to the actual situation, for example, using a RabbitMQ-based invoking mode or a Kafka-based invoking mode, which may be specific to the actual situation and is not limited herein.
The calling process of the first micro service to the second micro service may specifically include: the second micro service monitors the queue on the message middleware when providing service, the first micro service sends a request message to the queue on the message middleware when needing to call the second micro service, meanwhile, the first micro service also correspondingly establishes a temporary queue corresponding to the request and monitors the temporary queue, and after the second micro service receives the request message and carries out corresponding business processing and database operation, the second micro service sends the generated return message to the temporary queue, so that the first micro service uses the return message and completes the call, and meanwhile, the temporary queue is deleted.
The calling mode based on the message middleware can actively select the number of calling requests required to be received, so that the flow peak value can be reduced, the effect of flow peak clipping is achieved, and the calling mode based on the message middleware is more suitable for the situation of large flow.
204. A first invocation mode between the first microservice and the second microservice is changed to a message-middleware based invocation mode.
And changing the transmission control protocol-based calling mode between the first micro service and the second micro service into a message middleware-based calling mode. The specific modification process may refer to step 104 in the embodiment corresponding to fig. 1, and details thereof are not repeated herein. It can be understood that, the above procedure provides a process of switching from the invocation mode based on the tcp to the invocation mode based on the messaging middleware, and in an actual implementation process of the present solution, the invocation mode based on the messaging middleware may also be switched to the invocation mode based on the tcp, that is, when the flow data of the middleware is smaller than a certain preset range, the invocation mode based on the messaging middleware is changed to the invocation mode based on the tcp, which may be determined according to actual situations, and is not limited herein.
The embodiment provides that when the calling mode between the first micro service and the second micro service is the calling mode based on the transmission control protocol, the transmission data volume of the service center is judged, and when the data volume is larger than the preset range, the calling mode between the first micro service and the second micro service is switched to the calling mode based on the message middleware. The method enables the calling process between the first micro service and the second micro service to better cope with the large-flow condition, enables the calling process between the first micro service and the second micro service to be more stable, and improves the feasibility of the scheme.
Based on the embodiment described in fig. 1, another detailed embodiment that can be selectively executed in the implementation process of the present solution is provided below, and referring to fig. 3, an embodiment of the method for invoking micro-services in the present application includes: step 301-step 305.
301. A first invocation pattern between the first microservice and the second microservice is determined.
A first invocation pattern between the first microservice and the second microservice is determined. Specifically, the calling mode between the first microservice and the second microservice may be a calling mode based on a transmission control protocol, a calling mode based on a message middleware, or a calling mode based on a hypertext transfer protocol, and this embodiment is described by taking the first calling mode as the calling mode based on the transmission control protocol or the calling mode based on the message middleware as an example. It is understood that, when the first invocation mode between the first microservice and the second microservice is the hypertext transfer protocol based invocation mode, possibly due to a change of the previous invocation mode, the current invocation mode condition may be sent to the execution side of the microservice for adjustment.
302. Whether the middleware used in the first calling mode is in a reliable state is detected.
Whether the middleware used in the first calling mode is in a reliable state is detected. Specifically, the detection method may be heartbeat detection, the server continuously sends a heartbeat detection signal to the middleware, if a return signal is obtained, it indicates that the middleware is in a reliable state, and the requirement of the calling process can be completed, and if a return signal cannot be obtained, it indicates that the middleware is in an unreliable state, and the calling mode needs to be adjusted. The specific type of the middleware is determined based on the type of the first invocation mode, and may be a message middleware used in the invocation mode based on the message middleware or a service center used in the invocation mode based on the transmission control protocol, which may be determined according to the actual situation, and is not limited herein.
303. The hypertext transfer protocol based invocation mode is determined as a second invocation mode.
And if the middleware used by the first calling mode is in an unreliable state, determining the calling mode based on the hypertext transfer protocol as a second calling mode. The calling mode based on the hypertext transfer protocol is a traditional calling mode without using middleware, and has a standby function in the scheme.
304. Changing a first calling mode between the first micro service and the second micro service into a calling mode based on the hypertext transfer protocol.
The first calling mode between the first micro service and the second micro service is changed to a calling mode based on the hypertext transfer protocol, so that the subsequent calling process can be smoothly performed, and the specific switching process of the calling mode may refer to step 104 in the embodiment corresponding to fig. 1, which is not described herein in detail.
305. And sending prompt information to the operator of the first micro service and/or the second micro service.
After the calling mode between the first microservice and the second microservice is changed into the calling mode based on the hypertext transfer protocol, because the calling mode based on the hypertext transfer protocol is an alternative mode, when the calling mode is started, the problem that other calling modes cannot be automatically repaired may occur, and therefore the situation can be sent to the running party of the first microservice and/or the second microservice in the form of prompt information. So that the operator can find the condition in time and carry out corresponding adjustment, and further ensure the stability of the calling process.
It can be understood that the embodiment corresponding to fig. 2 and the embodiment corresponding to fig. 3 do not conflict with each other in the actual implementation process, and when the solution is actually implemented, the flow data and the reliability of the middleware may be simultaneously detected, and the adjustment of the different second call modes is performed based on the obtained result, which may be determined according to the actual situation, and is not limited herein.
According to the embodiment, the reliability of the middleware is judged, when the middleware is in an unreliable state, the calling mode between the first micro service and the second micro service is adjusted to be the calling mode based on the hypertext transfer protocol, so that the calling process can deal with the sudden serious problem, meanwhile, the situation is forwarded to the operator, the operator can timely know the situation and adjust the situation, and the implementation performance of the scheme is improved.
The above describes the micro-service invoking method provided by the present application, and the following describes the micro-service invoking device provided by the present application, please refer to fig. 4, where an embodiment of the micro-service invoking device of the present application includes:
the first calling mode determining unit is used for determining a first calling mode between the first micro service and the second micro service;
a detecting unit 401, configured to detect whether a state parameter of a middleware used in the first calling mode meets a preset condition when the first calling mode is a middleware-based calling mode;
a second call mode determining unit 402, configured to determine a second call mode based on the state parameter of the middleware if the state parameter of the middleware does not meet a preset condition;
a call mode changing unit 403, configured to change a first call mode between the first microservice and the second microservice to the second call mode.
In this embodiment, the flow executed by each unit in the micro service invocation device is similar to the method flow described in the embodiment corresponding to fig. 1, and is not described herein again.
Fig. 5 is a schematic structural diagram of a micro service invocation device according to an embodiment of the present application, where the server 500 may include one or more Central Processing Units (CPUs) 501 and a memory 505, and one or more applications or data are stored in the memory 505.
In this embodiment, the specific functional module division in the central processing unit 501 may be similar to the functional module division manner of each unit described in fig. 4, and is not described herein again.
The server 500 may also include one or more power supplies 502, one or more wired or wireless network interfaces 503, one or more input-output interfaces 504, and/or one or more operating systems, such as Windows Server, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.
The central processing unit 501 may perform the operations performed by the micro service invoking method in the embodiment shown in fig. 1, which are not described herein again.
The present invention also provides a computer readable storage medium for implementing the above-mentioned micro-service calling method, on which a computer program is stored, and when the computer program is executed by a processor, the processor can be used for executing the micro-service calling method as described in fig. 1.
It will be appreciated that the integrated unit, if implemented as a software functional unit and sold or used as a stand-alone product, may be stored in a corresponding one of the computer readable storage media or integrated as a computer program product for performing the above-described method. Based on such understanding, all or part of the flow of the method according to the above embodiments may be implemented by a computer program, which may be stored in a computer-readable storage medium and used by a processor to implement the steps of the above embodiments of the method. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may also be implemented in the form of a software functional unit.
The above-mentioned embodiments are only used for illustrating the technical solutions of the present invention, and not for limiting the same; although the present invention has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.
Claims (10)
1. A method for invoking a micro-service, comprising:
determining a first calling mode between the first micro service and the second micro service;
under the condition that the first calling mode is a calling mode based on a middleware, detecting whether state parameters of the middleware used by the first calling mode meet preset conditions or not;
if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware;
changing a first calling mode between the first microservice and the second microservice to the second calling mode.
2. The micro-service invocation method according to claim 1, wherein said first invocation mode is a transmission control protocol-based invocation mode;
the detecting whether the state parameter of the middleware used in the first calling mode meets a preset condition includes:
detecting whether the transmission data volume of the middleware used in the first calling mode is larger than a preset range or not;
if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware, including:
and if the transmission data volume of the middleware used in the first calling mode is larger than a preset range, determining the calling mode based on the message middleware as a second calling mode.
3. The micro-service calling method according to claim 1, wherein the first calling mode is a transmission control protocol-based calling mode or a message middleware-based calling mode;
the detecting whether the middleware used by the first calling mode meets a preset condition includes:
detecting whether the middleware used by the first calling mode is in a reliable state;
if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware, including:
and if the middleware is in an unreliable state, determining the calling mode based on the hypertext transfer protocol as a second calling mode.
4. The method for calling the microservice according to claim 1, wherein the step of detecting whether the middleware used by the first calling mode meets a preset condition comprises the following steps:
if the first calling mode is a calling mode based on a transmission control protocol, detecting whether the transmission data volume of the middleware used by the first calling mode is larger than a preset range;
if the first calling mode is a calling mode based on a transmission control protocol or a calling mode based on message middleware, detecting whether the middleware used by the first calling mode is in a reliable state;
if the state parameter of the middleware does not meet the preset condition, determining a second calling mode based on the state parameter of the middleware, including:
if the transmission data volume of the middleware used in the first calling mode is larger than a preset range, determining the calling mode based on the message middleware as a second calling mode;
and if the middleware used by the first calling mode is in an unreliable state, determining the calling mode based on the hypertext transfer protocol as a second calling mode.
5. The micro-service invocation method according to claim 3 or 4, wherein after changing the first invocation mode between the first micro-service and the second micro-service to the hypertext transfer protocol based invocation mode, the method further comprises:
and sending prompt information to the running party of the first micro service and/or the second micro service.
6. The method of any of claims 3 to 5, wherein the transmission control protocol based invocation mode is a ZOOKEEPER implementation based invocation mode using the Thrift remote procedure invocation protocol framework.
7. The micro-service invocation method according to any of the claims 3 to 5, wherein the message middleware based invocation mode comprises: any one of an ActiveMQ based invocation mode, a RabbitMQ based invocation mode or a Kafka based invocation mode.
8. A microservice invocation device, comprising:
the first calling mode determining unit is used for determining a first calling mode between the first micro service and the second micro service;
the detection unit is used for detecting whether the state parameters of the middleware used in the first calling mode meet preset conditions or not under the condition that the first calling mode is a calling mode based on the middleware;
a second calling mode determining unit, configured to determine a second calling mode based on the state parameter of the middleware if the state parameter of the middleware does not meet a preset condition;
a call mode changing unit configured to change a first call mode between the first microservice and the second microservice to the second call mode.
9. A microservice invocation device, comprising:
the system comprises a central processing unit, a memory, an input/output interface, a wired or wireless network interface and a power supply;
the memory is a transient storage memory or a persistent storage memory;
the central processor is configured to communicate with the memory, the execution of the operations of the instructions in the memory on the microservice invocation device to perform the method of any of claims 1-6.
10. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method of any of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110143429.6A CN114928635B (en) | 2021-02-02 | 2021-02-02 | Micro-service calling method and related equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110143429.6A CN114928635B (en) | 2021-02-02 | 2021-02-02 | Micro-service calling method and related equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114928635A true CN114928635A (en) | 2022-08-19 |
| CN114928635B CN114928635B (en) | 2024-08-09 |
Family
ID=82804156
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110143429.6A Active CN114928635B (en) | 2021-02-02 | 2021-02-02 | Micro-service calling method and related equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114928635B (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106686094A (en) * | 2016-12-30 | 2017-05-17 | 郑州云海信息技术有限公司 | Micro-service architecture |
| CN109542639A (en) * | 2018-11-06 | 2019-03-29 | 用友网络科技股份有限公司 | A kind of processing method, processing unit for ensureing micro services and calling data consistency |
| US20190104184A1 (en) * | 2017-09-29 | 2019-04-04 | Siemens Aktiengesellschaft | Information processing method, apparatus, and system |
| CN109714319A (en) * | 2018-12-06 | 2019-05-03 | 深圳市中农网有限公司 | Management system, method, apparatus, computer equipment and the storage medium of micro services |
| CN110149397A (en) * | 2019-05-20 | 2019-08-20 | 湖北亿咖通科技有限公司 | A kind of micro services integration method and device |
| CN110677475A (en) * | 2019-09-26 | 2020-01-10 | 亿企赢网络科技有限公司 | Micro-service processing method, device, equipment and storage medium |
-
2021
- 2021-02-02 CN CN202110143429.6A patent/CN114928635B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106686094A (en) * | 2016-12-30 | 2017-05-17 | 郑州云海信息技术有限公司 | Micro-service architecture |
| US20190104184A1 (en) * | 2017-09-29 | 2019-04-04 | Siemens Aktiengesellschaft | Information processing method, apparatus, and system |
| CN109542639A (en) * | 2018-11-06 | 2019-03-29 | 用友网络科技股份有限公司 | A kind of processing method, processing unit for ensureing micro services and calling data consistency |
| CN109714319A (en) * | 2018-12-06 | 2019-05-03 | 深圳市中农网有限公司 | Management system, method, apparatus, computer equipment and the storage medium of micro services |
| CN110149397A (en) * | 2019-05-20 | 2019-08-20 | 湖北亿咖通科技有限公司 | A kind of micro services integration method and device |
| CN110677475A (en) * | 2019-09-26 | 2020-01-10 | 亿企赢网络科技有限公司 | Micro-service processing method, device, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114928635B (en) | 2024-08-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7305495B2 (en) | Dynamic loading of protocol stacks under signaling control | |
| WO2021129008A1 (en) | Service invocation method, apparatus and device, and medium | |
| CN109542659A (en) | Using more activating methods, equipment, data center's cluster and readable storage medium storing program for executing | |
| CN114189525B (en) | Service request method and device and electronic equipment | |
| CN112035344A (en) | Multi-scenario test method, device, equipment and computer readable storage medium | |
| CN110677475A (en) | Micro-service processing method, device, equipment and storage medium | |
| CN112398689A (en) | Network recovery method and device, storage medium and electronic equipment | |
| KR100704358B1 (en) | Connecting system-level functionality of domestic OS of mobile phone to any application OS | |
| CN110881224A (en) | Network long connection method, device, equipment and storage medium | |
| CN112084042B (en) | Message processing method and device | |
| CN113179295B (en) | Message processing method and device | |
| CN106992893A (en) | The management method and device of router | |
| CN110275701B (en) | Data processing method, device, medium and computing equipment | |
| CN111240760B (en) | Application publishing method, system, storage medium and equipment based on registry | |
| CN110740172B (en) | Routing management method, device and system based on micro-service architecture | |
| JP2005228183A (en) | Program execution method and computer system for executing the program | |
| CN114928635B (en) | Micro-service calling method and related equipment | |
| CN111698499B (en) | Automatic connection method based on GMS test, terminal equipment and readable storage medium | |
| CN112073322B (en) | Discovery method and device of network tester | |
| CN114219585A (en) | Business processing method, business processing device, electronic equipment, storage medium and program product | |
| CN107766212A (en) | Determine the method and device of the installment state of application program | |
| CN113535439A (en) | Service request processing method, device, equipment and storage medium | |
| US20090183172A1 (en) | Middleware Bridge System And Method | |
| CN113438093A (en) | Alarm method, device and equipment | |
| CN113434316A (en) | Function integration method, device, equipment and storage medium based on redis plug-in |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |