Distributed service change configuration processing method and device, electronic equipment and program product

Abstract

The invention discloses a distributed service change configuration processing method. The method comprises the following steps: monitoring version information stored in a distributed coordinated storage service; in response to a change notification of the subscribed configuration source, obtaining a change configuration content from the configuration source; writing the changed configuration version identifier into the distributed coordinated storage service so as to update the configuration version identifier of the service instance in the version information; reading a current configuration version identifier of each service instance in the version information in response to the version information change obtained by monitoring; the read configuration version identifiers are compared, and under the condition that the configuration version identifiers of all the service instances are inconsistent, service processing of the service is not executed. According to the method disclosed by the embodiment of the invention, the running consistency of a plurality of instances of the same service application in a high-frequency configuration updating scene can be ensured.

Description

Technical Field

[0001] This disclosure relates to the field of computer application technology, and in particular to methods, apparatus, electronic devices and program products for processing distributed service configuration changes. Background Technology

[0002] With the increasing popularity of cloud-native and microservice architectures, business applications are typically deployed in container orchestration environments using multiple instances. The runtime configuration of the same business application is maintained uniformly by an independent configuration management system, and each instance obtains configuration updates through subscription and takes effect during runtime.

[0003] In such distributed deployments, due to factors such as communication latency and real-time instance load, there is a time lag between the acquisition and application of runtime configurations by each instance. When runtime configurations are adjusted continuously within a short period of time, different instances of the same business application may use different configurations within the same time window, leading to inconsistencies in the overall operation of the business application and fluctuations in processing results.

[0004] Therefore, it is necessary to provide a new scheme for handling configuration changes in order to ensure the stability and consistency of multi-instance operation in high-frequency update scenarios.

[0005] The background description is provided for the purpose of understanding the relevant technologies in this field and is not intended as an admission of prior art. Summary of the Invention

[0006] The embodiments disclosed herein aim to provide a distributed service change configuration processing method and apparatus, electronic device and program product, which can mitigate or solve at least one of the aforementioned technical problems.

[0007] In a first aspect, embodiments of this disclosure provide a distributed service configuration change processing method, applied to a service instance, which may include:

[0008] Monitor the version information stored in the distributed coordination storage service, wherein the version information includes the configuration version identifier corresponding to each service instance that belongs to the same service as the service instance;

[0009] In response to a change notification from a subscribed configuration source, the changed configuration content is obtained from the configuration source, wherein the changed configuration content includes a changed configuration version identifier;

[0010] Write the changed configuration version identifier into the distributed coordination storage service, thereby updating the configuration version identifier of the service instance in the version information;

[0011] In response to changes in the version information obtained from monitoring, the current configuration version identifier of each service instance is read from the version information;

[0012] The configuration version identifiers of each service instance are compared. If the current configuration version identifiers of each service instance are inconsistent, the business processing of the service will not be executed.

[0013] In some embodiments, the method further includes: performing business processing of the service based on the changed configuration content, provided that the configuration version identifiers of each service instance are consistent.

[0014] In some embodiments, the method further includes, prior to performing the listening, the following:

[0015] The service instance is registered to the distributed coordination storage service, which is used to create a set of key-value pairs of version information for each service instance belonging to the same service.

[0016] In some embodiments, the distributed coordination storage service includes a tree-like directory structure, which includes key-value pairs corresponding one-to-one with multiple service instances, wherein the key of any key-value pair is a path identifier including a service instance identifier corresponding to the service instance, and the value of any key-value pair is a configuration version identifier of the corresponding service instance.

[0017] In some embodiments, comparing the read configuration version identifier further includes:

[0018] If the first configuration version identifier of the service instance lags behind the second configuration version identifier of any other service instance, the missing configuration changes of the service instance relative to the other service instances are obtained, wherein the second configuration version identifier is the latest configuration version identifier corresponding to each service instance.

[0019] In some embodiments, obtaining the missing configuration changes of the service instance relative to other service instances includes:

[0020] Determine the configuration version identifier that is missing from the first configuration version identifier relative to the second configuration version identifier;

[0021] Obtain the supplementary changed configuration content corresponding to the missing configuration version identifier from the configuration source;

[0022] The modified configuration version identifier in the supplementary modified configuration content is written into the distributed coordination storage service, thereby updating the configuration version identifier of the service instance in the version information.

[0023] In some embodiments, the monitoring of version information stored in the distributed coordination storage service includes:

[0024] The path in the distributed coordination and storage service that is prefixed with a service identifier is monitored, wherein the service identifier is used to identify the service to which the service instance belongs.

[0025] In a second aspect, embodiments of this disclosure provide a distributed service change configuration processing apparatus, applied to a service instance, which may include:

[0026] The listening unit is configured to listen to the version information stored in the distributed coordination storage service, wherein the version information includes the configuration version identifier corresponding to each service instance that belongs to the same service as the service instance;

[0027] The acquisition unit is configured to, in response to a change notification from a subscribed configuration source, acquire changed configuration content from the configuration source, wherein the changed configuration content includes a changed configuration version identifier;

[0028] The update unit is configured to write the changed configuration version identifier into the distributed coordination storage service, thereby updating the configuration version identifier of the service instance in the version information;

[0029] The reading unit is configured to read the current configuration version identifier of each service instance from the version information in response to changes in the version information obtained from the monitoring.

[0030] The comparison unit is configured to compare the configuration version identifiers of each service instance read. If the current configuration version identifiers of each service instance are inconsistent, the service's business processing will not be executed.

[0031] In a third aspect, embodiments of this disclosure provide an electronic device that may include: a processor and a memory storing a computer program, the processor being configured to implement the method as described in the first aspect when the computer program is executed.

[0032] In a fourth aspect, embodiments of this disclosure provide a program product including a computer program, wherein the computer program, when executed by a processor, implements the method as described in the first aspect.

