Distributed data service cluster access method and device, electronic equipment and storage medium
By dynamically determining and managing access instances of distributed data service clusters, the business system complexity problems caused by changes in cluster environments in the financial and medical fields are solved, and efficient and stable data access is achieved.
Patent Information
- Application Number
- CN202510731364.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-30
- Publication Date
- 2025-07-18
AI Technical Summary
In the financial and medical fields, the business system call relationship management caused by the version upgrade and environmental migration of distributed data clusters is highly complex, affecting business continuity and data access stability.
By obtaining target business requests and cluster configuration information, dynamically determine the target service cluster, use the historical instance library to find or create cluster access instances, realize data access, and update the instances in a timely manner when configuration changes, ensuring that the business system does not perceive the underlying cluster changes.
It reduces the development complexity of the environment changes of distributed data clusters, improves the stability and flexibility of data access, reduces the overhead of repeated initialization of connections, and ensures the continuity of data access and real-time adaptability to cluster configuration changes.
Smart Images

Figure CN120343025A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical fields of finance and medical services, and in particular to a method and device for accessing a distributed data service cluster, an electronic device, and a storage medium. Background Art
[0002] In the technical fields of finance and medical services, enterprises generally rely on large-scale data storage and retrieval and analysis capabilities to support their daily operations. For example, a distributed data cluster is used to support real-time transaction monitoring, fast query of risk measurement models, or full-text search of electronic health records and fast positioning of medical image metadata. With the continuous development of business and the continuous growth of data volume, financial institutions and medical organizations often need to deploy and operate and maintain multiple distributed data clusters, and these clusters may be physically isolated or logically separated due to data types, data sensitivity levels, and business line divisions.
[0003] In the related art, due to the impacts brought by the version upgrade, environment migration, and configuration change of the cluster itself, the management of the call relationship between the business system and these distributed data clusters often requires a large amount of operation and maintenance investment. For example, when a certain cluster is upgraded in version, all business systems depending on this cluster need to modify their connection configurations and API call logics for interacting with the cluster. This process is not only time-consuming and laborious, but also may cause service interruption or data access exception in industries such as finance and medical that have extremely high requirements for business continuity. Summary of the Invention
[0004] The main purpose of the embodiments of the present application is to propose a method and device for accessing a distributed data service cluster, an electronic device, and a storage medium, aiming to reduce the development complexity caused by the change of the distributed data cluster environment, and thus improve the stability of data access.
[0005] To achieve the above object, a first aspect of the embodiments of the present application proposes a method for accessing a distributed data service cluster, the method including:
[0006] Obtain a target business request from a target business scenario and cluster configuration information of multiple distributed data service clusters;
[0007] Based on the target business request, determine at least one target service cluster from multiple distributed data service clusters;
[0008] For each target service cluster, search for a corresponding cluster access instance in a historical instance library according to the cluster configuration information;
[0009] If a matching cluster access instance is found in the historical instance library, determine the found cluster access instance as a target cluster access instance;
[0010] If no matching cluster access instance is found in the historical instance library, create the target cluster access instance according to the cluster configuration information of the target service cluster;
[0011] Perform data access on the target service cluster through the target cluster access instance to obtain target response data returned by the target service cluster.
[0012] In some embodiments, determining at least one target service cluster from multiple distributed data service clusters based on the target service request includes:
[0013] Parse the target service request to obtain a target service scenario identifier for indicating the target service scenario;
[0014] According to the target service scenario identifier, determine a corresponding target mapping rule in the preset mapping configuration information; wherein, the target mapping rule defines the association between the target service scenario identifier and one or more distributed data service clusters;
[0015] Determine at least one of the target service clusters according to the target mapping rule.
[0016] In some embodiments, for each target service cluster, searching for a corresponding cluster access instance in the historical instance library according to the cluster configuration information includes:
[0017] For each target service cluster, extract a preset key configuration item from its corresponding cluster configuration information; wherein, the key configuration item includes a cluster network address and a cluster connection parameter;
[0018] Generate a configuration summary string that uniquely identifies the current configuration state of the target service cluster according to the key configuration item;
[0019] Use the configuration summary string as a search key to retrieve in the historical instance library whether there is a previously created and stored cluster access instance that matches it.
[0020] In some embodiments, if no matching cluster access instance is found in the historical instance library, creating the target cluster access instance according to the cluster configuration information of the target service cluster includes:
[0021] Create a new target cluster access instance according to the cluster configuration information of the target service cluster;
[0022] Associate the newly created target cluster access instance with the configuration summary string corresponding to the target service cluster to obtain an instance association relationship;
[0023] Store the instance association relationship and the newly created target cluster access instance in the historical instance library.
[0024] In some embodiments, the data access to the target service cluster through the target cluster access instance to obtain the target response data returned by the target service cluster includes:
[0025] Parse the target business request to obtain a business operation instruction;
[0026] Convert the business operation instruction into a native API call instruction supported by each target service cluster;
[0027] Use the target cluster access instance corresponding to each target service cluster to send the native API call instructions for the target service cluster to the target service cluster for execution respectively, and receive the target response data returned from each target service cluster that has completed the execution of the native API call instruction.
[0028] In some embodiments, after the data access to the target service cluster through the target cluster access instance to obtain the target response data returned by the target service cluster, it further includes:
[0029] When there are multiple target service clusters, perform an aggregation process on the target response data received from different target service clusters according to a preset business rule to obtain target aggregation data;
[0030] Return the target aggregation data or the target response data to the target business scenario.
[0031] In some embodiments, the method further includes:
[0032] In response to detecting a change event in the cluster configuration information, for each cluster access instance in the historical instance library, verify whether the configuration summary string associated with the cluster access instance matches any of the current configuration summary strings generated according to the changed cluster configuration information to obtain a first verification result;
[0033] Verify whether the continuous unused duration of the cluster access instance has exceeded a preset maximum deactivation time threshold to obtain a second verification result;
[0034] If the first verification result indicates that the configuration summary string of the cluster access instance has expired, or the continuous unused duration has exceeded the maximum deactivation time threshold, remove the cluster access instance from the historical instance library.
[0035] To achieve the above object, a second aspect of the embodiments of the present application proposes an access device for a distributed data service cluster, the device comprising:
[0036] An acquisition module, configured to acquire a target service request from a target business scenario and cluster configuration information of a plurality of distributed data service clusters;
[0037] A first determination module, configured to determine at least one target service cluster from the plurality of distributed data service clusters based on the target service request;
[0038] A search module, configured to search for a corresponding cluster access instance in a historical instance library according to the cluster configuration information for each target service cluster;
[0039] A second determination module, configured to, if a matching cluster access instance is found in the historical instance library, determine the found cluster access instance as a target cluster access instance;
[0040] A creation module, configured to, if a matching cluster access instance is not found in the historical instance library, create the target cluster access instance according to the cluster configuration information of the target service cluster;
[0041] A data access module, configured to perform data access on the target service cluster through the target cluster access instance to obtain target response data returned by the target service cluster.
[0042] To achieve the above object, a third aspect of the embodiments of the present application proposes an electronic device, the electronic device comprising a memory and a processor, the memory storing a computer program, and the processor implementing the method described in the first aspect above when executing the computer program.
[0043] To achieve the above object, a fourth aspect of the embodiments of the present application proposes a computer-readable storage medium, the computer-readable storage medium storing a computer program, and the computer program implementing the method described in the first aspect above when executed by a processor.
[0044] The access method and device for a distributed data service cluster, an electronic device, and a storage medium proposed in this application obtain a target service request from a target business scenario and cluster configuration information of multiple distributed data service clusters; determine at least one target service cluster from the multiple distributed data service clusters based on the target service request; for each target service cluster, search for a corresponding cluster access instance in a historical instance library according to the cluster configuration information; if a matching cluster access instance is found in the historical instance library, determine the found cluster access instance as the target cluster access instance; if no matching cluster access instance is found in the historical instance library, create a target cluster access instance according to the cluster configuration information of the target service cluster; and perform data access on the target service cluster through the target cluster access instance to obtain target response data returned by the target service cluster.
[0045] First, this application obtains the service request of the target business scenario and the configuration information of all available clusters. Then, by dynamically determining the target service cluster based on the service request, it can achieve the matching of business logic and physical cluster deployment, enabling the business system to be unaware of the version changes, environment migrations, or scaling changes of the underlying clusters, greatly improving the flexibility and maintainability of the system, especially in financial and medical data-intensive applications where the clusters change frequently. Then, for each determined target service cluster, by preferentially searching for and reusing existing cluster access instances in the historical instance library according to its current configuration information, it can effectively avoid the overhead of repeated initialization connections, significantly improving the response speed of data access and the utilization efficiency of system resources. Further, when no matching instance is found in the historical instance library, a new access instance is created immediately according to the latest configuration information of the target service cluster, ensuring the continuity of data access and the real-time adaptability to cluster configuration changes, and also providing a reuse basis for subsequent requests with the same configuration. Finally, data access is performed on the target service cluster through the target cluster access instance to obtain target response data. In summary, the method and device proposed in this application can effectively address the adaptation and maintenance challenges brought by distributed data service clusters to the business system in complex scenarios such as version upgrades, environment migrations, and coexistence of multiple versions. Through cluster dynamic selection, an efficient access instance lifecycle management and reuse mechanism, it significantly reduces the development and maintenance costs of the business system, improves data access performance and overall stability and flexibility, and provides reliable and efficient data service access for core businesses in financial and medical fields such as financial risk control, electronic medical records, and medical image analysis that need to process massive and high-concurrency data. Brief Description of the Drawings
[0046] Figure 1 is a flowchart of the access method for a distributed data service cluster provided by an embodiment of this application;
[0047] Figure 2 It is another flowchart of the access method for the distributed data service cluster provided by the embodiments of the present application;
[0048] Figure 3 It is another flowchart of the access method for the distributed data service cluster provided by the embodiments of the present application;
[0049] Figure 4 It is another flowchart of the access method for the distributed data service cluster provided by the embodiments of the present application;
[0050] Figure 5 It is another flowchart of the access method for the distributed data service cluster provided by the embodiments of the present application;
[0051] Figure 6 It is another flowchart of the access method for the distributed data service cluster provided by the embodiments of the present application;
[0052] Figure 7 It is another flowchart of the access method for the distributed data service cluster provided by the embodiments of the present application;
[0053] Figure 8 It is a schematic structural diagram of the access device for the distributed data service cluster provided by the embodiments of the present application;
[0054] Figure 9 It is a schematic hardware structure diagram of the electronic device provided by the embodiments of the present application. Detailed implementation manners
[0055] In order to make the objectives, technical solutions and advantages of the present application more clear and understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0056] It should be noted that although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order from the module division in the device or the flowchart in the flowchart. The terms "first", "second", etc. in the description and claims of the specification and the above-mentioned drawings are used to distinguish similar objects and do not necessarily need to be used to describe a specific order or sequence.
[0057] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.
[0058] Based on this, the embodiments of the present application provide a method and apparatus for accessing a distributed data service cluster, an electronic device, and a storage medium, aiming to improve the management efficiency of the call relationship of the service system.
[0059] The method and apparatus for accessing a distributed data service cluster, an electronic device, and a storage medium provided by the embodiments of the present application will be specifically described through the following embodiments. First, the method for accessing a distributed data service cluster in the embodiments of the present application will be described.
[0060] The method for accessing a distributed data service cluster provided by the embodiments of the present application relates to the technical field of financial services. The method for accessing a distributed data service cluster provided by the embodiments of the present application can be applied to a terminal, a server, or software running on a terminal or a server. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application for implementing the method for accessing a distributed data service cluster, etc., but is not limited to the above forms.
[0061] The present application can be used in many general or specific computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and so on. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application can also be practiced in a distributed computing environment where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.
[0062] It should be noted that in each specific embodiment of the present application, when it comes to relevant processing based on data related to the user's identity or characteristics, such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first. Moreover, the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiments of the present application need to obtain the user's sensitive personal information, the user's separate permission or separate consent will be obtained through methods such as pop-up windows or redirecting to a confirmation page. After clearly obtaining the user's separate permission or separate consent, the necessary user-related data for the normal operation of the embodiments of the present application will be obtained.
[0063] Figure 1 FIG. is an alternative flowchart of the access method for a distributed data service cluster provided by an embodiment of the present application. Figure 1 The method in may include, but is not limited to, steps S101 to S106.
[0064] Step S101, obtain a target service request from a target business scenario and the cluster configuration information of multiple distributed data service clusters.
[0065] Step S102, determine at least one target service cluster from multiple distributed data service clusters based on the target service request.
[0066] Step S103, for each target service cluster, search for the corresponding cluster access instance in the historical instance library according to the cluster configuration information.
[0067] Step S104, if a matching cluster access instance is found in the historical instance library, determine the found cluster access instance as the target cluster access instance.
[0068] Step S105, if no matching cluster access instance is found in the historical instance library, create a target cluster access instance according to the cluster configuration information of the target service cluster.
[0069] Step S106, perform data access on the target service cluster through the target cluster access instance to obtain the target response data returned by the target service cluster.
[0070] Steps S101 to S106 illustrated in the embodiments of this application, first by obtaining the service request of the target business scenario and the configuration information of all available clusters, and then, by dynamically determining the target service cluster based on the service request, it can achieve the matching of business logic and physical cluster deployment, enabling the business system to be unaware of the version changes, environment migrations, or scale-up / scale-down changes of the underlying clusters, greatly improving the flexibility and maintainability of the system, especially in financial and medical data-intensive applications where the clusters change frequently; then, for each determined target service cluster, first search for and reuse the existing cluster access instances in the historical instance library according to its current configuration information, which can effectively avoid the overhead of repeated initialization connections, significantly improving the response speed of data access and the utilization efficiency of system resources; further, when no matching instance is found in the historical instance library, a new access instance is created immediately according to the latest configuration information of the target service cluster, ensuring the continuity of data access and the real-time adaptability to cluster configuration changes, and at the same time providing a reuse basis for subsequent requests with the same configuration. Finally, data access is performed on the target service cluster through the target cluster access instance to obtain the target response data. In summary, the method and device proposed in this application can effectively address the adaptation and maintenance challenges brought by the distributed data service cluster to the business system in complex scenarios such as version upgrades, environment migrations, and coexistence of multiple versions. Through cluster dynamic selection, efficient access instance lifecycle management and reuse mechanisms, it significantly reduces the development and maintenance costs of the business system, improves data access performance and overall stability and flexibility, and provides reliable and efficient data service access for the core businesses in financial and medical fields such as financial risk control, electronic medical records, and medical image analysis that need to process massive and high-concurrency data.
[0071] In step S101 of some embodiments, first obtain a specific target business scenario, such as the "rapid electronic medical record retrieval system" in the medical field, and the specific target business request initiated by it. This request may include information such as query conditions and operation types. At the same time, the cluster configuration information of multiple distributed data service clusters deployed in the current environment will also be loaded or obtained. These cluster configuration information are preset and describe in detail the network address, port, authentication credentials, and important connection pool parameters such as the maximum connection number, maximum idle connection number, and minimum idle connection number of each cluster (such as an Elasticsearch cluster).
[0072] In step S102 of some embodiments, based on the service scenario identifier specified in the received target service request and in combination with preset mapping configuration information that defines which specific data service clusters should be accessed for different service scenarios, at least one or more target service clusters are intelligently determined among multiple distributed data service clusters. For example, if the target service request comes from the "Customer Transaction Behavior Analysis Module", the mapping configuration may specify that it should access the "Historical Transaction Data Cluster A" and the "Customer Portrait Cluster B"; or a "Cross-Hospital Area Imaging Diagnosis and Consultation" request may need to access the "Imaging Archiving Cluster of Hospital A" and the "Imaging Archiving Cluster of Hospital B" simultaneously.
[0073] Please refer to Figure 2 , in some embodiments, step S102 may include but is not limited to steps S201 to S203:
[0074] Step S201, parse the target service request to obtain a target service scenario identifier for indicating the target service scenario.
[0075] Step S202, determine the corresponding target mapping rule in the preset mapping configuration information according to the target service scenario identifier.
[0076] Step S203, determine at least one target service cluster according to the target mapping rule.
[0077] In step S201 of some embodiments, first, the received target service request is parsed. The purpose of the parsing is to extract or generate a "target service scenario identifier" that clearly indicates the current service operation context. This "target service scenario identifier", as a key basis for subsequent routing and resource location, may be directly included in the metadata of the request, such as the value of a field named business_context_id being CREDIT_SCORE_QUERY_V1, or indirectly determined by parsing the service interface definition of the request (such as the URI path of a RESTful API or the query name of GraphQL). Its core role is to perform a preliminary logical mapping between the upper-layer service intention and the lower-layer data service.
[0078] In step S202 of some embodiments, then, using the "target business scenario identifier" successfully identified in step S201, an exact search is performed in the "mapping configuration information" that is pre-configured and loaded into the system memory or dynamically obtained from a configuration center (such as Nacos, Consul, etc.) to determine the "target mapping rule" uniquely corresponding to this identifier. The "mapping configuration information" is a structured data set that defines the routing logic between all supported business scenarios and their backend data service clusters in the entire system. Each "target mapping rule" specifically and clearly specifies that a certain "target business scenario identifier" should be directed to one or more specific distributed data service clusters (for example, the logical alias, cluster label, or service discovery address of a specific Elasticsearch cluster). For example, for the "CREDIT_SCORE_QUERY_V1" identifier in the aforementioned financial scenario, its corresponding "target mapping rule" may indicate that the request should be routed to the "Production Environment - Financial Credit Data - ES Cluster Group A"; for the medical scenario identifier, the rule may specify accessing the "Shared Imaging Data - ES Cluster C".
[0079] In step S203 of some embodiments, according to the "target business scenario identifier", when the corresponding "target mapping rule" is successfully matched and obtained in the "mapping configuration information", the detailed identifier information (such as cluster name, IP address list, port number, etc.) of one or more associated distributed data service clusters is parsed and extracted from this rule. These extracted clusters are finally determined as the "at least one target service cluster" for this specific target business request, and they are the direct objects for subsequent data access instance search (step S103), instance creation (step S105), and actual data interaction (step S106).
[0080] In summary, through steps S201 to S203, the embodiments of the present application first accurately identify the business scenario and then dynamically determine the target cluster according to the centrally managed mapping rules. The present application enables the upper-layer business system to not care about the specific location, version, or configuration details of the underlying cluster (such as the Elasticsearch cluster) when initiating data access. It enhances the flexibility and maintainability of the system, such that in the context of rapid iteration of financial business or constantly changing requirements for medical data integration, the upgrade and migration of the backend data cluster can be quickly completed by modifying the mapping configuration information, without the need to modify a large amount of business application code, thereby significantly reducing the complexity and risk of system evolution and improving the adaptability and operation and maintenance efficiency of the overall architecture.
[0081] In step S103 of some embodiments, for each target service cluster determined in step S102, according to the cluster configuration information of the target service cluster, check whether there is a cluster access instance that has been created and can be reused in a historical instance library maintained internally. The historical instance library is usually a key-value storage structure (such as a hash table), and its key is usually a unique configuration summary string generated based on key items of the cluster configuration information (such as network address, authentication information, key connection parameters), and the value is the corresponding initialized cluster access instance object. This search process aims to reuse existing connections preferentially to avoid unnecessary resource consumption.
[0082] In step S104 of some embodiments, if in the historical instance library, a cluster access instance that is completely matched and in a normal state is successfully found through the configuration summary string generated in step S103, then this existing and immediately available cluster access instance will be determined as the target cluster access instance for this request, that is, if the connection instance already exists in the historical instance library and the configuration has not changed, directly reuse this instance, thereby skipping the time-consuming connection establishment and authentication processes and quickly responding to business requests.
[0083] Please refer to Figure 3 , in some embodiments, step S104 may include but is not limited to steps S301 to S303:
[0084] Step S301, for each target service cluster, extract preset key configuration items from its corresponding cluster configuration information.
[0085] Step S302, generate a configuration summary string that uniquely identifies the current configuration state of the target service cluster according to the key configuration items.
[0086] Step S303, use the configuration summary string as the search key to retrieve in the historical instance library whether there is a previously created and stored cluster access instance that matches it.
[0087] In step S301 of some embodiments, for each target service cluster determined in step S102, a set of predefined "key configuration items" is precisely extracted from the loaded cluster configuration information corresponding to the cluster. These "key configuration items" are the core parameters that can uniquely and sufficiently describe the connection characteristics and status of a cluster. For example, for an Elasticsearch cluster serving as a target service cluster, its "key configuration items" may include, but are not limited to, the network address of the cluster (such as a list of hostnames or IP addresses), port number, connection protocol (HTTP or HTTPS), and possible authentication credentials (such as username, password, or API Key). In addition, it also includes important "cluster connection parameters" that affect the behavior of the connection pool, such as the maximum number of connections (maxTotal), the maximum number of idle connections (maxIdle), connection timeout (connectTimeout), socket timeout (socketTimeout), etc. In the post-analysis of high-concurrency transactions in the financial field, accurately extracting these parameters is crucial for establishing a stable and efficient data connection.
[0088] In step S302 of some embodiments, then, using the set of "key configuration items" extracted for each target service cluster in step S301, a unique "configuration summary string" is generated through a deterministic algorithm (for example, sorting all key configuration items in a fixed order and then concatenating them and calculating their hash value). Any change in a "key configuration item" (for example, a change in the IP address of an Elasticsearch cluster node or an adjustment of the maximum number of connections in the connection pool) will result in a different "configuration summary string". This mechanism ensures that as long as the core connection attributes of the cluster remain unchanged, the generated "configuration summary string" remains consistent, and vice versa. For example, if the node list or authentication method of an Elasticsearch cluster relied on by a financial risk control rule engine is updated, the new "configuration summary string" will be different from the old one.
[0089] In step S303 of some embodiments, the "configuration summary string" generated for a specific target service cluster in step S302 is then used as a search key to perform a retrieval operation in the internally maintained "historical instance library". The "historical instance library" is a storage structure for caching and reusing created cluster access instances, usually implemented as an efficient key-value store (such as a hash table in memory). The purpose of the retrieval is to determine whether there is a cluster access instance that was previously created and stored in this library based on the exact same combination of "critical configuration items" (i.e., having the same "configuration summary string"). If there is such an instance with a completely matching configuration, it means that it can be directly reused, avoiding the overhead of repeated connection creation. For example, in a medical image retrieval application, if the connection parameters for a certain image archiving Elasticsearch cluster do not change within a short period of time, then a reusable connection instance can be found in the "historical instance library" through its "configuration summary string".
[0090] In summary, through steps S301 to S303, by precisely extracting and generating a unique configuration summary string based on the critical configuration items of the cluster, and then using this summary string as a key to search in the historical instance library, it can be ensured that reuse will only occur when the connection configuration of the target service cluster is exactly the same as that of a cached instance in the historical instance library, greatly improving the accuracy of connection reuse and avoiding the risk of connection failure or data access errors caused by misusing old instances due to configuration mismatch, which is crucial for financial transactions and medical diagnoses with extremely high requirements for data consistency and stability. Secondly, by reusing the already established connection instances, the number of time-consuming operations such as re-executing network connection establishment for each request is significantly reduced, thereby greatly reducing the data access latency and enhancing the overall response speed and throughput capacity. Finally, this instance management method based on the configuration summary also provides a clear identifier and basis for subsequent instance lifecycle management (such as instance creation, storage, and invalidation cleanup).
[0091] In step S105 of some embodiments, if a matching cluster access instance cannot be found in the historical instance library based on the configuration summary string, which may occur when accessing a certain cluster for the first time, the cluster configuration information has recently changed, or the historical instance has been cleared due to timeout, etc., a brand-new target cluster access instance will be dynamically created based on the latest cluster configuration information of the current target service cluster. For example, after the medical information system is upgraded, the port number of a related cluster changes, resulting in no matching instance in the historical instance library. At this time, an access instance configured with the new port number will be created. The newly created instance will then also be stored in the historical instance library and associated with its corresponding configuration summary string for reuse by subsequent requests with the same configuration.
[0092] Please refer to Figure 4, in some embodiments, step S105 may include but is not limited to steps S401 to S403:
[0093] Step S401, create a new target cluster access instance according to the cluster configuration information of the target service cluster.
[0094] Step S402, associate the newly created target cluster access instance with the configuration summary string corresponding to the target service cluster to obtain an instance association relationship.
[0095] Step S403, store the instance association relationship and the newly created target cluster access instance in the historical instance library.
[0096] In step S401 of some embodiments, when no existing cluster access instance matching the "configuration summary string" of the current target service cluster can be found in the historical instance library in step S103, a new "target cluster access instance" will be dynamically initialized and constructed based on the complete and up-to-date "cluster configuration information" of the "target service cluster". For example, in the financial field, if an Elasticsearch cluster for processing "end-of-day batch clearing" has just completed a version upgrade, resulting in a change in its connection protocol or authentication method, so that its new "configuration summary string" cannot be found in the historical instance library, a new object that adapts to the new version protocol and authentication will be created according to the upgraded new configuration information as the "target cluster access instance".
[0097] In step S402 of some embodiments, after successfully creating a new "target cluster access instance" in step S401, the newly created instance will be associated with the unique "configuration summary string" generated for the "target service cluster" in step S302, that is, the "configuration summary string" points to its corresponding "target cluster access instance" initialized according to this configuration to form an "instance association relationship". This "instance association relationship" is the basis for subsequent storage and search in the historical instance library. For example, for the newly created access instance that adapts to the upgraded Elasticsearch cluster in the aforementioned financial scenario, it will be bound to the "configuration summary string" representing the new configuration state of the cluster.
[0098] In step S403 of some embodiments, the "instance association relationship" established in step S402, together with the newly created "target cluster access instance" object itself, is stored in the "historical instance library". By storing the new instance and its association relationship in the historical instance library, the instance is transformed from a temporary object that only serves the current request to a shared resource that can be reused by subsequent business requests with the same cluster configuration. For example, the first connection instance created for the newly launched "gene sequencing data analysis" cluster in the medical field, after this storage is completed, all subsequent requests for this cluster with unchanged configuration will be able to directly find and reuse this instance from the historical instance library through steps S103 and S104.
[0099] In summary, through steps S401 to S403, it is first ensured that when accessing a distributed data service cluster that has not been accessed before or whose configuration has been updated, available access instances can be dynamically created based on the latest configuration information, guaranteeing the continuity of data access and the adaptability to changes in the cluster environment, which is crucial for financial services with extremely high requirements for business continuity and medical applications that need to quickly respond to changes in clinical data. Secondly, by associating the newly created instance and its configuration summary and storing them in the historical instance library, the optimization of creating once and reusing multiple times is achieved, providing a fast channel for subsequent requests with the same configuration requirements to obtain initialized connections, thereby sharing the cost of instance initialization and gradually improving the overall access performance. This mechanism also helps to control the total number of active connection instances in the system and avoid the problem of resource exhaustion caused by unlimited creation of new connections.
[0100] In step S106 of some embodiments, the target cluster access instance finally determined through step S104 or S105 performs actual data access operations on one or more target service clusters. This includes converting the operation instructions in the upper-layer target business request into native API call instructions supported by the target service cluster and sending these instructions through this instance. After the execution is completed, the target response data returned from the target service cluster is received. If there are multiple target service clusters, this step may also include processing such as merging, deduplicating, sorting, or aggregating the response data from different clusters to form a unified final result that meets the expectations of the business scenario. For example, data is obtained from the "user preference cluster" and the "product information cluster" respectively, and then aggregated to generate a recommendation list as the target response data.
[0101] Please refer to Figure 5 , in some embodiments, step S106 may include but is not limited to steps S501 to S503:
[0102] Step S501, parse the target business request to obtain the business operation instructions.
[0103] Step S502: Convert the service operation instruction into a native API call instruction supported by each target service cluster.
[0104] Step S503: Use the target cluster access instance corresponding to each target service cluster to separately send the native API call instruction for the target service cluster to the target service cluster for execution, and receive the returned target response data from each target service cluster that has completed the execution of the native API call instruction.
[0105] In step S501 of some embodiments, first, it is necessary to further deeply analyze the "target business request" initially received from the target business scenario, aiming to extract the specific "service operation instruction" therefrom. This "service operation instruction" represents the actual operation intention of the upper-layer business logic on the underlying data service. For example, in the scenario of "querying customer transaction flow" in the financial field, this instruction may be "query the last 100 transaction records according to the customer ID and time range and sort them in reverse chronological order".
[0106] In step S502 of some embodiments, next, the "service operation instruction" parsed in step S501 will be converted into a "native API call instruction" supported by each "target service cluster" determined in step S102. If a "service operation instruction" needs to access multiple different versions of "target service clusters" (for example, a financial business request may need to query an Elasticsearch cluster and an OpenSearch cluster simultaneously), it is necessary to translate the unified "service operation instruction" into specific API requests that each cluster can understand and execute. For example, for the query instruction in the aforementioned financial scenario, if the target service cluster is Elasticsearch, then the "native API call instruction" will be a JSON request body that conforms to the Elasticsearch query DSL (Domain Specific Language) specification; for medical image retrieval, if the underlying is a vector retrieval engine based on Elasticsearch, it will be converted into a corresponding vector search API call.
[0107] In step S503 of some embodiments, subsequently, the "native API call instructions" generated in step S502 for a specific "target service cluster" are respectively sent to the corresponding "target service cluster" for execution by using the "target cluster access instance" determined for each "target service cluster" in step S104 or S105. If a business request is associated with multiple "target service clusters", instructions will be sent to these clusters through their respective "target cluster access instances". After each "target service cluster" completes the execution of the "native API call instructions" it receives, the "target response data" returned by each completed "target service cluster" will be received. For example, the stock trading data ES cluster returns stock position and price information, and the bond trading data ES cluster returns bond position and valuation information.
[0108] In summary, through steps S501 to S503, first, by automatically converting business operation instructions into native APIs of the underlying clusters, the development complexity of upper-layer business applications is simplified. Business developers do not need to deeply understand the specific API details and version differences of different data service clusters, and only need to focus on the business logic itself. Second, by using the pre-prepared target cluster access instances to execute data access, the efficiency and stability of interacting with the underlying clusters are ensured. Finally, when a business request needs to access multiple target service clusters, this process can effectively coordinate the access to these clusters and obtain their response data respectively.
[0109] Please refer to Figure 6 , in some embodiments, after step S106, it may further include but is not limited to steps S601 to S602:
[0110] Step S601, when there are multiple target service clusters, aggregate the target response data received from different target service clusters according to preset business rules to obtain target aggregated data.
[0111] Step S602, return the target aggregated data or the target response data to the target business scenario.
[0112] In step S601 of some embodiments, when there are multiple "target service clusters" determined in step S102 and step S106 has successfully received their respective "target response data" from these different "target service clusters", according to a "preset business rule" preset and associated with the current "target business scenario", perform "aggregation processing" on the multiple "target response data" collected from these different "target service clusters". "Aggregation processing" can include various operations, such as: data merging, deduplication, sorting, or filtering and combining based on specific logic. For example, obtain a "target response data" from cluster A storing customer basic information, another from cluster B storing customer transaction history, and a third from cluster C storing customer risk ratings. At this time, the "aggregation processing" will, according to the "preset business rule", integrate these scattered "target response data" into a more complete-structured "target aggregated data".
[0113] In step S602 of some embodiments, finally, the processed data will be returned to the "target business scenario" that initially initiated the request. If "aggregation processing" is performed in step S601, the "target aggregated data" will be returned; if aggregation is not required, the "target response data" directly obtained in step S106 will be returned.
[0114] In summary, through the introduction of steps S601 and S602, first, through "aggregation processing", the scattered "target response data" from multiple "target service clusters" can be transformed into "target aggregated data" that better meets the upper-layer business requirements and has a higher information density, improving the direct availability of data and business insights, which is particularly crucial for scenarios such as financial risk control or medical diagnosis that require comprehensive decision-making.
[0115] Please refer to Figure 7 , in some embodiments, the access method of the distributed data service cluster may further include but is not limited to steps S701 to S703:
[0116] Step S701, when detecting a cluster configuration information change event, for each cluster access instance in the historical instance library, verify whether the configuration summary string associated with the cluster access instance matches any of the current configuration summary strings generated according to the changed cluster configuration information, to obtain a first verification result.
[0117] Step S702, verify whether the continuous unused duration of the cluster access instance has exceeded a preset maximum deactivation time threshold, to obtain a second verification result.
[0118] Step S703, if the first verification result indicates that the configuration summary string of the cluster access instance has expired, or the continuous unused duration has exceeded the maximum deactivation time threshold, remove the cluster access instance from the historical instance library.
[0119] In step S701 of some embodiments, when a change event of the global "cluster configuration information" is detected, it triggers a validity check for each cached "cluster access instance" in the "historical instance library". Specifically, for each "cluster access instance" in the library, the "configuration summary string" associated with it at the time of creation is retrieved, and it is verified whether this old "configuration summary string" can still match any "configuration summary string" of a valid cluster generated by the current, changed "cluster configuration information". If no currently valid cluster configuration can be matched, it means that the original cluster configuration corresponding to this cached instance no longer exists or has changed, thus obtaining a "first verification result" indicating that its configuration has expired.
[0120] In step S702 of some embodiments, as another independent verification, for each "cluster access instance" in the "historical instance library", check its "continuous unused duration". This duration records the time elapsed since the instance was last successfully used for a data access operation. This duration is compared with a "preset maximum deactivation time threshold" (for example, configured as 1 day or 1 hour). If the "continuous unused duration" exceeds this threshold, it indicates that the instance has been idle for a relatively long time, thus obtaining a "second verification result" indicating that it has timed out.
[0121] In step S703 of some embodiments, if the "first verification result" generated in the foregoing step S701 indicates that the "configuration summary string" associated with a certain "cluster access instance" has expired, or the "second verification result" generated in step S702 indicates that the "continuous unused duration" of this "cluster access instance" has exceeded the "preset maximum deactivation time threshold", then this specific "cluster access instance" will be removed from the "historical instance library".
[0122] In summary, steps S701 to S703 first ensure that the "cluster access instances" cached in the "historical instance library" are always consistent with the currently valid cluster configuration by responding to configuration changes and verifying the "configuration summary string", avoiding connection errors or data access failures caused by using outdated instances pointing to expired or changed clusters. Then, by checking and removing instances that have not been used for a long time, effective management and recycling of system resources are achieved, preventing performance degradation or resource exhaustion problems that may be caused by a large number of idle connections occupying resources for a long time, and ensuring the stable operation of the system in a high-concurrency or resource-constrained environment.
[0123] The access method and device for a distributed data service cluster, an electronic device, and a storage medium proposed in this application obtain a target service request from a target business scenario and cluster configuration information of multiple distributed data service clusters; determine at least one target service cluster from the multiple distributed data service clusters based on the target service request; for each target service cluster, search for a corresponding cluster access instance in a historical instance library according to the cluster configuration information; if a matching cluster access instance is found in the historical instance library, determine the found cluster access instance as the target cluster access instance; if no matching cluster access instance is found in the historical instance library, create a target cluster access instance according to the cluster configuration information of the target service cluster; and perform data access on the target service cluster through the target cluster access instance to obtain target response data returned by the target service cluster.
[0124] This application first obtains the service request of the target business scenario and the configuration information of all available clusters. Then, by dynamically determining the target service cluster based on the service request, it can achieve the matching of business logic and physical cluster deployment, enabling the business system to be unaware of the version change, environment migration, or scale-up / scale-down changes of the underlying cluster, greatly improving the flexibility and maintainability of the system, especially in financial and medical data-intensive applications where the cluster changes frequently. Then, for each determined target service cluster, by preferentially searching for and reusing existing cluster access instances in the historical instance library according to its current configuration information, it can effectively avoid the overhead of repeated initialization connections, significantly improving the response speed of data access and the utilization efficiency of system resources. Further, when no matching instance is found in the historical instance library, a new access instance is created immediately according to the latest configuration information of the target service cluster, ensuring the continuity of data access and the real-time adaptability to cluster configuration changes, and at the same time providing a reuse basis for subsequent requests with the same configuration. Finally, data access is performed on the target service cluster through the target cluster access instance to obtain target response data. In summary, the method and device proposed in this application can effectively address the adaptation and maintenance challenges brought by the distributed data service cluster to the business system in complex scenarios such as version upgrade, environment migration, and coexistence of multiple versions. Through cluster dynamic selection, an efficient access instance lifecycle management and reuse mechanism, it significantly reduces the development and maintenance costs of the business system, improves data access performance, overall stability, and flexibility, and provides reliable and efficient data service access for core businesses in financial and medical fields such as financial risk control, electronic medical records, and medical image analysis that need to process massive and high-concurrency data.
[0125] Please refer to Figure 8 , this application embodiment also provides an access device for a distributed data service cluster, which can implement the above access method for the distributed data service cluster. The device includes:
[0126] An acquisition module, configured to acquire a target service request from a target business scenario and cluster configuration information of multiple distributed data service clusters;
[0127] A first determination module, configured to determine at least one target service cluster from multiple distributed data service clusters based on the target service request;
[0128] A search module, configured to, for each target service cluster, search for a corresponding cluster access instance in a historical instance library according to the cluster configuration information;
[0129] A second determination module, configured to, if a matching cluster access instance is found in the historical instance library, determine the found cluster access instance as the target cluster access instance;
[0130] A creation module, configured to, if a matching cluster access instance is not found in the historical instance library, create a target cluster access instance according to the cluster configuration information of the target service cluster;
[0131] A data access module, configured to perform data access on the target service cluster through the target cluster access instance to obtain target response data returned by the target service cluster.
[0132] The specific implementation manner of the access device for the distributed data service cluster is basically the same as the specific embodiments of the above-mentioned access method for the distributed data service cluster, and will not be elaborated herein.
[0133] An embodiment of the present application further provides an electronic device. The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the above-mentioned access method for the distributed data service cluster is implemented. The electronic device can be any intelligent terminal including a tablet computer, an in-vehicle computer, etc.
[0134] Please refer to Figure 9 , Figure 9 which schematically shows the hardware structure of an electronic device in another embodiment. The electronic device includes:
[0135] A processor 901, which can be implemented in a general-purpose CPU (Central Processing Unit, central processor), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., and is configured to execute relevant programs to implement the technical solutions provided by the embodiments of the present application;
[0136] The memory 902 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM), etc. The memory 902 can store an operating system and other application programs. When implementing the technical solutions provided in the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 902 and are called by the processor 901 to execute the access method of the distributed data service cluster in the embodiments of this application;
[0137] The input / output interface 903 is used to implement information input and output;
[0138] The communication interface 904 is used to implement communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or through wireless means (such as mobile network, WIFI, Bluetooth, etc.);
[0139] The bus 905 transmits information between the various components of the device (such as the processor 901, the memory 902, the input / output interface 903, and the communication interface 904);
[0140] Among them, the processor 901, the memory 902, the input / output interface 903, and the communication interface 904 are communicatively connected to each other inside the device through the bus 905.
[0141] The embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the above-mentioned access method of the distributed data service cluster.
[0142] As a non-transitory computer-readable storage medium, the memory can be used to store non-transitory software programs and non-transitory computer-executable programs. In addition, the memory can include high-speed random access memory, and can also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory optionally includes a memory remotely set relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above-mentioned network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.
[0143] The access method and device, electronic device and storage medium of the distributed data service cluster proposed in this application obtain a target service request from a target business scenario and cluster configuration information of multiple distributed data service clusters; determine at least one target service cluster from the multiple distributed data service clusters based on the target service request; for each target service cluster, search for a corresponding cluster access instance in the historical instance library according to the cluster configuration information; if a matching cluster access instance is found in the historical instance library, determine the found cluster access instance as the target cluster access instance; if no matching cluster access instance is found in the historical instance library, create a target cluster access instance according to the cluster configuration information of the target service cluster; perform data access on the target service cluster through the target cluster access instance to obtain target response data returned by the target service cluster.
[0144] This application first obtains the service request of the target business scenario and the configuration information of all available clusters. Then, by dynamically determining the target service cluster based on the service request, it can achieve the matching of business logic and physical cluster deployment, enabling the business system to be unaware of the version changes, environment migrations, or scaling changes of the underlying clusters, greatly improving the flexibility and maintainability of the system, especially in financial and medical data-intensive applications where the clusters change frequently. Then, for each determined target service cluster, it preferentially searches for and reuses existing cluster access instances in the historical instance library according to its current configuration information, which can effectively avoid the overhead of repeated initialization connections, significantly improving the response speed of data access and the utilization efficiency of system resources. Further, when no matching instance is found in the historical instance library, a new access instance is created immediately according to the latest configuration information of the target service cluster, ensuring the continuity of data access and the real-time adaptability to cluster configuration changes, while also providing a reuse basis for subsequent requests with the same configuration. Finally, data access is performed on the target service cluster through the target cluster access instance to obtain target response data. In summary, the method and device proposed in this application can effectively address the adaptation and maintenance challenges brought by the distributed data service cluster to the business system in complex scenarios such as version upgrades, environment migrations, and coexistence of multiple versions. Through cluster dynamic selection, an efficient access instance lifecycle management and reuse mechanism, it significantly reduces the development and maintenance costs of the business system, improves data access performance and overall stability and flexibility, and provides reliable and efficient data service access for core businesses in financial and medical fields such as financial risk control, electronic medical records, and medical image analysis that need to process massive and high-concurrency data.
[0145] The embodiments described in the embodiments of the present application are for more clearly explaining the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art can know that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.
[0146] Those skilled in the art can understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than those shown in the figures, or combine certain steps, or different steps.
[0147] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0148] Those of ordinary skill in the art can understand that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, and their appropriate combinations.
[0149] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products, or devices.
[0150] It should be understood that in this application, "at least one (item)" means one or more, and "a plurality" means two or more. "And / or" is used to describe the relationship between associated objects and indicates that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist at the same time. Here, A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single items or plural items. For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0151] In several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the above division of units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces. The indirect coupling or communication connection of devices or units can be in electrical, mechanical, or other forms.
[0152] The units described above as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0153] In addition, in each embodiment of this application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.
[0154] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes: various media that can store programs, such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs.
[0155] The preferred embodiments of the embodiments of this application have been described above with reference to the accompanying drawings, and thus do not limit the scope of the rights of the embodiments of this application. Any modifications, equivalent replacements, and improvements made by those skilled in the art without departing from the scope and essence of the embodiments of this application shall be within the scope of the rights of the embodiments of this application.
Claims
1. A method for accessing a distributed data service cluster, characterized in that, including: obtaining a target service request from a target business scenario and cluster configuration information of multiple distributed data service clusters; determining at least one target service cluster from the multiple distributed data service clusters based on the target service request; for each target service cluster, looking up a corresponding cluster access instance in a historical instance library according to the cluster configuration information; if a matching cluster access instance is found in the historical instance library, determining the found cluster access instance as a target cluster access instance; if a matching cluster access instance is not found in the historical instance library, creating the target cluster access instance according to the cluster configuration information of the target service cluster; performing data access on the target service cluster through the target cluster access instance to obtain target response data returned by the target service cluster.
2. The access method of the distributed data service cluster according to claim 1, wherein The determining at least one target service cluster from the multiple distributed data service clusters based on the target service request includes: parsing the target service request to obtain a target business scenario identifier for indicating the target business scenario; determining a corresponding target mapping rule in preset mapping configuration information according to the target business scenario identifier; wherein the target mapping rule defines an association between the target business scenario identifier and one or more distributed data service clusters; determining at least one of the target service clusters according to the target mapping rule.
3. The access method of the distributed data service cluster according to claim 1, characterized in that, The looking up a corresponding cluster access instance in the historical instance library for each target service cluster according to the cluster configuration information includes: for each target service cluster, extracting a preset key configuration item from its corresponding cluster configuration information; wherein the key configuration item includes a cluster network address and a cluster connection parameter; generating a configuration summary string that uniquely identifies the current configuration state of the target service cluster according to the key configuration item; using the configuration summary string as a search key to retrieve in the historical instance library whether there is a previously created and stored cluster access instance that matches it.
4. The access method of the distributed data service cluster according to claim 3, characterized in that The creating the target cluster access instance according to the cluster configuration information of the target service cluster if a matching cluster access instance is not found in the historical instance library includes: creating a new target cluster access instance according to the cluster configuration information of the target service cluster; associating the newly created target cluster access instance with the configuration summary string corresponding to the target service cluster to obtain an instance association relationship; storing the instance association relationship and the newly created target cluster access instance in the historical instance library.
5. The access method of the distributed data service cluster according to claim 1, characterized in that, The performing data access on the target service cluster through the target cluster access instance to obtain target response data returned by the target service cluster includes: parsing the target service request to obtain a service operation instruction; converting the service operation instruction into a native API call instruction supported by each target service cluster; Using the target cluster access instance corresponding to each of the target service clusters, the native API call instructions for the target service clusters are respectively sent to the target service clusters for execution, and the target response data returned is received from each of the target service clusters that have completed the execution of the native API call instructions.
6. The access method of the distributed data service cluster according to claim 1, characterized in that After obtaining the target response data returned by the target service cluster through data access to the target service cluster by the target cluster access instance, it further includes: When there are multiple target service clusters, aggregating the target response data received from different target service clusters according to a preset business rule to obtain target aggregated data; Returning the target aggregated data or the target response data to the target business scenario.
7. The access method of the distributed data service cluster according to claim 3, wherein The method further includes: In response to detecting a change event in the cluster configuration information, for each cluster access instance in the historical instance library, verifying whether the configuration summary string associated with the cluster access instance matches any of the current configuration summary strings generated according to the changed cluster configuration information, to obtain a first verification result; Verifying whether the continuous unused duration of the cluster access instance has exceeded a preset maximum deactivation time threshold to obtain a second verification result; If the first verification result indicates that the configuration summary string of the cluster access instance has expired, or the continuous unused duration has exceeded the maximum deactivation time threshold, then removing the cluster access instance from the historical instance library.
8. An access device for a distributed data service cluster, characterized in that, It includes: An acquisition module for acquiring a target business request from a target business scenario and the cluster configuration information of multiple distributed data service clusters; A first determination module for determining at least one target service cluster from multiple distributed data service clusters based on the target business request; A search module for searching for a corresponding cluster access instance in the historical instance library according to the cluster configuration information for each target service cluster; A second determination module for, if a matching cluster access instance is found in the historical instance library, determining the found cluster access instance as the target cluster access instance; A creation module for, if no matching cluster access instance is found in the historical instance library, creating the target cluster access instance according to the cluster configuration information of the target service cluster; A data access module for performing data access to the target service cluster through the target cluster access instance to obtain the target response data returned by the target service cluster.
9. An electronic device, characterized in that, It includes: A memory and a processor, where the memory stores a computer program, and the processor implements the access method for the distributed data service cluster according to any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that, The storage medium stores a program, and the program is implemented by the processor to implement the access method for the distributed data service cluster according to any one of claims 1 to 7.
Citation Information
Cited By
Business system and business execution method
CN120952950A
A business system and a business execution method
CN120952950B
Model calling method, related device and storage medium
CN121210181A