Service calling method, electronic equipment, program product and storage medium

Abstract

The invention provides a service calling method, electronic equipment, a program product and a storage medium. The method comprises the following steps: when a calling terminal service initiates remote procedure calling with a target terminal service, acquiring first version information corresponding to the target terminal service from a target database; wherein first version information currently registered by each registered sub-service is stored in the target database; the first version information is used for identifying the version state of the sub-service in the global release version of the software system; determining second version information corresponding to the target terminal service based on the first version information and a target mapping relationship; wherein the target mapping relationship represents a corresponding relationship between the first version information and the second version information; the second version information is used for indicating an interface protocol version followed during remote procedure call; and based on the addressing mode of the remote procedure call message, determining target version information from the second version information and sending the remote procedure call message.

Description

Technical Field

[0001] This application relates to Internet technology, and more particularly to a service invocation method, electronic device, program product, and storage medium. Background Technology

[0002] With the widespread adoption of distributed systems and microservice architectures, Remote Procedure Call (RPC) has become a core mechanism for communication between different service instances. In large-scale software systems, such as OpenStack-based cloud computing platforms, services are typically deployed as distributed clusters of multiple instances and interact via message queues (MQ) for RPC. In these systems, software version iteration and rolling service upgrades are essential for maintaining system vitality and functional evolution. However, existing RPC communication mechanisms suffer from several drawbacks when dealing with rolling or partial service upgrades. Inconsistent version information between the calling and target terminal services prevents older target instances from correctly parsing and processing the new call messages, leading to service failures, message backlogs, and even business process interruptions. Alternatively, static configuration often specifies a globally uniform, lower RPC version number, preventing upgraded services from immediately utilizing the new features and functionalities offered by the new version interface, thus extending the new feature launch cycle. Summary of the Invention

[0003] This application provides a service invocation method, electronic device, program product, and storage medium, which not only avoids the risk of RPC messages not being consumed, service failure, or even business interruption caused by version mismatch between the calling end and the target end, but also effectively takes into account diverse needs such as cluster compatibility, load pressure, and functional priority while ensuring business continuity.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a service invocation method, the method comprising: When a terminal service initiates a remote procedure call with a target terminal service, it retrieves the first version information corresponding to the target terminal service from the target database; wherein, the target database stores the first version information of each registered sub-service currently registered; the first version information is used to identify the version status of the sub-service in the global release version of the software system; Based on the first version information and the target mapping relationship, the second version information corresponding to the target terminal service is determined; wherein, the target mapping relationship represents the correspondence between the first version information and the second version information; the second version information is used to indicate the interface protocol version followed when performing a remote procedure call; Based on the addressing method of remote procedure call messages, the target version information is determined from the second version information and the remote procedure call message is sent.

[0005] In the above scheme, the addressing method based on remote procedure call messages, determining the target version information from the second version information and sending the remote procedure call message, includes: If the addressing method includes broadcast addressing, the target version information is determined from multiple second version information based on the business scenario conditions, and the remote procedure call message is sent. If the addressing method includes unicast addressing, the target version information is determined based on the second version information corresponding to the target terminal service identified by the unicast addressing, and the remote procedure call message is sent.

[0006] In the above scheme, determining the target version information from multiple second version information based on business scenario conditions includes: If the business scenario conditions include a business load greater than a first threshold, a first target version information is determined from multiple second version information as the target version information; wherein, the first target version information is the version information that is sorted first after sorting multiple second version information according to version sorting rules; If the business scenario conditions include a business requirement priority greater than a second threshold, a second target version information is determined from multiple second version information as the target version information; wherein, the second target version information is the latest version information determined after sorting multiple second version information according to version sorting rules; If the business scenario conditions include the requirement for multiple versions to run in parallel, the tag information of each target terminal service is obtained from the target database, and the target version information is determined based on multiple second version information and multiple tag information.

[0007] In the above scheme, determining the target version information based on multiple pieces of second version information and multiple pieces of tag information includes: Based on the tag information, multiple target terminal services are grouped to obtain multiple target groups; For each target group, the second version information corresponding to the target group is determined as the target version information.

[0008] In the above scheme, sending the remote procedure call message includes: Determine the message queue identifier corresponding to each of the target groups; For each target group, a remote procedure call message corresponding to the target group is generated based on the interface protocol defined by the target version information corresponding to the target group. For each target group, the remote procedure call message is sent to the message queue indicated by the message queue identifier corresponding to the target group.

[0009] In the above scheme, determining the target version information based on the second version information corresponding to the target terminal service identified by the unicast address includes: Obtain at least one second version information corresponding to the target terminal service identified by the unicast address from the target database; Based on at least one of the second version information obtained, the version information that is ranked last according to the version sorting rules is determined as the target version information.

[0010] In the above scheme, before obtaining the first version information corresponding to the target terminal service from the target database, the following steps are also included: Obtain the target mapping relationship; wherein the target mapping relationship is generated by updating the first version information and the second version information corresponding to the sub-service whose interface parameters have changed when the interface parameters of any registered sub-service change.

[0011] A service invocation apparatus, the service invocation apparatus comprising: The acquisition unit is used to acquire the first version information corresponding to the target terminal service from the target database when the calling terminal service initiates a remote procedure call with the target terminal service; wherein, the target database stores the first version information of each registered sub-service currently registered; the first version information is used to identify the version status of the sub-service in the global release version of the software system; The determining unit is configured to determine the second version information corresponding to the target terminal service based on the first version information and the target mapping relationship; wherein the target mapping relationship represents the correspondence between the first version information and the second version information; the second version information is used to indicate the interface protocol version followed when performing a remote procedure call; The processing unit is used to determine the target version information from the second version information and send the remote procedure call message based on the addressing mode of the remote procedure call message.

