Service processing method, device, electronic device, storage medium and program product

Abstract

The present application provides a service processing method, device, electronic device, computer-readable storage medium and computer program product; the method includes: obtaining a first stateful service for updating; performing registration processing of the stateful service based on the first stateful service to obtain a second stateful service, the second stateful service corresponding to the first stateful service; during the operation of the first stateful service, migrating the coroutine of the first stateful service to the second stateful service to obtain the migrated second stateful service; executing the corresponding coroutine service request through the coroutine of the migrated second stateful service. Through the present application, it is possible to realize online updating of stateful services and improve the application fluency of services.

Description

Technical Field

[0001] The present application relates to computer graphics and image technology, and in particular to a service processing method, device, electronic device, computer-readable storage medium, and computer program product. Background Art

[0002] Display technology based on graphics processing hardware has expanded the channels for perceiving the environment and obtaining information, especially the display technology of virtual scenes. It can realize diversified interactions between virtual objects controlled by users or artificial intelligence according to actual application needs, and has various typical application scenarios. For example, in virtual scenes such as games, it can simulate the real battle process between virtual objects.

[0003] In recent years, as the speed of game content updates has increased, various problems have often been brought to the game service (a stateful service) function. In the related art, game service updates are achieved by downtime updates. This solution seriously affects the application fluency of the service because all game services are unavailable during the downtime update. Summary of the invention

[0004] The embodiments of the present application provide a service processing method, device, electronic device, computer-readable storage medium and computer program product, which can realize online updating of stateful services and improve the application fluency of the services.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] The present application provides a service processing method, including:

[0007] Obtain a first stateful service for updating;

[0008] Performing stateful service registration processing based on the first stateful service to obtain a second stateful service, where the second stateful service corresponds to the first stateful service;

[0009] During the operation of the first stateful service, migrating the coroutine of the first stateful service to the second stateful service to obtain the migrated second stateful service;

[0010] The corresponding coroutine service request is executed through the coroutine of the migrated second stateful service.

[0011] The present application provides a service processing device, including:

[0012] An acquisition module, used to acquire a first stateful service for updating;

[0013] A registration module, configured to perform a stateful service registration process based on the first stateful service to obtain a second stateful service, where the second stateful service corresponds to the first stateful service;

[0014] A migration module, used to migrate the coroutine of the first stateful service to the second stateful service during the operation of the first stateful service, so as to obtain the migrated second stateful service;

[0015] A processing module is used to execute the corresponding coroutine service request through the coroutine of the migrated second stateful service.

[0016] In the above technical solution, the registration module is further used to call the scheduling node based on the stateful service to be registered corresponding to the first stateful service;

[0017] Performing registration verification processing on the stateful service to be registered by the scheduling node;

[0018] When the registration verification process is passed, the stateful service to be registered is registered to obtain the second stateful service.

[0019] In the above technical solution, the registration module is further used to determine the file lock of the stateful service to be registered based on the stateful service to be registered corresponding to the first stateful service;

[0020] The scheduling node is called based on the shared memory message channel corresponding to the file lock.

[0021] In the above technical solution, the registration module is further used to determine a plurality of candidate file locks corresponding to the first stateful service based on the first stateful service;

[0022] Performing occupation processing of the candidate file lock based on the stateful service to be registered corresponding to the first stateful service;

[0023] When the candidate file lock is not occupied, the candidate file lock is used as the file lock of the stateful service to be registered, and the version number of the stateful service to be registered is written into the file lock.

[0024] In the above technical solution, the registration module is also used to determine the registration message of the stateful service to be registered, and the registration message includes the version number of the stateful service to be registered;

[0025] The registration message is sent to the scheduling node through the shared memory message channel corresponding to the file lock.

[0026] In the above technical solution, the registration module is also used to register the stateful service to be registered to the service list when the version number of the stateful service to be registered is greater than the version number of the registered stateful service, obtain the second stateful service, and set the state of the second stateful service to be in coroutine migration.

[0027] In the above technical solution, the migration module is also used to perform the following processing on any coroutine in the first stateful service:

[0028] Migrating the coroutine to the second stateful service without loss, to obtain a new coroutine in the migrated second stateful service, wherein the new coroutine corresponds to the coroutine one-to-one;

[0029] When the number of coroutines in the first stateful service is zero, the state of the migrated second stateful service is set to normal operation, and the state of the first stateful service is set to unavailable state.

[0030] In the above technical solution, the migration module is also used to obtain at least one service request in the task queue of the coroutine;

[0031] Performing data processing on the at least one service request based on the coroutine to obtain a processing result of the service request;

[0032] A new coroutine corresponding to the coroutine is created in the second stateful service, and a processing result of the service request is saved through the new coroutine.

[0033] In the above technical solution, the migration module is further used to set the state of the coroutine of the first stateful service to lossless exit when the first stateful service receives a migration request for the coroutine, and obtain at least one service request in the task queue of the coroutine from the shared memory message channel corresponding to the first stateful service;

[0034] The migration request is used to instruct the first stateful service to perform coroutine migration.

[0035] In the above technical solution, before creating a new coroutine corresponding to the coroutine in the second stateful service, the migration module is also used to send a notification message to the second stateful service when the service request does not exist in the task queue of the coroutine, and the notification message carries the processing result of the service request;

[0036] Based on the notification message, it is determined that an operation of creating a new coroutine corresponding to the coroutine in the second stateful service will be executed.

[0037] In the above technical solution, the migration module is also used to obtain the status data of the coroutine, and the status data includes the scene data of the virtual scene;

[0038] The state data is saved to the new coroutine in the migrated second stateful service.

[0039] In the above technical solution, the processing module is also used to cache the new coroutine service request for the coroutine to the scheduling node during the migration process of the first stateful service;

[0040] After the migration of the first stateful service is completed, the migrated second stateful service obtains the new coroutine service request from the scheduling node and executes the new coroutine service request.

[0041] In the above technical solution, before migrating the coroutine of the first stateful service to the second stateful service, the migration module is further used to determine the number of coroutine service requests;

[0042] When the number of the coroutine service requests is less than the number threshold, it is determined that an operation of migrating the coroutine of the first stateful service to the second stateful service will be performed.

[0043] In the above technical solution, before migrating the coroutine of the first stateful service to the second stateful service, the migration module is further used to determine the network quality during the operation of the first stateful service;

[0044] When the network quality is greater than a quality threshold, it is determined that an operation of migrating the coroutine of the first stateful service to the second stateful service will be performed.

[0045] An embodiment of the present application provides an electronic device for service processing, the electronic device comprising:

[0046] A memory for storing executable instructions;

[0047] The processor is used to implement the service processing method provided in the embodiment of the present application when executing the executable instructions stored in the memory.

[0048] An embodiment of the present application provides a computer-readable storage medium storing executable instructions for causing a processor to execute and implement the service processing method provided by the embodiment of the present application.

[0049] An embodiment of the present application provides a computer program product, including a computer program or instructions, characterized in that when the computer program or instructions are executed by a processor, the service processing method provided by the embodiment of the present application is implemented.

[0050] The embodiments of the present application have the following beneficial effects:

[0051] By registering a second stateful service and migrating the coroutine of the first stateful service to the second stateful service while the first stateful service is running, the function of online updating of the stateful service can be realized, the application fluency of the service can be improved, and the efficiency of service update can be improved by coroutine migration, thereby saving related communication resources and computing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1A-1B It is a schematic diagram of an application mode of the service processing method provided in an embodiment of the present application;

[0053] Figure 2 is a schematic diagram of the structure of an electronic device for service processing provided in an embodiment of the present application;

[0054] Figure 3-Figure 5 It is a flowchart of the service processing method provided in the embodiment of the present application;

[0055] Figure 6 It is a schematic diagram of the architecture of the service processing method provided in the embodiment of the present application;

[0056] Figure 7 It is a flowchart of the service processing method provided in the embodiment of the present application;

[0057] Figure 8 It is a schematic diagram of the service registration process provided by the embodiment of the present application;

