Cross-registration center service synchronization method

Abstract

The invention discloses a cross-registration center service synchronization method, registration centers comprise a source registration center and a target registration center, and the method comprises the following steps: constructing a metadata model, defining fields for service registration, and realizing field conversion between the metadata model and the registration centers through a field mapping rule; monitoring a service change event of the source registration center, converting the service change event into a field of the metadata model according to a field mapping rule, and triggering a synchronization operation of the metadata model to the target user registration center through an event-driven synchronization engine according to an event type; and according to a field mapping rule, converting the field of the metadata model into the field of the target registration center, executing a synchronization operation, and according to a performance index of the synchronization operation, triggering an alarm. According to the method, the problem of field difference of multiple registration centers is solved through a unified metadata model and a field mapping rule, synchronous operation is triggered in parallel based on an event-driven engine, and service change is responded in real time; and high availability is guaranteed by combining performance monitoring and an alarm mechanism.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of service synchronization, and particularly relates to a cross-registration-center service synchronization method. BACKGROUND

[0002] With the wide application of microservice architecture, service registration and discovery become the core link to support the stable operation of the system. In practical applications, enterprises often need to register services to multiple registration centers (such as Eureka, Consul, Nacos, etc.) at the same time to meet the needs of hybrid cloud deployment, multi-team collaboration or cross-technology stack compatibility. However, the existing technology has the problems of high complexity, poor consistency and low efficiency when implementing cross-registration-center service synchronization.

[0003] The current mainstream solutions (such as Spring Cloud and Dubbo) require the microservice code layer to be directly bound to a specific registration center plug-in, resulting in the need to deploy multiple sets of code environments for the same service for different registration centers. At this time, the service information of multiple registration centers needs to be manually maintained, which is prone to data inconsistency due to manual operation and has high operation and maintenance complexity. New registration centers need to modify the code and redeploy, which is difficult to adapt to the rapid iteration of business needs and has poor scalability.

[0004] Different registration centers (such as the metadata field of Eureka and the tags field of Consul) have significant differences in the definition of service information. Customized field mapping logic is required for each registration center, which is high in development cost and prone to errors, and has low synchronization efficiency. Moreover, due to the differences in the definition of service information of different servers, field conversion errors occur in the field mapping process, causing service discovery failure or health check abnormalities.

[0005] Existing tools (such as Consul Exporter) rely on periodic polling to synchronize data or only support one-way switching. Not only does the polling interval cause service changes to be unable to be synchronized in a timely manner, affecting system availability and causing high latency. Moreover, due to the different processing logic of different event types, parallel synchronization execution processes may cause conflicts or avoidance of event responses, further reducing the efficiency of data synchronization.

[0006] In summary, there is an urgent need to develop a cross-registration-center service synchronization method to solve the complexity, consistency and low efficiency of cross-registration-center synchronization in the existing technology. SUMMARY

[0007] The application provides a cross-registration-center service synchronization method, which solves the complexity, consistency and low efficiency of cross-registration-center synchronization in the existing technology.

[0008] The technical solution adopted by the application is: A method for synchronizing services across registry centers, wherein the registry centers include a source registry center and a target registry center, the method comprising: Construct a metadata model, define fields for service registration, and implement the conversion between the metadata model and the fields of the registration center through field mapping rules; Listen for service change events in the source registry, convert them into fields of the metadata model according to the field mapping rules, and trigger the synchronization operation of the metadata model to the target user registry through the event-driven synchronization engine according to the event type. According to the field mapping rules, the fields of the metadata model are converted into the fields of the target registry center, a synchronization operation is performed, and an alarm is triggered based on the performance metrics of the synchronization operation.

[0009] The cross-registry center service synchronization method provided by this invention also has the following additional technical features: The field in question is specifically: The fields include core fields and extensible fields. The core fields include service name, instance IP, port, and health status, which are used for the definition of the registry center. The extensible field is initially set to empty and is used to extend the mapping between the implementation and the non-core fields of the registry center.

[0010] The metadata model is specifically as follows: The metadata model can be built into a plug-in structure using SPI or a modular framework; Based on the plugin structure, hot loading with the registration center is achieved through the core fields and the field mapping rules.

