Micro-service architecture implementation method without independent registration center

Abstract

According to the micro-service architecture implementation method without the independent registration center provided by the invention, the micro-services can complete the processes of function registration, function discovery, function calling and the like without depending on the independently deployed registration center, so that the micro-services are not influenced by the fault of the registration center, and the micro-service architecture implementation method has higher stability and is more convenient to use. The implementation method of the micro-service architecture without the independent registration center comprises the following steps: each micro-service establishes a connection through a configuration file, and actively sends a function list of the micro-service to other connected micro-services, and the other micro-services cache the function lists and merge the same functions to obtain the micro-service architecture without the independent registration center. And finally, each micro-service which is connected with each other contains a complete function list. And when other micro-service functions need to be called, directly taking out a real column of a specified function from the locally cached function list according to a certain load balancing algorithm for calling.

Description

Technical Field

[0001] The present invention relates to the field of microservice technology in the computer field, and in particular to a method for implementing a microservice architecture without an independent registration center. Background Art

[0002] Microservice is a computer software technology architecture. Its core idea is to divide a large system or complex application into multiple service architectures. Each service coordinates and cooperates with each other to provide users with ultimate value. Each service has an independent life cycle and can be maintained and deployed separately. Qualified business modules are loosely coupled, which makes more efficient use of computer resources than traditional applications. Application expansion is more flexible, and can handle functional and performance bottlenecks by extending components. In a computer information system with a more complex microservice architecture, the number of microservices is usually large, such as dozens or even hundreds. As a whole computer information system, these microservices usually have a more complex mutual calling relationship. In order to solve the complexity of the calling relationship between microservices, the existing technical solutions usually adopt the method of deploying an independent registration center (that is, a component in the microservice architecture that records the instance information of each service). Each microservice registers its functions in the registration center. When a service needs to call other services, it only needs to obtain a required service instance from the registration center for calling.

[0003] The basic principle of the existing microservice registration center technical solution is: the service provider (i.e. the provider of the microservice function, also known as the function callee) registers its network address and other information to the registration center when it starts. The registration center stores this data, and the service consumer (i.e. the user of the microservice function, also known as the function caller) obtains the address of the service provider from the registration center and calls the service provider's interface through the address. Each microservice communicates with the registration center using a certain mechanism (such as heartbeat). If the registration center cannot communicate with a microservice for a long time, the instance will be deregistered. When the network address of a service changes (such as the increase of instances or changes in IP, etc.), it will re-register with the registration center.

[0004] The main disadvantage of the existing microservice technology architecture based on the registration center is that the calls between various microservices are strongly dependent on the registration center. Once the registration center fails, the service provider will not be able to register the service normally, and the service consumer will not be able to obtain the service list normally, which will lead to the overall failure of the computer information system. Summary of the invention

[0005] In view of the defects of the prior art, the present invention provides a method for implementing a microservice technology architecture that does not rely on an independent registration center, so that in a computer information system implemented based on the present microservice technology architecture, each microservice can complete the process of function registration, function discovery and function call without relying on an independently deployed registration center, so that in this type of computer information system, there is no need to independently deploy the registration center component, and thus it will not be affected by the failure of the registration center, so that the computer information system based on the present invention has higher stability. In addition, since it does not rely on an independent registration center, the computer information system based on the present invention also has more flexibility, scalability and possibility in deployment. In specific implementation, each microservice will actively send its own function list to other connected microservices, and other microservices will cache these function lists and merge the same functions, and finally realize that each interconnected microservice contains a complete function list. When it is necessary to call other microservice functions, directly from the locally cached function list, according to a certain load balancing algorithm, take out a real column of the specified function and call it. In addition, each microservice will update the local function list in real time through the heartbeat mechanism, for example, a new function is added or a faulty function is deleted from it.

[0006] The technical solution of the present invention is as follows: (1) Each microservice instance of this embodiment is provided with a configuration file in XML format, the contents of which mainly include the ID number of the microservice instance, IP address and port, function list, plug-in configuration, information of other microservice instances to be connected with it, task configuration, personalized settings, HTTP port and HTTP function mapping list. It should be noted that in some embodiments, the configuration file may be in other formats, such as JSON format, INI format, etc. A microservice instance refers to a microservice application.

