A distributed service registration and consensus mechanism scheduling method and system

Abstract

The present invention discloses a method and system for scheduling service registration and consensus mechanism based on distributed service registration and consensus mechanism. By deploying multiple registration center nodes in a service scheduling platform and using the Raft algorithm to select a master node to be responsible for the work in the current stage, the load pressure of a single registration center is transferred to multiple nodes. The stability and disaster recovery capability of the Themis system are improved by designing multiple modules such as a coroutine pool and an exception handling module and optimizing the workflow. At the same time, a consensus mechanism scheduling interface for the managed services is provided to the outside world, facilitating unified and effective management of the operation of the consensus mechanism, and having good scalability and convenience.

Description

Technical Field

[0001] The present invention belongs to the field of microservice registration and scheduling technology, and specifically relates to a distributed service registration and consensus mechanism scheduling method and system. Background Art

[0002] The current rise of internet informatization and technologies like big data and artificial intelligence has led to a continuous expansion in the number and scale of users on major websites and internet platforms, and explosive growth in both business types and the volume of information and data. Under this trend, central cloud servers responsible for data processing and storage, due to their limited computing resources and capabilities, are prone to low data processing efficiency, excessive load, and inability to effectively guarantee data security, which in turn impacts user experience and privacy protection.

[0003] With the rapid development of computer technology and the continuous expansion of website applications, conventional application architectures such as monolithic and vertical application architectures are no longer able to cope with various new challenges. More and more large platforms are transitioning from centralized to distributed architectures. Service-oriented distributed architecture (SOA) effectively improves the stability and scalability of the entire system by splitting the different services of the entire application and deploying them to different distributed servers. The microservices architecture further decentralizes SOA by removing the enterprise service bus and making services of different business types completely independent.

[0004] In this context, managing these fine-grained services becomes a key design element of a microservices platform. Furthermore, real-time changes in service status, such as an increase in the number of services in the system, automatic scaling of service nodes, and service restarts, place higher demands on service governance. Registries are used to automate service management and are being applied in some distributed scenarios. However, with increasing business volume, traditional registry architectures struggle to cope with high concurrency. Specifically, when many microservice nodes in a distributed architecture initiate service requests to the same registry node in the service scheduling platform, the service scheduling platform's efficiency decreases, impacting service quality and potentially even causing a system crash, rendering the entire service system inoperable. While multiple nodes working together in the service scheduling platform can alleviate system pressure, a unified solution is required to synchronize node status and information to ensure distributed consistency. System availability and operational efficiency also need to be considered. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to address the deficiencies in the above-mentioned existing technologies and provide a distributed service registration and consensus mechanism scheduling method and system to solve the technical problems that the service scheduling platform of the microservice architecture is difficult to cope with high concurrency scenarios and the consensus mechanism of the service is difficult to uniformly and effectively schedule.

[0006] The present invention adopts the following technical solutions:

[0007] A distributed service registration and consensus mechanism scheduling method includes the following steps:

[0008] S1. Themis system selectively enables and configures database connection and cluster synchronization according to its own needs;

[0009] S2. Define the mode and function of the configuration loader;

[0010] S3. Standardize the basic information of the Themis system, the results returned by Themis after processing data, the structure of username and password, the distributed service model registered in Themis, and the database mapping structure of the distributed service model registered in Themis;

[0011] S4. After the core business logic layer is initialized, two types of core businesses are started. Among them, the business operations provided by the business logic interface are called by the front-end controller to obtain the returned data or operation results, and the underlying data logic business is the necessary thread business required to maintain the normal operation of the Themis system functions;

[0012] S5. Themis system provides a call interface for managing the consensus mechanism through the core business logic layer. It performs related scheduling and management of the consensus mechanism through the call interface, obtains the scheduling operation results and data information from the business logic interface, and performs consensus mechanism scheduling.

[0013] S6. Forward HTTP / HTTPS requests received by the Themis system during operation to the corresponding front-end controller. At the same time, define the OpenAPI core interface provided by the project through the back-end routing, including service communication API and management operation API, and provide API operations to users;

[0014] S7. After receiving the HTTP / HTTPS request, the front-end controller authenticates, checks, and handles exceptions on the data, and then submits the legal and correct data to the corresponding business logic layer for processing;

[0015] S8. The registration service thread retrieves the relevant information from the business logic layer and sends it to the registration center for service information registration;

[0016] S9. During the operation of the Themis system, the registration center determines the viability of each service through the service heartbeat thread, deletes threads that are no longer alive, and obtains system status information regularly through the system status thread and records it;

[0017] S10. Submit the function execution tasks that need to be executed asynchronously when the Themis system is working to the coroutine pool, which is responsible for concurrently processing each task;

[0018] S11. If an internal exception occurs in the Themis system, the exception handler is responsible for capturing and processing the exception, and making system interrupt processing or printing related logs according to the exception type.

[0019] Specifically, in step S1, the database connection layer in the database connection provides database connection management, initialization, connection closing, and data difference processing to the database connection instance. Then, the database connection instance provides the database CURD and transaction functions to the outside through the database interface layer, and operates on the remote database and the local database. When the database connection module is selected to be turned on, data persistence is performed through the data persistence function to back up key system information. If the system crashes due to an external failure, when the system is re-initialized, the data backed up in the database is read into the memory through the database connection module to restore the data information. When cluster synchronization is selected to be turned on, cluster synchronization is performed by calling the Raft algorithm.

[0020] Specifically, in step S2, the configuration loader includes a service configuration loader, a database configuration loader, a service port loader, a listening port loader, a permission management loader, a cluster configuration loader, and a concurrent pool loader; the configuration loader is initialized when called by the initialization factory, and the variable parameters of the system are concentrated into a unified configuration file, and then the file is read, and the system's built-in system authentication, character checking, regular expression matching and other loading rules are used to check the read file. If an error occurs, an exception is thrown, and the system destruction factory is called to terminate the program.

[0021] Specifically, in step S3, the data model module adopts a three-tier architecture of namespace, cluster, and service name to construct the underlying data model, and stipulates the system basic information data model, the front-end return result model, the permission user name and password model, the database storage mapping service model, and the service model; and unifies the standards for the currently deployed system basic information, the result returned after processing the data, the structure of the user name and password, the distributed service model registered in the system, and the database mapping structure of the distributed service model registered in the system.