[0011] Listen for service change events in the source registry, specifically: Monitor the source registry via API and / or Webhooks to capture service change events in real time; The service change event includes at least one of the following: service registration, service deregistration, and service status change.

[0012] Based on the event type, the event-driven synchronization engine triggers a synchronization operation between the metadata model and the target user registration center, specifically: Identify the source data center of the service change event and determine the type of service change event; Service change events of the same type are assigned to an event-driven synchronization engine to synchronously trigger the synchronization operation of the metadata model to the target user registry.

[0013] Perform a synchronization operation, specifically: According to the metadata model, a timestamp is set for a service change event mapped to the metadata model; According to the timestamp, content comparison is performed on service change events in the same time interval, For consistent content of a plurality of service change events, a synchronization operation of a service change event at the last time in the time interval is performed through data deduplication; For new and / or missing content of a subsequent service change event, a plurality of service change events are concurrently executed; For contradictory content of a subsequent service change event and a previous service change event, a synchronization operation of the subsequent service change event is performed.

[0014] The performance indicators of the synchronization operation are specifically: The performance indicators at least include synchronization success rate, synchronization delay time, and failure times; According to the performance indicators, an alarm level is determined, and an alarm mode is set accordingly, When the synchronization success rate is less than 90%, a serious alarm is triggered; When the average synchronization delay is greater than 10 seconds, a warning alarm is triggered; When the number of failures per unit time is greater than or equal to 5 times, a prompt alarm is triggered.

[0015] The service change event of the source registry center is listened to, and the method further includes: Through the metadata model, user role definitions are extracted, and according to permission rules, it is checked whether the user role permissions match the service change event, If the check is passed, a mapping operation of the service change event to the metadata model is performed.

[0016] The application also provides a storage medium, The storage medium stores a computer program, and the computer program is executed to realize the steps of the cross-registry center service synchronization method.

[0017] The application further provides a processing device, which includes: A memory for storing a computer program; A processor for executing the computer program to realize the steps of the cross-registry center service synchronization method.

[0018] Due to the adoption of the above technical solutions, the application has the following beneficial effects: 1. In the present application, the unified metadata model and field mapping rules are defined by defining fields, which unify the field definitions of different registration centers (such as Eureka and Consul), solve the inconsistency of fields, and eliminate the field mapping errors caused by protocol / format differences. In addition, developers do not need to customize field conversion logic for each registration center, and only need to maintain a unified metadata model, reducing the workload of repeated development and reducing the development and maintenance cost.

[0019] By listening to the events of the source registration center and combining the event-driven engine to trigger the synchronization operation in real time, the delay problem of the traditional polling mechanism (such as the periodic synchronization of Consul Exporter) is avoided, and real-time synchronization and low delay are achieved. According to the event type, the synchronization operation of the metadata model to the target registration center is triggered in parallel, that is, events of the same event type are executed in parallel. In this way, not only the synchronization efficiency is improved through parallel operation, but also the conflict caused by different event type processing logic is avoided, and the problem of slow or failed event synchronization response is avoided.

[0020] In addition, by monitoring the performance indicators of the synchronization operation, the system anomalies (such as network interruption and target center overload) are sensed in real time, and the problem is avoided. After triggering the alarm, the operator can be notified to handle in time, so as to avoid the expansion of the problem.

[0021] In summary, the present application does not need to be directly bound to a specific registration center plug-in, and only needs to be connected to the tool to realize multi-center synchronization, avoid multiple code environment deployment, and provide flexible expansion capability for future access to new registration centers. Through the event-driven engine and the monitoring of the performance indicators of the synchronization operation, the high availability and fault tolerance of the synchronization task are ensured. BRIEF DESCRIPTION OF DRAWINGS

[0022] The accompanying drawings, which are included to provide a further understanding of the present application, constitute a part of the present application and illustrate the illustrative embodiments of the present application and their description serve to explain the present application, and do not constitute an improper limitation on the present application. In the drawings: Figure 1 The flowchart of the cross-registration center service synchronization method in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0023] In order to more clearly explain the overall concept of the present application, the following will be described in detail with reference to the accompanying drawings.