[0058] Fig. 9 It is a flowchart of lossless migration of player-oriented coroutines provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0060] In the following description, the terms "first\second" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0061] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0062] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0063] 1) In response to: used to indicate the conditions or states on which the executed operations depend. When the dependent conditions or states are met, one or more operations executed may be in real time or have a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations executed may be executed.

[0064] 2) Client: An application running in a terminal to provide various services, such as a video player client, a game client, etc.

[0065] 3) Virtual scene: A virtual game scene displayed (or provided) when the game program is running on the terminal. The virtual scene can be a simulation environment of the real world, a semi-simulation and semi-fictitious virtual environment, or a purely fictitious virtual environment. The virtual scene can be any one of a two-dimensional virtual scene, a 2.5-dimensional virtual scene, or a three-dimensional virtual scene. The embodiment of the present application does not limit the dimension of the virtual scene. For example, the virtual scene may include the sky, land, ocean, etc. The land may include environmental elements such as deserts and cities, and users can control virtual objects to move in the virtual scene.

[0066] 4) Virtual objects: images of various people and objects that can interact in a virtual scene, or movable objects in a virtual scene. The movable objects can be virtual characters, virtual animals, cartoon characters, etc., such as characters and animals displayed in a virtual scene. The virtual object can be a virtual image in a virtual scene that represents a user. A virtual scene can include multiple virtual objects, each of which has its own shape and volume in the virtual scene and occupies a part of the space in the virtual scene.

[0067] 5) Scene data: characteristic data representing a virtual scene, such as the area of ​​the construction area in the virtual scene, the current architectural style of the virtual scene, etc.; it may also include the location of the virtual building in the virtual scene, and the area occupied by the virtual building, etc.

[0068] 6) Service: including stateful service and stateless service. Stateful service and stateless service are two different service architectures. The difference between them lies in the handling of service status. Service status is the data required for service request, which can be a variable or a data structure. Stateless service does not record service status, and there is no relationship between different requests; while stateful service does record service status, and there is also a relationship between different requests. The judgment basis of stateful service and stateless service is whether two requests from the same initiator have a contextual relationship on the server side.

[0069] For stateless services, all the data that the server can process comes from the information carried by the request. The processing of a single request from the client by a stateless service does not depend on other requests. The information for processing a request is included in the request, such as the request data is transmitted by saving a token through data stored on the user's local terminal (Cookie).

[0070] For stateful services, the server will store data related to the request context, and the requests can be related. For example, in web applications, sessions are often used to maintain the context information of logged-in users. Although the Hyper Text Transfer Protocol (HTTP) is stateless, with the help of sessions, HTTP services can be converted into stateful services.

[0071] 7) Coroutine: A coroutine is not a process or thread, and its execution process is more like a subroutine, or a function call without a return value. A coroutine is a program component, such as cooperative multitasking, iterators, infinite lists, and pipelines. Coroutines are more flexible than subroutines. It should be noted that the coroutine in the embodiment of the present application is a Golang coroutine (also known as a Go coroutine or a go coroutine).

[0072] 8) Golang: Also known as Go, it is a statically strongly typed, compiled, concurrent, and garbage collected programming language. The syntax of Go is similar to that of C, but the declaration of variables is different. Compared with C++, Go does not include features such as enumeration, exception handling, inheritance, generics, assertions, virtual functions, etc., but adds language-level support for features such as slices, concurrency, pipelines, garbage collection, and interfaces. Unlike Java, Go has built-in associative arrays (also called hash tables or dictionaries).

[0073] 9) File Lock: Also known as file renewal lock, a file locking mechanism that forces access to computer files to be limited to one user or process at any given time, preventing malicious updates through file locks.

[0074] 10) Shared memory message channel: a communication channel between multiple processes. This channel is used for communication between multiple processes. In fact, multiple programs can also transmit information through the shared memory message channel. Among them, shared memory refers to a large-capacity memory that can be accessed by different central processing units (CPUs) in a multi-processor computer system.

[0075] Games have various stateful services (also called stateful game services). Stateful services can effectively reduce the frequency of access to the database and improve the throughput of the server by caching player status data, such as player database data. For example, the lobby service is a stateful service in the game. Most of the functions that players can participate in activities, complete tasks, and upgrade heroes (a virtual object) on the game interface are provided by the lobby service.

[0076] With the vigorous development of the mobile game industry in recent years, in order to cope with the problem of players consuming game content too quickly, further attract players and retain players, the game side needs to continuously update game content. In addition, as the speed of game content updates accelerates, it often brings instability to game service functions. For example, if the self-test is not careful, the function will appear abnormal, thus affecting the player experience. Therefore, how to stably update the game content without affecting the online player experience, and how to quickly update and repair when encountering external network function abnormalities, is of great value in actual game operations. Among them, the update of stateful services is the main carrier of game services, and its online update technology has always been the focus and difficulty in the game background design.

[0077] In the related technology, all players are directly kicked out through downtime updates to update services. This method seriously affects the player experience because all services are unavailable during the downtime update. Grayscale release is adopted to gradually update services, but some compatibility issues need to be dealt with, such as special processing of certain business logics when the new and old versions coexist. In addition, the update process requires some redundant grayscale machine resources, and grayscale release is time-consuming.

[0078] In order to solve the above problems, the embodiments of the present application provide a service processing method, device, electronic device, computer-readable storage medium and computer program product, which can realize online updating of stateful services and improve the application fluency of services. In order to facilitate easier understanding of the service processing method provided by the embodiments of the present application, the exemplary implementation scenario of the service processing method provided by the embodiments of the present application is first described. The virtual scene (implemented by stateful service) in the service processing method provided by the embodiments of the present application can be completely based on terminal output, or based on the coordinated output of the terminal and the server.

[0079] In some embodiments, the virtual scene can be an environment for game characters to interact. For example, it can be an environment for game characters to fight in the virtual scene. By controlling the actions of the game characters, both parties can interact in the virtual scene, allowing users to relieve life stress during the game.

[0080] In one implementation scenario, see Figure 1A , Figure 1A It is a schematic diagram of the application mode of the service processing method provided in the embodiment of the present application, which is suitable for some application modes that completely rely on the graphics processing hardware computing power of the terminal 400 to complete the relevant data calculation of the virtual scene 100, such as stand-alone / offline mode games, and the output of the virtual scene is completed through various types of terminals 400 such as smart phones, tablets and virtual reality / augmented reality devices.

[0081] As an example, types of graphics processing hardware include a central processing unit (CPU) and a graphics processing unit (GPU).

[0082] When forming a visual perception of the virtual scene 100, the terminal 400 calculates the data required for display through the graphics computing hardware, and completes the loading, parsing and rendering of the display data, and outputs video frames that can form a visual perception of the virtual scene through the graphics output hardware, for example, presenting two-dimensional video frames on the display screen of a smartphone, or projecting video frames to achieve a three-dimensional display effect on the lenses of augmented reality / virtual reality glasses; in addition, in order to enrich the perception effect, the terminal 400 can also use different hardware to form one or more of auditory perception, tactile perception, motion perception and taste perception.

[0083] As an example, a client 410 (e.g., a stand-alone game application) is running on the terminal 400. During the operation of the client 410, a virtual scene including role-playing is output (implemented by running a stateful service (also called a stateful game service). In the stateful service, there is a coroutine for each player to process player requests, that is, one coroutine corresponds to one player). The virtual scene can be an environment for game characters to interact, such as a plain, a street, a valley, etc. for game characters to fight against each other. Taking the first-person perspective display of the virtual scene 100 as an example, the virtual scene 100 is displayed The virtual object 110 is shown. The virtual object 110 can be a game character (corresponding to a coroutine in a stateful service) controlled by a user (or a player), which will operate in the virtual scene in response to the real user's operation on buttons (including joystick buttons, attack buttons, defense buttons, etc.). For example, when the real user moves the joystick button to the left, the virtual object will move to the left in the virtual scene, and can also remain still, jump, and use various functions (such as skills and props); the virtual object 110 can also be an artificial intelligence (AI) trained to fight in a virtual scene; the virtual object 110 can also be a non-user character (NPC, Non-Player Character) set in the virtual scene interaction; the virtual object 110 can also be an inactive object or an active object in the virtual scene 100.