[0033] The distributed service configuration change processing method of this disclosure can monitor version information stored in the distributed coordination storage service, wherein the version information includes the configuration version identifier corresponding to each service instance belonging to the same service as the service instance; in response to the change notification of the subscribed configuration source, it obtains the changed configuration content from the configuration source, wherein the changed configuration content includes the changed configuration version identifier; writes the changed configuration version identifier into the distributed coordination storage service, thereby updating the configuration version identifier of the service instance in the version information; in response to the monitored version information change, it reads the current configuration version identifier of each service instance in the version information; compares the read configuration version identifiers of each service instance, and if the current configuration version identifiers of each service instance are inconsistent, the service's business processing is not executed. Therefore, the distributed service configuration change processing method of this disclosure, through the monitoring mechanism and configuration version identifier management based on the distributed coordination storage service, enables any change in the configuration version identifier of a service instance to be immediately monitored by other instances, and triggers the reading and comparison of the configuration version identifiers of all service instances under the same business service, ensuring that all service instances have the same configuration version at the same point in time before executing business processing, fundamentally solving the problem of inconsistent service instance configuration versions caused by differences in configuration acquisition timing in the prior art. Even in extreme scenarios where the configuration source changes frequently, the method of this disclosure embodiment can ensure that different service instances of the same business service run under the same processing logic, thereby guaranteeing the stability of the processing results of the business service.

[0034] Other optional features and technical effects of the embodiments of this disclosure are described in part below, and in part will be apparent from reading this document. Attached Figure Description

[0035] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings. The elements shown are not limited to the scale shown in the drawings, and the same or similar reference numerals in the drawings denote the same or similar elements, wherein:

[0036] Figure 1 A schematic diagram of the processing flow of a configuration change processing system is shown.

[0037] Figure 2 The diagram illustrates the architecture of a distributed service change configuration processing system according to an embodiment of the present disclosure. This system can be used to implement a distributed service change configuration processing method according to an embodiment of the present disclosure.

[0038] Figure 3 An exemplary flowchart of a distributed service configuration change processing method according to an embodiment of this disclosure is shown;

[0039] Figure 4 An exemplary flowchart of a distributed service configuration change processing method according to an embodiment of this disclosure is shown;

[0040] Figure 5 An exemplary flowchart of a distributed service configuration change processing method according to an embodiment of this disclosure is shown;

[0041] Figure 6 An exemplary structural diagram of a distributed service change configuration processing apparatus according to embodiments of the present disclosure is shown; and

[0042] Figure 7 An exemplary structural diagram of an electronic device capable of implementing the methods according to embodiments of the present disclosure is shown. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this disclosure clearer, the disclosure will be further described in detail below with reference to specific embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this disclosure are used to explain this disclosure, but are not intended to limit this disclosure.

[0044] The term "comprising" and its variations as used herein signify open inclusion, i.e., "including but not limited to". Unless otherwise stated, the term "or" means "and / or". The term "based on" means "at least partially based on". The terms "one example embodiment" and "one embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least some embodiments". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0045] In this embodiment of the disclosure, a service instance refers to an independent running entity that carries the same business logic. Logically, they may belong to the same business service, but physically they are distributed in different computing nodes. Each service instance can independently process business requests, and multiple service instances work together to share the business load, so as to improve the processing capacity and availability of the business service.

[0046] The user data, data acquisition, and / or use involved in the embodiments of this disclosure strictly comply with the laws, regulations, and industry standards of relevant countries and regions. The collection and acquisition of data involved in the embodiments of this disclosure are all done in advance by actively prompting or prominently displaying information to inform users and obtaining authorization, or by obtaining full authorization from all parties. The processing, manipulation, forwarding, and use of data involved in the embodiments of this disclosure are all carried out on the premise that the user or relevant party is fully informed and authorized. When implementing the embodiments of this disclosure, the types of data or information, scope of use, and usage scenarios that may be involved are informed to users or relevant parties and authorization is obtained through appropriate means. The specific methods of notification and authorization may vary according to actual circumstances, and this disclosure is not limited in this regard. The processing of personal information involved in the embodiments of this disclosure is carried out under the premise of having a legal basis (such as obtaining the consent of the personal information subject or being necessary for the performance of a contract), and is only processed within the prescribed or agreed scope. Sensitive personal information such as biometric information, medical and health information, financial account information, and precise location information involved in the embodiments of this disclosure are all processed under the premise of having a specific purpose and sufficient necessity, and with the separate authorization and consent of the user or relevant party. In some embodiments of this disclosure, if a user or related party refuses to process personal information other than the information necessary for the basic functions, it will not affect the use of the basic functions of the embodiments of this disclosure.

[0047] As mentioned earlier, in distributed deployment scenarios, multiple service instances of the same business service are affected by various factors such as network communication latency, instance processing load, and system resource contention, resulting in time differences in the acquisition and application of changed configuration content by each service instance. When the configuration source undergoes continuous configuration changes within a short period of time, different service instances may acquire different versions of the configuration content, leading to multiple service instances of the same business service executing business processing based on different versions of the configuration. This inconsistency in configuration versions can cause significant differences and fluctuations in business processing results, which seriously affects the normal operation of critical businesses, including but not limited to financial transaction systems and risk control decision-making systems, which have extremely high requirements for data consistency and processing stability.