[0012] An electronic device configured to operate as a terminal service, comprising: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the above-described method.

[0013] A computer program product includes a computer program that, when executed by a processor, implements the above-described method.

[0014] A computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the above-described method.

[0015] The embodiments of this application have the following beneficial effects: By constructing a target database, the version status of the target terminal service (i.e., the first version status) can be obtained in real time, and a compatible RPC interface version (i.e., the second version status) can be dynamically selected in combination with the preset target mapping relationship. This fundamentally avoids the risk of RPC messages not being consumed, service failure, or even business interruption caused by the mismatch between the calling end and the target end version. At the same time, it also supports the use of differentiated version selection strategies based on the addressing method (broadcast or unicast) of the remote call message to accurately match the capabilities of the target end. Unlike related technologies, it is not necessary to wait for all target terminal services to be upgraded before secure communication can be established. Thus, while ensuring business continuity, it effectively takes into account the diverse needs such as cluster compatibility, load pressure, and functional priority. Attached Figure Description

[0016] Figure 1 This is a schematic diagram illustrating the interactions between services provided in related technologies; Figure 2 This is a first flowchart illustrating a service invocation method provided in an embodiment of this application; Figure 3 This is a second flowchart illustrating a service invocation method provided in an embodiment of this application; Figure 4 This is a first schematic diagram illustrating the determination of target version information in a service invocation method provided in this application embodiment; Figure 5 This is a second schematic diagram illustrating the determination of target version information in a service invocation method provided in this application embodiment; Figure 6 This is a third schematic diagram illustrating the determination of target version information in a service invocation method provided in this application embodiment; Figure 7 This is a fourth schematic diagram illustrating the determination of target version information in a service invocation method provided in this application embodiment; Figure 8 This is a schematic diagram of the structure of a service invocation device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0017] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] It should be noted that OpenStack is an open-source cloud computing management platform project, which is a combination of a series of open-source software projects. It was jointly developed and initiated by the National Aeronautics and Space Administration (NASA) and Rackspace, and is licensed under the Apache License (a free software license issued by the Apache Software Foundation). OpenStack provides scalable and elastic cloud computing services for both private and public clouds. The project aims to provide a simple-to-implement, scalable, feature-rich, and standardized cloud management platform. Nova, a sub-project of the OpenStack cloud platform, primarily provides users with management and scheduling of computing resources. It launches multiple virtual machines (VMs) using physical machine resources and manages their lifecycle to provide cloud host services. Nova offers two main categories of services: control services, including nova-api (providing a RESTful API interface), nova-scheduler (planning and scheduling computing resources according to set policies), and nova-conductor (proxying services that are not allowed to directly access data to access the database); and computing services, including nova-compute, which is responsible for the actual access and allocation of computing resources. The main computing resources include: Central Processing Unit (CPU), memory, disk, and network.

[0020] It should be noted that all internal access between services in OpenStack (such as nova, Cinder, Neutron, etc.) is conducted through message queues (MQ). For details regarding the internal access chain of the nova component mentioned above, please refer to [link to relevant documentation]. Figure 1As shown, each service is a distributed multi-node system, and services interact via MQ (Message Queue). There is interaction between multiple nodes and services. During service interaction, nova-api acts as a producer, sending Remote Procedure Call (PRC) messages to the message queue, and the nova-conductor service consumes these messages. It's important to note that MQ is a message queue mechanism with producer-consumer relationships. Producers and consumers can specify message version information. If the producer specifies a message version (such as a version number), the consumer's version number must be the same as or higher than the producer's version number; otherwise, the consumer cannot consume the message.

[0021] It's important to note that rolling hot upgrades are essential for cluster maintenance scenarios, ensuring uninterrupted service updates. Under the current architecture, the compatibility of RPC versions between control services isn't considered. For example, if the `nova-api` sub-service is upgraded, modifying interface parameters, it will send a higher-version RPC message with a version number. However, if the `nova-conductor` sub-service hasn't upgraded, the message will be unconsumable, causing system failure. For compute service interactions, the current architecture supports passing a version number specified in a configuration item. In a compute node rolling upgrade scenario, only a lower version can be specified. This means new features and interface functionalities cannot be used after the upgrade; the control service configuration must be modified and restarted after all compute nodes are upgraded for the changes to take effect. Furthermore, upgrading specific compute nodes to enable new features without a global upgrade is also impossible under this architecture. It's clear that under the current architecture, changes to the interfaces used for service interaction lead to numerous limitations in rolling upgrades, potentially even causing service unavailability.

[0022] Based on this, embodiments of this application provide a service invocation method, which can be applied to an electronic device (configured to run as a service invocation terminal), referring to... Figure 2 As shown, the method includes the following steps: Step 101: When the terminal service initiates a remote procedure call with the target terminal service, the first version information corresponding to the target terminal service is obtained from the target database.

[0023] The target database stores the first version information of each registered sub-service; the first version information is used to identify the version status of the sub-service in the global release version of the software system.