[0084] For example, during the operation of a stateful game service, a virtual object 110 is displayed in a virtual scene 100, and a player controls the virtual object to complete a task in the virtual scene. However, the stateful game service is updated, and a new stateful game service is registered through the service processing method of an embodiment of the present application. The new stateful service corresponds to the stateful service before the update. During the operation of the stateful service, the coroutine of the stateful service is migrated to the new stateful service to obtain the migrated new stateful service. The corresponding coroutine service request is executed through the coroutine of the migrated new second stateful service, so that the virtual object 110 is displayed in the virtual scene 100 through the migrated new second stateful service, and the player controls the virtual object to complete the task in the virtual scene.

[0085] In another implementation scenario, see Figure 1B , Figure 1B It is a schematic diagram of an application mode of the service processing method provided in an embodiment of the present application, which is applied to a terminal 400 and a server 200, and is suitable for an application mode that relies on the computing power of the server 200 to complete virtual scene calculations and output virtual scenes at the terminal 400.

[0086] Taking the visual perception of the virtual scene 100 as an example, the server 200 calculates the virtual scene related display data (such as scene data) and sends it to the terminal 400 through the network 300. The terminal 400 relies on the graphics computing hardware to complete the loading, parsing and rendering of the display data, and relies on the graphics output hardware to output the virtual scene to form a visual perception. For example, a two-dimensional video frame can be presented on the display screen of a smartphone, or a video frame with a three-dimensional display effect can be projected on the lenses of augmented reality / virtual reality glasses. For the perception of the form of the virtual scene, it can be understood that the corresponding hardware output of the terminal 400 can be used, such as using a microphone to form auditory perception, using a vibrator to form tactile perception, and so on.

[0087] As an example, a client 410 (e.g., a network version of a game application) is running on the terminal 400, and the game interaction with other users is performed by connecting to the server 200 (e.g., a game server). The terminal 400 outputs the virtual scene of the client 410 (implemented by running a stateful service (also called a stateful game service). In a stateful service, there is a coroutine for each player to process the player's request, that is, one coroutine corresponds to one player). Taking the first-person perspective display of the virtual scene 100 as an example, a virtual object 110 is displayed in the virtual scene 100. The virtual object 110 can be a game character (corresponding to a stateful service) controlled by a user (or player). The virtual object 110 is a coroutine in a dynamic service, which will operate in the virtual scene in response to the real user's operation on buttons (including joystick buttons, attack buttons, defense buttons, etc.). For example, when the real user moves the joystick button to the left, the virtual object will move to the left in the virtual scene, and can also remain still, jump, and use various functions (such as skills and props); the virtual object 110 can also be an artificial intelligence (AI, Artificial Intelligence) set in a virtual scene battle through training; the virtual object 110 can also be a non-user character (NPC, Non-Player Character) set in the virtual scene interaction; the virtual object 110 can also be an inactive object or an active object in the virtual scene 100.

[0088] For example, during the operation of a stateful game service, a virtual object 110 is displayed in a virtual scene 100, and a player controls the virtual object to complete a task in the virtual scene. However, the stateful game service is updated, and a new stateful game service is registered through the service processing method of an embodiment of the present application. The new stateful service corresponds to the stateful service before the update. During the operation of the stateful service, the coroutine of the stateful service is migrated to the new stateful service to obtain the migrated new stateful service. The corresponding coroutine service request is executed through the coroutine of the migrated new second stateful service, so that the virtual object 110 is displayed in the virtual scene 100 through the migrated new second stateful service, and the player controls the virtual object to complete the task in the virtual scene.

[0089] In some embodiments, the terminal 400 can implement the service processing method provided by the embodiments of the present application by running a computer program. For example, the computer program can be a native program or software module in the operating system; it can be a native application (APP, APPlication), that is, a program that needs to be installed in the operating system to run, such as a dress-up game APP (that is, the above-mentioned client 410); it can also be a small program, that is, a program that can be run only by downloading it to a browser environment; it can also be a game small program that can be embedded in any APP. In short, the above-mentioned computer program can be an application, module or plug-in in any form.

[0090] Taking a computer program as an application program as an example, in actual implementation, the terminal 400 installs and runs an application program that supports a virtual scene. The application program can be any one of a first-person shooting game (FPS), a third-person shooting game, a virtual reality application program, a three-dimensional map program, or a multiplayer gunfight survival game. The user uses the terminal 400 to operate a virtual object in the virtual scene to perform an activity, which includes but is not limited to: adjusting body posture, crawling, walking, running, riding, jumping, driving, picking up, shooting, attacking, throwing, and building a virtual building. Indicatively, the virtual object can be a virtual character, such as a simulated character or an anime character.

[0091] In some embodiments, the embodiments of the present application can also be implemented with the aid of cloud technology. Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or a local area network to achieve data calculation, storage, processing, and sharing.

[0092] Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, and application technology based on the cloud computing business model. It can form a resource pool that can be used on demand and is flexible and convenient. Cloud computing technology will become an important support. The background services of the technical network system require a large amount of computing and storage resources.

[0093] For example, Figure 1B The server 200 in the example may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal 400 may be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited thereto. The terminal 400 and the server 200 may be directly or indirectly connected via wired or wireless communication, which is not limited in the embodiments of the present application.

[0094] See also Figure 2 , Figure 2 2 is a schematic diagram of the structure of an electronic device for service processing provided in an embodiment of the present application, and is described by taking the electronic device as a server 200 as an example. Figure 2 The electronic device 400 shown includes: at least one processor 420, a memory 460, at least one network interface 430 and a user interface 440. The various components in the terminal 400 are coupled together via a bus system 450. It is understood that the bus system 450 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 450 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 450 is not shown in FIG. Figure 2 Various buses are labeled as bus system 450 .

[0095] The processor 420 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0096] The user interface 440 includes one or more output devices 441 that enable presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 440 also includes one or more input devices 442, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0097] The memory 460 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, etc. The memory 460 may optionally include one or more storage devices that are physically remote from the processor 420.

[0098] The memory 460 includes a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 460 described in the embodiments of the present application is intended to include any suitable type of memory.

[0099] In some embodiments, memory 460 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplarily described below.

[0100] Operating system 461, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0101] A network communication module 462, for reaching other computing devices via one or more (wired or wireless) network interfaces 430, exemplary network interfaces 430 include: Bluetooth, Wireless Compatibility Authentication (WiFi), and Universal Serial Bus (USB);

[0102] a presentation module 463 for enabling presentation of information via one or more output devices 441 (e.g., display screen, speaker, etc.) associated with the user interface 440 (e.g., a user interface for operating peripherals and displaying content and information);

[0103] The input processing module 464 is used to detect one or more user inputs or interactions from one of the one or more input devices 442 and translate the detected inputs or interactions.

[0104] In some embodiments, the service processing device provided in the embodiments of the present application may be implemented in software. Figure 2 A service processing device 465 stored in the memory 460 is shown, which can be software in the form of programs and plug-ins, including the following software modules: an acquisition module 4651, a registration module 4652, a migration module 4653, and a processing module 4654. These modules are logical and can therefore be arbitrarily combined or further split according to the functions implemented.

[0105] In other embodiments, the service processing device provided in the embodiments of the present application can be implemented in hardware. As an example, the service processing device provided in the embodiments of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the service processing method provided in the embodiments of the present application. For example, the processor in the form of a hardware decoding processor can adopt one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs) or other electronic components.

[0106] The service processing method provided by the embodiment of the present application will be described in detail below with reference to the accompanying drawings. Figure 1A The terminal 400 in the embodiment can be executed separately or by Figure 1B The terminal 400 and the server 200 cooperate to execute.

