CN113760445B - A service switching method and device - Google Patents
A service switching method and device Download PDFInfo
- Publication number
- CN113760445B CN113760445B CN202011331403.6A CN202011331403A CN113760445B CN 113760445 B CN113760445 B CN 113760445B CN 202011331403 A CN202011331403 A CN 202011331403A CN 113760445 B CN113760445 B CN 113760445B
- Authority
- CN
- China
- Prior art keywords
- instance
- provider service
- service
- identifier
- computer room
- 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.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/142—Reconfiguring to eliminate the error
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention discloses a service switching method and device, and relates to the technical field of computers. One embodiment of the method comprises the following steps: acquiring a first machine room identifier of the provider service from a service calling strategy according to the machine room identifier of the consumer service; acquiring a first main instance of the provider service from an instance container according to a first machine room identifier of the provider service; wherein a first primary instance identity of the provider service is the same as the first machine room identity; and calling the first main instance of the provider service to initiate a request for calling the provider service deployed in the first machine room, and if the calling result of the first main instance of the provider service is abnormal, performing retry across the machine room. The implementation mode can solve the technical problem that service switching has randomness and can not ensure retry across a machine room.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a service switching method and apparatus.
Background
In order to ensure that the RPC service is highly available, when the RPC service is abnormal (e.g., no service provider is abnormal and the time is abnormal), the capability of retrying disaster recovery across machine rooms is required. When the RPC service provider alias is switched, the RPC service consumer also needs to switch in time to cope with the disaster recovery capability of the dependent service.
In the process of implementing the present invention, the inventor finds that at least the following problems exist in the prior art:
The service abnormal retry has randomness and cannot guarantee the retry across the machine room. For example: when all the services of the machine room A are abnormal, the ideal scene is that the request sent to the machine room A is automatically retried to the machine room B after the abnormality is found, but the request is sent to the machine room A again in the actual scene due to the randomness of the retried request, so that the request fails.
RPC service switching relies primarily on switching of service aliases, but service aliases are often configured in a resource file fashion, which is only reloaded when a service container is started, requiring that the container be restarted once service switching is involved. Thus, restarting a container switching service alias is less time efficient and can affect other services within the container not being available.
Disclosure of Invention
In view of the above, the embodiments of the present invention provide a service switching method and apparatus, so as to solve the technical problems that service switching has randomness and can not guarantee retry across a machine room.
To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a service switching method including:
Acquiring a first machine room identifier of the provider service from a service calling strategy according to the machine room identifier of the consumer service;
Acquiring a first main instance of the provider service from an instance container according to a first machine room identifier of the provider service; wherein a first primary instance identity of the provider service is the same as the first machine room identity;
invoking a first master instance of the provider service to initiate a request to invoke the provider service deployed at the first machine room;
and if the calling result of the first main instance of the provider service is abnormal, performing cross-machine room retry.
Optionally, if the call result of the first main instance of the provider service is a call exception, performing a retry across machine rooms, including:
judging whether the calling result of the first main instance of the provider service is abnormal;
If yes, a first slave instance of the provider service is obtained from the instance container; wherein the first slave instance identity of the provider service is different from the first machine room identity, and the first slave instance identity of the provider service is the same as the second machine room identity;
A first slave instance of the provider service is invoked to initiate a request to invoke the provider service deployed at the second machine room.
Optionally, determining whether the call result of the first main instance of the provider service is a call exception includes:
judging whether the first main instance of the provider service throws out an exception;
if yes, continuing to judge whether the exception is a remote procedure call exception.
Optionally, the method further comprises:
if the first machine room fails, acquiring a second main instance of the provider service from the instance container; wherein the second primary instance identity of the provider service is different from the first machine room identity, and the second primary instance identity of the provider service is the same as the second machine room identity;
And invoking a second master instance of the provider service to initiate a request to invoke the provider service deployed at the second machine room.
Optionally, after invoking the second main instance of the provider service, further comprising:
judging whether the calling result of the second main instance of the provider service is abnormal;
If yes, a second slave instance of the provider service is obtained from the instance container; wherein the second slave instance identity of the provider service is different from the first machine room identity, and the second slave instance identity of the provider service is the same as the second machine room identity;
A second slave instance of the provider service is invoked to initiate a request to invoke the provider service deployed at the second machine room.
Optionally, the identity of the machine room where the consumer service is located is the same as the identity of the first machine room where the provider service is located.
Optionally, invoking the first master instance of the provider service to initiate a request to invoke the provider service deployed at the first machine room includes:
Burying a point for a first main instance of the provider service;
Printing a request for entry of the provider service;
invoking a first master instance of the provider service to initiate a request to invoke the provider service deployed at the first machine room;
printing the request for the provider service.
In addition, according to another aspect of an embodiment of the present invention, there is provided a service switching apparatus including:
the acquisition module is used for acquiring a first machine room identifier of the provider service from the service calling strategy according to the machine room identifier of the consumer service;
The switching module is used for acquiring a first main instance of the provider service from an instance container according to a first machine room identifier of the provider service; invoking a first master instance of the provider service to initiate a request to invoke the provider service deployed at the first machine room; if the calling result of the first main instance of the provider service is abnormal, performing cross-machine room retry; wherein the first primary instance identification of the provider service is the same as the first machine room identification.
Optionally, the switching module is further configured to:
judging whether the calling result of the first main instance of the provider service is abnormal;
If yes, a first slave instance of the provider service is obtained from the instance container; wherein the first slave instance identity of the provider service is different from the first machine room identity, and the first slave instance identity of the provider service is the same as the second machine room identity;
A first slave instance of the provider service is invoked to initiate a request to invoke the provider service deployed at the second machine room.
Optionally, the switching module is further configured to:
judging whether the first main instance of the provider service throws out an exception;
if yes, continuing to judge whether the exception is a remote procedure call exception.
Optionally, the switching module is further configured to:
if the first machine room fails, acquiring a second main instance of the provider service from the instance container; wherein the second primary instance identity of the provider service is different from the first machine room identity, and the second primary instance identity of the provider service is the same as the second machine room identity;
And invoking a second master instance of the provider service to initiate a request to invoke the provider service deployed at the second machine room.
Optionally, the switching module is further configured to:
After the second main instance of the provider service is called, judging whether a calling result of the second main instance of the provider service is abnormal;
If yes, a second slave instance of the provider service is obtained from the instance container; wherein the second slave instance identity of the provider service is different from the first machine room identity, and the second slave instance identity of the provider service is the same as the second machine room identity;
A second slave instance of the provider service is invoked to initiate a request to invoke the provider service deployed at the second machine room.
Optionally, the identity of the machine room where the consumer service is located is the same as the identity of the first machine room where the provider service is located.
Optionally, the switching module is further configured to:
Burying a point for a first main instance of the provider service;
Printing a request for entry of the provider service;
invoking a first master instance of the provider service to initiate a request to invoke the provider service deployed at the first machine room;
printing the request for the provider service.
According to another aspect of an embodiment of the present invention, there is also provided an electronic device including:
one or more processors;
Storage means for storing one or more programs,
The one or more processors implement the method of any of the embodiments described above when the one or more programs are executed by the one or more processors.
According to another aspect of an embodiment of the present invention, there is also provided a computer readable medium having stored thereon a computer program which, when executed by a processor, implements the method according to any of the embodiments described above.
One embodiment of the above invention has the following advantages or benefits: the method comprises the steps of acquiring a first main instance of the provider service from an instance container according to a first machine room identifier of the provider service, calling the first main instance, and if the calling is abnormal, performing cross-machine room retry, so that the technical problems that service switching has randomness and the cross-machine room retry cannot be guaranteed in the prior art are solved. The embodiment of the invention decides the abnormal retry strategy by the service consumption based on the configuration mode, so that the service retry has pertinence and controllability, and the problem of randomness of the service retry is solved; if the service of the provider is switched, the consumer service only needs to modify the dynamic configuration, and the service does not need to be reissued, so that the timeliness is higher.
Further effects of the above-described non-conventional alternatives are described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:
Fig. 1 is a schematic diagram of a main flow of a service switching method according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of the main flow of a service switching method according to one referenceable embodiment of the invention;
FIG. 3 is a schematic diagram of a configuration relationship between an RPC proxy object and an RPC instance object according to an embodiment of the present invention;
FIGS. 4a-4d are schematic diagrams of configuration information according to embodiments of the present invention;
Fig. 5 is a schematic diagram of the main flow of a service switching method according to one referenceable embodiment of the present invention;
fig. 6 is a schematic diagram of main modules of a service switching apparatus according to an embodiment of the present invention;
FIG. 7 is an exemplary system architecture diagram in which embodiments of the present invention may be applied;
fig. 8 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the invention.
Detailed Description
Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding, and are to be considered merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
Fig. 1 is a schematic diagram of a main flow of a service switching method according to an embodiment of the present invention. As an embodiment of the present invention, as shown in fig. 1, the service switching method may include:
Step 101, according to the machine room identifier of the customer service, acquiring a first machine room identifier of the provider service from the service calling strategy.
In an embodiment of the invention, the consumer service invokes the provider service and determines a first room identity in which the provider service resides according to a service invocation policy. Optionally, the identity of the machine room where the consumer service is located is the same as the identity of the first machine room where the provider service is located. For example, if the room identifier of the customer service is LF, then the first room identifier of the provider service is LF; if the room identifier of the customer service is HT, then the first room identifier of the provider service is also HT. The same machine room calling principle is met, and the service performance is improved.
Step 102, according to a first machine room identifier where the provider service is located, acquiring a first main instance of the provider service from an instance container; wherein the first primary instance identification of the provider service is the same as the first machine room identification.
In the embodiment of the invention, the instances (beans) with different service identifications need to be registered in the Spring container in advance, and the identifications of the instances are identical to the machine room identifications. For example, there are a machine room LF and a machine room HT, and then the instance LF and the instance HT are registered in the Spring container, and for the machine room LF, the instance LF is a master instance, the instance HT is a slave instance, and for the machine room HT, the instance HT is a master instance, and the instance LF is a slave instance.
And if the machine room identifier where the provider service is located is the first machine room identifier, acquiring a first main instance of the provider service from the Spring container, wherein the first main instance identifier of the provider service is the same as the first machine room identifier. For example, if the machine room in which the provider service is located is identified as LF, the instance LF is obtained from the Spring container.
Step 103, calling a first main instance of the provider service to initiate a request for calling the provider service deployed in the first machine room.
After a first primary instance of the provider service is obtained from the instance container, the first primary instance is invoked to initiate a request to invoke the provider service deployed at the first machine room, i.e., to make the request to the provider service deployed at the first machine room.
Optionally, step 103 may include: burying a point for a first main instance of the provider service; printing a request for entry of the provider service; invoking a first master instance of the provider service to initiate a request to invoke the provider service deployed at the first machine room; printing the request for the provider service. The embodiment of the invention can also uniformly collect logs, realize interception in a service dimension and solve the problems of monitoring buried points and log printing in a centralized way, thereby achieving the purposes of reducing research and development burden and improving research and development efficiency.
And 104, if the calling result of the first main instance of the provider service is abnormal, performing the retry across the machine room.
Optionally, after step 103, determining whether the call result of the first main instance of the provider service is a call exception; if yes, a first slave instance of the provider service is obtained from the instance container; wherein the first slave instance identity of the provider service is different from the first machine room identity, and the first slave instance identity of the provider service is the same as the second machine room identity; a first slave instance of the provider service is invoked to initiate a request to invoke the provider service deployed at the second machine room. When an exception occurs in the calling of the first main instance of the provider service, a first slave instance of the provider service can be obtained from the Spring container based on a pre-configured abnormal retry strategy, wherein the first slave instance identification is different from the first machine room identification, the first slave instance identification is identical to the second machine room identification, and then the first slave instance is called. Therefore, when the service is abnormal, the embodiment of the invention can ensure the retry across the machine room, and solve the problem of randomness of service switching.
For example: and registering querySku the RPC instances with the interfaces HT and LF in advance to a Spring container, if the first machine room identifier of the provider service is LF, calling the first main instance LF, and when the first main instance LF is abnormal in calling, calling the first auxiliary instance HT for abnormal retry, namely calling the service deployed in the second machine room HT, thereby realizing the purpose of retry across the machine rooms. If the first slave instance HT also presents the call exception, the request fails.
It should be noted that the first slave instance is not limited to one, and may be plural, and if the first slave instance is plural, the abnormal retry order of the first slave instance may be specified by an abnormal retry policy. For example, there are a room LF, a room HT, and a room LL, and then the instance LF, the instance HT, and the instance LL are registered in the Spring container, for the room LF, the instance LF is a master instance, the instance HT is a slave instance, and for the room HT, the instance HT is a master instance, the instance LF, and the room LL are slave instances. If the first machine room identifier where the provider service is located is LF, the first master instance LF is called first, and when the first master instance LF has a call exception, the first slave instance HT or LL is called to perform an abnormal retry, and the call order of the first slave instances HT and LL may be specified by an abnormal retry policy, for example, the first slave instance HT is called first to perform an abnormal retry, and when the call fails, the first slave instance LL is called again to perform an abnormal retry.
Optionally, determining whether the call result of the first main instance of the provider service is a call exception includes: judging whether the first main instance of the provider service throws out an exception; if yes, continuing to judge whether the exception is a remote procedure call exception. When judging whether the calling result of the instance is abnormal, firstly judging whether the instance throws out the abnormality, if so, continuously judging whether the abnormality is RPC abnormality, thereby accurately judging whether the RPC service calling abnormality of the instance.
When the first slave instance is called, the logs can be collected uniformly, interception is realized in a service dimension, the problems of monitoring buried points and log printing are solved in a centralized mode, and therefore the purposes of reducing research and development burden and improving research and development efficiency are achieved. Specifically, burying a first slave instance of the provider service; printing a request for entry of the provider service; invoking a first slave instance of the provider service to initiate a request to invoke the provider service deployed at the second machine room; printing the request for the provider service.
The embodiment of the invention configures the abnormal retry strategy by the service consumer based on the configuration mode, and designates the normal request service (main instance) and the abnormal retry service (slave instance) by the configuration, so that the service retry has pertinence and controllability, the problem of randomness of service switching is solved, and the service retry across the machine room is ensured. And service aliases can be dynamically switched based on configuration, so that service switching timeliness is improved.
According to the various embodiments described above, it can be seen that in the embodiment of the present invention, by obtaining the first main instance of the provider service from the instance container according to the first machine room identifier where the provider service is located, calling the first main instance, and if the calling is abnormal, performing a retry across machine rooms, so as to solve the technical problem that in the prior art, service switching has randomness and cannot guarantee a retry across machine rooms. The embodiment of the invention decides the abnormal retry strategy by the service consumption based on the configuration mode, so that the service retry has pertinence and controllability, and the problem of randomness of the service retry is solved; if the service of the provider is switched, the consumer service only needs to modify the dynamic configuration, and the service does not need to be reissued, so that the timeliness is higher.
Fig. 2 is a schematic diagram of the main flow of a service switching method according to a reference embodiment of the present invention. As still another embodiment of the present invention, as shown in fig. 2, the service switching method may include:
step 201, according to the machine room identifier of the customer service, acquiring a first machine room identifier of the provider service from the service calling strategy.
Step 202, according to a first machine room identifier where the provider service is located, a first main instance of the provider service is obtained from an instance container. Wherein the first primary instance identification of the provider service is the same as the first machine room identification.
Step 203, invoking a first main instance of the provider service to initiate a request to invoke the provider service deployed in the first machine room.
Step 204, if the first machine room fails, obtaining a second main instance of the provider service from the instance container.
For example, there are a machine room LF and a machine room HT, if the machine room LF fails, a second main instance of the provider service is obtained from the instance container, where the second main instance identifier of the provider service is different from the first machine room identifier, and the second main instance identifier of the provider service is the same as the second machine room identifier, that is, the second main instance of the provider service is HT, so as to implement service hot switching.
Step 205, invoking a second master instance of the provider service to initiate a request to invoke the provider service deployed at the second machine room.
After a second primary instance of the provider service is obtained from the instance container, the second primary instance is invoked to initiate a request to invoke the provider service deployed at the second machine room, i.e., to make the request to the provider service deployed at the second machine room.
When the second main instance is called, the logs can be collected uniformly, interception is realized in a service dimension, the problems of monitoring buried points and log printing are solved in a centralized mode, and therefore the purposes of reducing research and development burden and improving research and development efficiency are achieved. Specifically, burying a second main instance of the provider service; printing a request for entry of the provider service; invoking a second master instance of the provider service to initiate a request to invoke the provider service deployed at the second machine room; printing the request for the provider service.
Step 206, judging whether the calling result of the second main instance of the provider service is abnormal; if yes, go to step 207; if not, ending.
Step 207 obtains a second slave instance of the provider service from the instance container.
And if the calling result of the second main instance of the provider service is abnormal, acquiring a second slave instance of the provider service from an instance container, wherein the second slave instance identification of the provider service is different from the first machine room identification, and the second slave instance identification of the provider service is identical to the second machine room identification. That is, the second master instance identity is the same as the second slave instance identity. And no matter which machine room fails, the second master instance identifier and the second slave instance identifier are identifiers of the machine rooms which do not fail, so that service hot switching is realized.
Step 208, invoking a second slave instance of the provider service to initiate a request to invoke the provider service deployed at the second machine room.
For example: and registering querySku the RPC instances with the interfaces HT and LF in advance to a Spring container, if the machine room HT fails, calling the second main instance LF, and when the second main instance LF has abnormal calling, calling the second auxiliary instance LF again to carry out abnormal re-test, thereby achieving the purpose of service hot switching.
It should be noted that the second slave instance is not limited to one, and may be plural, and if the second slave instance is plural, the abnormal retry order of these second slave instances may be specified by the abnormal retry strategy.
When the second slave instance is called, the logs can be collected uniformly, interception is realized in a service dimension, the problems of monitoring buried points and log printing are solved in a centralized mode, and therefore the purposes of reducing research and development burden and improving research and development efficiency are achieved. Specifically, burying a second slave instance of the provider service; printing a request for entry of the provider service; invoking a second slave instance of the provider service to initiate a request to invoke the provider service deployed at the second machine room; printing the request for the provider service.
In addition, in one embodiment of the present invention, the service switching method is described in detail in the above-mentioned service switching method, and thus, the description thereof will not be repeated here.
The embodiment of the invention can expand based on MethodInterceptor in aopalliance expansion packages, so that after each RPC request passes through a unified interceptor, interface configuration information is acquired from a configuration center, then an example of provider service is determined based on the interface configuration information, and finally remote service is called, thereby expanding the capability of retry across machine rooms, service hot switching and extension house monitoring on the basis of original remote service calling.
Fig. 3 is a schematic diagram of a configuration relationship between an RPC proxy object and an RPC instance object according to an embodiment of the present invention. As shown in fig. 3, a proxy object of an RPC instance is used to invoke an RPC service, and one RPC proxy object may contain multiple RPC instances. The RPC instance is used for initiating RPC call, is an instantiation result of remote service, and different RPC instances need to be configured with different RPC instance identifiers for calling the same service of different machine rooms.
Proxy object of RPC instance the proxy object of the Spring-based AOP proxy implementation is configured as shown in fig. 4a using the proxy-based AOP implementation. The proxyInterfaces is the interface full path to be proxied, and the reference pointed to by interceptorNames is the service retry configuration across the machine room. The service retry configuration across machine room is shown in fig. 4b, and only one example is needed for the service retry configuration across machine room (the retry policy configuration bean across machine room in fig. 3), wherein:
The Services attribute, map structure, key is the interface full path of the RPC example, the value is the calling strategy configuration detail of the RPC interface, the data type is ServiceConfig, the detailed attribute is shown in figure 4 c;
The appName attribute is used for monitoring the use of the buried point by the registration interface method and is the current application name;
umpKeyPrefix attributes for monitoring the fixed prefix by the method, so that the method monitoring key can be distinguished and arranged conveniently;
The group attribute is used for identifying the machine room where the provider service is located, acquiring RPC call configuration information of the specified machine room according to the identification, setting through the program configuration file, and reloading along with release of the application service to take effect. The monitoring of the extension room of the method is realized based on the attribute, for example, the service is located in the LF machine room and can be configured as group_lf, and the container service is located in the HT machine room and can be configured as group_ht;
configCenter attributes for obtaining configuration center instances for dynamic configuration, such as configuration center services like DUCC, nacos, apollo.
The RPC interface calling strategy configuration designates the method of the interface to support retry, the consumption retry strategy and the ID associated with the configuration center information, each RPC proxy object needs to configure the RPC interface calling strategy for configuring the retry strategy of the interface in detail, and the specific configuration information is shown in FIG. 4 c. Wherein:
consumers attribute, map structure, key is RPC instance identification, the configuration center arranges the calling order among RPC instances based on the identification, value is RPC instance, object type is Object;
retryMethods attribute for configuring the method name (i.e., provider service) for supporting retries, if there are multiple methods comma-separated, for example: querySku, queryProduct, querySkuDetail;
configId attribute, which is used to filter the configuration information of the interface from the configuration center, and is generally set as the RPC interface full path to facilitate distinguishing the identification.
The configuration center is mainly used for configuring a cross-machine room retry strategy and a machine room hot switching strategy of the RPC service, and configuring an execution strategy and an execution sequence arrangement of each RPC interface through a certain data text format. Configuration information data text format fig. 4c shows that the data text is presented in JSON format, and the data is composed of a 2-layer map structure:
The first layer map structure configures the calling strategy of a plurality of interfaces. The key is a value corresponding to configId attributes in fig. 4c, and is used to filter configuration information of the interface from configuration data, for example: com.xxx.product rpc; and the value is a map structure, and a machine room calling strategy configured by the RPC interface is set.
The second layer map structure is the detailed calling strategy of the single interface. The key is a value corresponding to the group attribute in fig. 4b, and is used for identifying a machine room where the current container service is located, and acquiring different RPC interface detailed calling strategies according to the dimension of the machine room; value is the calling sequence arrangement of a certain machine room service of the interface, lf-ht is separated by "-" for two RPC instance identifiers, and lf and ht are values corresponding to keys in consumers attributes in FIG. 4 c.
For example: "lf_group" means "LF-ht" and represents the RPC request, the computer room LF will call the RPC instance corresponding to the LF instance identifier (i.e. the productRpcLF instance pointed to by the 4 th row value-ref in fig. 4 c) first, and if the RPC is thrown out, the ht instance object identifier is used to identify the corresponding RPC instance (i.e. the productRpcHT instance pointed to by the 5 th row value-ref in fig. 4 c).
RPC service invocation orchestration supports a number of different forms, different scenarios, as shown in the following table:
Based on the above configuration, once complete RPC request and retry, as shown in fig. 5, after the RPC proxy object bean receives the RPC request and passes through the unified interceptor, the cross-machine-room retry policy configuration bean obtains configuration information of the interface from the configuration center according to a method path, and the RPC proxy object bean implements the cross-machine-room retry function and the service hot switching function according to the configuration information.
Retry function across machine room: acquiring a first machine room identifier of the provider service from a service calling strategy according to the machine room identifier of the consumer service; acquiring a first main instance of the provider service from an instance container according to a first machine room identifier of the provider service; wherein a first primary instance identity of the provider service is the same as the first machine room identity; a first master instance of the provider service is invoked to initiate a request to invoke the provider service deployed at the first machine room. Judging whether the calling result of the first main instance of the provider service is abnormal; if yes, a first slave instance of the provider service is obtained from the instance container; wherein the first slave instance identity of the provider service is different from the first machine room identity, and the first slave instance identity of the provider service is the same as the second machine room identity; a first slave instance of the provider service is invoked to initiate a request to invoke the provider service deployed at the second machine room.
Service hot switching function: if the first machine room fails, acquiring a second main instance of the provider service from the instance container; wherein the second primary instance identity of the provider service is different from the first machine room identity, and the second primary instance identity of the provider service is the same as the second machine room identity; and invoking a second master instance of the provider service to initiate a request to invoke the provider service deployed at the second machine room.
The embodiment of the invention is realized based on the configuration center, can support configuration change at any time and service hot switching at any time, and further improves timeliness, thereby improving the processing and recovery capacity of the system for coping with the abnormality. Moreover, the embodiment of the invention can be realized based on the AOP realization mode of the proxy, depends on xml configuration, can be realized by adopting a tangent plane mode driven by @ AspectJ annotation, and reduces the xml configuration.
The embodiment of the invention does not depend on any external resource, and can perfectly fit the Spring framework. RPC service cross-machine room retry, service hot switching, monitoring buried points and log records can be packaged into jar packets to enable the outside. The function can be used by simply introducing the jar packet and adding the configuration shown in fig. 4a-4 d. The service codes are zero-invasive, the degree of function multiplexing is greatly improved, and the effect of being used after unpacking is achieved.
Fig. 6 is a schematic diagram of main modules of a service switching device according to an embodiment of the present invention, and as shown in fig. 6, the service switching device 600 includes an acquisition module 601 and a switching module 602; the acquiring module 601 is configured to acquire, from a service calling policy, a first room identifier where a provider service is located according to a room identifier where a consumer service is located; the switching module 602 is configured to obtain, from an instance container, a first main instance of the provider service according to a first machine room identifier where the provider service is located; invoking a first master instance of the provider service to initiate a request to invoke the provider service deployed at the first machine room; if the calling result of the first main instance of the provider service is abnormal, performing cross-machine room retry; wherein the first primary instance identification of the provider service is the same as the first machine room identification.
Optionally, the switching module 602 is further configured to:
judging whether the calling result of the first main instance of the provider service is abnormal;
If yes, a first slave instance of the provider service is obtained from the instance container; wherein the first slave instance identity of the provider service is different from the first machine room identity, and the first slave instance identity of the provider service is the same as the second machine room identity;
A first slave instance of the provider service is invoked to initiate a request to invoke the provider service deployed at the second machine room.
Optionally, the switching module 602 is further configured to:
judging whether the first main instance of the provider service throws out an exception;
if yes, continuing to judge whether the exception is a remote procedure call exception.
Optionally, the switching module 602 is further configured to:
if the first machine room fails, acquiring a second main instance of the provider service from the instance container; wherein the second primary instance identity of the provider service is different from the first machine room identity, and the second primary instance identity of the provider service is the same as the second machine room identity;
And invoking a second master instance of the provider service to initiate a request to invoke the provider service deployed at the second machine room.
Optionally, the switching module 602 is further configured to:
After the second main instance of the provider service is called, judging whether a calling result of the second main instance of the provider service is abnormal;
If yes, a second slave instance of the provider service is obtained from the instance container; wherein the second slave instance identity of the provider service is different from the first machine room identity, and the second slave instance identity of the provider service is the same as the second machine room identity;
A second slave instance of the provider service is invoked to initiate a request to invoke the provider service deployed at the second machine room.
Optionally, the identity of the machine room where the consumer service is located is the same as the identity of the first machine room where the provider service is located.
Optionally, the switching module 602 is further configured to:
Burying a point for a first main instance of the provider service;
Printing a request for entry of the provider service;
invoking a first master instance of the provider service to initiate a request to invoke the provider service deployed at the first machine room;
printing the request for the provider service.
According to the various embodiments described above, it can be seen that in the embodiment of the present invention, by obtaining the first main instance of the provider service from the instance container according to the first machine room identifier where the provider service is located, calling the first main instance, and if the calling is abnormal, performing a retry across machine rooms, so as to solve the technical problem that in the prior art, service switching has randomness and cannot guarantee a retry across machine rooms. The embodiment of the invention decides the abnormal retry strategy by the service consumption based on the configuration mode, so that the service retry has pertinence and controllability, and the problem of randomness of the service retry is solved; if the service of the provider is switched, the consumer service only needs to modify the dynamic configuration, and the service does not need to be reissued, so that the timeliness is higher.
The specific implementation of the service switching device according to the present invention is described in detail in the service switching method described above, and thus the description thereof will not be repeated here.
Fig. 7 illustrates an exemplary system architecture 700 to which the service switching method or service switching apparatus of embodiments of the present invention may be applied.
As shown in fig. 7, a system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705. The network 704 is the medium used to provide communication links between the terminal devices 701, 702, 703 and the server 705. The network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
A user may interact with the server 705 via the network 704 using the terminal devices 701, 702, 703 to receive or send messages or the like. Various communication client applications such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only) may be installed on the terminal devices 701, 702, 703.
The terminal devices 701, 702, 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.
The server 705 may be a server providing various services, such as a background management server (by way of example only) providing support for shopping-type websites browsed by users using the terminal devices 701, 702, 703. The background management server can analyze and other data such as the received article information inquiry request and feed back the processing result to the terminal equipment.
It should be noted that, the service switching method provided by the embodiment of the present invention is generally executed by the server 705, and accordingly, the service switching device is generally disposed in the server 705.
It should be understood that the number of terminal devices, networks and servers in fig. 7 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 8, there is illustrated a schematic diagram of a computer system 800 suitable for use in implementing an embodiment of the present invention. The terminal device shown in fig. 8 is only an example, and should not impose any limitation on the functions and the scope of use of the embodiment of the present invention.
As shown in fig. 8, the computer system 800 includes a Central Processing Unit (CPU) 801 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM803, various programs and data required for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to the bus 804.
The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, mouse, etc.; an output portion 807 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 808 including a hard disk or the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. The drive 810 is also connected to the I/O interface 805 as needed. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as needed so that a computer program read out therefrom is mounted into the storage section 808 as needed.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication section 809, and/or installed from the removable media 811. The above-described functions defined in the system of the present invention are performed when the computer program is executed by a Central Processing Unit (CPU) 801.
The computer readable medium shown in the present invention may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer programs according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules involved in the embodiments of the present invention may be implemented in software or in hardware. The described modules may also be provided in a processor, for example, as: a processor includes an acquisition module, a switching module, and a calling module, where the names of the modules do not constitute a limitation on the module itself in some cases.
As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by a device, implement the method of: acquiring a first machine room identifier of the provider service from a service calling strategy according to the machine room identifier of the consumer service; acquiring a first main instance of the provider service from an instance container according to a first machine room identifier of the provider service; wherein a first primary instance identity of the provider service is the same as the first machine room identity; invoking a first master instance of the provider service to initiate a request to invoke the provider service deployed at the first machine room; and if the calling result of the first main instance of the provider service is abnormal, performing cross-machine room retry.
According to the technical scheme provided by the embodiment of the invention, the first main instance of the provider service is acquired from the instance container according to the first machine room identifier of the provider service, and the first main instance is called, and if the calling is abnormal, the technical means of performing the cross-machine room retry is adopted, so that the technical problems that the service switching has randomness and the cross-machine room retry cannot be ensured in the prior art are solved. The embodiment of the invention decides the abnormal retry strategy by the service consumption based on the configuration mode, so that the service retry has pertinence and controllability, and the problem of randomness of the service retry is solved; if the service of the provider is switched, the consumer service only needs to modify the dynamic configuration, and the service does not need to be reissued, so that the timeliness is higher.
The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.
Claims (9)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011331403.6A CN113760445B (en) | 2020-11-24 | 2020-11-24 | A service switching method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011331403.6A CN113760445B (en) | 2020-11-24 | 2020-11-24 | A service switching method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113760445A CN113760445A (en) | 2021-12-07 |
| CN113760445B true CN113760445B (en) | 2024-11-19 |
Family
ID=78786096
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011331403.6A Active CN113760445B (en) | 2020-11-24 | 2020-11-24 | A service switching method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113760445B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108932295A (en) * | 2018-05-31 | 2018-12-04 | 康键信息技术（深圳）有限公司 | Primary database method for handover control, device, computer equipment and storage medium |
| CN109726046A (en) * | 2018-11-23 | 2019-05-07 | 网联清算有限公司 | Computer room switching method and switching device |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7403996B2 (en) * | 2002-02-21 | 2008-07-22 | Bea Systems, Inc. | Systems and methods for migratable services |
| US10063644B1 (en) * | 2013-06-13 | 2018-08-28 | Amazon Technologies, Inc. | Managing operation of instances |
| JP6471117B2 (en) * | 2016-04-28 | 2019-02-13 | 株式会社東芝 | Telephone communication system, telephone communication method, telephone communication program |
| CN110166524B (en) * | 2019-04-12 | 2023-04-07 | 未鲲(上海)科技服务有限公司 | Data center switching method, device, equipment and storage medium |
| CN111200532A (en) * | 2020-01-02 | 2020-05-26 | 广州虎牙科技有限公司 | Method, device, equipment and medium for master-slave switching of database cluster node |
| CN111414263A (en) * | 2020-03-20 | 2020-07-14 | 深圳乐信软件技术有限公司 | Information processing method, device, server and storage medium |
-
2020
- 2020-11-24 CN CN202011331403.6A patent/CN113760445B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108932295A (en) * | 2018-05-31 | 2018-12-04 | 康键信息技术（深圳）有限公司 | Primary database method for handover control, device, computer equipment and storage medium |
| CN109726046A (en) * | 2018-11-23 | 2019-05-07 | 网联清算有限公司 | Computer room switching method and switching device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113760445A (en) | 2021-12-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10511482B2 (en) | Dynamic activation of web applications | |
| CN112311786B (en) | Service request processing method and device, storage medium and computing equipment | |
| CN106537843B (en) | Automated service profile description and orchestration | |
| CN112119374A (en) | Selectively providing mutual transport layer security using alternate server names | |
| CN111045833B (en) | Interface calling method and device | |
| CN106533713B (en) | Application deployment method and device | |
| US20150222616A1 (en) | Private cloud connected device cluster architecture | |
| CN109274777B (en) | A method, device, equipment and readable storage medium for exporting configuration files | |
| US11882154B2 (en) | Template representation of security resources | |
| US11811884B1 (en) | Topic subscription provisioning for communication protocol | |
| CN107818268A (en) | The access control method and server of big data platform | |
| US20230344815A1 (en) | End-point instance indexing and owner pop selection in gateway service ticketing | |
| CN115412549B (en) | Information configuration method, device and request processing method and device | |
| CN113778499B (en) | Method, apparatus, device and computer readable medium for publishing services | |
| CN113760445B (en) | A service switching method and device | |
| CN115378993B (en) | Method and system for supporting namespace-aware service registration and discovery | |
| US9876677B1 (en) | System and method for connection efficiency | |
| CN113760693B (en) | Method and device for local debugging of microservice system | |
| US20110320527A1 (en) | Method and system for managing a web-domain request | |
| CN113296968A (en) | Address list updating method, device, medium and electronic equipment | |
| CN116032995B (en) | Data communication method and device, electronic device and computer-readable storage medium | |
| US11902178B2 (en) | System and method to effectively allocate computing resources to end users | |
| CN112804279B (en) | Request processing method and device | |
| CN114500485B (en) | Data processing method and device | |
| CN116069753A (en) | Storage-computing separation method, system, equipment and medium |
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 |