[0007] (2) When the microservice instance is started, it reads the other microservice instance information configured in the configuration file described in (1), and creates a corresponding connection based on the read information. Taking microservice A creating microservice B as an example, the process of creating a connection is as follows: microservice A creates a SOCKET connection to microservice B based on the IP and port information of microservice B in the configuration file. After microservice B receives the event of connection creation by microservice A, it parses the IP address and port information of microservice A contained in the event and sends an "MDPW_READY" message to microservice A. After microservice A receives the "MDPW_READY" message sent by microservice B, the main connection is successfully established. It should be noted that in this embodiment, while the main connection between microservices is established, a connection specifically for function list transmission will also be established separately. In some embodiments, there may be no connection specifically for function list transmission, but the main connection between microservices is reused.

[0008] (3) After the connection between microservice instances is established, the thread dedicated to function registration will detect that a new connection to other microservice instances has been established. When the next function registration heartbeat is triggered, the microservice instance will send its supported function list to other microservice instances through the "MDPW_REGISTER" message. It should be noted that whether to register a function can be determined by the configuration item "<reg_service> " is configured. If the value of this configuration item is "true", the function registration is performed, otherwise the function registration is not performed. The "function registration" in the above content refers to the action of sending the function list to other microservice instances through the "MDPW_REGISTER" message.

[0009] (4) The "MDPW_REGISTER" message mentioned in (3) above mainly includes two parts. The first is the ID number of the microservice instance that sends this "MDPW_REGISTER" message; the second is the function name. When the microservice instance receives the "MDPW_REGISTER" message, it will parse out the microservice instance ID number and function name contained therein, and merge the function into the local function list. It should be noted that the same function may have multiple service providers, that is, multiple instances of the same function. If the same function has multiple instances, when making a function call, a certain load balancing algorithm will be used to calculate a suitable instance for calling.

[0010] (5) It should be noted that the function registration heartbeat described in (3) uses a timed task mechanism and is triggered at fixed intervals. It should be further noted that not every function registration heartbeat actually sends an "MDPW_REGISTER" message. The "MDPW_REGISTER" message is only sent when the local service list changes or the connection is disconnected and reconnected. This mechanism greatly reduces the network data transmission generated by function registration between microservice instances, reduces network data transmission pressure, and saves network resources for business data transmission.

[0011] (6) In the scenario where two microservice instances are connected, if microservice instance A is configured to connect to microservice instance B in its configuration file, but microservice instance B is not configured to connect to microservice instance A in its configuration file. In this case, after microservice instance A starts and connects to microservice instance B, microservice instance B will also create a connection to microservice instance A. Then, the functions of microservice instance A can be called through microservice instance B. In the above scenario, if the value of the personalized setting "active_register" is configured to "true" in the configuration file of microservice instance B, then after the connection is established, microservice instance B will still register its functions with microservice instance A. Correspondingly, the functions of microservice instance B can also be called through microservice instance A.

[0012] (7) Take the example of calling function b1 of microservice instance B through microservice instance A to explain the technical implementation of function calling between microservice instances. Assume that microservice instance B has been connected to microservice instance A and has registered its functions (including b1) with microservice instance A.

[0013] ① The external application sends a business request to microservice instance A. Microservice instance A receives the business request message and parses the function name b1 contained in the request; ② Microservice instance A searches for function name b1 from its function list, and obtains the service provider microservice instance B associated with it based on function name b1; ③Add the ID number of the current microservice instance A to the routing list of the business request message, and send the business request to microservice instance B; ④ Microservice instance B receives the business request message and parses the function name b1 contained in the request; ⑤ Microservice instance B searches for function name b1 from its function list and obtains a function instance of function b1. If the function instance is a local function, it distributes the business request message to the business function processing module for business processing; ⑥ After the business is processed, a business request response message is created, and the business request response message has a routing list consistent with the business request message; ⑦ According to the routing list of the business response message, send the business response message to microservice instance A; ⑧ Microservice instance A receives the business response message and continues to send the business response message to the external application according to its routing list; ⑨The external application receives the service response message and the service request ends.