[0024] In the following description, many specific details are set forth in order to provide a thorough understanding of the present application, however, the present application can also be implemented in other ways different from those described herein, therefore, the scope of protection of the present application is not limited by the specific embodiments disclosed below.

[0025] AsFigure 1 As shown in the figure, a cross-registration center service synchronization method, the registration center includes a source registration center and a target registration center, the method comprises: S100: Construct a metadata model, define the fields used for service registration, and realize the field conversion of the metadata model and the registration center through the field mapping rule.

[0026] It should be noted that in the microservice architecture, the registration center is the core component of service registration and discovery, used to store the metadata of service instances (such as service name, IP, port, health status).

[0027] According to the architecture design of the registration center, it can be divided into a source registration center and a target registration center. Among them, the source registration center refers to the initiator of the service change event, that is, the original source of service registration, deregistration or state change (such as Eureka, Consul, etc.). The target registration center refers to the receiver of the service change event, that is, the target registration center that needs to synchronize service information (such as Nacos, ZooKeeper, etc.).

[0028] In the registration center, only the source registration center can initiate a service change event. That is, the service synchronization method in the present application is that after the user submits a service change event through the source registration center, the synchronization from the source registration center to the target registration center is performed.

[0029] The core purpose of this step is to solve the inconsistency problem caused by the difference in field definition in cross-registration center service synchronization.

[0030] It can be understood that different registration centers (such as Eureka, Consul, Nacos) have significant differences in field definition of service information (for example, the metadata field of Eureka and the tags field of Consul). The prior art needs to customize field mapping logic for each registration center, which has high development cost and is easy to cause service discovery failure or health check exception due to field conversion error This step defines the core fields of service registration (such as service name, instance IP, port, health status) through a unified metadata model, and dynamically adapts the non-core fields of different registration centers combined with the field mapping rule, eliminates the field difference, and ensures the consistency of service information across registration centers.

[0031] Specifically, by constructing a metadata model, the fields used for service registration are defined, which are not only used for the definition of the registration center, but also used for the event definition of the registration center, so as to perform accurate event synchronization for a specific registration center.

[0032] Through the field mapping rule, the conversion logic of different registry center fields and metadata model fields is defined through a field mapping table or a script (such as a JSON / YAML configuration file) (for example, the metadata of Eureka is mapped to the tags of Consul). That is, the application synchronizes the events from the source registry center to the target registry center through the metadata model as middleware, field mapping from the source registry center to the metadata model, and field mapping from the metadata model to the target registry center.

[0033] Through the unified metadata model and field mapping rule, the field automatic conversion across the registry centers is realized without custom development for each center, and the operation and maintenance complexity is reduced. When the registry center is added or deleted, the metadata model and the field mapping rule can be dynamically updated without restarting the update system to adapt to the addition of the registry center or the change of the field.

[0034] In summary, this step solves the field difference problem in cross-registry center service synchronization by constructing a unified metadata model and field mapping rule, and realizes the consistency of service information, the improvement of synchronization efficiency, and the dynamic expansion capability of the system.

[0035] S200: Listen to the service change event of the source registry center, convert it to the field of the metadata model according to the field mapping rule, and trigger the synchronization operation of the metadata model to the target registry center through the event-driven synchronization engine according to the event type.

[0036] The core purpose of this step is to solve the synchronization inefficiency problem caused by event response delay, field difference, and conflict processing in cross-registry center service synchronization.

[0037] It can be understood that the prior art relies on periodic polling (such as Consul Exporter) or one-way switching, which causes the service change to be unable to be synchronized in real time, affecting the system availability. The event type processing logic is not unified, and the data synchronization may fail due to event conflict (such as concurrent update).

[0038] This step realizes real-time listening to the service change event of the source registry center through the event-driven synchronization engine, combines the field mapping rule and the event type judgment, triggers the synchronization operation, and ensures the consistency and efficiency of the data across the registry centers.