[0048] refer to Figure 1This document illustrates an exemplary service configuration retrieval process. Three service instances obtain changed configuration content from a configuration source through a client listening mechanism. When the configuration version in the configuration source changes, each service instance independently responds to the configuration change notification and retrieves the corresponding changed configuration content. Specifically, a business service deploys three service instances, POD1, POD2, and POD3. At time t1, all service instances use an initial configuration with version identifier v0. Starting from time t2, the configuration in the configuration source undergoes three consecutive changes within a short period: the configuration is changed to versions v1, v2, and v3 at times t2, t4, and t6, respectively. At this point, due to differences in response latency, each service instance obtains configuration content at different times: POD1 obtains the configuration content of version v1, which changed at time t2, at time t3; when POD2 obtains configuration content at time t5, the configuration has already changed to version v2 at time t4, so POD2 obtains the configuration content of version v2, skipping version v1; when POD3 obtains configuration content at time t7, the configuration has already changed to version v3 at time t6, so POD3 obtains the configuration content of version v3, skipping versions v1 and v2. This asynchronous and skipping configuration acquisition leads to serious problems: First, skipping intermediate versions of configuration content causes the loss of some configuration change information; second, when service instances execute business processing simultaneously based on different configuration version identifiers, inconsistencies in business logic processing results occur, causing fluctuations in the processing results of the same business service, thus affecting the overall business output stability of the distributed system.

[0049] It is evident that this processing flow suffers from issues such as skipping the acquisition of service instance configuration version identifiers, loss of configuration content due to intermediate version changes, and discrepancies in results caused by concurrent execution of business processes based on inconsistent configuration version identifiers. The root cause of these problems lies in the lack of distributed consistency guarantees in the existing configuration acquisition mechanism, where each service instance independently and asynchronously acquires configuration changes, making it impossible to achieve synchronous alignment of configuration version identifiers.

[0050] In response, this disclosure provides a method for handling configuration changes in distributed services. This method is applicable to distributed business systems with strict requirements for configuration consistency, such as business application systems under microservice architecture, distributed applications deployed based on container orchestration platforms, and real-time data processing platforms. The method of this disclosure can be executed independently by multiple service instances. Each service instance interacts with a distributed coordination storage service, using the distributed coordination storage service as a unified management center for version information, to achieve configuration version synchronization and alignment among multiple service instances.

[0051] In some embodiments of this disclosure, the distributed service configuration change processing method can be applied to Figure 2 The system architecture shown is a distributed service change configuration processing system. For example... Figure 2 As shown, the configuration change processing system may include a configuration change client, a configuration source, multiple service instances, and a distributed coordination storage service. In this embodiment, the configuration change client, as the initiator of the configuration change, triggers the entire configuration change processing flow by submitting a configuration change request to the configuration source; the configuration source, also known as the configuration center, is responsible for storing and managing configuration content, and providing configuration change notifications and configuration content retrieval services to subscribed service instances; the multiple service instances include POD1, POD2, and POD3 under the same business application service A. These PODs can subscribe to configuration changes, retrieve configuration content, and execute business processing. Each service instance runs independently and maintains its own configuration version status; the distributed coordination storage service... Figure 2 The code is displayed as etcd, which serves as a unified storage and coordination center for configuration version information, providing distributed coordination functions such as key-value storage, event listening, and data consistency guarantees. This architecture will be used as an example in the following explanation. For clarification, etcd is an open-source distributed key-value store used to save and manage the information required by a distributed system to keep it running. However, it is conceivable that in other embodiments, this distributed service configuration change processing method can also be applied to system architectures using different components or deployment methods, such as other configuration centers like Nacos and Consul, or other distributed coordination and storage services like ZooKeeper and Redis Cluster, which falls within the scope of this disclosure.

[0052] In some embodiments of this disclosure, reference is made to Figure 3 The distributed service configuration change processing method may include the following steps 120, 130, 140, 150 and 160, and in some embodiments may also include a pre-step 110.

[0053] 110: Register the service instance to the distributed coordination storage service.

[0054] Among them, the distributed coordination storage service is used to create a set of key-value pairs of version information for each service instance belonging to the same service.

[0055] In some embodiments of this disclosure, step 110 is an optional step, which may be implemented, for example, when each service instance of the same service registers in the distributed coordination storage service. A detailed description of the service instances can be found above and will not be repeated here.

[0056] In some embodiments of this disclosure, the version information includes configuration version identifiers obtained by each of multiple service instances. The version information is a data structure that includes the current version status of all service instances corresponding to the same service. In some embodiments of this disclosure, the configuration version identifier is used to uniquely identify the configuration content version. Whenever the target configuration in the configuration source changes, the configuration source assigns a new configuration version identifier for that change.

[0057] In some embodiments of this disclosure, the distributed coordination storage service may include a distributed key-value storage system, where the key-value pair storage of the aforementioned version information is implemented, for example, through a distributed coordination storage service. In this embodiment, the distributed coordination storage service may provide a listening mechanism to support real-time monitoring of specified keys or key prefixes. When a monitored key changes, the system may proactively push a change event, for example, by configuring the change event to the listening client. In some embodiments, the distributed coordination storage service is etcd. In other embodiments, distributed storage systems such as Zookeeper and Redis Cluster may also be used to achieve coordinated management of multiple service instances; this disclosure does not impose any limitations on this.

[0058] In some embodiments of this disclosure, the registration includes writing basic information of the service instance into the distributed coordination storage service, and simultaneously creating a storage structure for version information for the service instance. Specifically, registration includes establishing a unique storage path for each service instance in the distributed coordination storage service, and creating key-value pairs under that path for storing version information.

[0059] In some embodiments of this disclosure, version information may be organized using a tree-structured directory path, wherein the version identifier corresponding to each service instance is stored in the directory path in the form of key-value pairs. In some embodiments of this disclosure, the key of any key-value pair is a path identifier including the service instance identifier of the corresponding service instance, and the value of any key-value pair is the configuration version identifier of the corresponding service instance.