[0107] Below, by Figure 1A The terminal 400 in the embodiment of the present application independently executes the service processing method provided in the embodiment of the present application as an example. Figure 3 , Figure 3 is a flow chart of the service processing method provided in the embodiment of the present application, which will be combined with Figure 3 The steps shown are explained.

[0108] It should be noted that Figure 3 The method shown can be executed by various forms of computer programs running on the terminal 400, and is not limited to the above-mentioned client 410, but can also be the above-mentioned operating system 461, software modules and scripts. Therefore, the client should not be regarded as a limitation on the embodiments of the present application.

[0109] In step 101, a first stateful service for updating is obtained.

[0110] For example, in order to attract and retain players, the game side needs to continuously update the game content. In addition, as the speed of game content updates accelerates, stateful services need to be continuously updated. When the function of the current stateful service in the game needs to be updated, the current stateful service is obtained and used as the first stateful service for updating (ie, the old stateful service). It should be noted that different stateful services have different service functions. For example, the lobby service in the game is used to provide players with functions such as participating in activities, completing tasks, and upgrading heroes on the game interface; the friend service in the game is used to provide communication functions such as chat.

[0111] In step 102, a stateful service registration process is performed based on the first stateful service to obtain a second stateful service, where the second stateful service corresponds to the first stateful service.

[0112] For example, after determining the first stateful service for updating, it is necessary to register a second stateful service corresponding to the first stateful service, that is, the first stateful service is the old stateful service that needs to be updated and replaced, and the second stateful service is the new stateful service generated after the update. After registering the second stateful service, the coroutine migration in the subsequent stateful service is performed to realize the function of updating the stateful service online, without the need for downtime update, so as to improve the application fluency of the service.

[0113] See also Figure 4 , Figure 4 is a flow chart of a service processing method provided in an embodiment of the present application, Figure 4 Show Figure 3 Step 102 can be implemented through steps 1021-1023: in step 1021, the scheduling node is called based on the stateful service to be registered corresponding to the first stateful service; in step 1022, the registration verification process is performed on the stateful service to be registered through the scheduling node; in step 1023, when the registration verification process passes, the stateful service to be registered is registered to obtain a second stateful service.

[0114] For example, the stateful service to be registered corresponding to the first stateful service (i.e., the second stateful service to be registered) starts the service and calls the scheduling node. The registration verification is performed on the stateful service to be registered through the scheduling node. When the registration verification passes, the stateful service to be registered is registered through the scheduling node, i.e., the second stateful service is registered successfully, and the coroutine-based migration processing of the first stateful service is about to be performed; when the registration verification fails, the stateful service to be registered is not registered, i.e., the registration of the second stateful service fails.

[0115] In some embodiments, calling a scheduling node based on a stateful service to be registered corresponding to a first stateful service includes: determining a file lock of the stateful service to be registered based on the stateful service to be registered corresponding to the first stateful service; and calling the scheduling node based on a shared memory message channel corresponding to the file lock.

[0116] For example, before registering the second stateful service through the scheduling node, you must first obtain ownership of the shared memory message pipe through the file renewal lock, and then complete the registration of the second stateful service by transmitting the registration message to the shared memory message pipe. The file renewal lock can solve the problem of distinguishing between the first stateful service and the second stateful service.

[0117] It should be noted that there are 2 pairs of 4 shared memory message channels between the scheduling node and each stateful service (including new stateful services and old stateful services), and the communication between the stateful service and the scheduling node must be through the exclusive use of one pair of shared memory message channels. Since the new stateful service and the old stateful service need to run simultaneously during the migration process, in order to distinguish between the new stateful service and the old stateful service, it is necessary to make a distinction in configuration. Once a distinction is made in configuration, it is to make a distinction in the service process identifier (ID), that is, the service process reads different configurations. Once a distinction is made in the process ID, it is bound to cause a burden on the daily operation of operation and maintenance. In response to this problem, the embodiment of the present application solves the problem of distinguishing between new stateful services and old stateful services by introducing a file renewal lock (referred to as file lock) to reduce the amount of maintenance calculations.

[0118] It should be noted that when the scheduling node, the first stateful service and the second stateful service are located in the same electronic device, information is transmitted between the scheduling node and each stateful service through a shared memory message channel; when the scheduling node, the first stateful service and the second stateful service are located in different electronic devices, information is transmitted between the scheduling node and each stateful service through a message middleware (a supporting software system based on queue and message passing technology that provides synchronous or asynchronous, reliable message transmission for application systems in a network environment).

[0119] In some embodiments, based on the stateful service to be registered corresponding to the first stateful service, a file lock of the stateful service to be registered is determined, including: based on the first stateful service, multiple candidate file locks corresponding to the first stateful service are determined; based on the stateful service to be registered corresponding to the first stateful service, occupation processing of the candidate file locks is performed; when the candidate file lock is not occupied, the candidate file lock is used as the file lock of the stateful service to be registered, and the version number of the stateful service to be registered is written in the file lock.

[0120] like Figure 8As shown in the figure, before registering the service, the new stateful service and the old stateful service must first occupy one of the files to monopolize a pair of shared memory message pipes (shmpipe), where the file name is the shared memory message pipe ID. The file content in the file lock includes two parts: one is the version number of the stateful service that owns the ownership, where the version number can use the process compilation timestamp; the other is the expiration timestamp of the current stateful service renewing the file lock.

[0121] like Figure 8 As shown, based on the first stateful service (ie Figure 8 ), determine multiple candidate file locks corresponding to the first stateful service (i.e. Figure 8 ), the stateful service to be registered corresponding to the first stateful service (the new stateful service to be registered) sends an ownership request to file 1 (shmpipe1) to determine that file 1 has been occupied by the old stateful service, then the stateful service to be registered corresponding to the first stateful service sends an ownership request to file 2 (shmpipe2) to determine that file 2 is not occupied, then the stateful service to be registered corresponding to the first stateful service occupies file 2, and writes the version number of the stateful service to be registered in file 2 to indicate that file 2 is occupied by the stateful service to be registered.

[0122] In some embodiments, calling a scheduling node based on a shared memory message channel corresponding to a file lock includes: determining a registration message of a stateful service to be registered, the registration message including a version number of the stateful service to be registered; and sending the registration message to the scheduling node through a shared memory message channel corresponding to the file lock.

[0123] For example, after the file lock of the stateful service to be registered is determined, a registration message of the stateful service to be registered is sent based on the shared memory message channel corresponding to the file lock, so as to register the stateful service through the shared memory message channel.

[0124] In some embodiments, when the registration verification process passes, the stateful service to be registered is registered to obtain a second stateful service, including: when the version number of the stateful service to be registered is greater than the version number of the registered stateful service, the stateful service to be registered is registered to the service list to obtain the second stateful service, and the state of the second stateful service is set to be in coroutine migration.

[0125] For example, after the file lock of the stateful service to be registered is determined, a registration message of the stateful service to be registered is sent based on the shared memory message channel corresponding to the file lock. When the version number of the stateful service to be registered in the registration message is greater than the version number of the registered stateful service, it means that the registration verification is passed and the stateful service to be registered can be registered. The stateful service to be registered is then registered to the service list, and the registered second stateful service is obtained. The status of the second stateful service is set to be in coroutine migration to indicate that coroutine migration is required.

[0126] In step 103, during the operation of the first stateful service, the coroutine of the first stateful service is migrated to the second stateful service to obtain the migrated second stateful service.

[0127] For example, after registering the second stateful service, the coroutine of the first stateful service is migrated to the second stateful service during the operation of the first stateful service to implement the function of online updating of the stateful service without the need for downtime updates, thereby improving the application fluency of the service. Compared with the grayscale release method, the efficiency of service updates is improved, and no additional computer resources are required, thereby saving related communication resources and computing resources.