[0022] Specifically, in step S4, the core business logic layer includes the underlying data model instance, the scheduling center algorithm factory, the underlying data model instance management factory, the front-end controller data interception and inspection business, the core business, the database-related business, the communication API-related business, and the operation API-related business;

[0023] The underlying data model instance, the underlying data model instance management factory, the core business, the database-related business, and the scheduling center algorithm factory constitute the underlying data logic business, which is responsible for the front-end controller to call and obtain the returned data or operation results;

[0024] The front-end controller's data interception and inspection services, communication API-related services, and operation API-related services constitute the business logic interface, which is responsible for the necessary thread services required to maintain the normal operation of the entire system functions;

[0025] The core business logic layer's core operations include a registration service thread, a service heartbeat thread, and a system status check thread. The registration service thread is responsible for retrieving service information registered in the underlying concurrent queue by the business logic layer and sending the relevant information to the registration center for service registration. The service heartbeat thread is responsible for determining the viability of each service, and the system status thread periodically obtains and records system status information.

[0026] Specifically, in step S7, the front-end controller performs the following operations:

[0027] S701, the backend router sends the request to the corresponding frontend controller;

[0028] S702: The interceptor chain in the front-end controller performs the interception operation, verifies the relevant permissions of the request, and sends the request with legal permissions to the controller;

[0029] S703. If the user has enabled cluster fault tolerance and debug mode, the interceptor will also perform cluster role forwarding and debug log printing. At the same time, developers can implement corresponding interceptor plug-ins based on their business requirements and register them in the backend routing section.

[0030] S704: The controller performs exception handling on the data sent by the interceptor, binds the data with parameters, and then sends the request and data to the corresponding business layer through the backend business call function;

[0031] S705: The business layer performs specific operations such as adding, deleting, checking, and modifying the data according to the request.

[0032] Specifically, in step S10, the concurrent task processing of the coroutine pool is specifically as follows:

[0033] S1001. Package the tasks to be performed into inline body functions and exception body functions and pass them into the coroutine pool;

[0034] S1002: The coroutine pool uses the CreateWork method to receive the inline body function and exception body function packaged in S901 of this group, decorate and combine them with functions, and add them to an asynchronous call queue maintained in the coroutine pool;

[0035] S1003. If there is a free coroutine in the coroutine pool, the task in the asynchronous call queue is retrieved through the channel for execution. Otherwise, the task is called and executed only when a free coroutine is available after the currently executing task is completed.

[0036] S1004. If an exception occurs when the coroutine executes the task, the exception handling function packaged in the task is called to handle the exception;

[0037] S1005. After each task is completed, the coroutine pool locks and determines whether the current number of working coroutines is greater than the previously defined number of core threads. If it is greater, it jumps out of the loop and ends the coroutine. If it is less, it returns to the loop to monitor the asynchronous channel.

[0038] Specifically, in step S11, the exception handling is as follows:

[0039] S1101. Register and expand custom exception handlers in the exception handling factory according to your business needs.

[0040] S1102. When the system captures an exception, it sends the exception to the exception handler factory by calling the exception handler interface;

[0041] S1103. The exception handler factory processes the exceptions in a hierarchical manner and contacts the exception handlers of the corresponding levels to distribute the exceptions.

[0042] S1104. Each exception handler responds to the exception. The user exception handler only causes log printing, while other exception handlers cause system interruption and log printing at the same time.

[0043] Specifically, when the system is destroyed, the system destruction factory is called to shut down the database module, cluster module, concurrent pool, and service module in sequence to destroy the system.

[0044] In a second aspect, an embodiment of the present invention provides a distributed service registration and consensus mechanism scheduling system, including:

[0045] In the initial module, the Themis system selectively enables and configures database connections and cluster synchronization according to its own needs;

[0046] Custom modules, which can customize the modes and functions in the configuration loader according to your own needs;

[0047] The mapping module standardizes the basic information of the Themis system, the results returned by Themis after processing data, the structure of username and password, the distributed service model registered in Themis, and the database mapping structure of the distributed service model registered in Themis;

[0048] Business module, after the core business logic layer is initialized, two types of core businesses are started. The business operations provided by the business logic interface are called by the front-end controller to obtain the returned data or operation results. The underlying data logic business is the necessary thread business required to maintain the normal operation of the Themis system functions;

[0049] The calling module: Themis system provides a calling interface for managing the consensus mechanism through the core business logic layer. It performs related scheduling and management of the consensus mechanism through the calling interface, obtains the scheduling operation results and data information from the business logic interface, and performs consensus mechanism scheduling;

[0050] The forwarding module forwards the HTTP / HTTPS requests received by the Themis system during operation to the corresponding front-end controller. At the same time, it defines the OpenAPI core interface provided by the project through the back-end routing, including service communication API and management operation API, and provides users with specific API operations;

[0051] Exception handling module: After receiving HTTP / HTTPS requests, the front-end controller authenticates, checks, and handles exceptions on the data, and then submits the legal and correct data to the corresponding business logic layer for processing;

[0052] Registration module, the registration service thread extracts the relevant information from the business logic layer and sends it to the registration center for service information registration;

[0053] Judgment module: During the operation of the Themis system, the registration center judges the viability of each service through the service heartbeat thread, deletes threads that are no longer alive, and obtains system status information regularly through the system status thread and records it;

[0054] The processing module submits the function execution tasks that need to be executed asynchronously when the Themis system is working to the coroutine pool, which is responsible for concurrently processing each task;

[0055] Scheduling module: If an internal exception occurs in the Themis system, the exception handler is responsible for capturing and processing the exception, and making system interrupt processing or printing related logs according to the exception type.

[0056] Compared with the prior art, the present invention has at least the following beneficial effects:

[0057] A distributed service registration and consensus mechanism scheduling method. After the Themis system is started, users can selectively enable database connections, cluster synchronization modules, and define configuration loader properties. The core business logic layer provides a call interface for managing the consensus mechanism. The purpose is to enable users to configure specific functions according to their own needs, facilitate consensus mechanism scheduling for nodes managed by the registration center, and improve the scalability and availability of the entire system. After the user registers the service in the registration center, each module will perform authentication, exception handling, service registration, and survival judgment in turn. The function calls that need to be executed asynchronously by each module are processed through the coroutine pool. The benefit is that the reliability and stress resistance of the workflow are improved from all aspects, and the possibility of system interruption is reduced.