[0060] In some embodiments of this disclosure, the tree-like directory structure includes hierarchical path identifiers, and each service instance may correspond to a unique key-value pair. In this embodiment, the key of any key-value pair exists in the form of a path identifier, which may include the (unique) service instance identifier of the corresponding service instance. In some embodiments, the path identifier of a service instance may also include the service identifier corresponding to that service instance, and the path identifier can be used to uniquely identify the version information storage location of each service instance in the distributed coordination storage service.

[0061] In some embodiments of this disclosure, the service instance identifier corresponding to each service instance can be determined before registration, for example, by a service instance name pre-assigned through a container orchestration system (such as Kubernetes). In other embodiments, the service instance identifier can also be reassigned to the service instance when creating the tree directory structure, and this disclosure does not limit this.

[0062] In some embodiments of this disclosure, a service identifier can be used to distinguish different business services; a service instance identifier can be used to distinguish different instances under the same service. In some embodiments, the path identifier may also include a root directory identifier defined by the distributed coordination storage service or other optional identifiers, which are not limited in this disclosure. In a specific embodiment, a tree-like directory structure can be created for multiple instances of an order service. The tree structure includes multiple key-value pairs, wherein the key of the key-value pair created for POD1 is “ / services / order-service / instances / pod-001 / version”, where “services” is the root directory identifier, “order-service” is the service identifier, “instances” is the identifier of the set of service instances corresponding to the service, “pod-001” is the service instance identifier of the instance, and “version” is the version storage identifier.

[0063] In some embodiments of this disclosure, after creating key-value pairs, the initial configuration version identifier of the service instance corresponding to each key-value pair can be used as the value of the key-value pair.

[0064] In some embodiments of this disclosure, after creating a key-value pair, the initial configuration version identifier (e.g., "v0") can be written into the value of the corresponding key-value pair in the tree directory structure. In other embodiments, the configuration version identifier of the service instance currently being used can also be optionally identified and used as the value of the key-value pair, which falls within the protection scope of this disclosure.

[0065] In one specific embodiment, following the specific embodiment in step 110 above, for the three instances POD1, POD2, and POD3 belonging to the order service, after setting the initial configuration version identifier, the following complete set of key-value pairs can be obtained: key: " / services / order-service / instances / pod-001 / version", value: "v0"; key: " / services / order-service / instances / pod-002 / version", value: "v0"; key: " / services / order-service / instances / pod-003 / version", value: "v0". Thus, this set of key-value pairs provides the foundation for the monitoring mechanism, enabling each service instance to obtain the version status of other instances in the same group through changes in a specific prefix.

[0066] In some embodiments, various suitable means can be used to promptly unregister or delete key-value pairs corresponding to offline service instances from the distributed coordination storage service.

[0067] In some embodiments, the timely cancellation or deletion of offline service instances can be achieved based on the lease function of a distributed coordinated storage service, such as etcd. In these embodiments, step 110 may include: creating a lease with a preset validity period in the distributed coordinated storage service; binding the key-value pair corresponding to the current service instance to the lease; and periodically renewing the lease during its validity period. Wherein, in response to the lease expiring without renewal, the distributed coordinated storage service automatically deletes the key-value pair corresponding to the current service instance.

[0068] Therefore, the lease mechanism enables dynamic maintenance of the service instance list. When a service instance fails, it is automatically removed from the version information, ensuring that the configuration version comparison is only performed on the currently alive service instances, thus avoiding configuration version comparison blocking caused by failed instances.

[0069] 120: Listens to version information stored in the distributed coordination storage service.

[0070] The version information includes the configuration version identifiers of each service instance that belongs to the same service as the current service instance.

[0071] In some embodiments of this disclosure, multiple service instances corresponding to the same service can independently monitor the version information stored in the distributed coordinated storage service. In this embodiment, "independent monitoring" means that each service instance can establish a connection with the distributed coordinated storage service separately and independently maintain its monitoring connection without relying on the monitoring status of other instances. In some embodiments, the aforementioned monitoring is continuous monitoring.

[0072] In some embodiments of this disclosure, step 120, namely, monitoring the version information stored in the distributed coordination storage service, may include: monitoring paths in the distributed coordination storage service that are prefixed with a service identifier, wherein the service identifier is used to identify the service to which the current service instance belongs. In a specific embodiment, referring to the specific embodiment in 110 above, three service instances POD1, POD2, and POD3 perform prefix monitoring on the version information storage path " / services / order-service / instances / " through etcd's Watch mechanism. Thus, during the monitoring process, any change in a key-value pair starting with the storage path will trigger a monitoring event for the corresponding service instances under that storage path, enabling each service instance to be aware in real time of version status changes for any service instance corresponding to the same service. This mechanism can also be combined with the embodiments of this disclosure below to achieve further effects, which will be described in detail below.

[0073] As an explanation and not a limitation, in the embodiments of this disclosure, through the listening mechanism, each service instance can obtain complete version information containing the version status of all instances in the same group, which also provides a basis for subsequent confirmation of the consistency of configuration version identifiers, as described below.

[0074] In some embodiments of this disclosure, the version information may record the latest configuration version identifier obtained by each service instance, thereby maintaining the current application version status of multiple service instances. The specific structure of the version information can be found in the description of step 110 and its sub-steps above, and will not be repeated here.

[0075] 130: In response to a change notification from a subscribed configuration source, obtain the changed configuration content from the configuration source.

[0076] The changed configuration content includes a changed configuration version identifier.

[0077] In some embodiments of this disclosure, the method may further include subscribing to configuration change notifications from a configuration source. Specifically, each service instance may establish a subscription connection with the configuration source to enable real-time monitoring of target configuration change events. In one example, the subscription may be executed, for instance, at startup of each service instance, and the subscribed configuration may include target configuration items or target configuration groups related to the service. In some embodiments, the subscription mechanism may adopt a push mode, whereby the configuration source may proactively push configuration change notifications to subscribed service instances when the target configuration in the configuration source changes.