[0128] See also Figure 5 , Figure 5 is a flow chart of a service processing method provided in an embodiment of the present application, Figure 5 Show Figure 3 Step 103 can be implemented through steps 1031-1032: in step 1031, the following processing is performed for any coroutine in the first stateful service: the coroutine is losslessly migrated to the second stateful service to obtain a new coroutine in the migrated second stateful service, and the new coroutine corresponds to the coroutine one-to-one; in step 1032, when the number of coroutines in the first stateful service is zero, the state of the migrated second stateful service is set to normal operation, and the state of the first stateful service is set to unavailable state.

[0129] For example, the following processing is performed for coroutine 1 in the first stateful service: Coroutine 1 is losslessly migrated to the second stateful service to obtain a new coroutine in the migrated second stateful service, the new coroutine corresponds to coroutine 1, and coroutine 1 in the first stateful service is set to losslessly exit to indicate that coroutine 1 has exited the first stateful service. When all coroutines in the first stateful service are migrated to the second stateful service, the state of the migrated second stateful service is set to normal operation, and the state of the first stateful service is set to unavailable.

[0130] In some embodiments, a coroutine is losslessly migrated to a second stateful service to obtain a new coroutine in the migrated second stateful service, including: obtaining at least one service request in the task queue of the coroutine; performing data processing on at least one service request based on the coroutine to obtain a processing result of the service request; creating a new coroutine corresponding to the coroutine in the second stateful service, and saving the processing result of the service request through the new coroutine.

[0131] For example, for coroutine 1 in the first stateful service, at least one service request in the task queue of coroutine 1 is obtained from the shared memory message channel corresponding to the first stateful service, and at least one service request is processed by coroutine 1 to obtain the processing result of the service request (i.e., key data). That is, when coroutine 1 has processed all service requests in the task queue, a new coroutine corresponding to coroutine 1 is created in the second stateful service, and the processing result of the service request is saved by the new coroutine so that the new coroutine can continue to process subsequent requests to avoid information interruption.

[0132] In some embodiments, obtaining at least one service request in the task queue of the coroutine includes: when a first stateful service receives a migration request for the coroutine, setting the state of the coroutine of the first stateful service to lossless exit, and obtaining at least one service request in the task queue of the coroutine from a shared memory message channel corresponding to the first stateful service; wherein the migration request is used to instruct the first stateful service to perform coroutine migration.

[0133] For example, Figure 7 As shown, after the scheduling node registers the second stateful service (new stateful service), it sends a notification message to the first stateful service (old stateful service) to notify the first stateful service to start the coroutine migration. When the first stateful service receives a migration request for the coroutine, the state of the coroutine of the first stateful service is set to lossless exit, and at least one service request in the task queue of the coroutine is obtained from the shared memory message channel corresponding to the first stateful service. The first stateful service processes the remaining coroutine messages (also known as service requests or player requests). After the first stateful service processes the remaining coroutine messages, it sends a coroutine migration success message to the scheduling node to indicate that the coroutine migration of the first stateful service is successful and can log in to the second stateful service.

[0134] In some embodiments, before creating a new coroutine corresponding to the coroutine in the second stateful service, when there is no service request in the task queue of the coroutine, a notification message is sent to the second stateful service, and the notification message carries the processing result of the service request; based on the notification message, it is determined that an operation of creating a new coroutine corresponding to the coroutine in the second stateful service will be executed.