[0039] Specifically, the service change event of the source registry center is listened to through the metadata model. It can be understood that in the application, only the source registry center is used to respond to the operation of the user, and the target registry center only performs data synchronization of the source registry center. Therefore, this step only listens to the source registry center according to the type of the registry center.

[0040] After listening to the service change event of the source registry center, the field of the source registry center (such as the healthCheckUrl of Eureka) is converted into the general field of the metadata model (such as the health status) according to the field mapping rule.

[0041] According to the mapped field, the event type is judged, the corresponding event-driven synchronization engine is allocated according to the event type (such as registration / deregistration), and the synchronization strategy is executed in parallel.

[0042] This step solves the problems of event delay, field difference and data conflict in cross-registry center service synchronization through the event-driven synchronization engine and the field mapping rule, and realizes real-time response and efficient processing of service changes.

[0043] S300: According to the field mapping rule, the field of the metadata model is converted into the field of the target registry center, the synchronization operation is executed, and the alarm is triggered according to the performance index of the synchronization operation.

[0044] The core purpose of this step is to solve the problems of data inconsistency and inefficiency caused by field mapping errors, synchronization delays and lack of monitoring in cross-registry center service synchronization.

[0045] It can be understood that in the prior art, the field definitions of different registry centers (such as metadata of Eureka and tags of Consul) are quite different, and service discovery failure or health check exception is easy to occur due to field conversion errors. If the performance monitoring and alarm function is not executed, the fault cannot be actively perceived.

[0046] This step converts the metadata model into the field of the target registry center through the field mapping rule, ensures the efficiency and data consistency of synchronization, triggers hierarchical alarm through performance index monitoring, and realizes active detection and rapid response of faults.

[0047] Specifically, in response to the event-driven synchronization engine, the field mapping is executed according to the field mapping rule, the field of the metadata model is converted into the field of the target registry center, and the last link of synchronization from the source registry center to the target registry center is realized. For example, the healthCheckUrl field in the metadata model is converted into the http check address of Consul or the metadata.healthCheckUrl of Eureka.

[0048] During the execution of the event-driven synchronization engine, the performance index of the synchronization task is collected in real time, and the alarm is triggered according to the performance index. Through the performance index monitoring and alarm mechanism, active detection and rapid response of faults are realized, and the problem of lack of monitoring and alarm is solved.

[0049] The field mapping rule and performance monitoring alarm mechanism are used to solve the field mapping error, synchronization delay and monitoring loss in the cross-registration center service synchronization, and the efficient, reliable and observable cross-center service synchronization is realized.

[0050] As a preferred embodiment of the present application, the field, in particular: The field includes a core field and an extensible field, and the core field includes a service name, an instance IP, a port and a health status, which are used for the definition of the registration center. The extensible field is initially set to be empty and is used to extend the mapping of non-core fields with the registration center.

[0051] The field structure of the core field and the extensible field is defined in the embodiment, and the inconsistency and high development and maintenance cost caused by the difference in field definition in the cross-registration center service synchronization are solved.

[0052] The core fields (service name, instance IP, port and health status) of the service registration are selected, and these fields are the minimum necessary information of the registration center (such as Eureka and Consul). During the establishment of the metadata model, the integrity check (such as the check of the required fields) of the core fields is required to avoid the synchronization failure caused by the field loss.

[0053] In addition, for some non-standard or special registration center, in addition to the core fields, there are a plurality of non-core fields with special functions or special marks. The mapping logic of the non-core fields and the extensible fields of different registration centers is defined by the configuration file (such as JSON / YAML) or script.

[0054] Through the decoupling design of the core field and the extensible field, the microservice only needs to connect to the unified field structure (core field), and through the extension of the extensible field, it can adapt to multiple registration centers. The extensible field is initially set to be empty, and is suitable for the addition of the registration center or the change of the field. Through the extension of the extensible field, the complete mapping of the field is realized, and the large change of the software architecture layer of the metadata model is avoided, and the operation complexity of the building and operation is reduced.

[0055] In summary, through the field structure design of the core field and the extensible field, the problems of field difference, high development and maintenance cost and insufficient extensibility in the cross-registration center service synchronization are solved. Not only the data consistency is ensured through the standardized core field, but also the flexibility and compatibility of the system are improved through the dynamic adaptation of the extensible field.