[0078] In some embodiments of this disclosure, when the target configuration of the configuration source changes, the subscribed service instance can receive the corresponding change notification sent by the configuration source, and can proactively request the complete changed configuration content from the configuration source in response to the received change notification.

[0079] In some embodiments of this disclosure, the changed configuration content may include a changed configuration version identifier, wherein the changed configuration version identifier is used to uniquely identify the configuration change, for example, using an incrementing version number format, such as "v1", "v2", "v3", etc. It is understood that the changed configuration content includes structured data objects, which, in addition to the changed configuration version identifier, may also include configuration parameter values ​​required for the operation of business application services, change timestamps, and optional change description information.

[0080] 140: Write the changed configuration version identifier to the distributed coordination storage service, thereby updating the configuration version identifier of the service instance in the version information.

[0081] In some embodiments of this disclosure, when a service instance obtains changed configuration content and a changed configuration version identifier therein through a configuration subscription mechanism, it can use the obtained changed configuration version identifier to update the configuration version identifier corresponding to the service instance stored in the distributed coordination storage service. In one example, the service instance updates the value of the corresponding key-value pair in its version information to the changed configuration version identifier through the write interface of the distributed coordination storage service.

[0082] In a specific embodiment of this disclosure, referring to the specific embodiments in steps 110 and 120 above, when the service instance POD1 of the order service obtains new changed configuration content, it extracts the changed configuration version identifier "v2" and updates the value of the corresponding key " / services / order-service / instances / pod-1 / version" in etcd from the original "v1" to "v2".

[0083] 150: In response to changes in the version information obtained from the monitoring, read the current configuration version identifier of each service instance in the version information.

[0084] In some embodiments of this disclosure, each service instance can monitor changes in the current configuration version identifier of all service instances corresponding to the same service in the version information through a listening mechanism. In some embodiments, the read operation can be triggered based on version information change events to ensure that each instance can obtain the latest version status information in a timely manner.

[0085] In some embodiments of this disclosure, as described above, based on a listening mechanism, any change to a key-value pair that begins with the version information storage path (and is prefixed with the corresponding service identifier) ​​will trigger listening events for the corresponding service instances under that storage path. In this embodiment, when a service instance updates its configuration version identifier in the version information, this update operation can trigger listening responses from other service instances, that is, trigger other service instances listening to this version information to receive a change notification and read the current configuration version identifier of each service instance in the version information.

[0086] In a specific embodiment of this disclosure, when the service instance POD1 of the order service updates the value of its corresponding key " / services / order-service / instances / pod-1 / version" in etcd from the original "v1" to "v2", POD2 and POD3 are triggered to obtain information containing the version status of all instances through the listening response mechanism: POD1 is "v2", POD2 is "v1", and POD3 is "v1".

[0087] 160: Compare the configuration version identifiers of each service instance read.

[0088] In some embodiments of this disclosure, step 160 can be performed during or after the version information reading in step 150. Specifically, after each service instance obtains the current configuration version identifier of each service instance in the version information, it can compare all the read configuration version identifiers to determine whether there are version differences.

[0089] In some embodiments, if the configuration version identifiers of all service instances are consistent, the following step 161 can be performed:

[0090] 161: When the configuration version identifiers of all service instances are consistent, perform service business processing based on the changed configuration content.

[0091] In a specific embodiment of this disclosure, when the service instance POD1 of the order service reads that the configuration version identifiers of all service instances POD1, POD2, and POD3 under the path " / services / order-service / instances" are "v2", it determines that the configuration version identifiers are consistent, and then performs business processing based on the current version. This strict matching strategy ensures that each service instance can perform business processing based on completely identical configuration content, fundamentally avoiding the problem of inconsistent business logic among multiple instances of the same business service due to configuration differences, thus preventing fluctuations in business service processing results.

[0092] In some embodiments, if the configuration version identifiers of the service instances are inconsistent, the following step 162 can be performed:

[0093] 162: If the current configuration version identifiers of the service instances are inconsistent, the service's business processing will not be executed.

[0094] In this embodiment of the disclosure, as described above, an update operation of a service instance updating its configuration version identifier in its version information can trigger a listening response from other service instances. In this embodiment, when the configuration version identifiers of the various service instances are inconsistent, the listening responses of other service instances can be triggered, the current configuration version identifiers of each service instance in the version information can be read, and further steps can be executed.

[0095] In other embodiments, a heartbeat mechanism can be used to achieve the timely deregistration or deletion of the offline service instances described above. In these embodiments, before comparing the configuration version identifiers of each service instance, the process further includes: determining the health status of each service instance based on its heartbeat information; and excluding the configuration version identifiers of service instances in an unhealthy state during the comparison. Those skilled in the art will understand that in different embodiments, this heartbeat mechanism and the aforementioned lease mechanism can be chosen individually or in combination.

[0096] Therefore, the heartbeat mechanism can monitor the health status of each service instance in real time, exclude unhealthy service instances during configuration version comparison, and ensure that configuration version comparison is only performed on currently alive service instances, avoiding configuration version comparison blocking caused by faulty instances.

[0097] In some embodiments of this disclosure, the step of comparing the read configuration version identifier further includes:

[0098] 162' (Unmarked): If the first configuration version identifier of the service instance lags behind the second configuration version identifier of any other service instance, obtain the change configuration content that the service instance is missing relative to the other service instances.

[0099] In this embodiment, the second configuration version identifier is the latest configuration version identifier corresponding to each service instance.

[0100] In this embodiment, the service instance performing the comparison can perform comparative analysis on the configuration version identifier obtained from step 150. When it is found that its current configuration version identifier (first configuration version identifier) ​​is behind the latest configuration version identifier (second configuration version identifier) ​​in other service instances, it is determined that the instance version is outdated and needs to be caught up. As an explanation and not a limitation, in the distributed coordination service, the configuration version identifier usually adopts an incremental version number format (such as "v1", "v2", "v3") or a timestamp format, and therefore has a clear chronological order. When the configuration version identifiers of each service instance are different, the newness of the version can be determined by the numerical value of the version number or the chronological order.