[0014] (8) In step ⑤ of (7) above, if the function instance is not a local function, the ID number of the current microservice instance is added to the routing list of the business request message, and the business request message is forwarded to the corresponding microservice instance. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The features and advantages of the present invention can be better understood after reading the detailed description of the embodiments of the present disclosure in conjunction with the following drawings. In the drawings, the components are not necessarily drawn to scale, and components with similar related properties or features may have the same or similar reference numerals.

[0016] Figure 1 It is a schematic diagram of function registration and calling under the existing microservice technology architecture.

[0017] Figure 2 This is a schematic diagram of function registration and calling under the technical architecture of this application.

[0018] Figure 3 This is a flowchart of establishing connections between microservices using the technical architecture of this application.

[0019] Figure 4 This is a flowchart of implementing function registration between microservices based on the technical architecture of this application.

[0020] Figure 5 This is a flowchart of implementing function calls between microservices based on the technical architecture of this application. DETAILED DESCRIPTION

[0021] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. Note that the aspects described below in conjunction with the accompanying drawings and specific embodiments are only exemplary and should not be construed as limiting the scope of protection of the present invention in any way. It should also be noted that, for ease of description, only the parts related to the invention are shown in the accompanying drawings. The dotted lines in the figure represent the process of function registration and obtaining a function list, and the solid lines represent the process of function call.

[0022] Figure 1 It is a schematic diagram of the function registration and call relationship in a computer information system implemented with the existing microservice technology architecture. Its basic components include: service consumers, a registration center, and several microservice instances. Its typical feature is that it has one or more independently deployed registration center components. It should be noted that the components of the above system are not limited to the above parts, and may also include load balancing components, configuration management components, log and monitoring components, and API gateway components. In order to simplify the description, they are not shown in the accompanying drawings, but it does not mean that this embodiment only includes the contents shown in the accompanying drawings. It should also be noted that the above-mentioned "service consumer" refers to the component within the system that needs to request other microservice functions, which is usually also a microservice instance.

[0023] Attached Figure 1 The basic operation process of the computer information system shown includes: Microservice A and microservice B register the function lists they provide to the outside world with the registration center. The registration center maintains a complete function list based on the received function list. The function list contains the instance information of each function and the address information required to call these function instances.

[0024] The service consumer obtains the function instance information to be called from the registration center, and uses the obtained function instance information to initiate the function call. It should be noted that in this type of embodiment, when the service consumer makes a specific function call, the function provided by microservice A can only call microservice A, and the function provided by microservice B can only call microservice B. The function provided by microservice B cannot be called through microservice A, and vice versa.

[0025] Figure 2 It is a schematic diagram of the function registration and calling relationship in the computer information system implemented by the microservice technology architecture of the present application. Its basic components include: service consumers and several microservice instances, but do not include a registration center. Its typical feature is that there is no need to independently deploy a registration center component. It should be noted that the components of the above system are not limited to the above parts, and may also include load balancing components, configuration management components, log and monitoring components, and API gateway components. In order to simplify the description, they are not shown in the accompanying drawings, but this does not mean that this embodiment only includes the contents shown in the accompanying drawings. It should also be noted that the above-mentioned "service consumer" refers to the component within the system that needs to request other microservice functions, which is usually also a microservice instance.

[0026] Attached Figure 2 The basic operation process of the computer information system shown includes: A connection is established between microservice A and microservice B, and function registration is performed. At this time, both microservice A and microservice B have a complete function list.

[0027] Microservice A and Microservice B establish connections with the service consumer and register their respective function lists with the service consumer. At this time, the service consumer also has a complete function list.

[0028] The service consumer obtains the function instance from the locally cached function list and initiates a function call.

[0029] It should be noted that whether to establish a connection between microservice A and microservice B, between them and the service consumer, and whether to register functions can all be configured through the configuration file. Figure 2The situation shown is that microservice A and microservice B establish a connection and register functions, and microservice A and microservice B establish a connection with the service consumer, but only one-way function registration is performed, and the service consumer does not register functions with microservice A and microservice B. In this case, the service consumer can call the functions provided by microservice A and microservice B respectively, and can also call the functions provided by microservice B through microservice A. Conversely, it can also call the functions provided by microservice A through microservice B.