[0056] As a preferred embodiment of the present application, the metadata model, in particular: The metadata model is built as a plug-in structure through SPI or a modular framework; According to the plug-in structure, the core field is combined with the field mapping rule to realize hot loading with the registration center.

[0057] The embodiment builds a plug-in structure of a metadata model through SPI (Service Provider Interface) or a modular framework, and solves the problems of high development and maintenance cost and poor system flexibility caused by field differences and insufficient scalability of the registration center in cross-registration center service synchronization.

[0058] Among them, the specific implementation of the plug-in structure is not limited by the application. The SPI interface is used to define the general interface of the registration center plug-in (such as RegistryPlugin), including service registration, deregistration, query and other abstract methods.

[0059] In addition, the dynamic loading and management of the plug-in are realized through the modular framework (such as OSGi), which allows the plug-in to be added or removed at runtime.

[0060] Define all the fields (service name, instance IP, port, health status) common to the registration center as the basic data structure shared between plug-ins. Load the field mapping rule, define the field mapping rule (for example, map the metadata of Eureka to the tags of Consul) of different registration centers through a configuration file (such as JSON / YAML) or a script, and encapsulate it as a plug-in module.

[0061] Through the plug-in structure, the field mapping rule is updated or the registration center plug-in is added without restarting the registration center, realizing the dynamic management of the mapping. In addition, when loading a new registration center, the definition of the metadata model core field mapping rule is realized through the definition of the metadata model core field mapping rule, and the adaptation can be completed without modifying the registration center code.

[0062] In summary, the embodiment builds a plug-in structure of a metadata model through SPI or a modular framework, solves the problems of field differences, high development and maintenance cost, and insufficient scalability in cross-registration center service synchronization, not only ensures data consistency through standardized core fields, but also improves the flexibility and compatibility of the system through dynamically adaptive field mapping rules and hot loading mechanism, and reduces the operation and maintenance complexity.

[0063] As a preferred embodiment of the application, the service change event of the source registration center is listened to, specifically: Through API and / or Webhooks, the source registration center is monitored to capture service change events in real time; The service change event includes at least one of service registration, service deregistration, and service state change.

[0064] The embodiment listens to the service change event of the source registry center in real time through API and / or Webhooks, and solves the low efficiency of service synchronization caused by high delay of the polling mechanism, field mapping error, and data inconsistency in the prior art.

[0065] It should be noted that the specific technology of the service change event listening of the present application is not limited. The API call is to obtain the service state change in real time through the RESTful API (such as / actuator / health of Eureka) provided by the source registry center. The Webhooks callback is to configure the Webhook address in the source registry center, and actively push the event to the tool when the service changes.

[0066] In the embodiment, not only the service change event of the source registry center is monitored, but also the type of the service change event is identified. The service change event is divided into service registration (new service instance joins), service deregistration (service instance goes offline), and service state change (health state changes). The event content (such as service name, instance IP, and health state) can be extracted through JSON / XML parsing and mapped to the core field of the metadata model.

[0067] In the embodiment, the polling mechanism is replaced by API / Webhooks to realize instant synchronization of service change, and avoid service discovery failure caused by delay. In addition, the service change event type is distinguished to execute the subsequent synchronization strategy.

[0068] As a preferred embodiment of the present embodiment, according to the event type, the event-driven synchronization engine is used to trigger the synchronization operation of the metadata model to the target registry center, specifically: The source data center responding to the service change event is identified, and the service change event type is judged. The same type of service change event is assigned to an event-driven synchronization engine to trigger the synchronization operation of the metadata model to the target registry center.

[0069] The embodiment solves the low efficiency of service synchronization caused by imperfect event processing logic, high synchronization delay, and data conflict in the prior art by identifying the source data center and the event type, and assigning the same type of event to a dedicated event-driven synchronization engine.