[0024] In this embodiment, the calling terminal service refers to the initiator of the remote procedure call (RPC), specifically the nova-api service; the target terminal service refers to the receiver of the RPC call, specifically the nova-conductor service or the nova-compute service; the calling terminal service initiating the remote procedure call with the target terminal service can refer to; The target database is a centralized database that stores version information for all sub-services (including calling sub-services and target sub-services). Each sub-service can report its own version information to the target database when it starts up. The first version information refers to the global release version information of the software system (specifically, the global release version number). It identifies which global software version a target sub-service belongs to. For example, whether a nova-conductor service is deployed on a system with the first version information v35 or a system with the first version information v36.

[0025] In this embodiment, when a terminal service (such as nova-api) needs to call a target terminal service (such as nova-conductor), it does not first guess or use a fixed configuration, but queries the target database. That is, it searches the target database for all currently registered target terminal services that are available for this call, and obtains their respective first version information (i.e., the system global version to which each target terminal service belongs, such as some target terminal services corresponding to version v35 and some target terminal services corresponding to version v36). It should be noted that each sub-service (including the calling terminal service and the target terminal service) can report its own first version information to the target database when it starts.

[0026] Step 102: Based on the first version information and the target mapping relationship, determine the second version information corresponding to the target terminal service.

[0027] The target mapping relationship represents the correspondence between the first version information and the second version information; the second version information is used to indicate the interface protocol version followed when making a remote procedure call.

[0028] In this embodiment, the target mapping relationship is a mapping table or transformation rule used to map the first version information (i.e., the global version number) to the second version information. The second version information refers to the specific RPC interface protocol version number, which determines which set of interface parameters and serialization format the calling terminal service should use when assembling RPC messages. For example, when the first version information is v35, the second version information (i.e., the RPC version information) corresponding to each target terminal service is: {'compute_rpc':'4.29','conductor_rpc':'1.20','scheduler_rpc':'4.6','consoleauth':'2.1'}; when the first version information is v36, the version information of each RPC is: {'compute_rpc':'4.29','conductor_rpc':'1.20','scheduler_rpc':'4.7','consoleauth':'2.1'}.

[0029] In this embodiment, after obtaining the global version information (such as v35, v36, etc.) of the target terminal services, the calling terminal service needs to know which specific RPC interface version should be used when communicating with these target terminal services. Therefore, the calling terminal service determines a set of second version information corresponding to one or more target terminal services from the target mapping relationship based on the first version information. This result has two possibilities: 1) In a unicast addressing scenario: a target terminal service can be specified, and the list of versions supported by that specified target terminal service is determined (e.g., the specified target terminal service may simultaneously support RPCv1.0, RPCv1.1, RPCv1.2, etc.); 2) In a broadcast addressing scenario: no target terminal service is specified, i.e., there can be multiple target terminal services, and multiple different version information is determined (e.g., target terminal service A supports RPCv1.1, target terminal service B supports RPCv1.2, and target terminal service C supports RPCv1.3). Thus, although the calling terminal service obtains a set of second version information, it knows the specific RPC protocol that each target terminal service can understand.

[0030] Step 103: Based on the addressing mode of the remote procedure call message, determine the target version information from the second version information and send the remote procedure call message.

[0031] In this embodiment of the application, the addressing mode refers to whether the RPC message is sent to a specific target terminal service (i.e., unicast addressing) or to all target terminal services (i.e., broadcast addressing); that is, the addressing mode can include unicast addressing and broadcast addressing; the target version information refers to the version information that is finally selected from the second version information and will be actually filled into the RPC message header and used for sending.

[0032] In this embodiment, the calling terminal service can analyze the remote procedure call (RPC) message to determine whether the RPC message is sent to a specific target terminal service (i.e., unicast addressing) or to all target terminal services (i.e., broadcast addressing). This allows for different strategies to determine the target version information from the second version information. Specifically, if it's broadcast addressing, the calling terminal service needs to select a version from the second version information that all target terminal services can handle as the target version information. If it's unicast addressing, the calling terminal service can directly select the highest version supported by the target terminal service specified in the message as the target version information. After the target version information is determined, the calling terminal service uses the interface protocol indicated by the version information to assemble the RPC message and sends it to the target terminal service.

[0033] The service invocation method provided in this application embodiment can obtain the version status of the target terminal service (i.e., the first version status) in real time by constructing a target database, and dynamically select a compatible RPC interface version (i.e., the second version status) in combination with a preset target mapping relationship. This fundamentally avoids the risk of RPC messages not being consumed, service failure, or even business interruption caused by version mismatch between the calling end and the target end. At the same time, it also supports a differentiated version selection strategy based on the addressing method (broadcast or unicast) of the remote call message to accurately match the capabilities of the target end. Unlike related technologies, it does not require waiting for all target terminal services to be upgraded before secure communication can be established. Thus, while ensuring business continuity, it effectively takes into account diverse needs such as cluster compatibility, load pressure, and functional priority.

[0034] Based on the foregoing embodiments, this application provides another service invocation method, which can be applied to an electronic device (configured to run as a service invocation terminal), see reference. Figure 3 As shown, the method includes the following steps: Step 201: Obtain the target mapping relationship.

[0035] The target mapping relationship is generated by updating the first and second version information of the sub-service whose interface parameters have changed when the interface parameters of any registered sub-service of the target sub-service change.