[0058] Furthermore, the Themis system can enhance its disaster recovery and resilience capabilities by optionally enabling the database connection module and cluster synchronization module, ensuring the consistency requirements of distributed services to a certain extent. When the database connection module is enabled, data persistence is performed at regular intervals through the system configuration file, storing registration information, service data, and node status information in a remote or local database. Users can also configure various persistence settings. In the event of a system downtime due to external environmental issues such as a power outage, this module retrieves and restores all recently stored information from the database after the external environment returns to normal, ensuring the system's ability to respond to special anomalies. When the cluster synchronization module is enabled, the system uses the Raft consensus protocol for cluster synchronization, dividing the registration center nodes into three states. The three-state state controller controls each node through the election process to select a working node. This advantage lies in the fair synchronization mechanism that divides the registration center nodes into different states, enabling information synchronization and coordination among multiple nodes, thereby reducing the burden on individual nodes. Furthermore, the Raft protocol is easy to implement, high-performance, and fault-tolerant, further improving the system's overall performance.

[0059] Furthermore, the Themis system facilitates dynamic parameter configuration through a configuration loader. For statically compiled languages, modifying data in the source program requires re-preprocessing, compiling, assembling, and linking the original program to obtain a new executable program, which greatly inconveniences operations and maintenance. Through the settings of this module, the system's variable parameters are centralized into a unified configuration file. The parameters in this file are loaded into memory. When parameters need to be modified, the program can be stopped and the file can be read and modified through a third-party module, thus eliminating the need for recompilation and facilitating system maintenance and modification.

[0060] Furthermore, the data model module is used to classify and define various types of data in the entire system. The advantage is that the data can be standardized uniformly, which enhances the understanding and convenience of data use by different developers, facilitates better code reuse through various data models during development, avoids repeated creation of objects due to unclear data definitions, and is conducive to future code development work and structural adjustments.

[0061] Furthermore, the core business logic layer consists of eight modules, divided into business logic interfaces and underlying data logic based on business type. This is because the Themis system needs to provide external services such as a registration center and a scheduling center, while also processing the underlying data model. The core business logic layer separates the application layer from the underlying logic, deploying distinct processing modules. The business logic interface connects to the front-end controller to perform application services such as service registration, while the separated underlying data logic provides support for the business logic interface. The underlying data logic sets read-write locks on the underlying data to enable concurrent read and write operations. Operations on the underlying data are asynchronously called with the business logic interface, enabling faster feedback and significantly improving the system's traffic disaster recovery. Specifically, the system registration thread in the core business is responsible for retrieving service information from the concurrent queue and sending it to the registration center for registration. This process selects appropriate nodes for the services in the queue based on load balancing strategies, and then performs HTTP / HTTPS and RPC calls. The service heartbeat thread is responsible for determining the liveness of each service, ensuring that service nodes proactively report their health status to the registration center node, avoiding the high computational and memory overhead incurred by proactive inquiries from the registration center. The system status thread periodically obtains and records system status information. Its purpose is to use asynchronous decoupling to put the obtained system information into a global variable. Information requests in the network are directly obtained from this variable, which greatly reduces the time spent on obtaining status information by calling the system API and facilitates concurrent calls.

[0062] Furthermore, when the front-end controller receives a network data processing request, it separates the data-related control operations from the specific business operations. The incoming request goes through three steps in sequence: forwarding by the back-end router, interception and execution by the interceptor, and execution by the controller. It is then handed over to the business layer for specific business operations such as addition, deletion, modification, and query. The advantage is that after the above two parts are separated, a more detailed division can be adopted for the handling of system exceptions, making the exception control mechanism more complete and reliable without affecting data operations, while improving the developer's focus and the clarity of the system architecture.

[0063] Furthermore, the coroutine pool maintains an asynchronous call queue to receive function tasks that need to be executed asynchronously by other modules and combines them with exception handling functions. At the same time, the number of working coroutines is controlled through the observer mode. The advantage is that the coroutines can be effectively reused through the work of the coroutine pool, avoiding excessive latency caused by frequent concurrent switching between coroutines, and ensuring the operating efficiency of the Themis system in high concurrency and high traffic scenarios.

[0064] Furthermore, the exception handling module categorizes program exceptions into different levels and configures corresponding exception handlers and system logs. It also allows developers to configure the exception handling methods required by their business. This facilitates hierarchical management of various exceptions during program execution, enabling the system to respond to them accordingly. This allows for full lifecycle exception capture, handling, and logging, enhancing the system's ability to handle exceptions.

[0065] Furthermore, when the system ends its operation, the database module, cluster module, concurrent pool, and service module are closed in sequence. The purpose is that when the system is destroyed, different modules need to perform operations such as memory release and thread exit in sequence to avoid data loss or leakage during destruction.

[0066] It can be understood that the beneficial effects of the second aspect mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here.

[0067] In summary, this invention provides a distributed service registration and consensus mechanism scheduling method and system, designing a system solution for distributed systems that supports the collaborative operation of multiple registration centers. Through a multi-faceted design encompassing the user layer, interface layer, core business layer, central data model, exception handling and database connection modules, and cluster synchronization solutions, high runtime concurrency, disaster resilience, and platform scalability are ensured. Furthermore, an external interface for managing the consensus mechanism is provided, enabling users to effectively schedule and manage the consensus mechanism within the distributed system.

[0068] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] Figure 1 This is a system architecture diagram for service registration and consensus mechanism scheduling in the present invention;

[0070] Figure 2 Configuration loading module architecture diagram for the present invention;

[0071] Figure 3 This is a diagram of the front-end controller architecture of the present invention;

[0072] Figure 4 This is the underlying data model architecture diagram of the present invention;

[0073] Figure 5 This is a diagram of the exception handling model architecture of the present invention;

[0074] Figure 6 This is a diagram of the database connection module architecture of the present invention;

[0075] Figure 7 This is a diagram of the concurrent pool model architecture of the present invention;

[0076] Figure 8 This is the core business logic model architecture diagram of the present invention;

[0077] Figure 9 This is a flowchart of the initialization of the cluster synchronization module of the present invention;