[0030] Assume that microservice A provides functions S1 and S2, and microservice B provides functions S2 and S3. The following table describes the above additional functions. Figure 2 In the above scenario, the service lists of service consumers, microservice A and microservice B are as follows: Microservice A Microservice B Serving consumers S1-A S1-A S1-A|B S2-A|B S2-A|B S2-A|B S3-B S3-B S3-A|B It can be seen that microservice A, microservice B and service consumers all have three functions S1, S2 and S3. The S2 function of microservice A and microservice B has two function instances A and B. The three functions of the service consumer all have two function instances A and B.

[0031] It should be noted that when the connection and function registration configuration between microservices in the system changes, the function list of each microservice will change accordingly. It should be further noted that when registering functions between microservices, whether to register local functions other than those of the microservice can be controlled by configuration, that is, functions registered from other microservices cannot be registered externally.

[0032] Figure 3 This is a flowchart of establishing a connection between microservices using the technical architecture of this application. This flowchart shows the process of establishing a connection between two microservice instances A and B in a computer information system implemented using the microservice technical architecture of this application.

[0033] Step 301: Microservice instance A starts. This step responds to the user's startup operation. In this embodiment, the user's startup operation is to enter a specific startup command in the terminal command line of the computer operating system. In some optional implementations, you can also double-click the executable file with a mouse or click the start button on the graphical interface. The premise of the startup operation is that the various configurations in the configuration file of the microservice instance are correctly configured, otherwise the startup may fail.

[0034] Step 302 reads the configuration file to obtain configuration information for establishing a connection. This step is automatically triggered in response to the microservice instance being started. In this embodiment, the configuration information includes an IP address, a port, whether to register a function, and a custom name, wherein the IP address and port are used to create a SOCKET connection, the whether to register a function is used to determine whether to register a function with the connection after the connection is established, and the custom name is a name customized by the microservice instance for the convenience of managing the connection.

[0035] Step 303: Microservice instance A creates a SOCKET connection to microservice instance B according to the configuration information read in step 302. This step is automatically triggered in response to reading the configuration information.

[0036] It should be noted that the SOCKET connection created here is not yet in a ready state. It is necessary to receive the "MDPW_READY" message sent by the other party before marking the SOCKET connection as ready. A SOCKET connection in an unready state cannot be used to transmit business data.

[0037] In step 304, microservice instance B responds to the event of microservice instance A creating a SOCKET connection in step 303, and creates a SOCKET connection to microservice instance A through the IP address and port information of microservice instance A parsed from the event.

[0038] It should be noted that the reason why microservice instance B can respond to the event of microservice instance A creating a SOCKET connection is that the microservice implemented based on the present invention will create an event listening device on the SOCKET connection of its bound listening port, and when there is a connection to the listening port, a specific event will be triggered.

[0039] Based on the above steps 303 and 304, it can be seen that the connection between the microservices implemented based on the present invention is bidirectional. As an example, assuming that microservice instance A listens to port 5555 and microservice instance B listens to port 5556, after the connection is established between them, microservice instance A creates a SOCKET connection connected to port 5556, and microservice instance B creates a SOCKET connection connected to port 5555.

[0040] Step 305: Microservice instance B sends an "MDPW_READY" message through the SOCKET connection to microservice instance A created in step 304. This step is automatically triggered in response to the connection being created.

[0041] The "MDPW_READY" message mainly contains information such as the microservice instance ID, IP address, and port that sent the message.

[0042] Step 306: Microservice instance A receives the "MDPW_READY" message sent by microservice instance B in step 305, parses the microservice instance ID, IP address, port and other information in the message, and marks the primary connection to microservice instance B as ready. This step is in response to receiving the "MDPW_READY" message.

[0043] At this point, the connection between the two microservice instances is established.

[0044] Figure 4 This is a flowchart of implementing function registration between microservices using the technical architecture of this application. This flowchart shows the process of function registration between two microservice instances A and B in a computer information system implemented using the microservice technical architecture of this application.