[0036] In this embodiment, when any registered sub-service (such as the nova-scheduler service) modifies the parameters of its RPC interface in version v35 (e.g., adds a new field), i.e., the interface parameters change, the electronic device can generate a new global version information (i.e., the first version information, such as upgrading from v35 to v36) through the target terminal service, and assign a new RPC interface version (and the second version information, such as upgrading scheduler_rpc from RPCv4.6 to RPCv4.7) to the sub-service that has changed, thereby generating a new version target mapping relationship. Then, the electronic device can obtain the latest target mapping relationship that reflects the current real service interface status of the system by calling the terminal service.

[0037] It should be noted that all subsequent steps are implemented by the electronic device by calling the terminal service.

[0038] Step 202: When the terminal service initiates a remote procedure call with the target terminal service, the first version information corresponding to the target terminal service is obtained from the target database.

[0039] The target database stores the first version information of each registered sub-service; the first version information is used to identify the version status of the sub-service in the global release version of the software system.

[0040] Step 203: Based on the first version information and the target mapping relationship, determine the second version information corresponding to the target terminal service.

[0041] The target mapping relationship represents the correspondence between the first version information and the second version information; the second version information is used to indicate the interface protocol version followed when making a remote procedure call.

[0042] It should be noted that after step 203, either step 204 or step 205 can be executed; Step 204: If the addressing method includes broadcast addressing, determine the target version information from multiple second version information based on the business scenario conditions, and send a remote procedure call message.

[0043] In the embodiments of the present application, the business scenario conditions refer to the objective situations and requirements faced by the current system or business, which are the strategic basis for deciding which version to select as the final sent version. Specifically, it may include business load, business requirement priority, and the requirement for parallel operation of multiple versions. When the calling terminal service discovers that there are multiple different second version information (i.e., RPC interface versions, such as (RPCv1.20, RPCv1.21)) in the cluster of the target terminal service, it cannot randomly select a version to send. Instead, it needs to select the most suitable target version information according to the current business scenario conditions to ensure business continuity and meet specific goals.

[0044] It should be noted that step 204 can be implemented in the following manner: Step 204A: If the business scenario conditions include that the business load is greater than the first threshold, determine the first target version information as the target version information from the multiple second version information.

[0045] Among them, the first target version information is the version information with the earliest sorting determined after sorting the multiple second version information according to the version sorting rule.

[0046] In the embodiments of the present application, the business load refers to the current processing pressure, such as the number of requests per second, CPU / memory usage rate, etc.; the first threshold is a preset critical value used to determine whether the business load is at a high level; the version sorting rule is an agreement for sorting version information, such as ascending order by numerical size (RPCv1.20 < RPCv1.21), or sorting by release time; the version information with the earliest sorting can refer to the version ranked first after sorting according to the above rules, that is, the lowest version.

[0047] In the embodiments of the present application, when it is monitored through the calling terminal service that the business load is greater than the first threshold (i.e., the business load pressure is high), the priority goal is to ensure the maximum compatibility and stability. At this time, the lowest RPC version supported by all target terminal services (i.e., the first target version information) can be selected as the target version information to be finally sent. In this way, it can be ensured that all target terminal services can participate in the consumption of messages (including low-version instances that have not been upgraded), so as to make full use of all computing resources and avoid task accumulation and crashes caused by some instances being unable to process messages.

[0048] In a feasible implementation manner, refer to Figure 4As shown, in scenarios where the business load exceeds the first threshold (i.e., the business load pressure is high), when the target sub-service (nova-conductor) presents a mixed version state, with most having been upgraded to RPCv4.1 but some still running the older version RPCv4.0, then following the principle of selecting the lowest version, for clusters with sub-services running the older version RPCv4.0, RPCv4.0 is selected as the target version, while for clusters with all sub-services upgraded to RPCv4.1, RPCv4.1 can be selected as the target version.

[0049] Step 204B: If the business scenario conditions include a business requirement priority greater than the second threshold, determine the second target version information as the target version information from multiple second version information.

[0050] The second target version information is the latest version information determined by sorting multiple second version information according to the version sorting rules.

[0051] In this application embodiment, the business requirement priority refers to the urgency of the business requirement to use the new functions and features provided by the new version of the service as soon as possible; the second threshold is a critical value used to judge the priority of the function launch requirement. When the priority is higher than this threshold, it means that the business wants the new function to take effect as soon as possible; the version information with the lowest ranking refers to the version that is ranked last after being sorted according to the version sorting rules, which is the highest version.

[0052] In this embodiment, when the priority of business needs is greater than the second threshold (i.e., the business party urgently wants to use the new function) and the load allows, the highest RPC version (i.e. the second target version information) among all target terminal services can be selected as the final target version to be sent. In this way, those target terminal services that have been upgraded to a higher version can immediately start using the new interface and new function without waiting for all target terminal services to be upgraded, thereby realizing the rapid launch and iteration of functions.

[0053] In one feasible implementation, refer to Figure 5 As shown, in scenarios where the business requirement priority is greater than the second threshold (i.e., the business party urgently wants to use the new function), when the target sub-service (nova-conductor) presents a mixed version state, most of which have been upgraded to RPCv4.1, but there are still sub-services running the old version RPCv4.0, then following the principle of selecting the highest version, RPCv4.1 can be selected as the target version.

[0054] Step 204C: If the business scenario requires multiple versions to run in parallel, obtain the tag information of each target terminal service from the target database, and determine the target version information based on multiple second version information and multiple tag information.