[0101] In some embodiments of this disclosure, a service instance may suspend corresponding service processing and optionally enter a configuration version synchronization waiting state if its first configuration version identifier lags behind its second configuration version identifier. This prevents service processing based on different configuration versions and avoids inconsistencies in the service results of the same service.

[0102] In some embodiments of this disclosure, reference is made to Figure 4 The step of obtaining the missing change configuration content of the current service instance relative to other service instances may include the following steps 1621', 1622' and 1623'.

[0103] 1621': Determine the configuration version identifier that is missing from the first configuration version identifier relative to the second configuration version identifier.

[0104] In the embodiments of this disclosure, as previously described, the configuration version identifier is used to uniquely identify the configuration content version. Therefore, in some embodiments of this disclosure, the difference between the first configuration version identifier and the latest second configuration version identifier can be analyzed to determine the configuration content version difference. In one example, when the latest configuration version identifier is "v3" and the configuration version identifier corresponding to a certain service instance is "v1", then the missing configuration version identifiers for that service instance are determined to be "v2" and "v3".

[0105] In some embodiments, the service instance may calculate all intermediate version identifiers between the first configuration version identifier and the second configuration version identifier based on the sequential characteristics of the configuration version identifiers, and determine the configuration version sequence that needs to be obtained.

[0106] 1622': Retrieve the supplementary configuration changes corresponding to the missing configuration version identifier from the configuration source.

[0107] In some embodiments of this disclosure, in response to the determination of a missing configuration version identifier, the service instance may sequentially obtain the configuration content of the missing version from the configuration source.

[0108] In some embodiments, if the service instance determines that a missing configuration version identifier is missing, it can send a request to the configuration source. The configuration source can then push the corresponding configuration content to service instances with outdated versions based on the configuration version identifier. In other embodiments, the service instance can proactively retrieve the missing configuration content from the configuration source, for example, by obtaining the missing configuration content on demand through a query interface based on the configuration version identifier between the service instance and the configuration source.

[0109] 1623': Write the changed configuration version identifier in the supplementary changed configuration content into the distributed coordination storage service, thereby updating the configuration version identifier of the current service instance in the version information.

[0110] In some embodiments of this disclosure, after the current service instance obtains the missing configuration content, it can write the changed configuration version identifier from the supplemented configuration content to the distributed coordination storage service, thereby updating its corresponding configuration version identifier in the version information. Thus, the update of the current service instance's version identifier can trigger the listening responses of other service instances, thereby returning to the execution of steps 150 and 160. Accordingly, only when the configuration version identifiers of all instances are consistent do each service instance execute its service's business processing logic based on the configuration content it has obtained, thus resuming business processing.

[0111] In some embodiments of this disclosure, the acquisition, update, read, comparison, and business processing steps are executed cyclically. For explanation, when the configuration source changes multiple times consecutively, the system can automatically repeat the acquisition, update, read, comparison, and business processing steps to ensure the consistency of subsequent configuration changes.

[0112] The following will further describe the distributed service configuration change processing method described in the above embodiments of this disclosure with reference to a specific example. (Reference) Figure 5This diagram illustrates a distributed service configuration change processing flow according to a specific embodiment. In this embodiment, during the initial stage, three service instances of the order settlement service, POD1, POD2, and POD3, are registered to etcd. Correspondingly, a tree-like directory structure is created in etcd, establishing a set of key-value pairs: " / services / order-service / instances / pod-1 / version: v0; / services / order-service / instances / pod-2 / version: v0; / services / order-service / instances / pod-3 / version: v0". Subsequently, the three service instances each establish a listener for the path " / services / order-service / instances / ", that is, they listen for paths prefixed with the service identifier "order-service", using etcd's Watch mechanism to detect version information changes in real time. In some embodiments, the timely deregistration or deletion of offline service instances can also be achieved during registration using etcd's lease mechanism. In one specific embodiment, POD1 creates a lease with a validity period of l1 seconds with etcd upon startup and binds the key " / services / order-service / instances / -001 / version" to this lease. Simultaneously, it sends a renewal request to etcd every s1 seconds. When POD1 stops sending renewal requests due to a failure, etcd automatically deletes the corresponding key-value pair of POD1 after the lease expires. At this time, when POD2 and POD3 compare configuration version identifiers, the version information only contains the configuration version identifiers of POD2 and POD3. When they match, business processing can be executed. Similarly, l2 and l3 leases can be set for POD2 and POD3, and renewal requests can be sent to etcd every s2 and s3 seconds. Therefore, the lease mechanism enables dynamic maintenance of the service instance list. When a service instance fails, it is automatically removed from the version information, ensuring that configuration version comparison is only performed on currently active service instances, avoiding configuration version comparison blocking caused by failed instances.