[0070] Determine the event type, parse the event content (such as JSON / XML format), and extract the event type (service registration, deregistration, state change). Assign a separate event queue (such as Redis Stream or Kafka Topic) for each event type (such as registration and deregistration). Assign events of the same type to a dedicated event-driven synchronization engine (such as a registration event engine and a deregistration event engine) to avoid resource competition between different event types. Concurrent processing of events of the same type is achieved through a thread pool.

[0071] This embodiment ensures independent processing of different types of events by binding event type classification to a dedicated synchronization engine, avoiding conflicts. In addition, by classifying events by type and batch processing, the number of network requests is reduced, synchronization delay is reduced, and synchronization efficiency is improved.

[0072] Specifically, the synchronization operation is performed, specifically: According to the metadata model, set a timestamp for the service change event mapped to the metadata model; According to the timestamp, compare the contents of service change events within the same time interval, For consistent content of multiple service change events, perform a synchronization operation on the service change event with the last time within the time interval through data deduplication; For the new and / or missing content of the latter service change event, perform concurrent execution on multiple service change events; For the conflicting content of the latter service change event and the former service change event, perform a synchronization operation on the latter service change event.

[0073] This embodiment solves the problem of low efficiency of cross-registration center service synchronization caused by event conflict, data redundancy, high synchronization delay, and poor consistency in the prior art through the synchronization operation steps of timestamp setting, content comparison, data deduplication, concurrent execution, and conflict content processing.

[0074] Assign a timestamp to each service change event to ensure that the event order is traceable.

[0075] Divide the time interval into multiple time intervals (such as one interval per second / minute) according to the timestamp, which facilitates subsequent content comparison and conflict processing. For example, event A (timestamp 1623456789000) and event B (timestamp 1623456789001) belong to the same time interval.

[0076] For events in the same time interval, content comparison and data deduplication are performed. The events in the same time interval are compared in content (such as service name, instance IP, port and other core fields), and consistent content is identified. Only the event with the latest timestamp (the later event covers the former event) is retained to avoid repeated synchronization.

[0077] Specifically, if the service name, IP and port of event A and event B are completely consistent, only the event B with the newer timestamp is retained.

[0078] In addition, for events of new content (such as new service instance) or missing content (such as service deregistration), the synchronization operation is performed by thread pool in parallel. Resource optimization can reduce the delay of single-thread processing and improve synchronization efficiency.

[0079] Specifically, event A is a new service instance, and event B is another new instance, and the synchronization to the target registration center can be performed in parallel.

[0080] In addition, for the contradictory content (such as the health status changing from 'UP' to 'DOWN') of the same service instance, the synchronization operation of the later event is preferentially performed. At this time, the event order needs to be further verified in combination with the timestamp and the version number (such as the version field of Eureka).

[0081] Specifically, event A (health status UP) and event B (health status DOWN) conflict, and if the timestamp of event B is updated, the 'DOWN' state is synchronized.

[0082] The embodiment ensures the final consistency of the conflict events, reduces redundant operations, synchronizes only the new / changed content, fully utilizes system resources, improves synchronization efficiency, and ensures the accuracy of field mapping through timestamp arbitration and later event covering mechanism.

[0083] In summary, the embodiment solves the problems of event conflict, data redundancy, high synchronization delay and poor consistency in the prior art through the synchronization operation steps of timestamp setting, content comparison, data deduplication, parallel execution and contradictory content processing, and realizes the real-time, data consistency and efficiency of service synchronization.

[0084] As a preferred embodiment of the present application, the performance index of the synchronization operation is specifically: The performance index at least includes synchronization success rate, synchronization delay time, and failure times; According to the performance index, the alarm level is judged, and the alarm mode is set correspondingly, When the synchronization success rate is less than 90%, a serious alarm is triggered; When the average synchronization delay is greater than 10 seconds, a warning alarm is triggered; When the failure times per unit time are greater than or equal to 5 times, a prompt alarm is triggered.

[0085] The embodiment defines three key performance indicators, i.e., a synchronization success rate, a synchronization delay time, and a failure number, and solves the problems of low efficiency of cross-registration center service synchronization and insufficient system stability caused by late synchronization exception detection and single alarm strategy in the prior art by combining a hierarchical alarm mechanism.