[0055] In this embodiment, parallel operation of multiple versions refers to the need for different versions of services (such as the stable version of an older version and the test version of a newer version) to coexist for a long time and provide services to the outside world simultaneously. This is common in scenarios such as canary releases, blue-green releases, and A / B testing. Tag information refers to an identifier (Tag) preset on the target terminal service. When the business scenario requires parallel operation of multiple versions, simply selecting the highest or lowest version is no longer applicable. At this time, calling the terminal service requires obtaining the tag information of each target terminal service from the target database, and then grouping multiple target terminal services according to the tag information. For each group, the method in step 204A or 204B can be applied independently to determine the target version corresponding to the group, thereby realizing fine-grained traffic control and long-term coexistence of different versions of the target terminal service.

[0056] It should be noted that step 204C can be achieved in the following way: Step 204c1: Group the multiple target terminal services based on the tag information to obtain multiple target groups.

[0057] In this embodiment, a target group refers to a logical set of services formed by dividing all target terminal services according to tag information. Target terminal services within each group share the same tags, thus being considered to have the same characteristics or purpose. After obtaining the tag information of all target terminal services from the target database, the calling terminal service can cluster the target terminal services based on this tag information, for example, referring to... Figure 6 As shown, all nova-conductor RPCv4.0 with tag=1 are grouped into target group 1; all nova-conductor RPCv4.1 with tag=2 are grouped into target group 2, thus obtaining multiple logical target groups. It should be noted that the purpose of grouping is to organize the different versions of target terminal services that are mixed together into several service units with unified internal versions and different functional characteristics provided externally, laying the foundation for subsequent differentiated message delivery.

[0058] Step 204c2: For each target group, determine the second version information corresponding to the target group as the target version information.

[0059] In this embodiment, the emphasis is on group-level granularity for each target group, rather than clustering the entire target terminal service. The second version information corresponding to the target group refers to the RPC interface version assigned to that target group. Since grouping in step 204c1 is based on tag information, and tag information is typically strongly associated with versions (e.g., all target terminal services in tag=1 are version v35, and all target terminal services in tag=2 are version v36), a target group usually corresponds to a unique second version information. After grouping, the terminal service will determine a target version information for sending messages for each target group. Specifically, for a given target group, since the versions of the target terminal services within the group are the same (guaranteed by the grouping logic), the terminal service can directly determine the common second version information of the sub-services within the group as the target version information to be sent to that group (e.g., ...). Figure 6 As shown, the lowest version message (i.e., RPCv4.0) is sent to target group 1 to ensure stability, while the highest version message (i.e., RPCv4.1) is sent to target group 2 to test new features. In this way, calling the terminal service is no longer about selecting a version from a global perspective, but about determining the most suitable version for each group. This provides a technical basis for realizing blue-green deployment or canary deployment. That is, different user traffic can be routed to different groups, thereby experiencing different versions of service functions.

[0060] It should be noted that, for situations involving multiple target groups, sending remote procedure call messages can be achieved in the following ways: Step 204D: Determine the message queue identifier corresponding to each target group.

[0061] In this embodiment of the application, the message queue identifier refers to a symbol that uniquely identifies a specific message queue (or topic) in the message middleware. After determining the target version information, the terminal service can determine a unique message queue identifier (Topic) for each target group. In this way, by specifying different message queues for different groups, it can be ensured that messages sent to the first group will not be consumed by the target terminal service of the second group, and vice versa. That is to say, physical isolation of messages can be achieved.

[0062] Step 204E: For each target group, generate a remote procedure call message corresponding to the target group based on the interface protocol defined by the target version information corresponding to the target group.

[0063] In this embodiment, the interface protocol defined by the target version information refers to the RPC version information determined for each target group in step 204c2 (e.g., v1.21 for target group 1). This version information corresponds to a specific set of interface definitions, including method name, parameter list, parameter type, and serialization method. Different versions may have different interface protocols. The remote procedure call message corresponding to the target group refers to the RPC message tailored for a specific target group. That is, the calling sub-service will assemble an RPC message for each target group, and will strictly use the interface protocol indicated by the target version information corresponding to the target group during assembly. For example, the calling sub-service will generate two messages: one is a message sent to target group 1, assembled using the v1.20 version interface protocol; the other is a message sent to target group 2, assembled using the v1.21 version interface protocol (which may contain new parameters or different serialization structures). In this way, it can be ensured that the generated message can be correctly parsed and processed by the sub-services within the target group in terms of format and content, thereby achieving accurate protocol matching.

[0064] Step 204F: For each target group, send a remote procedure call message to the message queue indicated by the message queue identifier corresponding to the target group.

[0065] In this embodiment, the terminal service calls the customized messages generated for each group in step 204E and delivers them to the message queues pointed to by the message queue identifiers (Topics) determined for that group in step 204D. For example, messages using the v1.20 protocol are sent to topic_1, and messages using the v1.21 protocol are sent to topic_2. Finally, the target terminal services (consumers) of different target groups listen to their respective dedicated message queues, consume and process RPC messages applicable to their own versions. This allows different versions of sub-services in the same service cluster to run simultaneously and independently, processing different versions of business requests, thus supporting advanced deployment strategies such as canary releases and blue-green deployments.

[0066] Step 205: If the addressing method includes unicast addressing, determine the target version information based on the second version information corresponding to the target terminal service identified by the unicast addressing, and send a remote procedure call message.