[0078] Figure 10 This is the architecture diagram of the cluster control module state controller of the present invention;

[0079] Figure 11 This is a schematic diagram of the consensus algorithm used by the cluster synchronization module in the present invention;

[0080] Figure 12 This is a comparison chart of the average latency between the coroutine pool and the native GMP concurrency model in the present invention;

[0081] Figure 13 This is a comparison chart of the best latency between the coroutine pool and the native GMP concurrency model in the present invention;

[0082] Figure 14 A diagram comparing the space consumption of objects stored in the system of the present invention and the traditional system;

[0083] Figure 15 This is a comparison chart of the time consumption for storing objects when the system of the present invention and the traditional system are working. DETAILED DESCRIPTION

[0084] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0085] In the description of the present invention, it is to be understood that the terms “include” and “comprise” indicate the presence of the described features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or collections thereof.

[0086] It should also be understood that the terms used in the present specification are only for the purpose of describing particular embodiments and are not intended to limit the present invention. As used in the present specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms unless the context clearly indicates otherwise.

[0087] It should be further understood that the term "and / or" as used in the present specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items. For example, A and / or B may represent: A alone, A and B simultaneously, or B alone. In addition, the character " / " herein generally indicates that the associated items are in an "or" relationship.

[0088] It should be understood that although the terms "first," "second," and "third" may be used to describe preset ranges in embodiments of the present invention, these preset ranges should not be limited to these terms. These terms are merely used to distinguish one preset range from another. For example, without departing from the scope of embodiments of the present invention, the first preset range may also be referred to as the second preset range, and similarly, the second preset range may also be referred to as the first preset range.

[0089] The word "if," as used herein, may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to the determination" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)," depending on the context.

[0090] The accompanying drawings illustrate various schematic diagrams of structures according to embodiments disclosed herein. These figures are not drawn to scale; for clarity, some details are exaggerated and some details may be omitted. The shapes of the various regions and layers shown in the figures, as well as their relative sizes and positional relationships, are merely exemplary and may deviate in practice due to manufacturing tolerances or technical limitations. Those skilled in the art may design regions / layers with different shapes, sizes, and relative positions as needed.

[0091] The present invention provides a method for scheduling service registration and consensus mechanism based on distribution. Aiming at the high concurrency requirements of the entire system and the operating efficiency requirements of the service scheduling system, relying on the concept of the traditional distributed microservice project registration center, a service scheduling platform for dynamic service discovery and node scheduling is proposed to solve the efficiency and stability problems faced by the system under high load conditions. The system provides a cluster synchronization solution, which adopts the Raft consensus algorithm as the consensus mechanism of the solution to ensure the high availability and distributed consistency of the system. In response to the problem that the context switching overhead of the system concurrent scheduling is too large and affects the performance, a scheduling mode based on the coroutine concurrent pool is proposed and a lightweight coroutine pool is designed to reduce the burden of system process scheduling. At the same time, in order to expand the security of service nodes, it also supports the service nodes managed by the system to access the blockchain network through the service scheduling system to improve the data security and system stability in the entire microservice architecture.

[0092] See also Figure 1 The present invention provides a system architecture for service registration and consensus mechanism scheduling based on distributed service registration and consensus mechanism scheduling, including a user layer, OpenAPI, a core business layer, a central data model, and an optional system disaster recovery and data backup module and a cluster synchronization module.

[0093] Among them, the user layer provides a console, multi-language SDK, a browser-supported management platform, and a customer and agent platform.

[0094] The user layer and the core business layer are connected through the OpenAPI interface.

[0095] The core business layer provides three main services: service management, configuration management, and tool modules.

[0096] The central data model is responsible for building the underlying data model, backing up related data, and performing secure concurrent processing.

[0097] Specifically, the entire system consists of 12 modules, namely configuration loader, front-end controller, data model module, exception handler, initialization / destruction factory, database connection module, concurrent pool, back-end routing, core business logic layer, cluster synchronization module, tool class, encryption and decryption module.

[0098] Among them, the core business logic layer is the core module of related blockchain scheduling and distributed service management businesses. The cluster synchronization module is a solution to problems such as system high availability and distributed consistency, and can be selected and enabled.

[0099] The present invention provides a distributed service registration and consensus mechanism scheduling method, comprising the following steps:

[0100] S1. Themis system performs initialization through the initialization factory, loading the log module, configuration module and concurrent pool module in the core module in sequence. Users can selectively enable and configure the database connection module and cluster synchronization module according to their own needs;

[0101] See also Figure 6 The database connection module calls the database connection instance. At the same time, the database connection layer in the database connection module provides the database connection instance with operations such as database connection management, initialization, connection closing, and data difference processing. The database connection instance then provides the database CURD and transaction functions to the outside world through the database interface layer, and operates on remote and local databases.

[0102] See also Figure 9 The cluster synchronization module has its own independent underlying data model and data model initialization factory. Its initialization process is as follows: the system initialization module makes initialization calls, initializes the cluster's underlying data model, adds basic high-availability cluster information, initializes UDP information transmission / reception queues, creates UDP information reception / sending services, creates core business data synchronization channels, and starts the state controller.

[0103] See also Figure 10 and Figure 11 The state controller reads the state of cluster nodes and distributes it to different states. These are then followed by three corresponding role controllers, which control the activities and actions of the three roles of the cluster nodes, completing the election process in the consensus algorithm. During synchronization, the cluster communicates via a UDP message transceiver, specifically responding to communication messages from the role controllers through UDP message receiving and sending queues and corresponding threads.

[0104] S2. Users customize the modes and functions in the configuration loader module according to their own needs, making it easier to modify system-related parameters later;

[0105] See also Figure 2 The configuration loader module includes 7 specific sub-modules, namely service configuration loader, database configuration loader, service port loader, listening port loader, permission management loader, cluster configuration loader, and concurrent pool loader. The sub-modules are called by the configuration loader through the calling interface. The configuration loader is initialized when called by the initialization factory, and the variable parameters of the system are concentrated into a unified configuration file. Then, the file is read and the system's built-in system authentication, character checking, regular expression matching and other loading rules are used to check the read file. If an error occurs, an exception is thrown and the system destruction factory is called to terminate the program.