[0135] For example, Figure 7As shown, the first stateful service (old stateful service) processes the remaining coroutine messages (also known as service requests or player requests). After the first stateful service has processed the remaining coroutine messages (i.e., there are no service requests in the coroutine's task queue), the scheduling node sends a coroutine migration success message to the second stateful service (new stateful service), notifying the first stateful service that the coroutine migration is successful and that the second stateful service can be logged in. The scheduling node sends a coroutine migration success message to the second stateful service. After receiving the coroutine migration success message, the second stateful service performs coroutine initialization to create a new coroutine corresponding to the coroutine.

[0136] In some embodiments, state data of the coroutine is obtained, the state data including scene data of the virtual scene; and the state data is saved to a new coroutine in the migrated second stateful service.

[0137] For example, during the migration of the first stateful service, state data (such as scene data needed during the game) is obtained and saved to a new coroutine in the migrated second stateful service to avoid data omissions that may cause the game to crash.

[0138] In some embodiments, before migrating a coroutine of a first stateful service to a second stateful service, the number of coroutine service requests is determined; when the number of coroutine service requests is less than a quantity threshold, it is determined that an operation of migrating the coroutine of the first stateful service to the second stateful service will be performed.

[0139] For example, although the service processing method provided in the embodiment of the present application has a fast migration speed, has little impact on players, and does not need to wait for a small number of online users to update, and has good real-time performance, in order to avoid unpredictable system errors, the migration operation can still be triggered only when there are fewer service requests, thereby reducing the burden of migration as much as possible.

[0140] In some embodiments, before migrating the coroutine of the first stateful service to the second stateful service, the network quality during the operation of the first stateful service is determined; when the network quality is greater than a quality threshold, it is determined that an operation of migrating the coroutine of the first stateful service to the second stateful service will be executed.

[0141] For example, although the service processing method provided in the embodiment of the present application has a fast migration speed, has little impact on players, and does not need to wait until there are few online users to update, and has good real-time performance, in order to avoid unpredictable system errors, the migration operation can still be triggered only when the network quality is good, so as to improve the security and speed of migration as much as possible.

[0142] In step 104, the corresponding coroutine service request is executed by the coroutine of the migrated second stateful service.

[0143] For example, after the coroutine migration is successful, the first stateful service will be unavailable, and the corresponding coroutine service request is subsequently executed through the coroutine of the migrated second stateful service to process the coroutine service request through the updated stateful service.

[0144] In some embodiments, during the migration of the first stateful service, a new coroutine service request for the coroutine is cached to the scheduling node; after the migration of the first stateful service is completed, the migrated second stateful service obtains the new coroutine service request from the scheduling node and executes the new coroutine service request.

[0145] For example, before the first stateful service is migrated, the old coroutine service request for the coroutine is added to the task queue of the shared memory message channel, and during the migration of the first stateful service, the new coroutine service request for the coroutine is cached to the scheduling node. After the migration of the first stateful service is completed, the migrated second stateful service obtains the new coroutine service request from the scheduling node and executes the new coroutine service request. Thus, by caching the new coroutine service request first and then executing the new coroutine service request after the migration is completed, the amount of calculation in the migration process is avoided and the migration speed is improved.

[0146] The following is an explanation of an exemplary application of the embodiments of the present application in a practical application scenario.

[0147] The embodiments of the present application can be applied to service update scenarios of various games, such as competitive games, racing games, dress-up games, etc.

[0148] The following is an example of a game using a virtual scene:

[0149] With the booming development of the mobile game industry in recent years, in order to deal with the problem of players consuming game content too quickly and to further attract and retain players, the game side needs to continuously update game content. Among them, the update of stateful services is the main carrier of game services, and its online update technology has always been the focus and difficulty in the design of game backgrounds.

[0150] In the related technology, all players are directly kicked out through downtime updates to update services. This method seriously affects the player experience because all services are unavailable during the downtime update. Grayscale release is adopted to gradually update services, but some compatibility issues need to be dealt with, such as special processing of certain business logics when the new and old versions coexist. In addition, the update process requires some redundant grayscale machine resources, and grayscale release is time-consuming.

[0151] In order to solve the above problems, an embodiment of the present application provides a stateful game background service update method based on Golang coroutine migration (i.e., a service processing method). This method uses Golang as the programming language, has high real-time performance, has little impact on players, and is friendly to operation and maintenance. It is suitable for online updates of most stateful game services.

[0152] It should be noted that the Golang language's rich community ecology and excellent modern programming language design have attracted many developers and have been widely used in various Internet fields. In particular, the language-level support for coroutines has greatly reduced the threshold for writing concurrent programs and greatly improved development efficiency.

[0153] The following specifically describes the stateful game background service update method based on Golang coroutine migration provided by the embodiment of the present application:

[0154] like Figure 6 As shown in the framework diagram, the player's status data is divided into login status data and game process data, among which the player's login status data is maintained on the scheduling node, and the back-end process will cache the player's status data during the online process. The scheduling node communicates with the back-end stateful service (including old stateful services and new stateful services) through a shared memory message channel (shmpipe, Shared Memory Message PIPE). The service request of the game client is first sent to the scheduling node, which routes the service request to the back-end stateful service. After the back-end stateful server processes it, the response data will be returned to the player via the scheduling node. The back-end stateful service will set a Golang coroutine for each player to process the player's service request and maintain the life cycle of the player object.

[0155] like Figure 6 As shown, the go1 coroutine and go2 coroutine in the old stateful service are the coroutines that have been migrated from the old stateful service, the go3 coroutine, go4 coroutine and go5 coroutine in the old stateful service are the coroutines that are being migrated from the old stateful service, the go1 coroutine and go2 coroutine in the new stateful service are the coroutines that have been migrated from the new stateful service, and the go6 coroutine and go7 coroutine in the new stateful service are the new coroutines generated during the migration process (corresponding to the new players generated during the migration process).

[0156] like Figure 7 As shown, the stateful game background service update method based on Golang coroutine migration provided by the embodiment of the present application includes four steps, namely service registration, lossless migration of player-oriented coroutines (i.e., Golang coroutines), exit of old stateful services, and scheduling node update status. The four steps are specifically described below:

[0157] Step 1, service registration: Before a new stateful service (also called a new stateful service) registers its service with the scheduling node, it must first obtain ownership of the shared memory message pipe through the file renewal lock, and then complete the registration of the new stateful service by transmitting a registration message to the shared memory message pipe.

[0158] like Figure 7 As shown, the service registration step specifically includes the following steps:

[0159] Step 11: The old stateful service sends a heartbeat request to the scheduling node.

[0160] Step 12: After receiving the heartbeat request, the scheduling node sends a heartbeat response to the old stateful service.

[0161] Among them, the heartbeat request is a data packet sent to the scheduling node at regular intervals, and the heartbeat response of the scheduling node is used to determine whether the communication link between the old stateful service and the scheduling node is connected.

[0162] Step 13: Start the new stateful service.

[0163] Step 14: The new stateful service sends a registration request (also called a registration message) of the new stateful service to the scheduling node.

[0164] Step 15: The scheduling node sends a registration response of the new stateful service to the new stateful service.

[0165] Step 16: The scheduling node sets the new stateful service to be available.

[0166] Among them, when the scheduling node determines that the registration request of the new stateful service is legal, it will return a successful registration response to the new stateful service and set the new stateful service to be available, indicating that it is necessary to enter the coroutine-based migration process.

[0167] Step 2: Lossless migration for player coroutines: When the scheduling node receives a new service registration, it starts driving the player coroutines on the old stateful service into a coroutine-based migration process in units of coroutines.

[0168] like Figure 7 As shown, the lossless migration steps for player coroutines specifically include the following steps:

[0169] Step 21: The scheduling node sends a notification message to the old stateful service to notify the old stateful service to start the coroutine migration.

[0170] Among them, the notification message is used to instruct the old stateful service to perform coroutine migration.

[0171] Step 22: The scheduling node caches player requests sent to the coroutine during the migration process.

[0172] It should be noted that during the migration process, new player requests may be generated. These player requests will not be sent to the coroutine of the old stateful service, but will be cached by the scheduling node. After the migration is completed, they will be processed by the coroutine of the new stateful service.

[0173] Step 23: The old stateful service processes the remaining messages of the coroutine (i.e., player requests).

[0174] Step 24: After the old stateful service processes the remaining coroutine messages, it sends a coroutine migration success message to the scheduling node.

[0175] The coroutine migration success message is used to indicate that the coroutine migration of the old stateful service is successful and the new stateful service can be logged in.

[0176] Step 25: The scheduling node sends a coroutine migration success message to the new stateful service.

[0177] The coroutine migration success message is used to indicate that the coroutine migration of the old stateful service is successful, and indicates logging into the new stateful service.

[0178] Step 26: The scheduling node sends the player request to the coroutine cached during the migration process to the new stateful service.

[0179] Step 27: The new stateful service initializes the coroutine and starts processing cached messages (i.e., cached player requests sent to the coroutine).

[0180] Step 3: Exit the old stateful service: After the old stateful service starts the coroutine migration, it keeps checking the number of player coroutines. When the number of player coroutines drops to 0, it automatically exits the process.

[0181] like Figure 7 As shown, the old stateful service exit procedure specifically includes the following steps:

[0182] Step 31: The old stateful service determines whether all coroutines have been successfully migrated.

[0183] Step 32: When all coroutines have been successfully migrated, the old stateful service automatically exits the process.

[0184] Step 4. Schedule node status update: When all player coroutines are successfully migrated, change the service status to normal operation and set the old stateful service to unavailable.

[0185] like Figure 7 As shown, the scheduling node status update step specifically includes the following steps:

[0186] Step 41: The scheduling node sets the old stateful service to be unavailable.

[0187] Step 42: The new stateful service sends a heartbeat request to the scheduling node.

[0188] Step 43: After receiving the heartbeat request, the scheduling node sends a heartbeat response to the new stateful service.

[0189] The heartbeat request is a data packet sent to the scheduling node at regular intervals, and the heartbeat response of the scheduling node is used to determine whether the communication link between the new stateful service and the scheduling node is connected.

[0190] It should be noted that there are 2 pairs of 4 shared memory message channels between the scheduling node and each back-end stateful service (including new stateful services and old stateful services). The communication between the back-end stateful services and the scheduling node must be through the exclusive use of one pair of shared memory message channels. Since the new stateful service and the old stateful service need to run simultaneously during the migration process, in order to distinguish between the new stateful service and the old stateful service, it is necessary to make a distinction in configuration. Once the configuration is distinguished, it is to make a distinction on the service process identifier (ID), that is, the service process reads different configurations. Once the distinction is made on the process ID, it is bound to cause a burden on the daily operation of operation and maintenance. In response to this problem, the embodiment of the present application solves the problem of distinguishing between new stateful services and old stateful services by introducing a file renewal lock (referred to as file lock). There will be 2 files between each stateful service process and the scheduling node, corresponding to 2 pairs of shared memory message channels respectively. The file renewal lock is specifically described below:

[0191] like Figure 8 As shown in the figure, before registering the service, the new stateful service and the old stateful service must first occupy one of the files to monopolize a pair of shared memory message pipes (shmpipe), where the file name is the shared memory message pipe ID. The file content in the file lock includes two parts: one is the version number of the stateful service that owns the ownership, where the version number can use the process compilation timestamp; the other is the expiration timestamp of the current stateful service renewing the file lock.

[0192] like Figure 8 As shown, the service registration steps based on the file renewal lock specifically include the following steps:

[0193] Step 11. The new stateful service sends an ownership request to file1 (shmpipe1).

[0194] Step 12: The new stateful service determines that file 1 is already occupied.

[0195] Before the new stateful service occupies file 1, file 1 has been occupied by the old stateful service, and shmpipe1 has been occupied by the old stateful service.

[0196] Step 13. The new stateful service sends an ownership request to file 2 (shmpipe2).

[0197] Step 14: The new stateful service determines that file 2 is not occupied, and file 2 is occupied successfully.

[0198] Before the new stateful service occupies file 2, file 2 is not occupied and is in an idle state. Then the new stateful service occupies file 2 successfully, and shmpipe2 is occupied by the new stateful service.

[0199] Step 15: The scheduling node initiates registration with the new stateful service through shmpipe2.

[0200] It should be noted that stateful service startup (such as Figure 8 After the new stateful service in the file is created, the system function will be called in turn to try to occupy the file lock. If the file is not occupied, the file ownership of the file will be occupied, and the version number of the occupant (that is, the version number of the stateful service) and the file lock expiration timestamp will be written. When the exclusive file is successfully occupied, a Golang coroutine needs to be created to regularly update the expiration timestamp of the file. For example, the time interval for regularly updating the expiration timestamp of the file is 30 seconds, and the file lock expiration timestamp will be set to the current timestamp plus 60 seconds.

[0201] After the file ownership is successfully acquired, the new stateful service will send a registration message to the corresponding shared memory message channel to the scheduling node to register the stateful service. In order to ensure that the coroutine migration is performed only when the function of the new stateful service changes, the calling node will compare the version number in the registration message with the version number of the currently registered stateful service. If the version number in the registration message is greater than the version number of the currently registered stateful service, the registration message is determined to be legal, the new stateful service is registered to the service list, and the new stateful service is set to be migrated.

[0202] It should be noted that after each player successfully logs in, a Golang coroutine will be created on the backend stateful service to process the player's messages. The stateful service and the coroutine are in a one-to-many relationship. There is a task queue in the coroutine to store the messages sent to the player by the scheduling node. The coroutine completes the corresponding function by continuously processing the messages (player requests) in the task queue.

[0203] like Fig. 9 As shown in the figure, taking coroutine 1 as an example, the steps for lossless migration of player coroutines are described in detail:

[0204] Step 21: The scheduling node sends a notification message to the old stateful service to notify the old stateful service to start the migration of coroutine 1.

[0205] The notification message is used to instruct the old stateful service to migrate coroutine 1.

[0206] Step 22: The scheduling node caches the player request sent to coroutine 1 during the migration process.

[0207] It should be noted that during the migration process, additional player requests for coroutine 1 may be generated. These player requests will not be sent to coroutine 1 of the old stateful service, but will be cached by the scheduling node. After the migration of coroutine 1 is completed, they will be processed by coroutine 1 of the new stateful service.

[0208] Step 23: The old stateful service processes the remaining messages (i.e., player requests) in the task queue of coroutine 1.

[0209] Step 24: After the old stateful service processes the remaining messages of coroutine 1, coroutine 1 in the old stateful service exits without loss, and sends a coroutine 1 migration success message to the scheduling node.

[0210] The Coroutine 1 migration success message is used to indicate that the Coroutine 1 of the old stateful service has been successfully migrated and can log in to the new stateful service.

[0211] Step 25: The scheduling node sends a message indicating that coroutine 1 has been successfully migrated to the new stateful service.

[0212] The Coroutine 1 migration success message is used to indicate that the Coroutine 1 migration of the old stateful service is successful, indicating logging into the new stateful service.

[0213] Step 26: The scheduling node sends the player request to coroutine 1 cached during the migration process to the new stateful service.

[0214] Step 27: The new stateful service creates a new coroutine (corresponding to coroutine 1) and starts processing cached messages (i.e., cached player requests sent to coroutine 1).

[0215] It should be noted that when the scheduling node enters the migration, it will use the coroutine as the unit. One process carries a stateful service, one process serves multiple players, and one player corresponds to one coroutine. There are multiple coroutines on one process, which notifies the player coroutine on the backend stateful service to enter the migration state. In addition, if the scheduling node does not receive confirmation from the old stateful service that the player coroutine has been migrated to the new stateful service, all messages sent to the player coroutine (i.e. player requests) will be cached to the scheduling node, for example Fig. 9 All messages sent to the player's coroutine 1 will be cached in the scheduling node first.

[0216] After the old stateful service receives the coroutine migration notification from the scheduling node and confirms that the coroutine needs to be migrated to the new stateful service, it will set the coroutine status to lossless exit, for example Fig. 9In the process of setting coroutine 1 in the old stateful service to a lossless exit, the player coroutine first processes all remaining messages in the task queue, and then saves the data, saving the key data (such as the processing results corresponding to the message) to the database. When all key data has been successfully saved, a notification message will be sent to the scheduling node to notify the player coroutine that it is ready to migrate to the new stateful service. At the same time, the notification message will also carry some state data of the player coroutine (such as data needed during the game, temporary data during the game).

[0217] When the scheduling node confirms that the player coroutine can be migrated to the new stateful service, it will send a notification message to the new stateful service. At the same time, it will send the player request and some state data cached during the coroutine migration process to the new stateful service. After receiving the notification message, the new stateful service will create a new coroutine to serve the player, save the state data and immediately process the player request during the migration process.

[0218] At this point, the player coroutine has completed the entire migration process. Repeat the above steps (coroutine 1 migration process) for all player coroutines on the old stateful service to migrate all online player coroutines to the new stateful service.

[0219] In summary, the embodiments of the present application provide an online update for stateful services. The update solution only requires the operation and maintenance to start the new stateful service to automatically complete the update of the new stateful service and exit the old stateful service; and the entire update process is oriented to the player's coroutines, and the migration of each player's coroutine does not affect each other, the migration speed is fast, and the impact on the players is small; since the number of coroutines on the new stateful service and the old stateful service is basically the same during the entire migration process, the migration process does not require additional machines, and there is no need to wait until the number of online people is small before updating, and the real-time performance is good.

[0220] So far, the service processing method provided by the embodiment of the present application has been described in combination with the exemplary application and implementation of the electronic device provided by the embodiment of the present application. The following will continue to describe the solution for implementing service processing by cooperating various modules in the service processing device 465 provided by the embodiment of the present application.

[0221] An acquisition module 4651 is used to acquire a first stateful service for updating; a registration module 4652 is used to perform registration processing of a stateful service based on the first stateful service to obtain a second stateful service, wherein the second stateful service corresponds to the first stateful service; a migration module 4653 is used to migrate the coroutine of the first stateful service to the second stateful service during the operation of the first stateful service to obtain the migrated second stateful service; and a processing module 4654 is used to execute a corresponding coroutine service request through the coroutine of the migrated second stateful service.

[0222] In some embodiments, the registration module 4652 is also used to call a scheduling node based on the stateful service to be registered corresponding to the first stateful service; perform registration verification processing on the stateful service to be registered through the scheduling node; when the registration verification processing passes, perform registration processing on the stateful service to be registered to obtain the second stateful service.

[0223] In some embodiments, the registration module 4652 is further used to determine the file lock of the stateful service to be registered based on the stateful service to be registered corresponding to the first stateful service; and call the scheduling node based on the shared memory message channel corresponding to the file lock.

[0224] In some embodiments, the registration module 4652 is also used to determine multiple candidate file locks corresponding to the first stateful service based on the first stateful service; perform occupation processing of the candidate file locks based on the stateful service to be registered corresponding to the first stateful service; when the candidate file lock is not occupied, use the candidate file lock as the file lock of the stateful service to be registered, and write the version number of the stateful service to be registered in the file lock.

[0225] In some embodiments, the registration module 4652 is also used to determine a registration message of the stateful service to be registered, wherein the registration message includes a version number of the stateful service to be registered; and send the registration message to the scheduling node through a shared memory message channel corresponding to the file lock.

[0226] In some embodiments, the registration module 4652 is also used to register the stateful service to be registered to the service list when the version number of the stateful service to be registered is greater than the version number of the registered stateful service, obtain the second stateful service, and set the state of the second stateful service to be in coroutine migration.

[0227] In some embodiments, the migration module 4653 is also used to perform the following processing for any coroutine in the first stateful service: losslessly migrate the coroutine to the second stateful service to obtain a new coroutine in the migrated second stateful service, and the new coroutine corresponds one-to-one with the coroutine; when the number of coroutines in the first stateful service is zero, set the state of the migrated second stateful service to normal operation, and set the state of the first stateful service to an unavailable state.

[0228] In some embodiments, the migration module 4653 is also used to obtain at least one service request in the task queue of the coroutine; perform data processing on the at least one service request based on the coroutine to obtain a processing result of the service request; create a new coroutine corresponding to the coroutine in the second stateful service, and save the processing result of the service request through the new coroutine.

[0229] In some embodiments, the migration module 4653 is also used to set the state of the coroutine of the first stateful service to lossless exit when the first stateful service receives a migration request for the coroutine, and obtain at least one service request in the task queue of the coroutine from the shared memory message channel corresponding to the first stateful service; wherein the migration request is used to instruct the first stateful service to perform coroutine migration.

[0230] In some embodiments, before creating a new coroutine corresponding to the coroutine in the second stateful service, the migration module 4653 is also used to send a notification message to the second stateful service when the service request does not exist in the task queue of the coroutine, and the notification message carries the processing result of the service request; based on the notification message, it is determined to execute the operation of creating a new coroutine corresponding to the coroutine in the second stateful service.

[0231] In some embodiments, the migration module 4653 is further used to obtain state data of the coroutine, wherein the state data includes scene data of the virtual scene; and save the state data to the new coroutine in the second stateful service after migration.

[0232] In some embodiments, the processing module 4654 is also used to cache the new coroutine service request for the coroutine to the scheduling node during the migration of the first stateful service; after the migration of the first stateful service is completed, the migrated second stateful service obtains the new coroutine service request from the scheduling node and executes the new coroutine service request.

[0233] In some embodiments, before migrating the coroutine of the first stateful service to the second stateful service, the migration module 4653 is also used to determine the number of the coroutine service requests; when the number of the coroutine service requests is less than a quantity threshold, it is determined to execute the operation of migrating the coroutine of the first stateful service to the second stateful service.

[0234] In some embodiments, before migrating the coroutine of the first stateful service to the second stateful service, the migration module 4653 is also used to determine the network quality during the operation of the first stateful service; when the network quality is greater than the quality threshold, it is determined to execute the operation of migrating the coroutine of the first stateful service to the second stateful service.

[0235] The embodiment of the present application provides a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the service processing method described above in the embodiment of the present application.

[0236] The embodiment of the present application provides a computer-readable storage medium storing executable instructions, wherein the executable instructions are stored. When the executable instructions are executed by a processor, the processor will execute the service processing method provided by the embodiment of the present application, for example, Figure 3-5 The service processing method shown.

[0237] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EP ROM, EEPROM, flash memory, magnetic surface storage, optical disk, or CD-ROM; or it may be various devices including one or any combination of the above memories.

[0238] In some embodiments, executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0239] As an example, executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions).