[0067] In the embodiments of this application, when the addressing mode is unicast addressing, the calling terminal service already knows which specific target terminal service the remote procedure call message should be sent to (for example, specifying to send it to nova-conductor with ID "instance 2"). Therefore, its decision logic is more direct than broadcast addressing, that is, it does not need to consider the version status of other target terminal services, but only needs to focus on this specific target terminal service and select the most suitable RPC version information for it.

[0068] It should be noted that step 205 can be achieved in the following way: Step 205G: Obtain at least one second version information corresponding to the target terminal service identified by unicast addressing from the target database.

[0069] In this embodiment, the target terminal service identified by the unicast address refers to the target terminal service explicitly specified in the unicast message; at least one second version information indicates that a target terminal service may support multiple RPC interface versions simultaneously. For example, a target terminal service may simultaneously support RPC v1.0, RPC v1.1, RPC v1.2, etc. Therefore, the query result is not a single version information, but a list of all version information supported by the target terminal service. The calling terminal service queries the target database for the second version information corresponding to the specific target terminal service based on the identifier of the target terminal service specified in the unicast address (such as the ID of a specific target terminal service). The query result is a list of version information, representing all RPC interface versions backward compatible with the target terminal service. For example, querying target terminal service 2 yields a list of supported version information (v1.20, v1.21).

[0070] Step 205H: Based on the at least one second version information obtained, the version information that is ranked last according to the version sorting rules is determined as the target version information.

[0071] In this embodiment, after the calling terminal service obtains at least one second version information (e.g., (v1.20, v1.21)) corresponding to the target terminal service identified by the unicast address, it sorts the list according to the version sorting rules. Then, it selects the last one in the list, which is the highest version information (v1.21 in this example), and determines it as the target version information finally used in this RPC call. It should be noted that selecting the highest version information supported by a specific target terminal service can ensure that this call can utilize the latest functions and optimal performance provided by that specific target terminal service. Since it is unicast communication, there is no compatibility problem that low versions cannot handle (that is, it ensures the compatibility of RPC messages, thereby ensuring 100% availability of the business system and improving the robustness of the entire system). Therefore, it can safely use the highest version and maximize the value of a single call.

[0072] In one feasible implementation, refer to Figure 7As shown, nova-api, acting as a calling terminal service, interacts with the target terminal service nova-conductor to dynamically query multiple different versions of nova-compute nodes. It can obtain the RPC version information of each target terminal service by querying the target database (DB). There are three nova-compute sub-services with different version information: RPCv4.5, RPCv4.6, and RPCv4.7. Therefore, if the identified target terminal service is RPCv4.5, then the target version information can be determined to be RPCv4.5; if the identified target terminal service is RPCv4.6, then the target version information can be determined to be RPCv4.6; and if the identified target terminal service is RPCv4.7, then the target version information can be determined to be RPCv4.7.

[0073] It should be noted that, through the above steps, this application designs a complete differentiated RPC message compatibility guarantee mechanism, which can ensure the continuity of the system's business in any service rolling upgrade scenario, not only improving the stability of the system, but also enhancing the availability and robustness of the entire system.

[0074] It should be noted that the descriptions of the same steps and contents as in other embodiments in this embodiment can be found in the descriptions in other embodiments, and will not be repeated here.

[0075] The service invocation method provided in this application embodiment can obtain the version status of the target terminal service (i.e., the first version status) in real time by constructing a target database, and dynamically select a compatible RPC interface version (i.e., the second version status) in combination with a preset target mapping relationship. This fundamentally avoids the risk of RPC messages not being consumed, service failure, or even business interruption caused by version mismatch between the calling end and the target end. At the same time, it also supports a differentiated version selection strategy based on the addressing method (broadcast or unicast) of the remote call message to accurately match the capabilities of the target end. Unlike related technologies, it does not require waiting for all target terminal services to be upgraded before secure communication can be established. Thus, while ensuring business continuity, it effectively takes into account diverse needs such as cluster compatibility, load pressure, and functional priority.

[0076] Based on the foregoing embodiments, this application provides a service invocation device, which can be applied to... Figure 2 and Figure 3 In the service invocation method provided in the corresponding embodiment, refer to Figure 8 As shown, the service invocation device 3 may include: an acquisition unit 31, a determination unit 32, and a processing unit 33, wherein, The acquisition unit 31 is used to retrieve the first version information corresponding to the target terminal service from the target database when the calling terminal service initiates a remote procedure call with the target terminal service; wherein, the target database stores the first version information currently registered for each registered sub-service; the first version information is used to identify the version status of the sub-service in the global release version of the software system; The determining unit 32 is used to determine the second version information corresponding to the target terminal service based on the first version information and the target mapping relationship; wherein, the target mapping relationship represents the correspondence between the first version information and the second version information; the second version information is used to indicate the interface protocol version followed when performing a remote procedure call; Processing unit 33 is used to determine the target version information from the second version information and send the remote procedure call message based on the addressing mode of the remote procedure call message.

[0077] In other embodiments of this application, the processing unit 33 is further configured to perform the following steps: If the addressing method includes broadcast addressing, the target version information is determined from multiple second version information based on the business scenario conditions, and a remote procedure call message is sent; If the addressing method includes unicast addressing, the target version information is determined based on the second version information corresponding to the target terminal service identified by the unicast addressing, and a remote procedure call message is sent.