[0045] In step 401, microservice instance A and microservice instance B are started and successfully connected. This is the prerequisite for function registration between the two microservice instances. It should be noted that whether function registration is performed between the two microservice instances depends on their respective configurations in addition to normal startup and connection establishment. Whether function registration is performed between the two interconnected microservice instances, and whether it is one-way registration or two-way registration can be configured according to actual needs. One-way registration means that only one microservice instance performs function registration with another microservice instance, and the other microservice instance does not perform reverse function registration; two-way registration means that both microservice instances perform function registration with each other.

[0046] In this embodiment, microservice A and microservice B are configured as a bidirectional registration relationship.

[0047] The microservice instance that establishes the connection in step 402 sends an "MDPW_REGISTER" message to the other party. The "MDPW_REGISTER" message contains a list of functions that the microservice instance can provide. It should be noted that the "MDPW_REGISTER" message is also sent bidirectionally in a microservice instance configured for bidirectional registration. As an example, in this embodiment, microservice instance A will send an "MDPW_REGISTER" message to microservice instance B, and microservice instance B will also send an "MDPW_REGISTER" message to microservice instance A. In addition, in this embodiment, the function list in the "MDPW_REGISTER" message is organized in JSON format. In some other embodiments, different forms of function list organization may also be used.

[0048] In this embodiment, the function registration between microservice instances is driven mainly in the form of scheduled tasks. The implementation form is that each microservice instance contains an independent thread dedicated to function registration. In the thread execution function, the thread sleep function is used to trigger the function registration every fixed time, such as 30 seconds. It should also be noted that the "MDPW_REGISTER" message is not actually sent every time the function registration is triggered. It will only be actually sent in the following situations: ① The function registration is triggered for the first time after the microservice instance is started; ②The function list has changed; ③A new connection is established; ④Disconnect and then reconnect.

[0049] It should also be noted that the processing of "invalid function registration" in this embodiment. The "invalid function registration" means that after a microservice instance receives a function registered by another microservice instance, it reversely registers the function to the microservice instance that provides the function. "Invalid function registration" will lead to invalid extension of the function call path, wasting network resources and computing resources. As an example, microservice instance A registers its unique function a to microservice instance B, and microservice instance B reversely registers function a to microservice instance A. As a result, microservice instance A has two instances A and B of function a, and microservice instance B has one instance A of function a. At this time, if an external request is made for function a of microservice instance A, microservice instance A may forward the request to microservice instance B, while microservice instance B has only one instance of function a, so it can only forward the request back to microservice instance A. If there is no corresponding control mechanism for this process, it may be executed in an indefinite number of cycles, but the final request handler can only be microservice instance A. It can be seen that "invalid function registration" will cause requests to flow invalidly between microservice instances, wasting network resources and computing resources.

[0050] In this embodiment, the microservice instance will filter the list of functions to be sent when registering functions, and remove the functions provided only by the other party from the list of functions to be sent, so as to avoid the occurrence of "invalid function registration".

[0051] Step 403: The microservice instance parses the received "MDPW_REGISTER" message and merges the parsed function list into the local function list. This step is in response to receiving the "MDPW_REGISTER" message. The merging of the function list is the operation of taking the union of the local function list and the received function list. The same functions are merged with their instances, and different functions are appended to the function list.

[0052] At this point, the function registration between the two microservice instances is completed.

[0053] Figure 5This is a flowchart for implementing inter-microservice function calls using the technical architecture of this application. This flowchart shows the process of an external application calling function b1 of microservice instance B through microservice instance A in a computer information system implemented using the microservice technical architecture of this application.

[0054] Step 501: Microservice instance A and microservice instance B start, establish a connection and complete function registration. This is the premise for function calls to be made between the two microservice instances.

[0055] In step 502, microservice instance A responds to receiving a service request sent by an external application. The service request may come from three sources: one is initiated by an external application using the access program provided by the technical architecture of this application; the second is initiated via HTTP; and the third is from other microservice instances implemented using the technical architecture of this application.