[0240] By way of example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices located at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0241] The above is only an embodiment of the present application and is not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A service processing method, characterized in that: The method comprises: Obtain a first stateful service for updating; Performing stateful service registration processing based on the first stateful service to obtain a second stateful service, where the second stateful service corresponds to the first stateful service; During the operation of the first stateful service, the following processing is performed for any coroutine in the first stateful service: the coroutine is losslessly migrated to the second stateful service to obtain a new coroutine in the migrated second stateful service, and the new coroutine corresponds to the coroutine one-to-one; when the number of coroutines in the first stateful service is zero, the state of the migrated second stateful service is set to normal operation, and the state of the first stateful service is set to unavailable state; The corresponding coroutine service request is executed by the new coroutine in the migrated second stateful service.

2. The method according to claim 1, characterized in that The performing registration processing of the stateful service based on the first stateful service to obtain the second stateful service includes: Invoking a scheduling node based on a stateful service to be registered corresponding to the first stateful service; Performing registration verification processing on the stateful service to be registered by the scheduling node; When the registration verification process is passed, the stateful service to be registered is registered to obtain the second stateful service.

3. The method according to claim 2, characterized in that The calling of the scheduling node based on the stateful service to be registered corresponding to the first stateful service includes: Determining a file lock of the stateful service to be registered based on the stateful service to be registered corresponding to the first stateful service; The scheduling node is called based on the shared memory message channel corresponding to the file lock.