[0078] In other embodiments of this application, the processing unit 33 is further configured to perform the following steps: If the business scenario conditions include a business load greater than a first threshold, the first target version information is determined as the target version information from multiple second version information; wherein, the first target version information is the version information that appears first after sorting multiple second version information according to the version sorting rules; If the business scenario conditions include a business requirement priority greater than the second threshold, the second target version information is determined as the target version information from multiple second version information; wherein, the second target version information is the last version information determined after sorting multiple second version information according to the version sorting rules; If the business scenario requires multiple versions to run in parallel, retrieve the tag information of each target terminal service from the target database, and determine the target version information based on multiple second version information and multiple tag information.

[0079] In other embodiments of this application, the processing unit 33 is further configured to perform the following steps: Multiple target terminal services are grouped based on tag information to obtain multiple target groups; For each target group, the second version information corresponding to the target group is determined as the target version information.

[0080] In other embodiments of this application, the processing unit 33 is further configured to perform the following steps: For each target group, a remote procedure call message corresponding to the target group is generated based on the interface protocol defined by the target version information corresponding to the target group. For each target group, a remote procedure call message is sent to the message queue indicated by the message queue identifier corresponding to the target group.

[0081] In other embodiments of this application, the processing unit 33 is further configured to perform the following steps: Retrieve at least one second version information corresponding to the target terminal service identified by unicast addressing from the target database; Based on at least one second version information obtained, the version information that is ranked last according to the version sorting rules is determined as the target version information.

[0082] In other embodiments of this application, the determining unit 32 is further configured to perform the following steps: Obtain the target mapping relationship; wherein, the target mapping relationship is generated by updating the first version information and the second version information corresponding to the sub-service whose interface parameters have changed when the interface parameters of any registered sub-service of the target sub-service change.

[0083] It should be noted that the specific implementation process of the steps performed by each module in the embodiments of this application can be referred to... Figure 2 and Figure 3 The implementation process of the service invocation method provided in the corresponding embodiment will not be described in detail here.

[0084] The service invocation device provided in this application embodiment can obtain the version status of the target terminal service (i.e., the first version status) in real time by constructing a target database, and dynamically select a compatible RPC interface version (i.e., the second version status) in combination with a preset target mapping relationship. This fundamentally avoids the risk of RPC messages not being consumed, service failure, or even business interruption caused by the mismatch between the calling end and the target end versions. At the same time, it also supports the use of differentiated version selection strategies based on the addressing method (broadcast or unicast) of the remote call message to accurately match the capabilities of the target end. Unlike related technologies, it does not require waiting for all target terminal services to be upgraded before secure communication can be established. Thus, while ensuring business continuity, it effectively takes into account diverse needs such as cluster compatibility, load pressure, and functional priority.

[0085] Based on the foregoing embodiments, embodiments of this application provide an electronic device that can be applied to... Figure 2 and Figure 3 In the service invocation method provided in the corresponding embodiment, refer to Figure 9As shown, the electronic device 4 may include: a processor 41, a memory 42, and a communication bus 43, wherein: Communication bus 43 is used to realize the communication connection between processor 41 and memory 42; The processor 41 is used to execute the service call program in the memory 42 to perform the following steps: When a terminal service initiates a remote procedure call with a target terminal service, it retrieves the first version information corresponding to the target terminal service from the target database. The target database stores the first version information of each registered sub-service. The first version information is used to identify the version status of the sub-service in the global release version of the software system. Based on the first version information and the target mapping relationship, the second version information corresponding to the target terminal service is determined; wherein, the target mapping relationship represents the correspondence between the first version information and the second version information; the second version information is used to indicate the interface protocol version followed when performing remote procedure calls; Based on the addressing method of remote procedure call messages, the target version information is determined from the second version information and a remote procedure call message is sent.

[0086] In other embodiments of this application, the processor 41 is configured to execute the service call program in the memory 42 using a remote procedure call message-based addressing mode, determine the target version information from the second version information, and send a remote procedure call message to implement the following steps: If the addressing method includes broadcast addressing, the target version information is determined from multiple second version information based on the business scenario conditions, and a remote procedure call message is sent; If the addressing method includes unicast addressing, the target version information is determined based on the second version information corresponding to the target terminal service identified by the unicast addressing, and a remote procedure call message is sent.

[0087] In other embodiments of this application, the processor 41 is used to execute the service calling program in the memory 42 to determine the target version information from multiple second version information based on business scenario conditions, in order to implement the following steps: If the business scenario conditions include a business load greater than a first threshold, the first target version information is determined as the target version information from multiple second version information; wherein, the first target version information is the version information that appears first after sorting multiple second version information according to the version sorting rules; If the business scenario conditions include a business requirement priority greater than the second threshold, the second target version information is determined as the target version information from multiple second version information; wherein, the second target version information is the last version information determined after sorting multiple second version information according to the version sorting rules; If the business scenario requires multiple versions to run in parallel, retrieve the tag information of each target terminal service from the target database, and determine the target version information based on multiple second version information and multiple tag information.

[0088] In other embodiments of this application, the processor 41 is used to execute the service calling program in the memory 42 to determine the target version information based on multiple second version information and multiple tag information, in order to implement the following steps: Multiple target terminal services are grouped based on tag information to obtain multiple target groups; For each target group, the second version information corresponding to the target group is determined as the target version information.

[0089] In other embodiments of this application, the processor 41 is configured to execute a service calling program in memory 42 to send a remote procedure call message to perform the following steps: Determine the message queue identifier corresponding to each target group; For each target group, a remote procedure call message corresponding to the target group is generated based on the interface protocol defined by the target version information corresponding to the target group. For each target group, a remote procedure call message is sent to the message queue indicated by the message queue identifier corresponding to the target group.