[0113] Continue to refer to Figure 5The configurations of the three service instances are continuously changed at times t2, t4, and t6: At time t2, the configuration source adjusts the discount rate from the initial value to 20% and updates the configuration version identifier to v1; at time t4, the configuration source adjusts the discount rate from 20% to 25% and updates the configuration version identifier to v2; at time t6, the configuration source adjusts the discount rate from 25% to 30% and updates the configuration version identifier to v3. At time t3, POD1 receives the configuration change notification first (refer to step 130), obtains the changed configuration content containing the configuration version identifier "v1", and updates its own version in etcd to "v1" (refer to step 140). At this time, the key-value pair corresponding to POD1 in the version information becomes: " / services / order-service / instances / pod-1 / version: v1". Subsequently, POD1 not only reads its own version information and compares it with the configuration version identifier, but also triggers the listening responses of POD2 and POD3 (refer to step 150). They read the version information and perform the configuration version identifier comparison (refer to step 160). POD2 and POD3 find that their corresponding versions are outdated, and therefore suspend business processing. In some specific examples, each service instance periodically sends heartbeat information to the distributed coordination storage service to indicate that it is alive. When a service instance fails to send heartbeat information within a preset time, it is marked as unhealthy. Thus, for example, before the comparison, assuming that POD3 of the order service is marked as unhealthy due to a fault, POD1, upon obtaining that POD3 is in an unhealthy state, only compares the configuration version identifiers of POD1 and POD2. If they match, business processing can be executed. The processing of other PODs is the same. Subsequently, POD2 and POD3 determine their missing version v1 based on their own configuration version identifier "v0" and the latest confirmed version configuration identifier "v1" (refer to step 1621'), and therefore actively obtain the changed configuration content of version "v1" from the configuration source (refer to step 1622'). POD2 completes the acquisition of the changed configuration content of version "v1" at time t5 and POD3 completes the update of their corresponding key-value pairs in the version information to "v1" at time t7. At time t8, when the configuration version identifier of all service instances is "v1", the three instances simultaneously start executing business processing based on a 20% discount rate, ensuring the consistency of business logic.

[0114] Subsequently, the three service instances POD1, POD2, and POD3 repeatedly execute the above subscription, retrieval, update, read, comparison, and business processing steps until the configuration version identifiers of the three service instances are all "v3". At this point, the three instances simultaneously begin to execute business processing based on a 30% discount rate, ensuring the consistency of business logic.

[0115] The distributed service configuration change processing method of this disclosure uses a listening mechanism and configuration version identifier management based on distributed coordinated storage service to ensure that any change in the configuration version identifier of any service instance can be immediately detected by all instances of the same business service. This triggers the reading and comparison of the configuration version identifiers of all service instances under the same business service, ensuring that business processing is only executed when all service instances have the same configuration version at the same point in time (i.e., no business processing is executed if they are inconsistent). This fundamentally solves the problem of inconsistent service instance configuration versions caused by differences in configuration acquisition timing in the prior art. Even in extreme scenarios where the configuration source changes frequently, the method of this disclosure can ensure that different service instances of the same business service run under the same processing logic, thereby guaranteeing the stability of the processing results of the business service.

[0116] The distributed service configuration change processing method of this disclosure embodiment also uses a configuration version identifier difference identification and supplementary acquisition mechanism. When the configuration version identifier of the current service instance is behind the latest configuration version identifier of other service instances, it can determine the missing configuration version of the service instance and trigger sequential supplementary acquisition. This enables different service instances of the same business service to be dynamically adjusted to the same configuration, further ensuring the consistency of processing logic of different service instances of the same business service.

[0117] In some embodiments of this disclosure, reference is made to Figure 6 Furthermore, a distributed service change configuration processing device 600 is provided, which may include a listening unit 610, an acquisition unit 620, an update unit 630, a reading unit 640, and a comparison unit 650.

[0118] The listening unit 610 is configured to listen to the version information stored in the distributed coordination storage service, wherein the version information includes the configuration version identifier corresponding to each service instance that belongs to the same service as the service instance.

[0119] The acquisition unit 620 is configured to acquire changed configuration content from the configuration source in response to a change notification from the subscribed configuration source, wherein the changed configuration content includes a changed configuration version identifier;

[0120] The update unit 630 is configured to write the changed configuration version identifier into the distributed coordination storage service, thereby updating the configuration version identifier of the service instance in the version information;

[0121] The reading unit 640 is configured to read the current configuration version identifier of each service instance in the version information in response to changes in the version information obtained by monitoring;

[0122] The comparison unit 650 is configured to compare the configuration version identifiers of each service instance read. If the configuration version identifiers of each service instance are consistent, the service's business processing is executed based on the changed configuration content. If the current configuration version identifiers of each service instance are inconsistent, the service's business processing is not executed.

[0123] In some embodiments of this disclosure, the distributed service change configuration processing apparatus 600 may further include a registration unit 660 (unidentified), which is configured to register the service instance to the distributed coordination storage service. In some embodiments, the distributed coordination storage service is used to create a set of key-value pairs of version information for each service instance belonging to the same service.

[0124] The apparatus, components, modules, units, and features described in the embodiments of this disclosure can be incorporated into the methods of the embodiments of this disclosure in a non-contradictory manner, and the methods, steps, sub-steps, and features described in the embodiments of this disclosure can also be incorporated into the apparatus of the embodiments of this disclosure in a non-contradictory manner.

[0125] In some embodiments of this disclosure, such as Figure 7 The diagram illustrates an electronic device 700 capable of implementing the methods of embodiments of the present disclosure. In some embodiments, it may include more or fewer electronic devices than illustrated. In some embodiments, it may be implemented using a single or multiple electronic devices. In some embodiments, it may be implemented using cloud-based or distributed electronic devices.

[0126] like Figure 7 As shown, the electronic device 700 includes a processor 701, which can perform various appropriate operations and processes based on programs and / or data stored in read-only memory (ROM) 702 or programs and / or data loaded from storage portion 708 into random access memory (RAM) 703. The CPU 701 can be a multi-core processor or may contain multiple processors. In some embodiments, the processor 701 may include a general-purpose main processor and one or more special coprocessors, such as a graphics processing unit (GPU), a neural network processor (NPU), a digital signal processor (DSP), etc. Various programs and data required for the operation of the electronic device 700 are also stored in RAM 703. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0127] The processor and memory described above are used together to execute a program stored in the memory. When the program is executed by a computer, it can implement the steps or functions of the distributed service change configuration processing method described in the above embodiments.

