Server updating method, service execution method, and related devices
By using a canary iteration server update method, the verification version server can be updated to the target version without service interruption, which solves the problem of server downtime required for server updates in existing technologies and achieves a highly efficient server update process.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHENZHEN TENCENT INFORMATION TECH CO LTD
- Filing Date
- 2022-02-24
- Publication Date
- 2026-05-19
AI Technical Summary
Existing technologies require server downtime for updates, which causes users to be unable to use the service and results in high resource consumption.
The method of gray-scale iteration is adopted. The server of the verification version is used to verify whether the server of the target version meets the preset requirements. The version update operation is executed in a loop to update the current version server to the target version server, so as to achieve uninterrupted update.
The server update was completed without affecting user experience, improving update efficiency and reducing resource consumption.
Smart Images

Figure CN116708170B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of communication and Internet technology, and more specifically, to a server update method, a service execution method, and related equipment. Background Technology
[0002] In some service platforms, servers are configured to provide various services to user terminals. During the service process, server updates are often required due to the need for system upgrades and maintenance or data updates to meet user needs.
[0003] In existing technologies, during server updates, the connection between the server and the user terminal needs to be disconnected, requiring a shutdown for the update. During this period, services cannot be provided to users, and the update consumes a significant amount of resources. Summary of the Invention
[0004] The purpose of this application is to provide a server update method, apparatus, electronic device, and storage medium that can complete server updates without service interruption. To achieve this purpose, the technical solutions provided by the embodiments of this application are as follows:
[0005] In a first aspect, embodiments of this application provide a server update method, the method comprising:
[0006] The version update operation is performed repeatedly on the verification version server until all current version servers are updated to the target version server; the verification version server is used to verify whether the response operation of the target version server when providing services meets the preset requirements.
[0007] The version update operation includes:
[0008] Configure at least one verified version server in the current version of the server cluster;
[0009] Upon receiving a server allocation request based on a target service, and determining that at least two versions of the server exist to execute the target service, the server with the higher version is identified as the target server, and the target server is allocated to execute the target service; wherein, the server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version;
[0010] If the target server is a verified version server and the response operation to the target service meets the preset requirements, the target server is determined to be verified and updated to the target version server.
[0011] In one feasible embodiment, configuring at least one verified version server in the current version of the server cluster includes:
[0012] In the first configuration information corresponding to the current version of the server cluster, at least one second configuration information is set for the verification version of the server;
[0013] The first instruction to execute the service is triggered, and the first service process is invoked to respond to the first instruction;
[0014] Upon receiving the first heartbeat message from the first service process, the server for the verification version is started;
[0015] The first heartbeat message indicates that there is a server with a verification version corresponding to the second configuration information that needs to be configured.
[0016] In one feasible embodiment, determining that the target server passes verification and is updated to the target version server when the target server is a verified version server and the response operation to the target service meets preset requirements includes:
[0017] If the target server is a verified version of the server, and the response operation to the target service meets the preset requirements, then the target server is determined to have passed the verification in the current round.
[0018] When the target server passes the verification of a preset threshold number of rounds, the target server is updated to the target version of the server, and the third configuration information corresponding to the target version of the server is set.
[0019] The second instruction to execute the service is triggered, and the second service process is invoked to respond to the second instruction;
[0020] Upon receiving the second heartbeat message from the second service process, the target version of the server is started.
[0021] The second heartbeat message indicates that the second configuration information is replaced with the third configuration information.
[0022] In one feasible embodiment, updating the target server to the target version of the server further includes:
[0023] Based on a preset first interval, the target server and its corresponding second configuration information are cleared.
[0024] In a feasible embodiment, setting at least one second configuration piece for the verification version server in the first configuration information corresponding to the current version of the server cluster further includes:
[0025] If the first configuration information includes historical update information, and the currently set second configuration information is consistent with the second configuration information corresponding to the previous round of version update operation, then the server of the verification version is updated to the server of the target version, and the server of the target version is started.
[0026] In one feasible embodiment, assigning the target server to execute the target service includes:
[0027] Based on the allocation request, the connection information of the target server is fed back to allocate the target server to execute the target service;
[0028] If the number of running verification servers is less than the preset configuration number, start the corresponding number of verification servers.
[0029] In one feasible embodiment, the step of repeatedly performing version update operations on the server for the verification version until the current version of the server is updated to the target version of the server includes:
[0030] Based on the resource configuration information, the number of servers required for each service mode and the configuration information of the servers currently providing services are determined as the first configuration information corresponding to the current version of the server.
[0031] Adjust the preset startup pool information corresponding to each service mode based on the first configuration information;
[0032] The version update operation is performed repeatedly on the server of the verification version until the current version server is updated to the target version server, and the preset startup pool information corresponding to each service mode is adjusted based on the updated first configuration information.
[0033] Secondly, embodiments of this application provide a server update method, the method comprising:
[0034] The version update operation is performed repeatedly on the verification version server until all servers of the current version in each partition are updated to the target version server; the verification version server is used to verify whether the response operation of the target version server when providing services meets the preset requirements.
[0035] The version update operation includes:
[0036] Obtain load information for each partition;
[0037] Based on the load information, configure at least one verified version server in the current version server cluster, on a partition-by-partition basis;
[0038] Upon receiving a server allocation request based on a target service, and determining that at least two versions of the server exist to execute the target service, the server with the higher version in the low-load partition is identified as the target server, and the target server is allocated to execute the target service; wherein, the server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version;
[0039] If the target server is a verified version server and the response operation to the target service meets the preset requirements, the target server is determined to be verified and updated to the target version server.
[0040] Thirdly, embodiments of this application provide a service execution method, the method comprising:
[0041] In response to a matching request initiated for a target service, a matching operation corresponding to the target service is performed, and then a server allocation request is sent.
[0042] Receive connection information of the target server allocated based on the allocation request, according to either the first or the second aspect.
[0043] Based on the connection information, the target service is executed using the target server.
[0044] Fourthly, embodiments of this application provide a server update apparatus, the apparatus comprising:
[0045] The first update module is used to repeatedly perform version update operations on the verification version servers until all current version servers are updated to the target version servers; the verification version servers are used to verify whether the response operations of the target version servers when providing services meet preset requirements.
[0046] The version update operation includes:
[0047] Configure at least one verified version server in the current version of the server cluster;
[0048] Upon receiving a server allocation request based on a target service, and determining that at least two versions of the server exist to execute the target service, the server with the higher version is identified as the target server, and the target server is allocated to execute the target service; wherein, the server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version;
[0049] If the target server is a verified version server and the response operation to the target service meets the preset requirements, the target server is determined to be verified and updated to the target version server.
[0050] Fifthly, embodiments of this application provide a server update apparatus, the apparatus comprising:
[0051] The second update module is used to perform version update operations cyclically on the verification version server until all current version servers in each partition are updated to the target version server; the verification version server is used to verify whether the response operation of the target version server when providing services meets preset requirements.
[0052] The version update operation includes:
[0053] Obtain load information for each partition;
[0054] Based on the load information, configure at least one verified version server in the current version server cluster, on a partition-by-partition basis;
[0055] Upon receiving a server allocation request based on a target service, and determining that at least two versions of the server exist to execute the target service, the server with the higher version in the low-load partition is identified as the target server, and the target server is allocated to execute the target service; wherein, the server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version;
[0056] If the target server is a verified version server and the response operation to the target service meets the preset requirements, the target server is determined to be verified and updated to the target version server.
[0057] Sixthly, embodiments of this application provide a service execution apparatus, the apparatus comprising:
[0058] The sending module is used to respond to a matching request initiated for a target service, perform a matching operation corresponding to the target service, and then send a server allocation request.
[0059] A receiving module is configured to receive connection information of a target server allocated based on the allocation request by either the first aspect or the second aspect.
[0060] An execution module is used to execute the target service using the target server based on the connection information.
[0061] In a seventh aspect, this application also provides an electronic device including a memory and a processor, wherein the memory stores a computer program, and the processor, when running the computer program, performs the methods provided in any optional embodiment of this application.
[0062] Eighthly, this application also provides a computer-readable storage medium storing a computer program that, when run in a processor, enables the processor to perform the methods provided in any optional embodiment of this application.
[0063] Ninthly, this application provides a computer program product, which includes a computer program that, when executed by a processor, implements the methods provided in any optional embodiment of this application.
[0064] The beneficial effects of the technical solution provided in this application are:
[0065] This application provides a server update method, specifically a canary iterative update method that operates without service interruption. During the iterative update process, a verification version of the server is used as the object of the server version update, and the target version of the server is obtained upon completion of the update. The verification version of the server is used to verify whether the response operation of the target version of the server when providing services meets preset requirements. Specifically, this application performs version update operations cyclically on the verification version of the server until all current version servers are updated to the target version servers. The version update operation includes the following steps: configuring at least one verification version server in the current version server cluster; upon receiving a server allocation request based on the target service, and determining that at least two versions of the server exist to execute the target service, identifying the higher version server as the target server and allocating the target server to execute the target service; if the target server is a verification version server and its response operation to the target service meets preset requirements, determining that the target server has passed verification and is updated to the target version server. This application sets the target version server version to be higher than the verification version server version, and the verification version server version to be higher than the current version server version. This application allows services to be provided to user terminals even during server updates, completing all server updates without service interruption. Furthermore, by assigning the verification version server to the target service executing client requests, the verification of the verification version server can be completed synchronously, thus updating it to the target version. Additionally, by cyclically executing version update operations, this application can replace the current version server with the target version server within a certain timeframe, thereby improving the efficiency of server updates.
[0066] This application also provides a server update method, which differs from the above-mentioned server update method in that the server is managed in the form of partitions, and a load balancing strategy is used for server updates for each partition, which can effectively balance the load of each partition during the server update process.
[0067] This application also provides a service execution method. In this method, a user terminal, in response to a matching request initiated for a target service, performs a matching operation corresponding to the target service, sends a server allocation request to the server, and receives connection information of the target server allocated based on the allocation request during the server update method. Then, based on the connection information, the target service is executed using the target server. The target server can be a current version server, a verified version server, or a target version server. This application allows the user terminal to still request services from the server during server updates. For the user, the server update process does not affect their ongoing use and is imperceptible, thus improving the user experience. Attached Figure Description
[0068] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.
[0069] Figure 1 A schematic flowchart illustrating a server update method provided in an embodiment of this application;
[0070] Figure 2 A flowchart illustrating another server update method provided in this application embodiment;
[0071] Figure 3 This is a flowchart illustrating a service execution method provided in an embodiment of this application;
[0072] Figure 4 A schematic diagram of an operational architecture provided for an embodiment of this application;
[0073] Figure 5 A schematic diagram of another operating architecture provided for an embodiment of this application;
[0074] Figure 6 The following is an execution flowchart of a server update method provided in an embodiment of this application;
[0075] Figure 7 A schematic diagram of an interface provided for an embodiment of this application;
[0076] Figure 8 Another schematic diagram of the interface provided in this application embodiment;
[0077] Figure 9 Another interface schematic diagram provided for an embodiment of this application;
[0078] Figure 10 A schematic diagram of a server update device provided in this application embodiment.
[0079] Figure 11 This is a schematic diagram of the structure of a server update device provided in an embodiment of this application;
[0080] Figure 12 This is a schematic diagram of the structure of a service execution device provided in an embodiment of this application;
[0081] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0082] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting the invention.
[0083] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.
[0084] This application addresses the problems of existing server update solutions, such as the need for service shutdowns leading to user churn and high resource consumption. It proposes a server update method, service execution method, and related equipment. Based on the implementation of this solution, server updates can be completed without service interruption.
[0085] The solutions in this application involve program or platform upgrades, maintenance, or adjustments based on requirements. For example, in a game service scenario, the solutions in this application can perform gray-scale iterative verification and full-scale server updates without interrupting the live network.
[0086] Optionally, the data involved in the server update method provided in this application (such as configuration information of various version servers) can be stored in a blockchain. The blockchain referred to in this application is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. A blockchain is essentially a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains a certain amount of processed data used to verify the validity of its information (anti-counterfeiting) and to generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.
[0087] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.
[0088] Gray-scale update: In this embodiment, it refers to an update method that transitions between different server versions through a replacement algorithm. During this process, the current version of the server can be used to provide services to a portion of users, while the target version (or a verification version) of the server (or a server with verified versions) is used to provide services to another portion of users. When the verification version of the server is used to provide services to users, and users have no complaints about the services provided, the verification version of the server can be gradually updated to the target version, and all users can be gradually migrated to the target version of the server.
[0089] Match Server: In operations requiring multiple users, the match server matches the user who initiates the match request with the appropriate number of users. For example, in a multiplayer game, when user A initiates the game, the server process matches user A with other players for a single match.
[0090] First Management Server: Used for server management. When the servers in the entire region are not managed in a partitioned manner, the first management server manages all servers; when the servers in the entire region are managed in a partitioned manner, the first management server manages the second management servers of each partition. That is, in this embodiment, the first management server is a global management server.
[0091] Secondary management server: Used for server management, suitable for distributed systems. The secondary management server can manage all servers in a specific partition.
[0092] In certain specific scenarios, such as battle scenarios in game services, dedicated servers (DS) are typically deployed to provide battle services for that specific battle. In this case, the first management server can be dedicated to managing the global DS, while the second management server can be dedicated to managing a specific partition of the DS. Correspondingly, the first management server can manage each of the second management servers. Since dedicated servers are developed based on Unreal Engine (UE), they have high hardware requirements and consume significant machine resources. A single server can only handle a limited number of DSs; therefore, as the number of users served increases, a large number of DSs are deployed. The term "dedicated" in DS means that all the hardware resources of this server are used solely for a specific purpose and not for other uses. In practical applications, game and transaction servers can use dedicated servers to achieve higher performance for the specific services provided, or to achieve physical isolation and ensure data and communication security.
[0093] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.
[0094] Figure 1 This illustration shows a flowchart of a server update method provided in an embodiment of this application. This method can be executed by any electronic device, such as a server. The server can be a standalone physical server, a server cluster or 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 communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms, but is not limited to these. In this method, during the server update process, the system can respond to requests from user terminals, which can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, etc. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.
[0095] Specifically, such as Figure 1 As shown, the server update method provided in this application embodiment includes the following steps S100:
[0096] Step S100: Repeatedly perform version update operations on the verification version servers until all current version servers are updated to the target version servers.
[0097] The verification version server is used to verify whether the response operation of the target version server when providing services meets preset requirements.
[0098] Specifically, a verification version server, also known as a gray-scale version server, serves as a transition server between the current version and the target version. The services provided by the verification version server are identical to those of the target version server. In this embodiment, the gray-scale update process (e.g., using a verification version server) is employed. Figure 6 Steps 3 and 4 (as shown) are then executed to perform a rolling update process after the server confirms that the verified version has passed verification (e.g., ...). Figure 6 Step 5) shows updating the current version of the server to the target version of the server.
[0099] The version update operation includes the following steps S101-S103:
[0100] Step S101: Configure at least one verified version server in the current version of the server cluster.
[0101] Specifically, the embodiments of this application adopt a gray-scale iterative update method. That is, when performing a version update operation, if the current version server cluster includes N servers, the number of servers configured for the verification version can be taken from [1, N-1], so as to ensure that during the verification process for the verification version server, there are still servers of the current version providing services to some users.
[0102] Optionally, in each round of the version update operation, the number of servers configured in step S101 for verifying the version can be determined based on the number of servers included in the current version's server cluster and the number configured in the preset verification process, so as to maintain a preset ratio between the number of current version servers providing services to users and the number of verification version servers; this ratio can be set to 1:1, 2:1, etc. For example, with a ratio of 1:1: when M users initiate a request, responding to the request requires calling all servers (this is just an example; in actual applications, the number of servers called needs to be determined based on the actual situation), all verification version servers will be used to provide services to M / 2 users, and the same number of current version servers as the verification version servers will be used to provide services to the other half of the users.
[0103] Step S102: Upon receiving a server allocation request initiated based on the target service, and determining that there are at least two versions of the server used to execute the target service, the server with the higher version is identified as the target server, and the target server is allocated to execute the target service.
[0104] Specifically, the server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version (corresponding to the server version of the original version). Optionally, the server version of the target version is a newer version relative to the server versions of the verification version and the current version (corresponding to the server version of the original version) (i.e., the server versions of the verification version and the current version are older versions); the server version of the verification version is a newer version relative to the server version of the current version (corresponding to the server version of the original version) (i.e., the current version is an older version).
[0105] If there are M users who initiate service requests for the target service, the server directly connected to the user terminal will receive the service request and initiate a server allocation request to the management server (the execution subject in this embodiment of the application) which manages each individual server. After receiving the server allocation request initiated based on the target service, the management server will first determine whether there are different versions of servers in the server cluster. If so, the server with the higher version will be identified as the target server and the target server will be allocated as the server to execute the target service.
[0106] Optionally, during the same period, the server cluster may include at least one of the following: the original version server V1, the verification version server V2, and the target version server V3. The original version server V1 is the server that provided services before the server update was performed; correspondingly, when the version update operation is performed for the first time, the original version server V1 is equivalent to the current version server.
[0107] Step S103: If the target server is a verified version server and the response operation to the target service meets the preset requirements, determine that the target server has passed verification and is updated to the target version server.
[0108] Specifically, since multiple versions of the server may exist at the same time, the identified target server is not necessarily the verified version server. When the target server is the original version server, that is, the service currently provided to the user is not affected by the server update, step S103 does not need to be executed. When the target server is the target version server, that is, the service currently provided to the user is provided by a verified and updated server, step S103 does not need to be executed. When the target server is the verified version server, that is, the process of providing the target service is also a server verification process, therefore, when it is determined that the target server's response to the target service meets the preset requirements, the target server can be updated to the target version server. The specific update operation will be described in detail in subsequent embodiments.
[0109] The preset requirements can be set for hardware resources, server performance, and the services provided. For example, regarding the response time of the service provided, if a user reports that the server response time of the verification version is too long, or if the system determines that the server response time of the verification version to the target service exceeds the preset requirement, then the server's response operation in providing the service does not meet the preset requirements, and thus fails the verification.
[0110] In this embodiment of the application, step S100 described above can be applied to, for example... Figure 4 and 5 The first management server in the system can also be used as a second management server. Figure 4 and Figure 5 In this embodiment, the first management server can be a global management server, and the second management server can be a partition management server; that is, the method provided in this application can be applied to a global management server or a partition management server.
[0111] When applied to a partition management server, that is, verification is performed only on a single partition management server for the verification version of the server. This can effectively reduce the impact on existing network users. Once the verification version of the server in a certain partition is confirmed to have passed verification, the servers in that partition can be updated to the target version of the server. At the same time, a notification message that the verification version of the server has passed verification is sent to the global management server, so that the global management server can directly update the current version of the server globally (i.e., all partitions) to the target version of the server.
[0112] When applied to a global management server, that is, to verify the server version in each partition, once the server version passes verification, the current version of the server in the global system can be updated to the target version of the server.
[0113] In one feasible embodiment, in step S101, at least one verified version server is configured in the current version server cluster, including the following steps A1-A3:
[0114] Step A1: In the first configuration information corresponding to the current version of the server cluster, set at least one second configuration information for the verification version server.
[0115] Step A2: Trigger the first instruction to execute the service and call the first service process to respond to the first instruction.
[0116] Step A3: Upon receiving the first heartbeat message from the first service process, start the verification version of the server.
[0117] The first heartbeat message indicates that there is a server with a verification version corresponding to the second configuration information that needs to be configured.
[0118] Specifically, in the system's server configuration, each server has configuration information that corresponds to itself. This configuration information may include version information and path information (such as the path connecting to the corresponding server). In this embodiment, the current version of the server corresponds to the first configuration information, and the verified version of the server corresponds to the second configuration information.
[0119] When configuring a server for a verification version in a server cluster, the corresponding configuration information must first be set in the cluster. This configuration information can distinguish between different versions of the server and determine the path to connect to that server.
[0120] Specifically, at process startup, the heartbeat status of the servers indicates whether the corresponding servers can be set to an available state. For example, if server A is in a heartbeat-maintaining state, server A can be set to service availability; if server B is in a heartbeat timeout or interrupted state, server B can be set to service unavailable, and will be added back to the service after the heartbeat resumes. Optionally, information related to the heartbeat status can be synchronously recorded in the server's configuration information.
[0121] Specifically, after executing step A1, a signal (such as a first instruction to trigger service execution) can be used to trigger the service process to detect server configuration changes. When a first heartbeat message is received from the first service process, it indicates that a verification version of the server configuration exists in the current server cluster. Therefore, based on this first heartbeat message, some verification version servers with pre-configured second configuration information can be started. The started verification version servers can be assigned to provide services to user terminals. Optionally, the number of verification version servers started can be determined based on the number of configurations in the preset verification process (the number of configurations for verification version servers), that is, considering how many verification version servers should be deployed to maintain the service capacity of the server.
[0122] like Figure 6 As shown, step A1 above can correspond to Figure 6 Step 3, step A3 can correspond to Figure 6 Step 2 in the process.
[0123] In a feasible embodiment, if the target server is a verified version server and the response operation to the target service meets preset requirements in step S103, the target server is determined to have passed verification and been updated to the target version server, including the following steps B1-B4:
[0124] Step B1: If the target server is a verified version of the server and the response operation to the target service meets the preset requirements, then the target server is determined to have passed the verification of the current round.
[0125] Step B2: When the target server passes the verification of the preset threshold rounds, update the target server to the target version of the server and set the third configuration information corresponding to the target version of the server.
[0126] Step B3: Trigger the second instruction to execute the service and call the second service process to respond to the second instruction.
[0127] Step B4: Upon receiving the second heartbeat message from the second service process, start the server for the target version.
[0128] The second heartbeat message indicates that the second configuration information is replaced with the third configuration information.
[0129] Specifically, as seen in steps B1 and B2, in this embodiment, the verified version server needs to undergo several verification cycles (verification through a preset threshold number of rounds) before it can be considered that the verified version server can be updated to the target version server, which is equivalent to determining that the target version server can be put into formal use. In subsequent processing, the service process can be triggered to perceive configuration changes through signals (such as triggering a second instruction to execute the service). When a second heartbeat message is received from the second service process, it indicates that the second configuration information corresponding to the verified version server in the current server cluster has been replaced with third configuration information (which may include version information and path information). Therefore, the target version server with the third configuration information can be started based on the second heartbeat message; the started target version server can be assigned to provide services to user terminals.
[0130] like Figure 6 As shown, step B2 above can correspond to Figure 6 Steps 5 and B4 in the text can correspond to Figure 6 Step 2 in the process.
[0131] In one feasible embodiment, updating the target server to the target version of the server in step B2 further includes the following step B21:
[0132] Step B21: Based on a preset first interval, clear the target server and its corresponding second configuration information.
[0133] Specifically, considering that the introduction of the verification version server aims to verify whether the response operation of the target version server to the target service meets preset requirements, this application embodiment can initiate a recycling mechanism while configuring the verification version server. In this recycling mechanism, if the verification version server is determined to have passed verification and has been modified into the target version server, data related to the verification version server, such as the second configuration information, can be cleared based on a preset first interval. The clearing of the target server can be considered as stopping the operation of the target server, preventing it from being allocated to provide services to user terminals.
[0134] like Figure 6 As shown, step B21 can correspond to Figure 6 Steps 6 and 7 in the process.
[0135] In a feasible embodiment, step A1, in the first configuration information corresponding to the current version of the server cluster, sets at least one second configuration information for the verification version server, and further includes the following steps A11-A13:
[0136] Step A11: If the first configuration information includes historical update information, and the currently set second configuration information is consistent with the second configuration information corresponding to the previous round of version update operation, then update the verification version server to the target version server and start the target version server.
[0137] Specifically, historical update information indicates that the first configuration information has been replaced, such as replacing the first configuration information corresponding to the original version of the server with the third configuration information of the target version. Since version update operations are executed cyclically, in the second round and subsequent version update operations, the current version of the server may be the original version server or the target version server. Therefore, the first configuration information corresponding to the current version of the server may be the configuration information corresponding to the original version server or the configuration information corresponding to the target version server. If the currently set second configuration information is consistent with the second configuration information corresponding to the version update operation in the previous round, it indicates that the server has passed verification and can be directly updated to the target version server. In step A11, updating the verified version server to the target version server means directly updating the current version server to the target version server.
[0138] Optionally, the execution of step A11 can be implemented by triggering a service process to detect configuration changes via a signal, such as triggering a third instruction to execute the service, calling a third service process to respond to the third instruction, and starting the target version of the server referred to in step A11 upon receiving a third heartbeat message from the third service process. The started target version of the server can then be assigned to provide services to users. The third heartbeat message indicates that the first configuration information includes historical update information, and the currently set second configuration information is consistent with the second configuration information corresponding to the previous round of version update operations (e.g., the service process detects that the version information and path information of the current server have changed, and are the same as the version information and path information of the server in the last verification).
[0139] In this embodiment of the application, the execution of step A11 is equivalent to triggering the rolling update process.
[0140] Step A12: End the version update operation for the current round.
[0141] Specifically, since the server for the verification version that needs to be verified in the current round has been directly updated to the server for the target version, the version update operation for the current round can be ended, and the version update operation for the next round can begin.
[0142] Step A13: Based on the preset second interval, clear the current version of the server and its corresponding first configuration information.
[0143] Specifically, considering that the original version of the server needs to be decommissioned after the server update is completed, this application embodiment can configure a recycling mechanism. In this recycling mechanism, if it is determined that the current version of the server has been updated to the target version of the server, data related to the current version of the server, such as the first configuration information, can be cleared based on a preset second interval. Clearing the current version of the server can be considered as stopping the server's operation, preventing it from being assigned as a server to provide services to user terminals.
[0144] like Figure 6 As shown, step A11 above can correspond to Figure 6 Step 4, step A13 in the text can correspond to Figure 6 Steps 6 and 7 in the process.
[0145] In a feasible embodiment, the target server is assigned to execute the target service in step S103, including the following steps C1-C2:
[0146] Step C1: Based on the allocation request, feedback the connection information of the target server to allocate the target server to execute the target service.
[0147] The connection information may include the server's IP address (such as Internet Protocol Address) and PORT information (such as interface information).
[0148] Step C2: When the number of running verification servers is less than the preset configuration number, start the corresponding number of verification servers.
[0149] In this regard, considering the need to maintain service capacity during the verification process of the verification version servers, the configuration number can be adjusted accordingly. If the number of running verification version servers is less than the preset configuration number, the corresponding number of verification version servers can be triggered to start. For example, in step A3, although several verification version servers are configured with second configuration information, not all verification version servers with the second configuration information need to be started when executing step A3.
[0150] In one feasible embodiment, step S100 involves repeatedly performing version update operations on the server for the verification version until the current version of the server is updated to the target version of the server, including the following steps D1-D3:
[0151] Step D1: Based on the resource configuration information, determine the number of servers required for each service mode and the configuration information of the servers currently providing services as the first configuration information corresponding to the current version of the server.
[0152] In a single platform, multiple services may be provided to users. Therefore, when the process starts, the security threshold of the number of servers to be allocated in each service mode can be read based on the resource configuration information, which is the number of servers required. At the same time, the configuration information of the servers currently providing services can also be read based on the resource configuration information, such as the configuration information of the original version of the server.
[0153] Step D2: Adjust the preset startup pool information corresponding to each service mode based on the first configuration information.
[0154] Specifically, after reading the information indicated in step D1 and waiting for the heartbeat of each server to be maintained, the preset startup pool size corresponding to each service mode can be adjusted uniformly according to the configuration information.
[0155] Step D3: Execute version update operations repeatedly for the verified version server until the current version server is updated to the target version server, and adjust the preset startup pool information corresponding to each service mode based on the updated first configuration information.
[0156] Specifically, since the configuration information will change when the old version of the server is updated to the target version, the preset startup pool size for each service mode can be adjusted based on the updated configuration information.
[0157] Figure 2 This document illustrates a flowchart of another server update method provided in an embodiment of this application. This method can be executed by any electronic device, such as a server. The server can be a standalone physical server, a server cluster or 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 communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms, but is not limited to these. In this method, during the server update process, the system can respond to requests from user terminals, which can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, etc. The terminals and the server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.
[0158] like Figure 2 As shown, another server update method provided in this application embodiment includes the following steps S200:
[0159] Step S200: Execute the version update operation repeatedly for the verification version server until all servers in each partition with the current version are updated to the target version server.
[0160] The verification version server is used to verify whether the response operation of the target version server when providing services meets preset requirements.
[0161] The version update operation includes the following steps S201-S204:
[0162] Step S201: Obtain the load information of each partition.
[0163] Step S202: Based on the load information, configure at least one verified version server in the current version server cluster, on a partition-by-partition basis.
[0164] Step S203: Upon receiving a server allocation request initiated based on the target service, and determining that there are at least two versions of the server used to execute the target service, the server with the higher version in the low-load partition is identified as the target server, and the target server is allocated to execute the target service; wherein, the server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version.
[0165] Step S204: If the target server is a verified version server and the response operation to the target service meets the preset requirements, determine that the target server has passed verification and is updated to the target version server.
[0166] In this embodiment of the application, step S200 described above can be applied to, for example... Figure 4 and Figure 5 The first management server in the system. Figure 4 and Figure 5 In this context, the first management server can be a global management server; that is, the server update method provided in this application embodiment can be applied to a global management server.
[0167] When applied to a global management server, any embodiment included in the server update method corresponding to step S100 above can be inherited according to the load balancing strategy.
[0168] To better illustrate the server update method corresponding to step S200, the following will combine... Figure 5 and Figure 6 The following explanation uses the update of a dedicated server as an example:
[0169] First, when the global DS management server (first management server) starts the process, it reads the security threshold of the number of DS to be allocated that each service mode needs to maintain according to the resource configuration, reads the DS and path information of the current V1 version according to the resource configuration, and waits for the heartbeat of all partition DS management servers (second management servers) to be maintained. Then, it notifies the partition DS management servers to adjust each game mode to the preset launch pool size according to the configured version information.
[0170] The partition DS management server will periodically report its load and version information to the global DS management server; the load information update frequency can be set to refresh once every 1 second or 500ms.
[0171] The global DS management server can cache the load information reported by all partition DS management servers and the global DS management server's own information. When the heartbeat of a partition DS management server times out or is interrupted, the corresponding information of the partition DS management server will be set to unavailable. It will be added back to the service after the heartbeat is restored.
[0172] Corresponding to Figure 6In step 3, when the grayscale DS version and path information of the global DS management server are set to valid values and the DS recycling mechanism is enabled, the global DS management server process detects the configuration change through signal triggering. When the global DS management server process finds that there is a grayscale DS configuration, it can request the partition DS management server according to the load balancing request, start a certain number of new V2 version DS on the specified grayscale DS path, and detect the startup result in the next heartbeat cycle by detecting the heartbeat status.
[0173] Corresponding to Figure 6 In step 5, when the grayscale DS version and path information of the global DS management server are modified, a signal triggers the process to detect the configuration change. The global DS management server process detects that the grayscale information (configuration information related to the verification version server) is inconsistent with the previous information. It then continues to partition the DS management server according to the load balancing request, starts the newly configured V3 version DS on the new grayscale DS path, and detects the startup result in the next heartbeat cycle by detecting the heartbeat status. Simultaneously, a timer with a specified time interval (corresponding to...) is started. Figure 6 Step 7) triggers a notification after a certain period of time, notifying the partition DS management server to reclaim the V2 version DS.
[0174] Corresponding to Figure 6 In step 4, when the current DS version and path information of the global DS management server are modified, and the gray-scale DS version and path information are reset, the process is triggered by a signal to detect the configuration change. When the global DS management server process finds that the current DS version and path information has changed and is the same as the previous gray-scale DS version and path, it triggers a rolling update and notifies the DS management server to adjust each game mode to the preset launch pool size according to the configuration version information.
[0175] like Figure 5 As shown, if a user initiates a matching request during server updates, and the matching server successfully matches, it will send a DS allocation request to the global DS management server. The global DS management server will determine whether multiple versions of the DS coexist based on the cached DS information. According to the version degradation strategy, it will select the partition DS management server with the lowest load through load balancing to request the allocation of the DS's IP and PORT information and return it to the client. Once the user's client receives the DS information, it can connect to the DS to begin operations.
[0176] The following is about Figure 6 The processing logic corresponding to the grayscale update process in steps 3 and 5 and the rolling update process in step 4 will be explained below:
[0177] Step 1: During process initialization, read the current DS version, path configuration information, and number of startups.
[0178] Step 2: Send a request to the partition DS management server to pre-launch the specified version of DS based on the configuration information.
[0179] Step 3: Determine whether the setting of grayscale version and path information has been triggered. If it has been triggered, proceed to step 2; otherwise, proceed to step 6.
[0180] Step 4: Determine if the setting of the current version and path information has been triggered. If it has, proceed to Step 2; otherwise, proceed to Step 6.
[0181] Step 5: Determine whether the update of the grayscale version and path information has been triggered. If it has, proceed to step 2; otherwise, proceed to step 6.
[0182] Step 6: Determine if a DS version that needs to be recycled has been generated and enable the DS old version recycling mechanism. If triggered, proceed to Step 7; otherwise, proceed to Step 8.
[0183] Step 7: Trigger the DS recycling timer. Set the timer according to the configured time. After the timer expires, send a recycling command for the specified version of DS to the partition DS management server.
[0184] Step 8: Return and wait for the next trigger to execute; the calculation logic ends.
[0185] Optionally, in this embodiment of the application, the recycling mechanism can also recycle servers and their configuration information that have failed verification.
[0186] Figure 3 The illustration shows a flowchart of a service execution method provided in an embodiment of this application. This method can be executed by any electronic device, such as a user terminal, which can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, in-vehicle device, etc.
[0187] like Figure 3 As shown, an embodiment of this application provides a service execution method including the following steps S301-S303:
[0188] Step S301: In response to a matching request initiated for the target service, perform a matching operation corresponding to the target service and then send a server allocation request.
[0189] Step S302: Receive the connection information of the target server allocated based on the allocation request in the above embodiment.
[0190] Step S303: Based on the connection information, the target server executes the target service.
[0191] The following is combined Figure 5 , Figure 7 , Figure 8and Figure 9 Steps S301-S303 of the above embodiment will be described as follows:
[0192] Figures 7-9 It can be applied to a game scenario, in Figure 7 In the middle, users can trigger the "Start Game" control, causing the client to initiate a match request; in Figure 8 In the middle, the client responds to the matching request and is in the matching operation; in Figure 9 In the middle, the user enters the game and starts a match.
[0193] Specifically, game users click on the client. Figure 7 Clicking the "Start Game" button on the client initiates a matchmaking request to the server. The server's matchmaking module (matchmaking server) then matches players to start a game. After receiving the matchmaking results from the server, the client displays the current matchmaking progress. Once the required number of players is met, the game can begin. The matchmaking interface looks like this: Figure 8 As shown in the diagram. After a user is successfully matched, the global DS manager (first management server) on the server side receives the server allocation request. It can then process the request using the server update method provided in the above embodiment and return the highest version DS server IP and port with optimal access speed and moderate load to the client for the user to connect and enter the game. The interface is shown in the diagram. Figure 9 As shown.
[0194] The server update method in the above embodiments is executed in... Figure 8 and Figure 9 It interacts with the interface transitions.
[0195] In this embodiment of the application, other logical modules in the entire game architecture are deployed with a fixed number of machines across all regions and servers. For the initial part, which requires timely response, deployment can be based on the initial number of machines. However, for users, the deployment of machines is transparent and is a case of all regions and servers (without server division). Different users are matched into the same game after matching, and the global DS manager will guide them to the DS server with the highest version and the best access speed and moderate load according to the actual situation of the DS cluster.
[0196] like Figure 5 As shown, the game's DS cluster and partition DS management server (secondary management server) can be deployed in three data centers, while the global DS management server and other global modules (such as matchmaking servers) are deployed in the same data center. The global DS management server manages all DS states by version, and also supports configuration updates to trigger canary DS releases to load balance the configured quantity across different regions.
[0197] Specifically, during the server update process, when user 1-M initiates a matching request and a match is successful, the matching server sends a request to the global DS management server (the first management server) to allocate a DS. After a series of internal calculations, the global DS management server determines whether multiple versions of the requested DS coexist, and allocates the higher version DS from partition 2 with lower load. Figure 5 The V3 version server (shown by the dashed line) is assigned to users 1-M for the initial battle.
[0198] Meanwhile, due to the change in the DS cluster state caused by the allocation of battle situation in partition 2, the global DS management server will perform internal calculations based on the load information reported by the partition DS management servers (second management servers) in partitions 1-3. If it finds that the number of existing DS versions globally is insufficient to meet the configuration requirements, it can request to start or stop some of the DS versions in several partitions (e.g., partitions 1-2) according to the load status to maintain the service capacity of the DS version to the preset grayscale DS configuration.
[0199] In this embodiment, the provided server update method and service execution method maintain the server's global reach and server-wide functionality for users. After successful matching, some users are prioritized for entry into gray-scale version battlegrounds (battlegrounds served by the verification version server), while other users continue to be assigned to the current version battlegrounds (battlegrounds served by the original version server). For game service scenarios, the game's login and other logic servers are global, while only the DS and matchmaking servers are deployed based on geographical location. Gray-scale DS battlegrounds (gray-scale version battlegrounds) can be randomly distributed across various regions. Furthermore, the game uses algorithms to prioritize the allocation of gray-scale DS battlegrounds and maintain the gray-scale ratio, ensuring that users within the gray-scale ratio range can quickly verify the gray-scale version functionality, while users outside the ratio range are unaware of server updates.
[0200] The following is combined Figure 4 The operational architecture of the embodiments of this application will be described.
[0201] like Figure 4 As shown, user terminal 20 and docking server 10 can communicate and exchange data via network 30; wherein, docking server 10 may be the matching server referred to in the above embodiment. Additionally, as... Figure 4 As shown, the first management server 11 communicates with the docking server 10, and the first management server 11 is a global management server; the second management server 12 communicates with the first management server 11, and the second management server 12 is a partition management server. Optionally, when there are K partitions (K can be greater than or equal to 1), the first management server 11 communicates with K second management servers 12 respectively.
[0202] Based on the same principles as the above-described method embodiments, this application also provides a server update device, such as... Figure 10 As shown, the server update device 100 may include a first update module 101.
[0203] The first update module 101 is used to repeatedly perform version update operations on the verification version server until all current version servers are updated to the target version server; the verification version server is used to verify whether the response operation of the target version server when providing services meets preset requirements.
[0204] The version update operation includes:
[0205] Configure at least one verified version server in the current version of the server cluster;
[0206] Upon receiving a server allocation request based on a target service, and determining that at least two versions of the server exist to execute the target service, the server with the higher version is identified as the target server, and the target server is allocated to execute the target service; wherein, the server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version;
[0207] If the target server is a verified version server and the response operation to the target service meets the preset requirements, the target server is determined to be verified and updated to the target version server.
[0208] In one feasible embodiment, the first update module 101 is used to configure at least one verified version server in the current version server cluster, specifically for:
[0209] In the first configuration information corresponding to the current version of the server cluster, at least one second configuration information is set for the verification version of the server;
[0210] The first instruction to execute the service is triggered, and the first service process is invoked to respond to the first instruction;
[0211] Upon receiving the first heartbeat message from the first service process, the server for the verification version is started;
[0212] The first heartbeat message indicates that there is a server with a verification version corresponding to the second configuration information that needs to be configured.
[0213] In a feasible embodiment, the first update module 101 is used to determine, when the target server passes verification and is updated to the target version server if the target server is a verified version server and the response operation to the target service meets preset requirements, specifically for:
[0214] If the target server is a verified version of the server, and the response operation to the target service meets the preset requirements, then the target server is determined to have passed the verification in the current round.
[0215] When the target server passes the verification of a preset threshold number of rounds, the target server is updated to the target version of the server, and the third configuration information corresponding to the target version of the server is set.
[0216] The second instruction to execute the service is triggered, and the second service process is invoked to respond to the second instruction;
[0217] Upon receiving the second heartbeat message from the second service process, the target version of the server is started.
[0218] The second heartbeat message indicates that the second configuration information is replaced with the third configuration information.
[0219] In a feasible embodiment, when the first update module 101 is used to update the target server to the target version of the server, it is further specifically used to:
[0220] Based on a preset first interval, the target server and its corresponding second configuration information are cleared.
[0221] In a feasible embodiment, the first update module 101, when setting at least one piece of second configuration information for the verification version server in the first configuration information corresponding to the current version of the server cluster, is further specifically used for:
[0222] If the first configuration information includes historical update information, and the currently set second configuration information is consistent with the second configuration information corresponding to the previous round of version update operation, then the server of the verification version is updated to the server of the target version, and the server of the target version is started.
[0223] End the current round of version update operations;
[0224] Based on a preset second interval, clear the current version of the server and its corresponding first configuration information.
[0225] In a feasible embodiment, the first update module 101 is used to, when assigning the target server to execute the target service, specifically for:
[0226] Based on the allocation request, the connection information of the target server is fed back to allocate the target server to execute the target service;
[0227] If the number of running verification servers is less than the preset configuration number, start the corresponding number of verification servers.
[0228] In one feasible embodiment, the first update module 101 is used to perform a cyclical version update operation on the server for the verification version until the current version of the server is updated to the target version of the server, specifically for:
[0229] Based on the resource configuration information, the number of servers required for each service mode and the configuration information of the servers currently providing services are determined as the first configuration information corresponding to the current version of the server.
[0230] Adjust the preset startup pool information corresponding to each service mode based on the first configuration information;
[0231] The version update operation is performed repeatedly on the server of the verification version until the current version server is updated to the target version server, and the preset startup pool information corresponding to each service mode is adjusted based on the updated first configuration information.
[0232] Based on the same principles as the above-described method embodiments, this application also provides a server update device, such as... Figure 11 As shown, the server update device 200 may include a second update module 201.
[0233] The second update module 201 is used to perform version update operations cyclically on the verification version server until all current version servers in each partition are updated to the target version server; the verification version server is used to verify whether the response operation of the target version server when providing services meets preset requirements.
[0234] The version update operation includes:
[0235] Obtain load information for each partition;
[0236] Based on the load information, configure at least one verified version server in the current version server cluster, on a partition-by-partition basis;
[0237] Upon receiving a server allocation request based on a target service, and determining that at least two versions of the server exist to execute the target service, the server with the higher version in the low-load partition is identified as the target server, and the target server is allocated to execute the target service; wherein, the server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version;
[0238] If the target server is a verified version server and the response operation to the target service meets the preset requirements, the target server is determined to be verified and updated to the target version server.
[0239] Based on the same principles as the above method embodiments, this application also provides a service execution device, such as... Figure 12 As shown, the service execution device 300 may include a sending module 301, a receiving module 302, and an execution module 303.
[0240] The sending module 301 is used to respond to a matching request initiated for a target service, perform a matching operation corresponding to the target service, and then send a server allocation request; the receiving module 302 is used to receive the connection information of the target server allocated based on the allocation request in the above embodiment; and the execution module 303 is used to execute the target service using the target server based on the connection information.
[0241] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.
[0242] This application provides an electronic device, including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of a server update method. Compared with related technologies:
[0243] On one hand, this application provides a server update method, specifically a canary iterative update method that operates without service interruption. During the server iterative update process, a verification version of the server is used as the object of the server version update, and the target version of the server is obtained after the update is completed. The verification version of the server is used to verify whether the response operation of the target version of the server when providing services meets preset requirements. Specifically, this application performs version update operations cyclically on the verification version of the server until all current version servers are updated to the target version servers. The version update operation includes the following steps: configuring at least one verification version server in the current version server cluster; upon receiving a server allocation request based on the target service, and determining that at least two versions of the server are used to execute the target service, identifying the higher version server as the target server and allocating the target server to execute the target service; if the target server is a verification version server and its response operation to the target service meets preset requirements, determining that the target server has passed verification and is updated to the target version server. This application sets the target version server version to be higher than the verification version server version, and the verification version server version to be higher than the current version server version. This application allows services to be provided to user terminals even during server updates, completing all server updates without service interruption. Furthermore, by assigning the verification version server to the target service executing client requests, the verification of the verification version server can be completed synchronously, thus updating it to the target version. Additionally, by cyclically executing version update operations, this application can replace the current version server with the target version server within a certain timeframe, thereby improving the efficiency of server updates.
[0244] On the other hand, this application also provides a server update method. The difference between this method and the above-mentioned server update method is that the server is managed in the form of partitions, and a load balancing strategy is used for server updates for each partition. This can effectively balance the load of each partition during the server update process.
[0245] On another front, this application also provides a service execution method. In this method, a user terminal, in response to a matching request initiated for a target service, performs a matching operation corresponding to the target service, sends a server allocation request to the server, and receives connection information of the target server allocated based on the allocation request during the server update method. Then, based on the connection information, the target service is executed using the target server. The target server can be the current version of the server, a verified version of the server, or a target version of the server. This application allows the user terminal to still request services from the server during server updates. For the user, the server update process does not affect their ongoing use and is imperceptible, thus improving the user experience.
[0246] In one alternative embodiment, an electronic device is provided, such as Figure 13 As shown, Figure 13 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.
[0247] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.
[0248] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 13 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0249] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.
[0250] The memory 4003 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 4001. The processor 4001 executes the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.
[0251] Electronic devices include, but are not limited to: servers, user terminals, and vehicle-mounted equipment.
[0252] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.
[0253] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.
[0254] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the illustrations or text descriptions.
[0255] It should be understood that although the flowcharts in the embodiments of this application use arrows to indicate the various operation steps, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of the embodiments of this application, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on the actual implementation scenario. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where the execution times are different, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and the embodiments of this application do not limit this.
[0256] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.
Claims
1. A server update method, characterized in that, include: The version update operation is performed repeatedly on the verification version server until all servers with the current version in each partition are updated to the target version server. The verification version of the server is used to verify whether the response operation of the target version of the server when providing services meets the preset requirements; The version update operation includes: Obtain load information for each partition; Based on the load information, at least one verified version server is configured in the server cluster of the current version of multiple partitions, so that the number of verified version servers in the multiple partitions reaches the preset configuration number. Upon receiving a server allocation request initiated based on a target service, and determining that at least two versions of the server are used to execute the target service, the server with the higher version among multiple partitions is identified as the target server. The target server is then allocated to execute a portion of the service requests in the target service, while the server with the current version is allocated to execute the other service requests in the target service, excluding the portion of the service requests. The server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version. If the target server is a verified version server and the response operation to the target service meets the preset requirements, the target server is determined to be verified and updated to the target version server.
2. The method according to claim 1, characterized in that, For each partition, configure at least one verified version server in the current version server cluster, including: In the first configuration information corresponding to the current version of the server cluster, at least one second configuration information is set for the verification version of the server; The first instruction to execute the service is triggered, and the first service process is invoked to respond to the first instruction; Upon receiving the first heartbeat message from the first service process, the server for the verification version is started; The first heartbeat message indicates that there is a server with a verification version corresponding to the second configuration information that needs to be configured.
3. The method according to claim 2, characterized in that, The step of determining that the target server passes verification and is updated to the target version server when the target server is a verified version server and the response operation to the target service meets the preset requirements includes: If the target server is a verified version of the server, and the response operation to the target service meets the preset requirements, then the target server is determined to have passed the verification in the current round. When the target server passes the verification of a preset threshold number of rounds, the target server is updated to the target version of the server, and the third configuration information corresponding to the target version of the server is set. The second instruction to execute the service is triggered, and the second service process is invoked to respond to the second instruction; Upon receiving the second heartbeat message from the second service process, the target version of the server is started. The second heartbeat message indicates that the second configuration information is replaced with the third configuration information.
4. The method according to claim 3, characterized in that, The process of updating the target server to the target version also includes: Based on a preset first interval, the target server and its corresponding second configuration information are cleared.
5. The method according to claim 2, characterized in that, The first configuration information corresponding to the current version of the server cluster, which sets at least one second configuration information for the verification version server, also includes: If the first configuration information includes historical update information, and the currently set second configuration information is consistent with the second configuration information corresponding to the previous round of version update operation, then the server of the verification version is updated to the server of the target version, and the server of the target version is started. End the current round of version update operations; Based on a preset second interval, clear the current version of the server and its corresponding first configuration information.
6. The method according to claim 1, characterized in that, The step of assigning the target server to execute a portion of the service requests in the target service includes: Based on the allocation request, the connection information of the target server is fed back to allocate the target server to execute a portion of the service requests in the target service; If the number of running verification servers is less than the preset configuration number, start the corresponding number of verification servers.
7. The method according to claim 1, characterized in that, The process of repeatedly performing version update operations on the verification version server until all servers in each partition are updated to the target version server includes: Based on the resource configuration information, the number of servers required for each service mode and the configuration information of the servers currently providing services are determined as the first configuration information corresponding to the current version of the server. Adjust the preset startup pool information corresponding to each service mode based on the first configuration information; The version update operation is performed repeatedly on the verification version server until the current version server in each partition is updated to the target version server, and the preset startup pool information corresponding to each service mode is adjusted based on the updated first configuration information.
8. The method according to claim 1, characterized in that, The target server is identified from multiple partitions with higher version numbers, including identifying the target server from multiple partitions with lower load.
9. A service execution method, characterized in that, include: In response to a matching request initiated for a target service, a matching operation corresponding to the target service is performed, and then a server allocation request is sent. Receive connection information of the target server allocated based on the allocation request according to any one of claims 1-8; Based on the connection information, the target service is executed using the target server.
10. A server update device, characterized in that, include: The first update module is used to perform version update operations on the verification version server in a loop until all the current version servers in each partition are updated to the target version server. The verification version of the server is used to verify whether the response operation of the target version of the server when providing services meets the preset requirements; The version update operation includes: Obtain load information for each partition; Based on the load information, at least one verified version server is configured in the server cluster of the current version of multiple partitions, so that the number of verified version servers in the multiple partitions reaches the preset configuration number. Upon receiving a server allocation request initiated based on a target service, and determining that at least two versions of the server are used to execute the target service, the server with the higher version among multiple partitions is identified as the target server. The target server is then allocated to execute a portion of the service requests in the target service, while the server with the current version is allocated to execute the other service requests in the target service, excluding the portion of the service requests. The server version of the target version is higher than the server version of the verification version, and the server version of the verification version is higher than the server version of the current version. If the target server is a verified version server and the response operation to the target service meets the preset requirements, the target server is determined to be verified and updated to the target version server.
11. The apparatus according to claim 10, characterized in that, The first update module is used to configure at least one verified version server in the current version server cluster for each partition, specifically for: In the first configuration information corresponding to the current version of the server cluster, at least one second configuration information is set for the verification version of the server; The first instruction to execute the service is triggered, and the first service process is invoked to respond to the first instruction; Upon receiving the first heartbeat message from the first service process, the server for the verification version is started; The first heartbeat message indicates that there is a server with a verification version corresponding to the second configuration information that needs to be configured.
12. The apparatus according to claim 11, characterized in that, The first update module is used to determine when the target server passes verification and is updated to the target version if the target server is a verified version server and the response operation to the target service meets preset requirements. Specifically, it is used to: If the target server is a verified version of the server, and the response operation to the target service meets the preset requirements, then the target server is determined to have passed the verification in the current round. When the target server passes the verification of a preset threshold number of rounds, the target server is updated to the target version of the server, and the third configuration information corresponding to the target version of the server is set. The second instruction to execute the service is triggered, and the second service process is invoked to respond to the second instruction; Upon receiving the second heartbeat message from the second service process, the target version of the server is started. The second heartbeat message indicates that the second configuration information is replaced with the third configuration information.
13. The apparatus according to claim 12, characterized in that, When the first update module is used to update the target server to the target version of the server, it is also specifically used for: Based on a preset first interval, the target server and its corresponding second configuration information are cleared.
14. The apparatus according to claim 11, characterized in that, The first update module is used to execute the first configuration information corresponding to the current version of the server cluster, and when setting at least one second configuration information for the verification version server, it is also specifically used for: If the first configuration information includes historical update information, and the currently set second configuration information is consistent with the second configuration information corresponding to the previous round of version update operation, then the server of the verification version is updated to the server of the target version, and the server of the target version is started. End the current round of version update operations; Based on a preset second interval, clear the current version of the server and its corresponding first configuration information.
15. The apparatus according to claim 10, characterized in that, The first update module is used to execute requests to allocate a portion of the target service to the target server, specifically for: Based on the allocation request, the connection information of the target server is fed back to allocate the target server to execute a portion of the service requests in the target service; If the number of running verification servers is less than the preset configuration number, start the corresponding number of verification servers.
16. The apparatus according to claim 10, characterized in that, The first update module is used to perform version update operations cyclically on the verification version server until all servers in each partition are updated to the target version server. Specifically, it is used for: Based on the resource configuration information, the number of servers required for each service mode and the configuration information of the servers currently providing services are determined as the first configuration information corresponding to the current version of the server. Adjust the preset startup pool information corresponding to each service mode based on the first configuration information; The version update operation is performed repeatedly on the server of the verification version until the current version server is updated to the target version server, and the preset startup pool information corresponding to each service mode is adjusted based on the updated first configuration information.
17. The apparatus according to claim 10, characterized in that, The first update module is used to determine the server with the higher version among multiple partitions as the target server, specifically: determining the server with the higher version among the partitions with low load as the target server.
18. A service execution device, characterized in that, include: The sending module is used to respond to a matching request initiated for a target service, perform a matching operation corresponding to the target service, and then send a server allocation request. The receiving module is configured to receive connection information of the target server allocated based on the allocation request according to any one of claims 1-8; An execution module is used to execute the target service using the target server based on the connection information.
19. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor, when running the computer program, performs the method of any one of claims 1 to 9.
20. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when run in a processor, is used to execute the method according to any one of claims 1 to 9.
21. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 9.