[0106] S3. The data model module standardizes the basic system information, the results returned by Themis after processing data, the structure of username and password, the distributed service model registered in Themis, and the database mapping structure of the distributed service model registered in Themis;

[0107] See also Figure 4 The data model module uses a three-tier architecture consisting of namespace, cluster, and service name to construct the underlying data model. It specifies five basic data models: the system basic information data model (ComputerInfoModel), the front-end return result model (ResultModel), the permission username and password model (RootModel), the database storage mapping service model (ServerMapperModel), and the service model (ServerModel). These five basic models unify the basic information of the currently deployed system, the results returned after data processing, the username and password structure, the distributed service model registered with the system, and the database mapping structure of the distributed service model registered with the system.

[0108] S4. After the core business logic layer is initialized, two types of core services are started. The business logic interface provides business operations for the front-end controller to call to obtain returned data or operation results. The underlying data logic business maintains the necessary thread services required for the normal operation of the entire system functions.

[0109] See also Figure 8 The core business logic layer can be functionally divided into eight modules: underlying data model instances, the dispatch center algorithm factory, underlying data model instance management factory, front-end controller data interception and inspection services, core services, database-related services, communication API-related services, and operation API-related services. Modules are divided into two categories based on service type. The underlying data model instances, underlying data model instance management factory, core services, database-related services, and dispatch center algorithm factory constitute the underlying data logic services, responsible for invoking and retrieving returned data or operation results by the front-end controller. The front-end controller data interception and inspection services, communication API-related services, and operation API-related services constitute the business logic interface, responsible for the necessary thread services required to maintain the normal operation of the entire system. Within the core business logic layer, core services primarily include the registration service thread, the service heartbeat thread, and the system scheduled status check thread. As described above, the registration service thread is responsible for retrieving service information registered in the underlying concurrent queue by the business logic layer and sending the relevant information to the registration center for service registration. The service heartbeat thread is responsible for determining the liveness of each service. The system status thread periodically retrieves and records system status information.

[0110] S5. Themis system provides a call interface for managing the consensus mechanism through the core business logic layer. It performs related scheduling and management of the consensus mechanism through the call interface, obtains the scheduling operation results and data information from the business logic interface, and performs consensus mechanism scheduling.

[0111] S6. The backend routing module forwards the HTTP / HTTPS requests received by the Themis system during operation to the corresponding frontend controller. At the same time, it defines the OpenAPI core interface provided by the project through the backend routing, including service communication API and management operation API, and provides users with specific API operations;

[0112] S7. After receiving the HTTP / HTTPS request, the front-end controller authenticates, checks, and handles exceptions on the data, and then submits the legal and correct data to the corresponding business logic layer for processing;

[0113] See also Figure 3 , separate the front-end controller from the business processing module, and the operation of the incoming request includes the following steps:

[0114] S701, the backend router sends the request to the corresponding frontend controller;

[0115] S702: The interceptor chain in the front-end controller performs the interception operation, verifies the relevant permissions of the request, and sends the request with legal permissions to the controller;

[0116] S703. If the user has enabled cluster fault tolerance and debug mode, the interceptor will also perform cluster role forwarding and debug log printing. At the same time, developers can implement corresponding interceptor plug-ins based on their business requirements and register them in the backend routing section.

[0117] S704: The controller performs exception handling on the data sent by the interceptor, binds the data with parameters, and then sends the request and data to the corresponding business layer through the backend business call function;

[0118] S705: The business layer performs specific operations such as adding, deleting, checking, and modifying the data according to the request.

[0119] S8. The registration service thread in the core business of the Themis system extracts the relevant information from the business logic layer and sends it to the registration center for service information registration. The system can then run the service.

[0120] S9. During the operation of the Themis system, the registration center determines the viability of each service through the service heartbeat thread and deletes threads that are no longer alive. At the same time, the system regularly obtains system status information through the system status thread and records it;

[0121] S10. When each module processes a task, it submits the task to the coroutine pool, which is responsible for processing each task concurrently.

[0122] See also Figure 7 , the concurrent task processing of the coroutine pool specifically includes the following steps:

[0123] S1001. When other modules call the coroutine pool module, they package the tasks to be done into two types of functions, namely, inline body functions and exception body functions, and pass the packaged functions into the coroutine pool;

[0124] S1002: The coroutine pool calls the CreateWork method to receive the packaged inline body function and the corresponding exception body function, decorates and combines them with a large function, and adds them to an asynchronous call queue maintained in the coroutine pool;

[0125] S1003. If there is a free coroutine in the coroutine pool, the task in the asynchronous call queue is retrieved through the channel for execution. Otherwise, the coroutine is called and executed when a free coroutine is available after the currently executing task is completed.

[0126] S1004. If an exception occurs during the execution of a task by the coroutine, the exception handling function packaged in the task will be called to handle the exception.

[0127] S1005. After each task is completed, the coroutine pool locks and determines whether the current number of working coroutines is greater than the previously defined number of core threads. If it is greater, it jumps out of the loop and ends the coroutine. If it is less, it returns to the loop to monitor the asynchronous channel.

[0128] S11. If an internal exception occurs in the system, the exception handler is responsible for capturing and processing the exception, and making system interrupt processing or printing related logs according to the exception type;

[0129] See also Figure 5 The exception handler classifies exceptions into four levels: configuration file exception, database exception, system exception, and user exception. For each level of exception, a separate exception handler is set up, corresponding to the configuration file exception handler, database exception handler, system exception handler, and user exception handler. There is also a general exception handler to distribute exceptions. Exception handling specifically includes the following steps:

[0130] S1101. Developers selectively register and expand custom exception handlers in the exception handling factory based on their own business needs;

[0131] S1102: When the system captures an exception, it first sends the exception to the exception handler factory by calling the exception handler interface;

[0132] S1103. The exception handler factory processes the exceptions at different levels and contacts the exception handlers at the corresponding levels to distribute the exceptions.

[0133] S1104. Each exception handler responds to the exception. The user exception handler only causes log printing, while other exception handlers cause system interruption and log printing at the same time.

[0134] S12. If the user chooses to enable the database connection module, the system will use the data persistence function to persist data at regular intervals according to the parameters specified by the developer, backing up key system information. If the system crashes due to external failures, the database connection module will read the data backed up in the database into memory during system reinitialization to restore the data information.