[0056] The message type of the business request is "MDPW_REQUEST". The "MDPW_REQUEST" message mainly includes the business request initiator information, function name, request data, authentication information, routing information, etc. It should be noted that other message types involved in this application also include the above content. The format of the request data is determined according to the implementation logic of the specific function, and is usually a certain format agreed upon in advance by the developer of the specific function and the function requester. In this embodiment, there are two formats of request data, one is JSON format and the other is a string.

[0057] In step 503, microservice instance A responds to receiving a business request sent by an external application and parsing the function name of the business request, and obtains an instance of the function from the local function list.

[0058] The process of obtaining a specific function instance is a process that depends on a certain load balancing algorithm, and developers can independently implement the algorithm according to actual needs. In this embodiment, a load balancing algorithm based on average distribution is provided. The specific implementation method is to number all instances of a certain function, and use a cursor to record the number of the last instance obtained. After each function instance is obtained, the cursor moves forward one number on the function instance list. After reaching the maximum number, the cursor is modulo the number of instances, thereby resetting the cursor to the beginning of the function list.

[0059] In step 504, microservice instance A responds to obtaining an available function instance. As an example, assuming that the function instance is microservice instance B, microservice instance A will add its ID number to the routing list of the service request message and send the service request message to microservice instance B.

[0060] In step 505, microservice instance B responds to the service request message sent by microservice instance A in step 504 by parsing the function name of the service request and obtaining an instance of the function from the local function list. It should be noted that it is assumed here that the function instance obtained is microservice instance B itself, which may not be the case in actual situations. If the function instance obtained is another microservice instance, microservice instance B will continue to forward the request. For details, please refer to steps 503 and 504.

[0061] It should also be noted that this embodiment also implements a mechanism for controlling "invalid function forwarding". The "invalid function forwarding" means: assuming that both microservice instance A and microservice instance B provide function b1, after completing the function registration, both microservice instance A and microservice instance B will contain two instances of function b1. At this time, if function b1 of microservice instance A is requested, the request may be forwarded to microservice instance B. Similarly, microservice instance B may continue to forward the request back to microservice instance A. At this time, the operation of microservice instance B forwarding the request back to microservice instance A is "invalid function forwarding".

[0062] This embodiment implements the control of "invalid function forwarding" by checking the routing list of the request message when obtaining the function instance. When obtaining the function instance, if the obtained function instance is already in the routing list of the request, the function instance is excluded, the request message is not forwarded, and other available function instances are obtained. In this way, the control of "invalid function forwarding" can be implemented. It is recommended to combine Figure 4 The relevant instructions about "invalid function registration" in step 402 are understood.

[0063] In step 506, microservice instance B responds to obtaining an available function instance, which is microservice instance B itself, and at this time distributes the business request to the business function processing module for actual business function processing. In this embodiment, the business function processing module is in the form of a loadable dynamic link library, and each function is an independent dynamic link library. Developers can use the unified interface standard provided by the technical architecture of this application to create specific business function modules.

[0064] After the business request processing is completed in step 507, a business request response message will be created based on the business request message, and the business request response message will be sent to the sender of the corresponding business request message, which is microservice instance A. The message type of the business request response message is "MDPW_REPLY". After the business request response message is created, it has the same routing list as the corresponding business request message. The business request response message is finally forwarded back to the initiator of the business request as its routing list is rolled back.

[0065] In step 508, microservice instance A responds to receiving the business request response message sent by microservice instance B in step 507, and continues to forward the business request response message to the initiator of the corresponding business request according to the routing list of the business request response message, which is the external application here.

[0066] The beneficial effects achieved by the present invention compared with the prior art are as follows: the present invention provides a method and device for implementing a microservice technology architecture that is not dependent on an independent registration center, so that in a computer information system implemented based on the present microservice technology architecture, each microservice can complete the processes of function registration, function discovery, and function call without relying on an independently deployed registration center, so that in this type of computer information system, there is no need to independently deploy a registration center component, and thus it will not be affected by the failure of the registration center, so that the computer information system based on the present invention has higher stability. In addition, since it does not rely on an independent registration center, the computer information system based on the present invention also has more flexibility, scalability, and possibilities in deployment.