[0128] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, mouse, touchscreen, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed. Figure 7 The diagram only shows a portion of the components and does not imply that the computer system 700 includes only a portion of the components. Figure 7 The components shown.

[0129] Although not shown, in embodiments of this disclosure, a program product is provided, including a computer program that, when executed by a processor, implements the methods of any of the embodiments of this disclosure.

[0130] Although not shown, in embodiments of this disclosure, a storage medium is provided that stores a computer program configured to be executed to implement the methods of any of the embodiments of this disclosure.

[0131] The storage media in embodiments of this disclosure include articles that are permanent and non-permanent, removable and non-removable, capable of storing information by any method or technology. Examples of storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0132] The methods, programs, systems, apparatuses, etc., of the embodiments of this disclosure can be executed or implemented in a single or multiple networked computers, or practiced in a distributed computing environment. In the embodiments of this specification, in these distributed computing environments, tasks can be performed by remote processing devices connected via a communication network.

[0133] Those skilled in the art will understand that the embodiments described in this specification can be provided as methods, systems, or computer program products. Therefore, those skilled in the art will realize that the functional modules / units or controllers and related method steps described in the above embodiments can be implemented in software, hardware, or a combination of both.

[0134] Unless explicitly stated otherwise, the actions or steps of the methods or procedures described in the embodiments of this disclosure do not necessarily have to be performed in a specific order and can still achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0135] This document describes several embodiments of the present disclosure; however, for the sake of brevity, the descriptions of the embodiments are not exhaustive, and identical or similar features or portions between the embodiments may be omitted. In this document, "one embodiment," "some embodiments," "example," "specific example," or "some examples" refers to at least one embodiment or example applicable to the present disclosure, but not all embodiments. The above terms do not necessarily refer to the same embodiment or example. Without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of the different embodiments or examples.

[0136] The exemplary systems and methods of this disclosure have been specifically shown and described with reference to the foregoing embodiments, and are merely examples of the best mode for implementing the systems and methods. Those skilled in the art will understand that various changes can be made to the embodiments of the systems and methods described herein without departing from the spirit and scope of this disclosure as defined in the appended claims when implementing the systems and / or methods.

Claims

1. A method for handling configuration changes in a distributed service, applied to a service instance, characterized in that, include: Monitor the version information stored in the distributed coordination storage service, wherein the version information includes the configuration version identifier corresponding to each service instance that belongs to the same service as the service instance; In response to a change notification from a subscribed configuration source, the changed configuration content is obtained from the configuration source, wherein the changed configuration content includes a changed configuration version identifier; Write the changed configuration version identifier into the distributed coordination storage service, thereby updating the configuration version identifier of the service instance in the version information; In response to changes in the version information obtained from monitoring, the current configuration version identifier of each service instance is read from the version information; The configuration version identifiers of each service instance are compared. If the current configuration version identifiers of each service instance are inconsistent, the business processing of the service will not be executed.

2. The distributed service configuration change processing method according to claim 1, characterized in that, Also includes: If the configuration version identifiers of all service instances are consistent, the service's business processing is executed based on the changed configuration content.

3. The distributed service configuration change processing method according to claim 1, characterized in that, Before executing the listener, the following is also included: The service instance is registered to the distributed coordination storage service, which is used to create a set of key-value pairs of version information for each service instance belonging to the same service.

4. The distributed service configuration change processing method according to claim 3, characterized in that, The distributed coordination storage service includes a tree-like directory structure, which includes key-value pairs corresponding one-to-one with multiple service instances. The key of any key-value pair is a path identifier that includes the service instance identifier corresponding to the service instance, and the value of any key-value pair is the configuration version identifier of the corresponding service instance.

5. The distributed service configuration change processing method according to claim 1, characterized in that, The comparison of the read configuration version identifier also includes: If the first configuration version identifier of the service instance lags behind the second configuration version identifier of any other service instance, the missing configuration changes of the service instance relative to the other service instances are obtained, wherein the second configuration version identifier is the latest configuration version identifier corresponding to each service instance.

6. The distributed service configuration change processing method according to claim 5, characterized in that, The step of obtaining the missing configuration changes for the service instance relative to other service instances includes: Determine the configuration version identifier that is missing from the first configuration version identifier relative to the second configuration version identifier; Obtain the supplementary changed configuration content corresponding to the missing configuration version identifier from the configuration source; The modified configuration version identifier in the supplementary modified configuration content is written into the distributed coordination storage service, thereby updating the configuration version identifier of the service instance in the version information.

7. The distributed service configuration change processing method according to any one of claims 1 to 6, characterized in that, The version information stored in the monitored distributed coordination storage service includes: The path in the distributed coordination and storage service that is prefixed with a service identifier is monitored, wherein the service identifier is used to identify the service to which the service instance belongs.

8. A distributed service configuration change processing device, applied to a service instance, characterized in that, include: The listening unit is configured to listen to the version information stored in the distributed coordination storage service, wherein the version information includes the configuration version identifier corresponding to each service instance that belongs to the same service as the service instance; The acquisition unit is configured to, in response to a change notification from a subscribed configuration source, acquire changed configuration content from the configuration source, wherein the changed configuration content includes a changed configuration version identifier; The update unit is configured to write the changed configuration version identifier into the distributed coordination storage service, thereby updating the configuration version identifier of the service instance in the version information; The reading unit is configured to read the current configuration version identifier of each service instance from the version information in response to changes in the version information obtained from the monitoring. The comparison unit is configured to compare the configuration version identifiers of each service instance read. If the current configuration version identifiers of each service instance are inconsistent, the service's business processing will not be executed.

9. An electronic device, characterized in that, include: A processor and a memory storing a computer program, the processor being configured to implement the method of any one of claims 1-7 when the computer program is executed.

10. A program product comprising a computer program, wherein, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images