[0086] Among them, the performance indicator is defined, the synchronization success rate is the ratio of the number of successful synchronization events to the total number of events (such as success number / (success number+failure number)). The synchronization delay time is the time interval from event capture to synchronization completion (such as calculated by time stamp difference). The failure number is the number of synchronization failures in a unit time (such as 1 minute).

[0087] Specifically, performance markers are inserted at key nodes of synchronization operations (such as event capture, field conversion, and target center writing), and performance indicator data is recorded in real time. The performance indicators are stored in the form of time series data (such as InfluxDB), which facilitates subsequent analysis and alarm triggering.

[0088] Alarm level division and triggering rules, severe alarm: when the synchronization success rate is less than 90%, trigger email / sms notification, prompt system-level failure (such as target center unavailable).

[0089] Warning alarm: when the average synchronization delay is greater than 10 seconds, trigger instant messaging tool notification (such as Dingding, Slack), and pre-alarm performance bottleneck (such as network congestion).

[0090] Prompt alarm: when the failure number per unit time is greater than or equal to 5 times, record logs and send emails to assist in locating local problems (such as single service instance exception).

[0091] It should be noted that when the synchronization success rate is less than 90%, it indicates that there is a systematic failure (such as target center downtime) in the synchronization task, which needs to be handled first. When the synchronization delay is greater than 10 seconds, it exceeds the acceptable range of the business (such as microservice health check timeout), which needs to be responded quickly. When the failure number is greater than or equal to 5 times, it may be an occasional problem (such as network jitter), which needs to be recorded but does not require urgent intervention.

[0092] According to the alarm level, different notification methods (such as email, SMS, and instant messaging tools) are selected to ensure that key problems are responded to in a timely manner.

[0093] The embodiment realizes real-time health assessment of synchronization operations through three indicators, i.e., synchronization success rate, delay time, and failure number. Through the hierarchical alarm mechanism (severe alarm, warning alarm, and prompt alarm), active detection and hierarchical response of faults are realized, key problems are handled first, and the complexity of operation and maintenance is reduced.

[0094] In summary, the embodiment solves the problems of existing technology, such as lagging in synchronization exception detection, single alarm strategy, and realizes real-time monitoring, active alarm and efficient response of service synchronization, improves the stability and maintainability of the system through quantitative indicators and hierarchical strategy.

[0095] As a preferred embodiment of the present application, the step of monitoring the service change event of the source registry center further comprises: According to the permission rule, the user role permission and the service change event are checked, If the check is passed, the mapping operation of the service change event to the metadata model is performed.

[0096] The embodiment extracts the user role definition through the metadata model, and checks the legality of the service change event based on the permission rule, solving the problems of unauthorized service change, data tampering and insufficient system security caused by the lack of permission control in the prior art.

[0097] The user role definition (such as role ID, role name, permission range) is embedded in the metadata model, and the service change event and the user role are associated through field mapping rules. The permission rule (such as the role admin can operate all services, and the role user can only operate specific services) is defined through a configuration file (such as JSON / YAML) or a database.

[0098] The service change event content (such as service name, operation type, instance IP) is parsed, and the service identifier to be operated is extracted. The user role permission and the operation type (such as registration, deregistration, state change) and the service identifier of the service change event are matched.

[0099] If the permission is matched successfully, the service change event is mapped to the metadata model and the synchronization operation (such as synchronizing service information to the target registry center) is triggered. If the permission is not matched, the log is recorded and the synchronization operation is refused.

[0100] The embodiment allows only authorized user roles to trigger synchronization operations through permission rule verification, prevents unauthorized service changes, prevents unauthorized user roles from modifying service information, reduces the risk of data tampering, and can also avoid service exceptions caused by user misoperation (such as accidental deletion of key service instances).

[0101] The embodiment solves the problems of unauthorized service change, data tampering and lack of permission control in the prior art through user role definition extraction and permission rule verification, and realizes the safety, controllability and flexibility of service synchronization operation.

[0102] The application also provides a storage medium, The storage medium stores a computer program, which, when executed, implements the steps of the cross-registration center service synchronization method.