[0090] In other embodiments of this application, the processor 41 is configured to execute the service calling program in the memory 42 to determine the target version information based on the second version information corresponding to the target terminal service identified by unicast addressing, in order to implement the following steps: Retrieve at least one second version information corresponding to the target terminal service identified by unicast addressing from the target database; Based on at least one second version information obtained, the version information that is ranked last according to the version sorting rules is determined as the target version information.

[0091] In other embodiments of this application, the processor 41 is used to execute the service invocation method of the service invocation program in the memory 42 to implement the following steps: Obtain the target mapping relationship; wherein, the target mapping relationship is generated by updating the first version information and the second version information corresponding to the sub-service whose interface parameters have changed when the interface parameters of any registered sub-service of the target sub-service change.

[0092] It should be noted that a detailed description of the steps performed by the processor can be found in [reference needed]. Figure 2 and Figure 3 The implementation process of the service invocation method provided in the corresponding embodiment will not be described in detail here.

[0093] The electronic device provided in this application embodiment can obtain the version status of the target terminal service (i.e., the first version status) in real time by constructing a target database, and dynamically select a compatible RPC interface version (i.e., the second version status) in combination with a preset target mapping relationship. This fundamentally avoids the risk of RPC messages not being consumed, service failure, or even business interruption caused by the mismatch between the calling end and the target end versions. At the same time, it also supports a differentiated version selection strategy based on the addressing method (broadcast or unicast) of the remote call message to accurately match the capabilities of the target end. Unlike related technologies, it does not require waiting for all target terminal services to be upgraded before secure communication can be established. Thus, while ensuring business continuity, it effectively takes into account diverse needs such as cluster compatibility, load pressure, and functional priority.

[0094] Based on the foregoing embodiments, this application provides a computer program product, including a computer program, which, when executed by a processor, implements... Figure 2 and Figure 3 The steps in the service invocation method provided in the corresponding embodiment.

[0095] Based on the foregoing embodiments, this application provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to achieve... Figure 2 and Figure 3 The steps in the service invocation method provided in the corresponding embodiment.

[0096] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A service invocation method, characterized in that, The method includes: When a terminal service initiates a remote procedure call with a target terminal service, it retrieves the first version information corresponding to the target terminal service from the target database; wherein, the target database stores the first version information of each registered sub-service currently registered; the first version information is used to identify the version status of the sub-service in the global release version of the software system; Based on the first version information and the target mapping relationship, the second version information corresponding to the target terminal service is determined; wherein, the target mapping relationship represents the correspondence between the first version information and the second version information; the second version information is used to indicate the interface protocol version followed when performing a remote procedure call; Based on the addressing method of remote procedure call messages, the target version information is determined from the second version information and the remote procedure call message is sent.

2. The method according to claim 1, characterized in that, The addressing method based on remote procedure call messages, which determines the target version information from the second version information and sends the remote procedure call message, includes: If the addressing method includes broadcast addressing, the target version information is determined from multiple second version information based on the business scenario conditions, and the remote procedure call message is sent. If the addressing method includes unicast addressing, the target version information is determined based on the second version information corresponding to the target terminal service identified by the unicast addressing, and the remote procedure call message is sent.

3. The method according to claim 2, characterized in that, The target version information is determined from multiple second version information based on business scenario conditions, including: If the business scenario conditions include a business load greater than a first threshold, a first target version information is determined from multiple second version information as the target version information; wherein, the first target version information is the version information that is sorted first after sorting multiple second version information according to version sorting rules; If the business scenario conditions include a business requirement priority greater than a second threshold, a second target version information is determined from multiple second version information as the target version information; wherein, the second target version information is the latest version information determined after sorting multiple second version information according to version sorting rules; If the business scenario conditions include the requirement for multiple versions to run in parallel, the tag information of each target terminal service is obtained from the target database, and the target version information is determined based on multiple second version information and multiple tag information.

4. The method according to claim 3, characterized in that, The target version information is determined based on multiple pieces of second version information and multiple pieces of tag information, including: Based on the tag information, multiple target terminal services are grouped to obtain multiple target groups; For each target group, the second version information corresponding to the target group is determined as the target version information.

5. The method according to claim 4, characterized in that, Sending the remote procedure call message includes: Determine the message queue identifier corresponding to each of the target groups; For each target group, a remote procedure call message corresponding to the target group is generated based on the interface protocol defined by the target version information corresponding to the target group. For each target group, the remote procedure call message is sent to the message queue indicated by the message queue identifier corresponding to the target group.

6. The method according to claim 2, characterized in that, The step of determining the target version information based on the second version information corresponding to the target terminal service identified by the unicast address includes: Obtain at least one second version information corresponding to the target terminal service identified by the unicast address from the target database; Based on at least one of the second version information obtained, the version information that is ranked last according to the version sorting rules is determined as the target version information.

7. The method according to claim 1, characterized in that, Before obtaining the first version information corresponding to the target terminal service from the target database, the method further includes: Obtain the target mapping relationship; wherein the target mapping relationship is generated by updating the first version information and the second version information corresponding to the sub-service whose interface parameters have changed when the interface parameters of any registered sub-service change.

8. An electronic device, characterized in that, The electronic device is configured to operate as a terminal service, including: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 7.

9. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs that can be executed by one or more processors to implement the method of any one of claims 1 to 7.

Images