Microservice registration method, device, equipment and computer storage medium
Through bytecode enhancement, the configuration information is written into the code logic of the proxy module during the microservice registration process, which solves the problem of high system coupling in microservice registration, realizes independent service registration, reduces system coupling and upgrade difficulty, and improves system performance.
Patent Information
- Application Number
- CN202211145550.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-09-20
- Publication Date
- 2025-08-22
- Estimated Expiration
- 2042-09-20
AI Technical Summary
In the existing microservice registration method, the same language as the SDK leads to high system coupling and poor specificity. When upgrading the SDK, multiple services need to be upgraded at the same time, which is highly invasive and increases the difficulty of development.
Bytecode enhancement method is used to write configuration information into the code logic of the proxy module, and receive service configuration information of the configuration center module through the proxy module, and send registration information to the registration center module to realize service registration and avoid multiple services being integrated in one SDK.
Reduce system coupling, make each service independent, reduce redundant code caused by registration information changes, improve system performance, and reduce upgrade and maintenance costs.
Smart Images

Figure CN115567587B_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of microservice registration technology, and in particular relates to a microservice registration method, apparatus, device, and computer storage medium. Background Art
[0002] The current microservice registration method is generally integrated and implemented based on the Software Development Kit (SDK). This requires that the business code and the SDK be written in the same language, resulting in high system coupling and poor specificity. Summary of the Invention
[0003] The embodiments of the present application provide a microservice registration method, apparatus, device, and computer storage medium, which can reduce the coupling degree of the system when registering microservices.
[0004] In a first aspect, an embodiment of the present application provides a microservice registration method, which is applied to a proxy module. The method includes:
[0005] Receive the configuration information of the microservices sent by the configuration center module, including the service name and registration address;
[0006] Use bytecode enhancement to write configuration information into the code logic of the proxy module to obtain registration information;
[0007] Send registration information to the registration center module to complete service registration.
[0008] In a second aspect, an embodiment of the present application provides a microservice registration device, the device comprising:
[0009] The receiving module is used to receive the configuration information of the microservice sent by the configuration center module. The configuration information includes the name and registration address of the service;
[0010] The writing module is used to write the configuration information into the code logic of the proxy module using bytecode enhancement to obtain registration information;
[0011] The sending module is used to send registration information to the registration center module to complete the registration of the service.
[0012] In a third aspect, an embodiment of the present application provides a microservice registration device, the device comprising:
[0013] The configuration center module is used to send the configuration information of services in the microservices, including the service name and registration address;
[0014] The proxy module is used to receive the configuration information sent by the configuration center module and write the configuration information into the code logic of the proxy module using bytecode enhancement to obtain registration information;
[0015] The proxy module is also used to send registration information;
[0016] The registration center module is used to receive registration information to complete service registration.
[0017] In a fourth aspect, an embodiment of the present application provides a microservice registration device, the device comprising: a processor and a memory storing computer program instructions;
[0018] When the processor executes the computer program instructions, the method described in the first aspect is implemented.
[0019] In a fifth aspect, an embodiment of the present application provides a computer storage medium, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method described in the first aspect is implemented.
[0020] In a sixth aspect, an embodiment of the present application provides a computer program product, characterized in that when the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the method described in the first aspect.
[0021] The microservice registration method, apparatus, device, and computer storage medium provided in the embodiments of the present application are as follows: the proxy module receives the configuration information of the service in the microservice sent by the configuration center module, and the configuration information includes the name and registration address of the service; the proxy module then uses bytecode enhancement to write the configuration information into the code logic of the proxy module to obtain the registration information; the proxy module then sends the registration information to the registration center module to complete the registration of the service. In this way, the service and the proxy module are integrated using the bytecode enhancement method, replacing the SDK and service integration method. One service corresponds to one proxy module. The proxy module receives the configuration information of the service sent by the configuration center module through the proxy service method, and assists the service in registering with the registration center module. This can avoid integrating multiple services into one SDK, making each service independent and reducing the coupling degree of the system. BRIEF DESCRIPTION OF THE DRAWINGS
[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0023] Figure 1 This is a schematic diagram of the structure of a microservice registration device provided in an embodiment of the present application.
[0024] Figure 2 This is a flowchart of the microservice registration method provided in an embodiment of the present application.
[0025] Figure 3 This is a structural diagram of another microservice registration device provided in an embodiment of the present application.
[0026] Figure 4 This is a schematic diagram of the structure of the microservice registration device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0027] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present application by illustrating the examples of the present application.
[0028] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, the elements defined by the phrase "comprising..." do not exclude the presence of other identical elements in the process, method, article, or device comprising the elements.
[0029] Microservices is a software development technique—a variation of the service-oriented architecture (SOA) architectural style. Microservices advocate for breaking a single application into a set of smaller services, known as microservice applications, that coordinate and collaborate with each other to deliver ultimate value to users. Each service runs in its own independent process, typically using a RESTful (Representation State Transfer-ful) application programming interface (API) based on the architectural constraints and principles of the Hypertext Transfer Protocol (HTTP). Services communicate with each other using lightweight communication mechanisms. Each service is built around a specific business need and can be independently deployed in production or production-like environments.
[0030] In addition, unified and centralized service management mechanisms should be avoided as much as possible. For a specific service, appropriate languages and tools should be selected to build it according to the context.
[0031] Currently, microservice registration is typically implemented through SDK integration. For example, in-application registration and discovery is employed, exemplified by Netflix's open-source Eureka. Eureka's architecture consists of three key components: the Eureka Server, the server-side Eureka Client, and the client-side Eureka Client. The Eureka Server is the server-side of the registry, implementing functions such as service registration, storage, and querying. The server-side Eureka Client is integrated with the server-side registry SDK. Service providers call the SDK to register and unregister services. The client-side Eureka Client is integrated with the client-side registry SDK. Service consumers call the SDK to subscribe to and update services.
[0032] Based on this, the business code and SDK of the microservice are written in the same programming language, resulting in high system coupling and poor specificity.
[0033] Furthermore, because multiple services in a microservice use the same service registration SDK, upgrading the registered SDK requires upgrading the entire service. This means that the service registrations of multiple services in the microservice must be changed simultaneously. Furthermore, SDK integration is highly invasive to the code, making development more difficult for client developers.
[0034] In order to solve the problems of the prior art, the embodiments of the present application provide a microservice registration method, apparatus, device and computer storage medium. The microservice registration apparatus provided in the embodiments of the present application is first introduced below.
[0035] The acquisition, storage, use and processing of data in the technical solution of this application are in compliance with the relevant provisions of national laws and regulations.
[0036] Figure 1 This is a schematic diagram of the structure of a microservice registration device provided in an embodiment of the present application. Figure 1 As shown, a microservice registration device 100 provided in an embodiment of the present application includes a configuration center module 101, an agent module 102 and a registration center module 103.
[0037] Under the microservice architecture, during the service registration process, the configuration center module 101 acts as the service provider. When the service is started, based on the configuration file corresponding to the service, that is, the configuration information including the name of the service and the registration address, the configuration information is written into the code logic of the proxy module through the proxy module 102 using bytecode enhancement to obtain the registration information, and the registration information corresponding to the service is sent to the registration center module 103 to complete the registration of the service.
[0038] During the service registration process and before and after the registration process, the configuration center module 101 needs to regularly send heartbeats to the registration center module 103 to report the survival status of the service.
[0039] In some embodiments of the present application, during the process of service change, the pre-configuration center module 104 receives the changed registration information of the target service in the microservice sent by the configuration center module 101, and sends the changed registration information of the target service to the proxy module 102, so as to register the service to the new registration center module through the proxy module 102 according to the changed registration information of the target service.
[0040] In some embodiments of the present application, during the process of user device 200 calling a service, user device 200 will send subscription information including the name of the called service to the registration center module 103. When the service starts, the registration center module 103 matches the called service according to the subscription information, and sends the subscription success information including the name, registration address and port of the called service that is successfully matched to the proxy module 102 for calling the service on the user device 200.
[0041] Next, the microservice registration method provided in the embodiment of the present application is introduced.
[0042] Figure 2 The following is a flow chart of a microservice registration method provided by an embodiment of the present application. Figure 2 As shown, a microservice registration method provided in an embodiment of the present application includes steps: S201 to S203.
[0043] S201: The proxy module receives the configuration information of the microservice sent by the configuration center module, where the configuration information includes the name and registration address of the service.
[0044] Before publishing a service, a service provider must first define an interface, declaring the interface name, parameters, and return type. The interface must then be packaged into a JAR file and published. Service providers publish interfaces by defining them in a service deployment configuration file. Service consumers reference interfaces by defining the interface in a service reference configuration file and importing the JAR file containing the interface definition into their code dependencies.
[0045] Based on this, the configuration center module can directly receive the microservice configuration information (i.e., configuration files) entered by client developers. The configuration center module can also receive configuration requirements entered by client developers and, based on these requirements, retrieve the microservice configuration information pre-edited by the client developers. The configuration center module then sends this microservice configuration information to the proxy module.
[0046] The agent module includes at least one Agent agent. An Agent agent represents the activation process of a microservice in the computer. When it is needed by an external microservice, it is responsible for the specific type of behavior of the microservice.
[0047] S202: The proxy module writes the configuration information into the code logic of the proxy module using bytecode enhancement to obtain registration information.
[0048] In one embodiment, the proxy module adopts a bytecode enhancement method, and also writes the configuration information into the relevant configuration information of the proxy module.
[0049] In one embodiment, the proxy module adopts a bytecode enhancement method to dynamically change the relevant configuration information or code logic and other contents within the proxy module itself.
[0050] The integration between services and proxy modules in microservices relies on the cross-language sidecar service plug-in (spring-cloud-netflix-sideca). The sidecar service plug-in defines the proxy module as a basic service.
[0051] The sidecar service plug-in is accessed as follows:
[0052] 1. Create a sidecar service. When creating a sidecar service, pay attention to the matching of the spring-boot-starter-parent version and the spring-cloud version.
[0053] 2. Configuration file; the configuration file includes the address of the service registration center module, the port of the service being used by the sidecar, and the health detection interface address of the service being used by the sidecar.
[0054] 3. Add a composite annotation to the startup class; the composite annotation can be the @Enable Sidecar annotation.
[0055] 4. Add a health detection interface.
[0056] 5. Start the service, complete the integration of the service and proxy module in the microservice, and obtain the registration information.
[0057] Dynamically changing the relevant configuration information or code logic within the proxy module itself mainly relies on bytecode enhancement to obtain the startup class, that is, the Class class. At the same time, the Bean Definition Builder of the open source design layer framework Spring is used to set the property values of the injected Bean, and then the Bean Definition Registry is used to inject the Bean into the Inversion of Control (IOC) container to dynamically change the corresponding Class object of the Class class, that is, the relevant configuration information or code logic.
[0058] In some embodiments, examples of setting property values of injected beans based on the Bean Definition Builder include:
[0059] The example class Person Bean Regiser for manually registering beans is used to implement the Bean Factory Aware interface and obtain the Spring factory class. Because Bean Factory is an interface, debugging shows that the factory implementation class injected by the Spring window is Default Listable Bean Factory. Through its source code, we can see that this Bean factory class implements the Bean Definition Registry interface. Through the register Bean Definition method of this interface, we can register beans with the Spring container.
[0060] In some embodiments, examples of using the Bean Definition Registry to inject beans into the IOC container include:
[0061] In one embodiment, an object is registered in the IOC container using annotations such as @Service, @Component, or @Bean.
[0062] In one embodiment, code is used to place an object into an IOC container, such as creating an object of a bean definition class, where the bean type is Calculate Service Impl; registering the bean definition into a spring environment; and printing current stack information.
[0063] The main purpose of adopting the bytecode enhancement method is to reduce redundant code and improve performance. The bytecode enhancement technology based on the bytecode enhancement method relies on the Code Generation Library (CGLIB), and enhances the code logic by implementing the method interceptor interface method. In one embodiment, the bytecode enhancement method is adopted to implement the dynamic injection of the received information by the proxy module. The bytecode enhancement method is Java bytecode enhancement. After the Java bytecode is generated, the Java bytecode is modified to enhance the Java bytecode function, which is equivalent to modifying the binary file of the application.
[0064] In some embodiments, examples of implementing the Method Interceptor interface method to enhance code logic include:
[0065] First, define a business class that has the functions of saving and deleting users; customize an interceptor and call this interceptor a notification. The notification implements two functions at one time: the pre-enhancement function and the post-exception handling enhancement function; the user defines a Java Bean containing the enhancement method, including the target object, method parameters and target method; perform method testing and output to the console.
[0066] As can be seen from the above, the Spring Framework's Aspect Oriented Programming (AOP) is very powerful. It can implement pre-enhancement, post-enhancement, final enhancement, and surround enhancement. In addition, it can control and filter method input parameters, thereby affecting the execution status of the target method. AOP is implemented based on the (CGLIB) proxy pattern. The key point is to implement the Method Interceptor interface and formulate the proxy method generation strategy in its "public Object invoke(MethodInvocation mi)" method. The MethodInvocation type parameter mi of this method can be used to obtain information such as the target object, method parameters, and target method. Based on this information, the enhancement effect can be precisely controlled.
[0067] S203: The proxy module sends registration information to the registration center module to complete the service registration.
[0068] The proxy module sends the name and registration address of the service in the microservice to the registration center module. The registration center module stores the name and registration address of the service in the local cache service node list to complete the registration of the service.
[0069] The service name and registration address in the microservice are the instance information when each microservice is started. The instance information also includes the port of the microservice.
[0070] When a microservice starts, it registers its instance information with the registry through the proxy module, allowing the registry module to store the microservice instance information. Service consumers obtain the service provider's instance information from the registry module and remotely call the service provider's interface using the "IP+port" method. Each microservice reports its heartbeat to the registry module, which decides whether to take a service instance offline based on whether it receives the report within a certain time period. When a microservice changes, such as adding an instance or changing its IP address, it re-registers its information with the registry module. This way, service consumers don't need to make changes and can directly obtain the latest information from the registry module.
[0071] The registry module provides functions including service registration, service registration and discovery, and service checking. The service registry is the core of the registry, recording information about each microservice instance, such as the service name, IP address, and port number. The service registry provides query and management APIs. The query API is used to query available microservice instances, while the management API is used to register and deregister services. Service registration and discovery refers to the process by which a microservice registers its information with the registry upon startup. Service discovery refers to the mechanism for querying the list of available microservices and their network addresses. Service checking involves the registry using a mechanism to periodically check registered services. If an instance is found to be inaccessible for an extended period, it will be removed from the service registry. It should be noted that actual microservice testing and deployment typically involve multiple environments, such as a production environment and a test environment. Developers conducting business self-tests and testers conducting regression testing typically use the test environment, registering the deployed RPC server nodes with the test registry cluster. However, it often happens that during development or testing deployment, the service nodes in the test environment are mistakenly registered with the online registration center cluster. In this case, the online traffic will be called to the RPC Server nodes in the test environment, which may cause unexpected consequences.
[0072] Therefore, the service registry also provides a protection mechanism. For example, imagine the registry as a room with a gate, where only RPC servers with access cards can enter. In practical applications, the registry can provide a whitelist mechanism. Only RPC servers added to the registry's whitelist can call the registry's registration interface. This prevents nodes in the test environment from accidentally running into the production environment.
[0073] The above is a specific implementation of the microservice registration method provided in the embodiment of the present application. The proxy module receives the configuration information of the service in the microservice sent by the configuration center module, and the configuration information includes the name and registration address of the service; the proxy module then uses the bytecode enhancement method to write the configuration information into the code logic of the proxy module to obtain the registration information; the proxy module then sends the registration information to the registration center module to complete the registration of the service. In this way, the service and the proxy module are integrated using the bytecode enhancement method, instead of the SDK and service integration method. One service corresponds to one proxy module. The proxy module receives the configuration information of the service sent by the configuration center module through the proxy service, and assists the service in registering with the registration center module. This can avoid integrating multiple services in one SDK, making each service independent and reducing the coupling degree of the system.
[0074] In some embodiments of the present application, the method further includes steps: S204 to S206.
[0075] S204: When the registration information of the service changes, the configuration information of the service after the change is received from the pre-configuration center module, where the configuration information of the service after the change includes the name and registration address of the service after the change; wherein the configuration information of the service after the change is sent from the configuration center module to the pre-configuration center module.
[0076] S205: The changed configuration information of the service is written into the code logic of the proxy module by using bytecode enhancement to obtain the changed registration information.
[0077] S206: Send the changed service registration information to the new registration center module to complete the changed service registration.
[0078] Once the registration center detects that a service provider node has been newly added or removed, it must immediately notify all service consumers who have subscribed to the service and refresh the locally cached service node information to ensure that service calls do not request unavailable service provider nodes.
[0079] For example, using Zoo Keeper as an example, the Watcher mechanism is used to notify service consumers of service status changes. When a service consumer calls Zoo Keeper's getData method to subscribe to a service, it can also obtain service changes through the Watcher's process method and then call the getData method to obtain the changed data and refresh the locally cached service node information.
[0080] The proxy module's version information, configuration information, code logic, and other related content are uniformly controlled by the pre-configuration center. When the service registration information changes, the pre-configuration center module receives the changed service configuration information from the configuration center module and sends the changed service configuration information to the proxy module.
[0081] The modified service configuration information is written into the code logic of the proxy module using bytecode enhancement to obtain the modified registration information.
[0082] Send the registration information of the changed service to the new registration center module to complete the service change registration. See the above implementation method and do not repeat it here.
[0083] It should be noted that whether it is the first registration of a service in a microservice or the change of the service registration information, it is achieved by integrating the service and proxy modules in the microservice.
[0084] The service is integrated with the proxy module using bytecode enhancement. The proxy module receives the configuration information of the service sent by the pre-configuration center module through the proxy service, and assists in changing the service to the new registration center module. This can reduce the redundant code caused by the change of registration information and improve the performance of the system.
[0085] In some embodiments of the present application, when the microservice includes multiple services, one service corresponds to one proxy module, and step S204 specifically includes step S2041.
[0086] S2041: When the registration information of the target service in the microservice is changed, the proxy module corresponding to the target service receives the changed configuration information of the target service sent by the pre-configuration center module. The changed configuration information of the target service includes the changed name and registration address of the target service.
[0087] Based on the proxy mode where one service corresponds to one proxy module, when the registration information of the target service changes, in the microservices, only the proxy module corresponding to the target service among multiple services receives the changed configuration information of the target service sent by the pre-configuration center module, and the proxy modules corresponding to services other than the target service do not accept the changed configuration information of the target service sent by the pre-configuration center module.
[0088] The service and proxy module are integrated using bytecode enhancement. One service corresponds to one proxy module. The proxy module receives the configuration information of the service sent by the pre-configuration center module through the proxy service, and assists the service to change to the new registration center module. This can avoid integrating multiple services in one SDK, make each microservice independent, and reduce the coupling degree of the system.
[0089] In some embodiments of the present application, the method further includes steps: S207 to S208.
[0090] S207: When the user equipment successfully subscribes to the service from the registration center module, the proxy module receives a subscription success message sent by the registration center module, where the subscription success message includes the service port.
[0091] S208: The proxy module opens a port for the user device to call a service through the port.
[0092] The user equipment successfully subscribes to the service from the registration center, that is, in the service node list of the registration center module, the subscribed service name is consistent with the registered service name.
[0093] After receiving the subscription success information sent by the registration center module, the proxy module will open the port of the service included in the subscription success information in the configuration center, so that the user device can call the service through the port.
[0094] By opening the port where the user device wants to call the service through the proxy module, the addressing of the microservice is realized so that the user can call the service through the port. This can avoid the problem of an increasing number of service registration SDK projects as the business complexity and the number of microservices increase, thereby reducing the upgrade and maintenance costs.
[0095] Based on the microservice registration method provided in the above embodiment, this application also provides a specific implementation of a microservice registration device. Please refer to the following embodiment.
[0096] See first Figure 3 Another microservice registration device provided in an embodiment of the present application includes the following modules:
[0097] Receiving module 301, used to receive the configuration information of the service in the microservice sent by the configuration center module, the configuration information includes the name and registration address of the service;
[0098] A writing module 302 is used to write the configuration information into the code logic of the proxy module using bytecode enhancement to obtain registration information;
[0099] The sending module 303 is used to send registration information to the registration center module to complete the registration of the service.
[0100] The above is a specific implementation method of another microservice registration device provided in an embodiment of the present application. The receiving module 301 receives the configuration information of the service in the microservice sent by the configuration center module, and the configuration information includes the name and registration address of the service; the writing module 302 then adopts the bytecode enhancement method to write the configuration information into the code logic of the proxy module to obtain the registration information; the sending module 303 then sends the registration information to the registration center module to complete the registration of the service. In this way, the service and the proxy module are integrated in a bytecode enhancement method instead of the SDK and service integration method. One service corresponds to one proxy module. The proxy module receives the configuration information of the service sent by the configuration center module through the proxy service, and assists the service to register with the registration center module. It can avoid integrating multiple services in one SDK, make each service independent, and reduce the coupling degree of the system.
[0101] In some embodiments of the present application, the above-mentioned receiving module 301 is also used to receive the configuration information of the service after the change sent by the pre-configuration center module when the registration information of the service changes. The configuration information of the service after the change includes the name and registration address of the service after the change; wherein, the configuration information of the service after the change is sent by the configuration center module to the pre-configuration center module.
[0102] The writing module 302 is further configured to write the changed configuration information of the service into the code logic of the proxy module using bytecode enhancement to obtain the changed registration information;
[0103] The sending module 303 is further configured to send the changed registration information of the service to the new registration center module to complete the changed registration of the service.
[0104] The service is integrated with the proxy module using bytecode enhancement. The proxy module receives the configuration information of the service sent by the pre-configuration center module through the proxy service, and assists in changing the service to the new registration center module. This can reduce the redundant code caused by the change of registration information and improve the performance of the system.
[0105] In some embodiments of the present application, when a microservice includes multiple services, one service corresponds to one proxy module.
[0106] The receiving module 301 includes: a receiving unit.
[0107] The receiving unit is used to receive the changed configuration information of the target service sent by the pre-configuration center module when the registration information of the target service in the microservice is changed. The changed configuration information of the target service includes the changed name and registration address of the target service.
[0108] The service and proxy module are integrated using bytecode enhancement. One service corresponds to one proxy module. The proxy module receives the configuration information of the service sent by the pre-configuration center module through the proxy service, and assists the service to change to the new registration center module. This can avoid integrating multiple services in one SDK, make each microservice independent, and reduce the coupling degree of the system.
[0109] In some embodiments of the present application, the device further includes: an opening module 304 .
[0110] The receiving module 301 is further configured to receive a subscription success message sent by the registration center module when the user equipment successfully subscribes to the service from the registration center module, where the subscription success message includes the service port.
[0111] The opening module 304 is used to open the port so that the user equipment can call the service through the port.
[0112] By opening the port where the user device wants to call the service through the proxy module, the addressing of the microservice is realized so that the user can call the service through the port. This can avoid the problem of an increasing number of service registration SDK projects as the business complexity and the number of microservices increase, thereby reducing the upgrade and maintenance costs.
[0113] Figure 3 The microservice registration device shown can be implemented Figure 2 The steps of the microservice registration method shown are described briefly and will not be repeated here.
[0114] Figure 4 A schematic diagram of the hardware structure of the microservice registration device provided in an embodiment of the present application is shown.
[0115] The microservice registration device may include a processor 401 and a memory 402 storing computer program instructions.
[0116] Specifically, the processor 401 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.
[0117] Memory 402 may include a large capacity memory for data or instructions. By way of example and not limitation, memory 402 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 402 may include removable or non-removable (or fixed) media. Where appropriate, memory 402 may be inside or outside the microservice registration device. In a specific embodiment, memory 402 is a non-volatile solid-state memory.
[0118] In certain embodiments, the memory 402 may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical, or other physical / tangible memory storage device. Thus, generally, the memory 402 includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of the present disclosure.
[0119] The processor 401 implements any one of the microservice registration methods in the above embodiments by reading and executing computer program instructions stored in the memory 402.
[0120] In one example, the microservice registration device may further include a communication interface 403 and a bus 410. Figure 4 As shown, the processor 401 , the memory 402 , and the communication interface 403 are connected via a bus 410 and communicate with each other.
[0121] The communication interface 403 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.
[0122] Bus 410 includes hardware, software or both, and the parts of microservice registration device are coupled to each other.For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industry standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industry standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 410 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the application considers any suitable bus or interconnection.
[0123] In addition, in conjunction with the microservice registration method in the above embodiments, embodiments of the present application may provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any of the microservice registration methods in the above embodiments is implemented.
[0124] It should be understood that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order of the steps after understanding the spirit of the present application.
[0125] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROMs, flash memories, erasable ROMs (EROMs), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.
[0126] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps. In other words, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.
[0127] The above reference is according to the flowchart and / or block diagram of the method, device (system) and computer program product of the embodiment disclosed in the present application.It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be realized by computer program instructions.These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device, to produce a kind of machine, so that these instructions executed via the processor of the computer or other programmable data processing device enable the realization of the function / action specified in one or more boxes of the flowchart and / or block diagram.Such a processor can be but is not limited to a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit.It is also understood that each box in the block diagram and / or the flowchart and the combination of the boxes in the block diagram and / or the flowchart can also be realized by the dedicated hardware that performs the specified function or action, or can be realized by the combination of dedicated hardware and computer instructions.
[0128] The above description is only a specific embodiment of the present application. Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the scope of protection of the present application.
Claims
1. A microservice registration method, characterized in that: Applied to a proxy module, one proxy module corresponds to one service, and the service is one of multiple services included in a microservice. The method includes: Receive configuration information of services in the microservices sent by the configuration center module, the configuration information including the name and registration address of the service; The configuration information is written into the code logic of the proxy module by adopting a bytecode enhancement method, and the relevant configuration information or code logic within the proxy module itself is dynamically changed to obtain registration information; Sending the registration information to the registration center module to complete the registration of the service; When the registration information of the target service in the microservice is changed, the proxy module corresponding to the target service receives the changed configuration information of the target service sent by the pre-configuration center module, and the changed configuration information of the target service includes the changed name and registration address of the target service; wherein, the changed configuration information of the target service is sent by the configuration center module to the pre-configuration center module; Writing the changed configuration information of the target service into the code logic of the proxy module corresponding to the target service by adopting a bytecode enhancement method, dynamically changing the relevant configuration information or code logic within the proxy module corresponding to the target service, and obtaining the changed registration information; Sending the changed registration information of the target service to the new registration center module to complete the changed registration of the target service; The method further comprises: The port of the service corresponding to the proxy module is opened to implement service addressing so that the user device can call the service through the port.
2. The method according to claim 1, characterized in that The method further comprises: When the user device successfully subscribes to the service from the registration center module, receiving a subscription success message sent by the registration center module, the subscription success message including the service port; The port is opened so that the user equipment can call a service through the port.
3. A microservice registration device, characterized in that: One proxy module corresponds to one service, which is one of multiple services included in the microservice. The device includes: A receiving module is used to receive the configuration information of the microservice sent by the configuration center module, wherein the configuration information includes the name and registration address of the service; A writing module, configured to write the configuration information into the code logic of the proxy module using a bytecode enhancement method, dynamically changing the relevant configuration information or code logic within the proxy module itself, and obtaining registration information; A sending module, configured to send the registration information to a registration center module to complete the registration of the service; The receiving module is further configured to, when the registration information of a target service in the microservice is changed, receive the changed configuration information of the target service sent by the pre-configuration center module by the proxy module corresponding to the target service, wherein the changed configuration information of the target service includes the changed name and registration address of the target service; wherein the changed configuration information of the target service is sent by the configuration center module to the pre-configuration center module; The writing module is further used to write the changed configuration information of the target service into the code logic of the proxy module corresponding to the target service by using bytecode enhancement, dynamically changing the relevant configuration information or code logic inside the proxy module corresponding to the target service itself to obtain the changed registration information; The sending module is further used to send the changed registration information of the target service to the new registration center module to complete the changed registration of the target service; The opening module is used to open the port of the service corresponding to the proxy module and realize the addressing of the service so that the user equipment can call the service through the port.
4. The device according to claim 3, characterized in that The device further comprises: The receiving module is further configured to receive a subscription success message sent by the registration center module when the user equipment successfully subscribes to the service from the registration center module, wherein the subscription success message includes a service port; The opening module is used to open the port so that the user equipment can call the service through the port.
5. A microservice registration device, characterized in that: The device comprises: The configuration center module is used to send the configuration information of the service in the microservice, and the configuration information includes the name and registration address of the service; The proxy module is configured to receive the configuration information sent by the configuration center module, write the configuration information into the code logic of the proxy module using bytecode enhancement, and dynamically change the relevant configuration information or code logic within the proxy module itself to obtain registration information; wherein, one proxy module corresponds to one service, and the service is one of the multiple services included in the microservice; The proxy module is further configured to send the registration information; A registration center module, configured to receive the registration information to complete the registration of the service; The pre-configuration center module is used to send the changed configuration information of the target service to the proxy module corresponding to the target service when the registration information of the target service in the microservice is changed.
6. A microservice registration device, characterized in that: The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the method according to any one of claims 1 to 2 is implemented.
7. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the method according to any one of claims 1 to 2.
8. A computer program product, characterized in that When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device is caused to perform the method according to any one of claims 1 to 2.
Citation Information
Patent Citations
Service management method and device, storage medium and electronic equipment
CN110032392A
Micro-service registration method and device, micro-service discovery method and device, storage medium and electronic equipment
CN110990081A