[0135] S13. If the user chooses to enable the cluster synchronization module, the system will use the Raft algorithm to perform cluster synchronization through the module to improve system availability.

[0136] S14. When the developer needs to destroy the system, he calls the system destruction factory and shuts down the database module, cluster module, concurrent pool, and service module in sequence to destroy the system.

[0137] In another embodiment of the present invention, a distributed service registration and consensus mechanism scheduling system is provided, which can be used to implement the above-mentioned distributed service registration and consensus mechanism scheduling method. Specifically, the distributed service registration and consensus mechanism scheduling system includes module, module, module, module and module.

[0138] Among them, in the initial module, the Themis system selectively enables and configures database connection and cluster synchronization according to its own needs;

[0139] Custom modules, which can customize the modes and functions in the configuration loader according to your own needs;

[0140] The mapping module standardizes the basic information of the Themis system, the results returned by Themis after processing data, the structure of username and password, the distributed service model registered in Themis, and the database mapping structure of the distributed service model registered in Themis;

[0141] Business module, after the core business logic layer is initialized, two types of core businesses are started. The business operations provided by the business logic interface are called by the front-end controller to obtain the returned data or operation results. The underlying data logic business is the necessary thread business required to maintain the normal operation of the Themis system functions;

[0142] The calling module: Themis system provides a calling interface for managing the consensus mechanism through the core business logic layer. It performs related scheduling and management of the consensus mechanism through the calling interface, obtains the scheduling operation results and data information from the business logic interface, and performs consensus mechanism scheduling;

[0143] The forwarding module forwards the HTTP / HTTPS requests received by the Themis system during operation to the corresponding front-end controller. At the same time, it defines the OpenAPI core interface provided by the project through the back-end routing, including service communication API and management operation API, and provides users with specific API operations;

[0144] Exception handling module: After receiving HTTP / HTTPS requests, the front-end controller authenticates, checks, and handles exceptions on the data, and then submits the legal and correct data to the corresponding business logic layer for processing;

[0145] Registration module, the registration service thread extracts the relevant information from the business logic layer and sends it to the registration center for service information registration;

[0146] Judgment module: During the operation of the Themis system, the registration center judges the viability of each service through the service heartbeat thread, deletes threads that are no longer alive, and obtains system status information regularly through the system status thread and records it;

[0147] The processing module submits the function execution tasks that need to be executed asynchronously when the Themis system is working to the coroutine pool, which is responsible for concurrently processing each task;

[0148] Scheduling module: If an internal exception occurs in the Themis system, the exception handler is responsible for capturing and processing the exception, and making system interrupt processing or printing related logs according to the exception type.

[0149] In another embodiment of the present invention, a terminal device is provided, which includes a processor and a memory, wherein the memory is used to store a computer program, the computer program includes program instructions, and the processor is used to execute the program instructions stored in the computer storage medium. The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. It is the computing core and control core of the terminal, which is suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions to implement the corresponding method flow or corresponding function; the processor described in the embodiment of the present invention can be used for the operation of the distributed service registration and consensus mechanism scheduling method, including:

[0150] Themis system selectively opens and configures database connections and cluster synchronization according to its own needs; customizes the modes and functions in the configuration loader according to its own needs; standardizes the basic information of the Themis system, the results returned after Themis processes data, the structure of usernames and passwords, the distributed service model registered in Themis, and the database mapping structure of the distributed service model registered in Themis; after the core business logic layer is initialized, two types of core businesses are started. Among them, the business operations provided by the business logic interface are called by the front-end controller to obtain the returned data or operation results, and the underlying data logic business maintains the necessary thread business required for the normal operation of the Themis system functions; Themis system provides a call interface for the management consensus mechanism through the core business logic layer, performs related scheduling and management of the consensus mechanism through the call interface, and obtains the scheduled operation results and data information from the business logic interface to perform consensus mechanism scheduling; The Themis system receives HTTP / H The TTPS request is forwarded to the corresponding front-end controller, and the OpenAPI core interface provided by the project is defined through the back-end routing, including service communication API and management operation API, to provide API operations to users; after receiving the HTTP / HTTPS request, the front-end controller authenticates, checks, and handles exceptions on the data, and then submits the legal and correct data to the corresponding business logic layer for processing; the registration service thread takes out the relevant information in the business logic layer and sends it to the registration center for service information registration; during the operation of the Themis system, the registration center determines the survival of each service through the service heartbeat thread, deletes threads that are no longer alive, and obtains system status information regularly through the system status thread and records it; the function execution tasks that need to be executed asynchronously when the Themis system is working are submitted to the coroutine pool, which is responsible for concurrently processing various tasks; if an internal exception occurs in the Themis system, the exception handler is responsible for capturing and processing the exception, and making system interrupt processing or printing related logs according to the exception type.

[0151] In another embodiment of the present invention, the present invention further provides a storage medium, specifically a computer-readable storage medium (Memory), which is a memory device in a terminal device for storing programs and data. It can be understood that the computer-readable storage medium here can include both the built-in storage medium in the terminal device and, of course, the extended storage medium supported by the terminal device. The computer-readable storage medium provides a storage space, which stores the operating system of the terminal. In addition, one or more instructions suitable for being loaded and executed by the processor are also stored in the storage space. These instructions can be one or more computer programs (including program codes). It should be noted that the computer-readable storage medium here can be a high-speed RAM memory or a non-volatile memory (Non-Volatile Memory), such as at least one disk memory.

[0152] The processor may load and execute one or more instructions stored in a computer-readable storage medium to implement the corresponding steps of the distributed service registration and consensus mechanism scheduling method in the above embodiment; the processor may load and execute the following steps:

[0153] Themis system selectively opens and configures database connections and cluster synchronization according to its own needs; customizes the modes and functions in the configuration loader according to its own needs; standardizes the basic information of the Themis system, the results returned after Themis processes data, the structure of usernames and passwords, the distributed service model registered in Themis, and the database mapping structure of the distributed service model registered in Themis; after the core business logic layer is initialized, two types of core businesses are started. Among them, the business operations provided by the business logic interface are called by the front-end controller to obtain the returned data or operation results, and the underlying data logic business maintains the necessary thread business required for the normal operation of the Themis system functions; Themis system provides a call interface for the management consensus mechanism through the core business logic layer, performs related scheduling and management of the consensus mechanism through the call interface, and obtains the scheduled operation results and data information from the business logic interface to perform consensus mechanism scheduling; The Themis system receives HTTP / H The TTPS request is forwarded to the corresponding front-end controller, and the OpenAPI core interface provided by the project is defined through the back-end routing, including service communication API and management operation API, to provide API operations to users; after receiving the HTTP / HTTPS request, the front-end controller authenticates, checks, and handles exceptions on the data, and then submits the legal and correct data to the corresponding business logic layer for processing; the registration service thread takes out the relevant information in the business logic layer and sends it to the registration center for service information registration; during the operation of the Themis system, the registration center determines the survival of each service through the service heartbeat thread, deletes threads that are no longer alive, and obtains system status information regularly through the system status thread and records it; the function execution tasks that need to be executed asynchronously when the Themis system is working are submitted to the coroutine pool, which is responsible for concurrently processing various tasks; if an internal exception occurs in the Themis system, the exception handler is responsible for capturing and processing the exception, and making system interrupt processing or printing related logs according to the exception type.

[0154] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0155] See also Figure 14 and Figure 15 The performance of this system was tested by simulating the number of objects that need to be stored under normal working conditions and the number of objects synchronized during the consensus mechanism runtime. As the number of stored objects continues to increase, the space resources consumed by this system are significantly smaller than those of traditional systems. This is because this system combines the registration center with the consensus mechanism scheduling system. The consensus mechanism scheduling system can achieve deduplication, avoid repeated storage of node information on multiple nodes, and reduce storage space consumption. The registration center can manage node information in a unified manner. When the number of objects synchronized in the distributed system increases, the data synchronization delay generated by this system is significantly lower than that of traditional systems. This is because the design of the system coroutine pool reduces the switching delay between coroutines. At the same time, multiple modules adopt a more fine-grained functional division, which reduces the complexity of the system and further improves the system's work efficiency and performance.

[0156] See also Figure 12 and Figure 13 The performance of the present invention was tested by simulating large-scale high-concurrency computing. The average latency and best latency of the proposed system coroutine pool were shortened by 13.62% and 13.69% respectively compared with the native GMP model. The system has good concurrency capability and can better cope with high-load and high-concurrency application scenarios.

[0157] In summary, the present invention provides a distributed service registration and consensus mechanism scheduling method and system. By deploying multiple registration center nodes in a service scheduling platform and using the Raft algorithm to select a master node to be responsible for the current stage of work, the load pressure of a single registration center is transferred to multiple nodes. The stability and disaster recovery capabilities of the Themis system are improved by designing multiple modules such as the coroutine pool and the exception handling module and optimizing the workflow. At the same time, a consensus mechanism scheduling interface for the managed services is provided to the outside world, facilitating unified and effective management of the operation of the consensus mechanism, with good scalability and convenience.

[0158] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0159] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0160] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0161] In the embodiments provided by the present invention, it should be understood that the disclosed devices / terminals and methods can be implemented in other ways. For example, the device / terminal embodiments described above are merely illustrative. For example, the division of the modules or units is merely a logical functional division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interface, indirect coupling or communication connection of devices or units, and can be electrical, mechanical, or other forms.

[0162] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0163] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0164] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0165] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0166] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0167] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0168] The above content is only for explaining the technical idea of the present invention and cannot be used to limit the protection scope of the present invention. Any changes made on the basis of the technical solution in accordance with the technical idea proposed by the present invention shall fall within the protection scope of the claims of the present invention.

Claims

1. A distributed service registration and consensus mechanism scheduling method, characterized in that: The following steps are involved: S1. Themis system selectively enables and configures database connection and cluster synchronization according to its own needs; S2. Define the mode and function of the configuration loader; S3. Standardize the basic information of the Themis system, the results returned by Themis after processing data, the structure of username and password, the distributed service model registered in Themis, and the database mapping structure of the distributed service model registered in Themis; S4. After the core business logic layer is initialized, two types of core businesses are started. Among them, the business operations provided by the business logic interface are called by the front-end controller to obtain the returned data or operation results, and the underlying data logic business is the necessary thread business required to maintain the normal operation of the Themis system functions; S5. Themis system provides a call interface for managing the consensus mechanism through the core business logic layer. It performs related scheduling and management of the consensus mechanism through the call interface, obtains the scheduling operation results and data information from the business logic interface, and performs consensus mechanism scheduling. S6. Forward HTTP / HTTPS requests received by the Themis system during operation to the corresponding front-end controller. At the same time, define the OpenAPI core interface provided by the project through the back-end routing, including service communication API and management operation API, and provide API operations to users; S7. After receiving the HTTP / HTTPS request, the front-end controller authenticates, checks, and handles exceptions on the data, and then submits the legal and correct data to the corresponding business logic layer for processing; S8. The registration service thread retrieves the relevant information from the business logic layer and sends it to the registration center for service information registration; S9. During the operation of the Themis system, the registration center determines the viability of each service through the service heartbeat thread, deletes threads that are no longer alive, and obtains system status information regularly through the system status thread and records it; S10. Submit the function execution tasks that need to be executed asynchronously when the Themis system is working to the coroutine pool, which is responsible for concurrently processing each task; S11. If an internal exception occurs in the Themis system, the exception handler is responsible for capturing and processing the exception, and making system interrupt processing or printing related logs according to the exception type.

2. The distributed service registration and consensus mechanism scheduling method according to claim 1 is characterized in that: In step S1, the database connection layer in the database connection provides database connection management, initialization, connection closing, and data difference processing to the database connection instance. Then, the database connection instance provides database CURD and transaction functions to the outside through the database interface layer, and operates on remote databases and local databases. When the database connection module is selected to be turned on, data persistence is performed through the data persistence function to back up key system information. If the system crashes due to an external fault, the system will be re-initialized and the data backed up in the database will be read into the memory through the database connection module to restore the data information. When cluster synchronization is enabled, the Raft algorithm is called to synchronize the cluster.

3. The distributed service registration and consensus mechanism scheduling method according to claim 1 is characterized in that: In step S2, the configuration loader includes a service configuration loader, a database configuration loader, a service port loader, a listening port loader, a permission management loader, a cluster configuration loader, and a concurrent pool loader; the configuration loader is initialized when called by the initialization factory, and the variable parameters of the system are concentrated into a unified configuration file, and then the file is read and the read file is checked using the system's built-in system authentication, character checking, regular expression matching and other loading rules. If an error occurs, an exception is thrown and the system destruction factory is called to terminate the program.