[0103] Therefore, any effect of the cross-registration center service synchronization method can be achieved, which will not be repeated here.

[0104] The application further provides a processing device, comprising: a memory for storing a computer program; a processor for executing the computer program to implement the steps of the cross-registration center service synchronization method.

[0105] Therefore, any effect of the cross-registration center service synchronization method can be achieved, which will not be repeated here.

[0106] The application can be implemented by using or referring to the existing technology for the unmentioned parts.

[0107] Each embodiment in the specification is described in a progressive manner, and the same or similar parts between each embodiment can be referred to each other, and each embodiment mainly describes the difference from other embodiments.

[0108] The above only describes the embodiments of the application and is not used to limit the application. The application can be variously changed and modified by those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the application shall be included in the scope of claims of the application.

Claims

1. A cross-repository service synchronization method, characterized by, The registration center includes a source registration center and a target registration center, and the method includes: Building a metadata model, defining fields for service registration, and realizing field conversion between the metadata model and the registration center through field mapping rules; Listening to service change events of the source registration center, converting fields of the metadata model according to the field mapping rules, triggering synchronization operations of the metadata model to the target registration center through an event-driven synchronization engine according to event types, and converting fields of the metadata model to fields of the target registration center according to the field mapping rules to execute the synchronization operations and trigger alarms according to performance indicators of the synchronization operations. The fields are specifically:

2. The cross-repository service synchronization method of claim 1, wherein, The fields include core fields and extensible fields, and the core fields include service name, instance IP, port, and health status for the definition of the registration center. The extensible fields are initially set to empty and are used to extend the mapping with non-core fields of the registration center. The metadata model is specifically:

3. The cross-repository service synchronization method of claim 2, wherein, The metadata model is built as a plug-in structure through SPI or a modular framework; According to the plug-in structure, the core fields are combined with the field mapping rules to realize hot loading with the registration center. Listening to service change events of the source registration center is specifically:

4. The cross-realm service synchronization method of claim 1, wherein, Through API and / or Webhooks, the source registration center is monitored to capture service change events in real time; The service change events at least include any one of service registration, service deregistration, and service state change. According to event types, the metadata model is triggered to synchronize to the target registration center through an event-driven synchronization engine, which is specifically:

5. The cross-repository service synchronization method of claim 4, wherein, Identifying a source data center responding to a service change event and judging a service change event type; Service change events of the same type are assigned to an event-driven synchronization engine to synchronize the metadata model to the target registration center. Executing synchronization operations is specifically:

6. The cross-repository service synchronization method of claim 5, wherein, According to the metadata model, a timestamp is set for service change events mapped to the metadata model; According to the timestamp, service change events in the same time interval are compared in content, For consistent content of multiple service change events, data deduplication is performed to execute synchronization operations of the service change event at the last time in the time interval; For new and / or missing content of a subsequent service change event, multiple service change events are concurrently executed; For contradictory content between the subsequent service change event and the previous service change event, the synchronization operation of the subsequent service change event is executed. The performance indicators of the synchronization operations are specifically:

7. The cross-realm service synchronization method of claim 1, wherein, The performance indicators at least include synchronization success rate, synchronization delay time, and failure times; According to the performance indicators, alarm levels are determined, and alarm modes are set accordingly, When the synchronization success rate is less than 90%, a serious alarm is triggered; When the average synchronization delay is greater than 10 seconds, a warning alarm is triggered; When the failure times per unit time are greater than or equal to 5 times, a prompt alarm is triggered. Listening to service change events of the source registration center also includes:

8. The cross-realm service synchronization method of claim 1, wherein, ​ Through the metadata model, a user role definition is extracted, and it is checked whether the user role permission matches the service change event according to a permission rule, If the check passes, a mapping operation of the service change event to the metadata model is performed.

9. A storage medium, characterized in that, The storage medium stores a computer program, and the computer program is executed to implement the steps of the cross-registration center service synchronization method according to any one of claims 1 to 8.

10. A processing device, characterized by Including: a memory for storing a computer program; a processor for executing the computer program to implement the steps of the cross-registration center service synchronization method according to any one of claims 1 to 8.

Images