[0067] In summary, the present application provides a method and device for implementing a microservice technology architecture that is independent of an independent registration center, so that the computer information system based on the present invention has higher stability, as well as more flexibility, scalability and possibilities in system deployment.

[0068] It will be appreciated by those skilled in the art that the steps, measures, and schemes in the various operations, methods, and processes discussed in this application may be alternated, altered, combined, or deleted. Furthermore, other steps, measures, and schemes in the various operations, methods, and processes discussed in this application may also be alternated, altered, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and schemes in the prior art that are similar to those disclosed in this application may also be alternated, altered, rearranged, decomposed, combined, or deleted.

[0069] The above description is only a partial implementation method of the present application and an explanation of the technical principles used. It should be pointed out that for ordinary technicians in this technical field, the scope of the invention involved in this application is not limited to the technical solution composed of a specific combination of the above-mentioned technical features, but should also cover related improvements and modifications without departing from the above-mentioned inventive concepts and principles. These improvements and modifications should also be regarded as the scope of protection of this application.

Claims

1. A method for implementing a microservice architecture without an independent registration center, characterized in that: The steps include: S1, establish a connection: when the microservice instance starts, read the information of other microservice instances in the configuration file and create a corresponding connection; S2, function registration: a microservice instance sends a list of functions it supports to other microservice instances; S3, function call: the external application sends a business request to the microservice instance.

2. A method for implementing a microservice architecture without an independent registration center as claimed in claim 1, characterized in that The establishing of the connection comprises: S1: The microservice instance creates a SOCKET connection to other microservice instances based on the IP and port information of other microservice instances in the configuration file; S2: After receiving the connection creation event, other microservice instances parse and send the IP address and port information of the microservice instance contained in the event; S3: After the microservice instance receives the IP address and port information sent by other microservice instances, the primary connection is established successfully.

3. A method for implementing a microservice architecture without an independent registration center as claimed in claim 2, characterized in that The function registration includes: S1: When the function registration heartbeat is triggered, the microservice instance sends a function list to other microservice instances through an "MDPW_REGISTER" message, where the "MDPW_REGISTER" message includes the ID number of the microservice instance that sends the "MDPW_REGISTER" message and the function name; S2: After receiving the "MDPW_REGISTER" message, the microservice instance will parse out the microservice instance ID number and function name contained in it, and merge the function into the local function list.

4. A method for implementing a microservice architecture without an independent registration center as claimed in claim 3, characterized in that The function call includes: S1: The external application sends a business request to the microservice instance. After receiving the business request message, the microservice instance parses the function name contained in the request; S2: The microservice instance searches for the function name from its function list and obtains other microservice instances associated with it based on the function name; S3: The microservice instance adds its ID number to the routing list of the business request message and sends the business request to other microservice instances; S4: Other microservice instances receive the business request message and parse the function name contained in the request; S5: Other microservice instances search for the function name from their function lists, obtain a function instance of the function name, and distribute the business request message to the business function processing module for business processing, or add the ID number of the current microservice instance to the routing list of the business request message, and continue to forward the business request message to the corresponding microservice instance; S6: After the service processing is completed, a service request response message is created, and the service request response message has a routing list consistent with the service request message; S7: according to the routing list of the business response message, send the business request response message to the microservice instance described in S1 above; S8: The microservice instance described in S1 receives the business response message and continues to send the business request response message to the external application according to its routing list; S9: The external application receives the service request response message, and the service request ends.

5. A method for implementing a microservice architecture without an independent registration center as claimed in claim 2, characterized in that: At the same time as the main connection described in S3 is established, a separate connection dedicated to the transmission of the function list is established.

6. A method for implementing a microservice architecture without an independent registration center as claimed in claim 3, characterized in that: When the function registration heartbeat is triggered, the "MDPW_REGISTER" message will only be actually sent if the local service list changes or the connection is disconnected and reconnected.

7. A method for implementing a microservice architecture without an independent registration center as claimed in claim 3, characterized in that The function list in S1 is screened, and functions provided only by the other party's microservice implementation example are removed from the list of functions to be sent.

Images