4. The method according to claim 3, characterized in that The determining, based on the stateful service to be registered corresponding to the first stateful service, a file lock of the stateful service to be registered, includes: Based on the first stateful service, determining a plurality of candidate file locks corresponding to the first stateful service; Performing occupation processing of the candidate file lock based on the stateful service to be registered corresponding to the first stateful service; When the candidate file lock is not occupied, the candidate file lock is used as the file lock of the stateful service to be registered, and the version number of the stateful service to be registered is written into the file lock.

5. The method according to claim 3, characterized in that: The calling the scheduling node based on the shared memory message channel corresponding to the file lock includes: Determine a registration message for the stateful service to be registered, where the registration message includes a version number of the stateful service to be registered; The registration message is sent to the scheduling node through the shared memory message channel corresponding to the file lock.

6. The method according to claim 2, characterized in that When the registration verification process is passed, registering the stateful service to be registered to obtain the second stateful service includes: When the version number of the stateful service to be registered is greater than the version number of the registered stateful service, the stateful service to be registered is registered in the service list to obtain the second stateful service, and the state of the second stateful service is set to be in coroutine migration.

7. The method according to claim 1, characterized in that The step of losslessly migrating the coroutine to the second stateful service to obtain a new coroutine in the migrated second stateful service includes: Obtain at least one service request in the task queue of the coroutine; Performing data processing on the at least one service request based on the coroutine to obtain a processing result of the service request; A new coroutine corresponding to the coroutine is created in the second stateful service, and a processing result of the service request is saved through the new coroutine.

8. The method according to claim 7, characterized in that The obtaining at least one service request in the task queue of the coroutine includes: When the first stateful service receives a migration request for the coroutine, setting the state of the coroutine of the first stateful service to lossless exit, and obtaining at least one service request in the task queue of the coroutine from the shared memory message channel corresponding to the first stateful service; The migration request is used to instruct the first stateful service to perform coroutine migration.

9. The method according to claim 7, characterized in that: Before creating a new coroutine corresponding to the coroutine in the second stateful service, the method further includes: When the service request does not exist in the task queue of the coroutine, sending a notification message to the second stateful service, the notification message carrying the processing result of the service request; Based on the notification message, it is determined that an operation of creating a new coroutine corresponding to the coroutine in the second stateful service will be executed.

10. The method according to claim 1, characterized in that The method further comprises: Acquire status data of the coroutine, wherein the status data includes scene data of the virtual scene; The state data is saved to the new coroutine in the migrated second stateful service.

11. The method according to claim 1, characterized in that: The method further comprises: During the migration of the first stateful service, a new coroutine service request for the coroutine is cached in a scheduling node; After the migration of the first stateful service is completed, the migrated second stateful service obtains the new coroutine service request from the scheduling node and executes the new coroutine service request.

12. The method according to claim 1, characterized in that Before migrating the coroutine of the first stateful service to the second stateful service, the method further includes: Determining the number of coroutine service requests; When the number of the coroutine service requests is less than the number threshold, it is determined that an operation of migrating the coroutine of the first stateful service to the second stateful service will be performed.

13. The method according to claim 1, characterized in that Before migrating the coroutine of the first stateful service to the second stateful service, the method further includes: Determining a network quality during operation of the first stateful service; When the network quality is greater than a quality threshold, it is determined that an operation of migrating the coroutine of the first stateful service to the second stateful service will be performed.

14. A service processing device, characterized in that: The device comprises: An acquisition module, used to acquire a first stateful service for updating; A registration module, configured to perform a stateful service registration process based on the first stateful service to obtain a second stateful service, where the second stateful service corresponds to the first stateful service; A migration module, configured to perform the following processing on any coroutine in the first stateful service during the operation of the first stateful service: losslessly migrate the coroutine to the second stateful service to obtain a new coroutine in the migrated second stateful service, wherein the new coroutine corresponds one-to-one with the coroutine; when the number of coroutines in the first stateful service is zero, set the state of the migrated second stateful service to normal operation, and set the state of the first stateful service to an unavailable state; A processing module is used to execute the corresponding coroutine service request through the new coroutine in the second stateful service after migration.

15. An electronic device, characterized in that: The electronic device comprises: A memory for storing executable instructions; The processor is used to implement the service processing method described in any one of claims 1 to 13 when executing the executable instructions stored in the memory.

16. A computer-readable storage medium, characterized in that: Executable instructions are stored, and are used to implement the service processing method described in any one of claims 1 to 13 when executed by a processor.

17. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the service processing method according to any one of claims 1 to 13 is implemented.

Images