4. The distributed service registration and consensus mechanism scheduling method according to claim 1 is characterized in that: In step S3, the data model module adopts a three-tier architecture of namespace, cluster, and service name to construct the underlying data model, and stipulates the system basic information data model, the front-end return result model, the permission user name and password model, the database storage mapping service model, and the service model; and unifies the standards for the currently deployed system basic information, the result returned after processing the data, the structure of the user name and password, the distributed service model registered in the system, and the database mapping structure of the distributed service model registered in the system.

5. The distributed service registration and consensus mechanism scheduling method according to claim 1 is characterized in that: In step S4, the core business logic layer includes the underlying data model instance, the scheduling center algorithm factory, the underlying data model instance management factory, the front-end controller data interception and inspection business, the core business, the database-related business, the communication API-related business, and the operation API-related business; The underlying data model instance, the underlying data model instance management factory, the core business, the database-related business, and the scheduling center algorithm factory constitute the underlying data logic business, which is responsible for the front-end controller to call and obtain the returned data or operation results; The front-end controller's data interception and inspection services, communication API-related services, and operation API-related services constitute the business logic interface, which is responsible for the necessary thread services required to maintain the normal operation of the entire system functions; The core business logic layer's core services include registration service threads, service heartbeat threads, and system timed status check threads. The registration service thread is responsible for retrieving service information registered in the underlying concurrent queue by the business logic layer and sending the relevant information to the registration center for service information registration. The service heartbeat thread is responsible for judging the viability of each service, while the system status thread periodically obtains and records system status information.

6. The distributed service registration and consensus mechanism scheduling method according to claim 1 is characterized in that: In step S7, the front-end controller performs the following operations: S701, the backend router sends the request to the corresponding frontend controller; S702: The interceptor chain in the front-end controller performs the interception operation, verifies the relevant permissions of the request, and sends the request with legal permissions to the controller; S703. If the user has enabled cluster fault tolerance and debug mode, the interceptor will also perform cluster role forwarding and debug log printing. At the same time, developers can implement corresponding interceptor plug-ins based on their business requirements and register them in the backend routing section. S704: The controller performs exception handling on the data sent by the interceptor, binds the data with parameters, and then sends the request and data to the corresponding business layer through the backend business call function; S705: The business layer performs specific operations such as adding, deleting, checking, and modifying the data according to the request.

7. The distributed service registration and consensus mechanism scheduling method according to claim 1 is characterized in that: In step S10, the concurrent task processing of the coroutine pool is specifically as follows: S1001. Package the tasks to be performed into inline body functions and exception body functions and pass them into the coroutine pool; S1002: The coroutine pool uses the CreateWork method to receive the inline body function and exception body function packaged in S901 of this group, decorate and combine them with functions, and add them to an asynchronous call queue maintained in the coroutine pool; S1003. If there is a free coroutine in the coroutine pool, the task in the asynchronous call queue is retrieved through the channel for execution. Otherwise, the task is called and executed only when a free coroutine is available after the currently executing task is completed. S1004. If an exception occurs when the coroutine executes the task, the exception handling function packaged in the task is called to handle the exception; S1005. After each task is completed, the coroutine pool locks and determines whether the current number of working coroutines is greater than the previously defined number of core threads. If it is greater, it jumps out of the loop and ends the coroutine. If it is less, it returns to the loop to monitor the asynchronous channel.

8. The distributed service registration and consensus mechanism scheduling method according to claim 1 is characterized in that: In step S11, the exception handling is specifically as follows: S1101. Register and expand custom exception handlers in the exception handling factory according to your business needs. S1102. When the system captures an exception, it sends the exception to the exception handler factory by calling the exception handler interface; S1103. The exception handler factory processes the exceptions in a hierarchical manner and contacts the exception handlers of the corresponding levels to distribute the exceptions. S1104. Each exception handler responds to the exception. The user exception handler only causes log printing, while other exception handlers cause system interruption and log printing at the same time.

9. The distributed service registration and consensus mechanism scheduling method according to claim 1 is characterized in that: When the system is destroyed, the system destruction factory is called to shut down the database module, cluster module, concurrent pool, and service module in sequence to destroy the system.

10. A distributed service registration and consensus mechanism scheduling system, characterized by: include: In the initial module, the Themis system selectively enables and configures database connections and cluster synchronization according to its own needs; Custom modules that define the modes and functions of configuration loaders; The mapping module standardizes the basic information of the Themis system, the results returned by Themis after processing data, the structure of username and password, the distributed service model registered in Themis, and the database mapping structure of the distributed service model registered in Themis; Business module, after the core business logic layer is initialized, two types of core businesses are started. The business operations provided by the business logic interface are called by the front-end controller to obtain the returned data or operation results. The underlying data logic business is the necessary thread business required to maintain the normal operation of the Themis system functions; The calling module: Themis system provides a calling interface for managing the consensus mechanism through the core business logic layer. It performs related scheduling and management of the consensus mechanism through the calling interface, obtains the scheduling operation results and data information from the business logic interface, and performs consensus mechanism scheduling; The forwarding module forwards the HTTP / HTTPS requests received by the Themis system during operation to the corresponding front-end controller. At the same time, it defines the OpenAPI core interface provided by the project through the back-end routing, including service communication API and management operation API, and provides users with specific API operations; Exception handling module: After receiving HTTP / HTTPS requests, the front-end controller authenticates, checks, and handles exceptions on the data, and then submits the legal and correct data to the corresponding business logic layer for processing; Registration module, the registration service thread extracts the relevant information from the business logic layer and sends it to the registration center for service information registration; Judgment module: During the operation of the Themis system, the registration center judges the viability of each service through the service heartbeat thread, deletes threads that are no longer alive, and obtains system status information regularly through the system status thread and records it; The processing module submits the function execution tasks that need to be executed asynchronously when the Themis system is working to the coroutine pool, which is responsible for concurrently processing each task; Scheduling module: If an internal exception occurs in the Themis system, the exception handler is responsible for capturing and processing the exception, and making system interrupt processing or printing related logs according to the exception type.

Images