CN114470787A

CN114470787A - Service processing method, service processing device, electronic device, storage medium, and program product

Info

Publication number: CN114470787A
Application number: CN202210106810.XA
Authority: CN
Inventors: 刘健强; 毛竹
Original assignee: Tencent Technology Chengdu Co Ltd
Current assignee: Tencent Technology Chengdu Co Ltd
Priority date: 2022-01-28
Filing date: 2022-01-28
Publication date: 2022-05-13

Abstract

The application provides a service processing method, a service processing device, an electronic device, a computer readable storage medium and a computer program product; the method comprises the following steps: 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, wherein the second stateful service corresponds to the first stateful service; in the running process of the first stateful service, the coroutine of the first stateful service is transferred to the second stateful service to obtain the transferred second stateful service; and executing the corresponding coroutine service request through the transferred coroutine of the second stateful service. By the method and the device, online updating of the stateful service can be achieved, and application fluency of the service is improved.

Description

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

Technical Field

The present application relates to computer graphics and image technologies, and in particular, to a service processing method, apparatus, electronic device, computer-readable storage medium, and computer program product.

Background

The display technology based on the graphic processing hardware expands the perception environment and the channel for acquiring information, particularly the display technology of the virtual scene, can realize diversified interaction between virtual objects controlled by users or artificial intelligence according to the actual application requirements, has various typical application scenes, and can simulate the real fighting process between the virtual objects in the virtual scene of games and the like.

With the recent increase in the speed of updating game contents, various problems are often caused in the game service (a stateful service) function. In the related art, the game service is updated by stopping updating, and the scheme has a serious influence on the application fluency of the service because all game services are unavailable during the stopping updating.

Disclosure of Invention

Embodiments of the present application provide a service processing method and apparatus, an electronic device, a computer-readable storage medium, and a computer program product, which can implement online update of a stateful service and improve application fluency of the service.

The technical scheme of the embodiment of the application is realized as follows:

an embodiment of the present application provides a service processing method, including:

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, wherein the second stateful service corresponds to the first stateful service;

in the running process 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;

and executing the corresponding coroutine service request through the transferred coroutine of the second stateful service.

An embodiment of the present application provides a service processing apparatus, including:

an obtaining module, configured to obtain a first stateful service for updating;

the registration module is used for performing registration processing on the stateful service based on the first stateful service to obtain a second stateful service, and the second stateful service corresponds to the first stateful service;

the migration module is used for migrating the coroutine of the first stateful service to the second stateful service in the running process of the first stateful service to obtain the migrated second stateful service;

and the processing module is used for executing the corresponding coroutine service request through the migrated coroutine of the second stateful service.

In the above technical solution, the registration module is further configured to invoke a scheduling node based on the to-be-registered stateful service corresponding to the first stateful service;

performing registration verification processing on the service to be registered with the state through the scheduling node;

and when the registration verification process is passed, performing registration process on the service with the state to be registered to obtain the second service with the state.

In the above technical solution, the registration module is further configured to determine a file lock of the to-be-registered stateful service based on the to-be-registered stateful service corresponding to the first stateful service;

and calling the scheduling node based on the shared memory message channel corresponding to the file lock.

In the foregoing technical solution, the registration module is further configured to determine, based on the first stateful service, a plurality of candidate file locks corresponding to the first stateful service;

performing occupation processing on the candidate file lock based on the to-be-registered stateful service corresponding to the first stateful service;

and when the candidate file lock is not occupied, taking the candidate file lock as the file lock of the state service to be registered, and writing the version number of the state service to be registered into the file lock.

In the above technical solution, the registration module is further configured to determine a registration message of the to-be-registered stateful service, where the registration message includes a version number of the to-be-registered stateful service;

and sending the registration message to the scheduling node through a shared memory message channel corresponding to the file lock.

In the above technical solution, the registration module is further configured to register the state service to be registered to a service list when the version number of the state service to be registered is greater than the version number of the state service already registered, obtain the second state service, and set the state of the second state service in coroutine migration.

In the foregoing technical solution, the migration module is further configured to execute the following processing for any coroutine in the first stateful service:

the protocol is transferred to the second stateful service in a lossless mode, so that a new protocol in the second stateful service after the protocol is transferred is obtained, and the new protocol corresponds to the protocol one to one;

when the number of the coroutines in the first stateful service is zero, setting the state of the second stateful service after the migration into a normal operation state, and setting the state of the first stateful service into an unavailable state.

In the above technical solution, the migration module is further configured to 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;

and creating a new coroutine corresponding to the coroutine in the second stateful service, and storing a processing result of the service request through the new coroutine.

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

wherein the migration request is used for indicating the first stateful service to perform protocol migration.

In the foregoing technical solution, before creating a new coroutine corresponding to the coroutine in the second stateful service, the migration module is further configured to send a notification message to the second stateful service when the service request does not exist in a task queue of the coroutine, where the notification message carries a processing result of the service request;

determining, based on the notification message, that an operation to create a new coroutine in the second stateful service corresponding to the coroutine is to be performed.

In the above technical solution, the migration module is further configured to obtain status data of the coroutine, where the status data includes scene data of a virtual scene;

and storing the state data to the new coroutine in the second stateful service after the migration.

In the above technical solution, the processing module is further configured to cache a new coroutine service request for the coroutine to a scheduling node in the first stateful service migration process;

and after the migration of the first stateful service is completed, the migrated second stateful service acquires the new coroutine service request from the scheduling node and executes the new coroutine service request.

In the above technical solution, before the coroutine of the first stateful service is migrated to the second stateful service, the migration module is further configured to determine the number of coroutine service requests;

when the number of the coroutine service requests is smaller than a number threshold value, determining that the operation of migrating the coroutine of the first stateful service to the second stateful service is to be executed.

In the above technical solution, before the coroutine of the first stateful service is migrated to the second stateful service, the migration module is further configured to determine a network quality in an operation process of the first stateful service;

determining that an operation of migrating a coroutine of the first stateful service into the second stateful service is to be performed when the network quality is greater than a quality threshold.

An embodiment of the present application provides an electronic device for service processing, where the electronic device includes:

a memory for storing executable instructions;

and the processor is used for realizing the service processing method provided by the embodiment of the application when the executable instructions stored in the memory are executed.

The embodiment of the present application provides a computer-readable storage medium, which stores executable instructions for causing a processor to implement the service processing method provided by the embodiment of the present application when executed.

The embodiment of the present application provides a computer program product, which includes a computer program or instructions, and is characterized in that the computer program or instructions, when executed by a processor, implement the service processing method provided in the embodiment of the present application.

The embodiment of the application has the following beneficial effects:

by registering the second stateful service and transferring the coroutine of the first stateful service to the second stateful service in the running process of the first stateful service, the function of updating the stateful service on line is realized, the application fluency of the service is improved, the service updating efficiency is improved by the coroutine transferring mode, and the related communication resources and the computing resources are saved.

Drawings

Fig. 1A-1B are schematic application mode diagrams of a service processing method provided in an embodiment of the present application;

FIG. 2 is a schematic structural diagram of an electronic device for service processing provided in an embodiment of the present application;

3-5 are schematic flow diagrams of service processing methods provided by embodiments of the present application;

fig. 6 is a schematic structural diagram of a service processing method according to an embodiment of the present application;

fig. 7 is a schematic flowchart of a service processing method provided in an embodiment of the present application;

FIG. 8 is a flow chart illustrating service registration provided by an embodiment of the present application;

FIG. 9 is a flowchart illustrating a player-oriented protocol lossless migration according to an embodiment of the present application.

Detailed Description

In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be described in further detail with reference to the attached drawings, the described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

In the following description, references to the terms "first", "second", and the like are only used for distinguishing similar objects and do not denote a particular order or importance, but rather the terms "first", "second", and the like may be used interchangeably with the order of priority or the order in which they are expressed, where permissible, to enable embodiments of the present application described herein to be practiced otherwise than as specifically illustrated and described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.

Before further detailed description of the embodiments of the present application, terms and expressions referred to in the embodiments of the present application will be described, and the terms and expressions referred to in the embodiments of the present application will be used for the following explanation.

1) In response to: for indicating the condition or state on which the performed operation depends, when the condition or state on which the performed operation depends is satisfied, the performed operation or operations may be in real time or may have a set delay; there is no restriction on the order of execution of the operations performed unless otherwise specified.

2) A client: and the terminal is used for running application programs for providing various services, such as a video playing client, a game client and the like.

3) Virtual scene: the game program displays (or provides) a virtual game scene when running on the terminal. The virtual scene may be a simulation environment of a real world, a semi-simulation semi-fictional virtual environment, or a pure fictional virtual environment. The virtual scene may be any one of a two-dimensional virtual scene, a 2.5-dimensional virtual scene, or a three-dimensional virtual scene, and the dimension of the virtual scene is not limited in the embodiment of the present application. For example, a virtual scene may include sky, land, ocean, etc., the land may include environmental elements such as deserts, cities, etc., and a user may control a virtual object to move in the virtual scene.

4) Virtual object: the image of various people and objects that can interact in the virtual scene, or the movable objects in the virtual scene. The movable object may be a virtual character, a virtual animal, an animation character, etc., such as a character, animal, etc., displayed in a virtual scene. The virtual object may be an avatar in a virtual scene that is virtual to represent the user. The virtual scene may include a plurality of virtual objects, each virtual object having its own shape and volume in the virtual scene and occupying a portion of the space in the virtual scene.

5) Scene data: the characteristic data representing the virtual scene may be, for example, the area of a building area in the virtual scene, the current architectural style of the virtual scene, and the like; the position of the virtual building in the virtual scene, the floor space of the virtual building, and the like may also be included.

6) Service: the method comprises a stateful service and a stateless service, wherein the stateful service and the stateless service are two different service architectures, and the difference between the stateful service and the stateless service is the processing of a service state. The service state is the data required to service the request and may be a variable or a data structure. The stateless service does not record the service state, and different requests have no relation; the stateful service records the service state, and there is a relationship between different requests. The judgment of the stateful service and the stateless service is based on whether two requests from the same initiator have a context relationship at the server side.

For the stateless service, all data which can be processed by the server side comes from information carried by the request, the processing of a single request of the client side by the stateless service does not depend on other requests, the information for processing the single request is contained in the request, and the request data is transmitted in a Token (Token) saving mode through data (Cookie) stored on the local terminal of the user.

For stateful services, the server stores data information related to the context of the request, and the consecutive requests may be related. For example, in Web page (Web) applications, a time domain (Session) is often used to maintain context information of a registered user, and although a hypertext transfer Protocol (HTTP) is stateless, an HTTP service can be converted into a stateful service by the Session.

7) Coroutine (coreutine): coroutines are not processes or threads, and perform more like subroutines, or function calls without return values. Coroutines are program components such as cooperative multitasking, iterators, infinite lists, and pipes. Coroutines are more flexible than subroutines. It should be noted that the coroutine in the embodiment of the present application is a gold coroutine (also referred to as Go coroutine or Go coroutine).

8) Golang: also called Go, is a programming language with strong static type, compiling type, concurrent type and garbage recycling function. Go's syntax is close to the C language, but declarations for variables are different. In contrast to C + +, Go does not include functions such as enumeration, exception handling, inheritance, generalization, assertion, virtual functions, but adds language level support for features such as Slice (Slice) type, concurrency, pipelining, garbage collection, Interface (Interface), etc. Unlike Java, Go embeds an associative array (also known as hash tables (Hashes) or Dictionaries (dictionary)).

9) File locking: also known as file persistent locks, a file locking mechanism that enforces access to a computer file that can only be maliciously updated by a user or process at any particular time, prevented by a file lock.

10) Sharing a memory message channel: the communication channel between multiple processes is used for communication between multiple processes, and actually, information can be transmitted between multiple programs through a shared memory message channel. A Shared Memory refers to a large-capacity Memory that can be accessed by different Central Processing Units (CPUs) in a multiprocessor computer system.

The game has various stateful services (also called stateful game services), and the stateful services can effectively reduce the access frequency to the database and improve the throughput of the single server by caching the state data of the player, such as the data of a player database. For example, a lobby service is a stateful service in a game, and most of the functions of a player to participate in activities, complete tasks, upgrade heros (a virtual object) and the like on a game interface are provided by the lobby service.

With the rapid development of the mobile game industry in recent years, in order to cope with the problem that the consumption speed of game contents by players is too high, and to attract players and retain players, the game side is required to continuously update game contents. In addition, as the updating speed of the game content is increased, instability is often brought to the game service function, for example, the player experience is affected due to abnormal functions caused by careless self-test. Therefore, how to stably update game contents without influencing the experience of online players and how to quickly update and repair the game contents when the external network function is abnormal has important value in the actual game operation, wherein the updating of stateful services is taken as a main carrier of the game services, and the online updating technology is always a key point and a difficult point in the game background design.

In the related technology, all players are directly kicked by the halt updating so as to update the service, and all the services are unavailable during the halt updating, so that the experience of the players is seriously influenced; the service is gradually updated by adopting a gray release manner, but some compatibility problems need to be handled, for example, special processing of some service logics under the condition that new and old versions exist at the same time, in addition, some redundant gray machine resources are needed in the updating process, and the gray release is time-consuming.

In order to solve the foregoing problems, embodiments of the present application provide a service processing method, an apparatus, an electronic device, a computer-readable storage medium, and a computer program product, which can implement online updating of a stateful service and improve application fluency of the service. In order to facilitate easier understanding of the service processing method provided by the embodiment of the present application, an exemplary implementation scenario of the service processing method provided by the embodiment of the present application is first described, and a virtual scenario (implemented by a stateful service) in the service processing method provided by the embodiment of the present application may be completely output based on a terminal, or cooperatively output based on the terminal and a server.

In some embodiments, the virtual scene may be an environment for game characters to interact with, for example, game characters to play against in the virtual scene, and the two-way interaction may be performed in the virtual scene by controlling actions of the game characters, so that the user can relieve life stress during the game.

In an implementation scenario, referring to fig. 1A, fig. 1A is an application mode schematic diagram of the service processing method provided in the embodiment of the present application, and is applicable to some application modes that can complete the calculation of related data of the virtual scenario 100 completely depending on the computing capability of the graphics processing hardware of the terminal 400, such as a single-machine/offline mode game, and complete the output of the virtual scenario through various different types of terminals 400, such as a smart phone, a tablet computer, and a virtual reality/augmented reality device.

As an example, types of Graphics Processing hardware include a Central Processing Unit (CPU) and a Graphics Processing Unit (GPU).

When the visual perception of the virtual scene 100 is formed, the terminal 400 calculates and displays required data through graphic computing hardware, finishes loading, analyzing and rendering of the display data, and outputs a video frame capable of forming the visual perception on the virtual scene through graphic output hardware, for example, a two-dimensional video frame is displayed on a display screen of a smart phone, or a video frame for realizing a three-dimensional display effect is projected on a lens of augmented reality/virtual reality glasses; in addition, the terminal 400 may also form one or more of auditory perception, tactile perception, motion perception, and taste perception by means of different hardware in order to enrich the perception effect.

As an example, the terminal 400 runs a client 410 (e.g. a standalone version of a game application), and outputs a virtual scene including role play during the running process of the client 410 (implemented by running a stateful service (also called a stateful game service) in which there is a coroutine for each player to process a player request, that is, one coroutine corresponds to one player), where the virtual scene may be an environment for game role interaction, such as a plain, a street, a valley, and the like for game role battle; taking the example of displaying the virtual scene 100 from the first human perspective, a virtual object 110 is displayed in the virtual scene 100, where the virtual object 110 may be a game character (corresponding to a coroutine in a stateful service) controlled by a user (or a player), and will operate in the virtual scene in response to an operation of a real user on a button (including a rocker button, an attack button, a defense button, and the like), for example, when the real user moves the rocker button to the left, the virtual object will move to the left in the virtual scene, and may also remain stationary in place, jump, and use various functions (such as skills and props); the virtual object 110 may also be Artificial Intelligence (AI) set in a virtual scene fight by training; the virtual object 110 may also be a Non-user Character (NPC) set in the virtual scene interaction; the virtual object 110 may also be an immovable object or a movable object in the virtual scene 100.

For example, in the process of running the stateful game service, the virtual object 110 is displayed in the virtual scene 100, and the player controls the virtual object to complete the task in the virtual scene, but the stateful game service is updated, by the service processing method according to the embodiment of the present application, a new stateful game service is registered, the new stateful service corresponds to the stateful service before updating, in the process of running the stateful service, the routine of the stateful service is migrated to the new stateful service to obtain the new stateful service after migration, the corresponding routine service request is executed by the routine of the new second stateful service after migration, so that the virtual object 110 is displayed in the virtual scene 100 by the new second stateful service after migration, and the player controls the virtual object to complete the task in the virtual scene.

In another implementation scenario, referring to fig. 1B, fig. 1B is a schematic diagram of an application mode of the service processing method provided in the embodiment of the present application, applied to a terminal 400 and a server 200, and adapted to complete virtual scenario calculation depending on the calculation capability of the server 200 and output an application mode of a virtual scenario at the terminal 400.

Taking the visual perception forming the virtual scene 100 as an example, the server 200 performs calculation of display data (e.g., scene data) related to the virtual scene and sends the calculated display data to the terminal 400 through the network 300, the terminal 400 relies on graphics computing hardware to complete loading, parsing and rendering of the calculated display data, and relies on graphics output hardware to output the virtual scene to form the visual perception, for example, a two-dimensional video frame may be presented on a display screen of a smart phone, or a video frame realizing a three-dimensional display effect may be projected on a lens of augmented reality/virtual reality glasses; for perception in the form of a virtual scene, it is understood that an auditory perception may be formed by means of corresponding hardware outputs of the terminal 400, for example using a microphone, a tactile perception using a vibrator, etc.

As an example, a client 410 (e.g. a network version of a game application) is running on the terminal 400, and the terminal 400 outputs a virtual scene of the client 410 (implemented by running a stateful service (also called a stateful game service) in which there is a protocol for each player to process a player request, i.e. a protocol corresponds to a player), and displays the virtual scene 100 in a first-person perspective, displays the virtual object 110 in the virtual scene 100, where the virtual object 110 can be a game character controlled by the user (or a player) (corresponding to a protocol in the stateful service), and will operate in the virtual scene in response to the operation of a real user on a button (including a joystick button, an attack button, a defense button, etc.), for example, when the real user moves the joystick button to the left, virtual objects will move to the left in the virtual scene, and may also remain stationary, jump, and use various functions (such as skills and props); the virtual object 110 may also be Artificial Intelligence (AI) set in a virtual scene fight by training; the virtual object 110 may also be a Non-user Character (NPC) set in the virtual scene interaction; the virtual object 110 may also be an immovable object or a movable object in the virtual scene 100.

In some embodiments, the terminal 400 may implement the service processing method provided by the embodiments of the present application by running a computer program, for example, the computer program may be a native program or a software module in an operating system; may be a Native APPlication (APP), i.e. a program that needs to be installed in an operating system to run, such as a change-over game APP (i.e. the client 410 described above); or may be an applet, i.e. a program that can be run only by downloading it to the browser environment; but also a game applet that can be embedded in any APP. In general, the computer programs described above may be any form of application, module or plug-in.

Taking a computer program as an application program as an example, in actual implementation, the terminal 400 is installed and runs with an application program supporting a virtual scene. The application program may 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 multi-player gunfight type live game. The user uses the terminal 400 to operate virtual objects located in a virtual scene for activities including, but not limited to: adjusting at least one of body posture, crawling, walking, running, riding, jumping, driving, picking, shooting, attacking, throwing, building a virtual building. Illustratively, the virtual object may be a virtual character, such as a simulated character or an animated character, among others.

In some embodiments, the embodiments of the present application may also be implemented by means of Cloud Technology (Cloud Technology), which refers to a hosting Technology for unifying resources of hardware, software, network, and the like in a wide area network or a local area network to implement computation, storage, processing, and sharing of data.

The cloud technology is a general term of network technology, information technology, integration technology, management platform technology, application technology and the like applied based on a cloud computing business model, can form a resource pool, is used as required, and is flexible and convenient. Cloud computing technology will become an important support. Background services of the technical network system require a large amount of computing and storage resources.

For example, the server 200 in fig. 1B may be an independent physical server, may also be a server cluster or a distributed system formed by a plurality of physical servers, and may also be a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, a middleware service, a domain name service, a security service, a CDN, and a big data and artificial intelligence platform. The terminal 400 may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, and the like. The terminal 400 and the server 200 may be directly or indirectly connected through wired or wireless communication, and the embodiment of the present application is not limited thereto.

Referring to fig. 2, fig. 2 is a schematic structural diagram 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, where the electronic device 400 shown in fig. 2 includes: at least one processor 420, memory 460, at least one network interface 430, and a user interface 440. The various components in the terminal 400 are coupled together by a bus system 450. It is understood that the bus system 450 is used to enable connected communication between these components. The bus system 450 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are designated as bus system 450 in figure 2.

The Processor 420 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor, or the like.

The user interface 440 includes one or more output devices 441, including one or more speakers and/or one or more visual display screens, that enable the presentation of media content. 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 screen, camera, other input buttons and controls.

The memory 460 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. Memory 460 may optionally include one or more storage devices physically located remote from processor 420.

The memory 460 may include volatile memory or nonvolatile memory, and may also include both volatile and nonvolatile memory. The nonvolatile memory may be a Read Only Memory (ROM), and the volatile memory may be a Random Access Memory (RAM). The memory 460 described in embodiments herein is intended to comprise any suitable type of memory.

In some embodiments, memory 460 may be capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

An operating system 461 comprising system programs for handling various basic system services and performing hardware related tasks, such as framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware based tasks;

a network communication module 462 for reaching other computing devices via one or more (wired or wireless) network interfaces 430, exemplary network interfaces 430 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;

a presentation module 463 for enabling presentation of information (e.g., user interfaces for operating peripherals and displaying content and information) via one or more output devices 441 (e.g., display screens, speakers, etc.) associated with user interface 440;

an input processing module 464 for detecting one or more user inputs or interactions from one of the one or more input devices 442 and translating the detected inputs or interactions.

In some embodiments, the service processing apparatus provided in this embodiment may be implemented in software, and fig. 2 shows the service processing apparatus 465 stored in the memory 460, which may be software in the form of programs and plug-ins, and includes the following software modules: the obtaining module 4651, the registering module 4652, the migrating module 4653 and the processing module 4654 are logical and thus may be arbitrarily combined or further split according to the implemented functions.

In other embodiments, the service processing apparatus provided in this embodiment may be implemented in hardware, and for example, the service processing apparatus provided in this embodiment may be a processor in the form of a hardware decoding processor, which is programmed to execute the service processing method provided in this embodiment, for example, the processor in the form of the hardware decoding processor may be 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.

The service processing method provided by the embodiment of the present application will be specifically described below with reference to the accompanying drawings. The service processing method provided by the embodiment of the present application may be executed by the terminal 400 in fig. 1A alone, or may be executed by the terminal 400 and the server 200 in fig. 1B in a cooperation manner.

Next, a service processing method provided in the embodiment of the present application is executed by the terminal 400 alone in fig. 1A as an example. Referring to fig. 3, fig. 3 is a schematic flowchart of a service processing method provided in an embodiment of the present application, and will be described with reference to the steps shown in fig. 3.

It should be noted that the method shown in fig. 3 can be executed by various forms of computer programs running on the terminal 400, and is not limited to the client 410 described above, but may also be the operating system 461, software modules and scripts described above, so that the client should not be considered as limiting the embodiments of the present application.

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

For example, in order to attract players and retain players, the game side is required to constantly update the game content. In addition, as the update speed of game contents increases, the 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 acquired and used as the first stateful service for updating (namely, the old stateful service). It should be noted that different stateful services have different service functions, for example, a lobby service in a game, which is used for providing functions of a player to participate in activities, complete tasks, upgrade hero, and the like on a game interface; and the friend service in the game is used for providing communication functions such as chatting and the like.

In step 102, a registration process of the stateful service is performed based on the first stateful service, so as to obtain a second stateful service, where the second stateful service corresponds to the first stateful service.

For example, after determining a first stateful service for updating, a second stateful service corresponding to the first stateful service needs to be registered, that is, the first stateful service is an old stateful service that needs to be updated and replaced, and the second stateful service is a new stateful service generated after updating. After the second stateful service is registered, coroutine migration in subsequent stateful services is carried out, so that the function of updating the stateful services on line is realized, halt updating is not needed, and the application fluency of the services is improved.

Referring to fig. 4, fig. 4 is a schematic flowchart of a service processing method provided in an embodiment of the present application, and fig. 4 shows that step 102 of fig. 3 can be implemented by steps 1021 to 1023: invoking a scheduling node based on the stateful service to be registered corresponding to the first stateful service in step 1021; in step 1022, performing registration verification processing on the to-be-registered stateful service through the scheduling node; in step 1023, when the registration verification process is passed, the registration process is performed on the service to be registered, and a second service with state is obtained.

For example, a service to be registered corresponding to a first stateful service (i.e., a second stateful service to be registered) starts a service, a scheduling node is called, the stateful service to be registered is registered and verified through the scheduling node, and when the registration and verification pass, the stateful service to be registered is registered through the scheduling node, that is, the registration of the second stateful service is successful, that is, the protocol-based migration processing of the first stateful service is to be performed; and when the registration verification fails, the state service to be registered is not registered, namely the second state service registration fails.

In some embodiments, invoking a scheduling node based on a to-be-registered stateful service corresponding to a first stateful service comprises: determining a file lock to be registered with the state service based on the state service to be registered corresponding to the first state service; and calling the scheduling node based on the shared memory message channel corresponding to the file lock.

For example, before registering the second stateful service through the scheduling node, the ownership of the shared memory message pipe must be obtained through the file persistent lock, and then the registration of the second stateful service is completed by transmitting the registration message to the shared memory message pipe.

It should be noted that there are 4 shared memory message channels in 2 pairs between the scheduling node and each stateful service (including the new stateful service and the old stateful service), and communication between the stateful service and the scheduling node must be performed by monopolizing one of the shared memory message channels. Since the new stateful service and the old stateful service need to be operated simultaneously in the migration process, in order to distinguish the new stateful service from the old stateful service, it is necessary to distinguish the new stateful service from the old stateful service in terms of configuration. Once the configuration is differentiated, the service process Identification (ID) is differentiated, i.e. the service process reads a different configuration. Once the process ID is distinguished, the operation and maintenance daily operation is burdened. In order to solve the problem, the embodiment of the application solves the problem of distinguishing the new stateful service from the old stateful service by introducing the file renewal lock (file lock for short) so as to reduce the calculation amount of maintenance.

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, the scheduling node transmits information to each stateful service through the 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 message middleware (a supporting software system that provides synchronous or asynchronous, reliable message transmission for application systems in a network environment based on queue and message passing technologies).

In some embodiments, determining a file lock to which a stateful service is to be registered based on the stateful service to be registered corresponding to the first stateful service includes: determining a plurality of candidate file locks corresponding to the first stateful service based on the first stateful service; carrying out occupation processing on the candidate file lock based on the to-be-registered stateful service corresponding to the first stateful service; and when the candidate file lock is not occupied, taking the candidate file lock as a file lock to be registered with the state service, and writing the version number of the state service to be registered into the file lock.

As shown in fig. 8, before registering a new stateful service and an old stateful service, one of the files must be occupied to monopolize a pair of shared memory message pipes (clipipe), where the file name is the shared memory message pipe ID. The file content in the file lock comprises 2 parts, namely a version number of a stateful service with ownership, wherein the version number can be compiled by using a process to obtain a timestamp; second is the expiration timestamp of the current stateful service renewal file lock.

As shown in fig. 8, based on the first stateful service (i.e., the old stateful service shown in fig. 8), a plurality of candidate file locks (i.e., file 1 and file 2 shown in fig. 8) corresponding to the first stateful service are determined, the to-be-registered stateful service (the new stateful service to be registered) corresponding to the first stateful service sends an ownership request to file 1 (shmipe 1) to determine that file 1 is already occupied by the old stateful service, the to-be-registered stateful service corresponding to the first stateful service sends an ownership request to file 2 (shmipe 2) to determine that file 2 is not occupied, the to-be-registered stateful service corresponding to the first stateful service occupies file 2, and the version number of the to-be-registered stateful service is written in file 2 to represent that file 2 is occupied by the to-be-registered stateful service.

In some embodiments, invoking a scheduling node based on a shared memory message channel corresponding to a file lock includes: determining a registration message of the state service to be registered, wherein the registration message comprises a version number of the state service to be registered; and sending the registration message to the scheduling node through the shared memory message channel corresponding to the file lock.

For example, after the file lock to be registered with the state service is determined, the registration message to be registered with the state service is sent based on the shared memory message channel corresponding to the file lock, so as to perform registration of the state service through the shared memory message channel.

In some embodiments, when the registration verification process passes, performing registration processing on the stateful service to be registered to obtain a second stateful service, including: and when the version number of the state service to be registered is greater than the version number of the registered state service, registering the state service to be registered to a service list to obtain a second state service, and setting the state of the second state service in coroutine migration.

For example, after a file lock of the state service to be registered is determined, a registration message of the state service to be registered is sent based on a shared memory message channel corresponding to the file lock, when the version number of the state service to be registered in the registration message is greater than the version number of the state service to be registered, it is indicated that the registration verification is passed, the state service to be registered can be registered, the state service to be registered is registered to a service list, a registered second state service is obtained, and the state of the second state service is set to be in the coroutine migration to indicate that the coroutine migration is required.

In step 103, in the running process of the first stateful service, the coroutine of the first stateful service is migrated to the second stateful service, so as to obtain the migrated second stateful service.

For example, after the second stateful service is registered, in the running process of the first stateful service, the coroutine of the first stateful service is transferred to the second stateful service to realize the function of updating the stateful service online without performing shutdown updating, so that the application fluency of the service is improved, the service updating efficiency is improved compared with a gray scale publishing mode, and no additional computer resource is needed, so that related communication resources and computing resources are saved.

Referring to fig. 5, fig. 5 is a schematic flowchart of a service processing method provided in an embodiment of the present application, and fig. 5 shows that step 103 of fig. 3 may be implemented by steps 1031 to 1032: in step 1031, the following processes are performed for any coroutine in the first stateful service: the protocol is transferred to the second stateful service in a lossless mode, so that a new protocol in the transferred second stateful service is obtained, and the new protocol corresponds to the protocol one to one; in step 1032, when the number of coordination processes in the first stateful service is zero, the state of the second stateful service after migration is set to be in normal operation, and the state of the first stateful service is set to be in an unavailable state.

For example, the following processing is performed for coroutine 1 in the first stateful service: and migrating the coroutine 1 to the second stateful service in a lossless manner to obtain a new coroutine in the migrated second stateful service, wherein the new coroutine corresponds to the coroutine 1, and setting the coroutine 1 in the first stateful service to be withdrawn in a lossless manner so as to represent that the coroutine 1 has been withdrawn from the first stateful service. When all the protocols in the first stateful service are migrated to the second stateful service, setting the state of the migrated second stateful service as the normal operation, and setting the state of the first stateful service as the unavailable state.

In some embodiments, the migrating the protocol to the second stateful service without loss to obtain a new protocol in the migrated second stateful service includes: acquiring at least one service request in a task queue of a coroutine; performing data processing on at least one service request based on the coroutine to obtain a processing result of the service request; and creating a new coroutine corresponding to the coroutine in the second stateful service, and storing a processing result of the service request through the new coroutine.

For example, for the coroutine 1 in the first stateful service, at least one service request in the task queue of the coroutine 1 is obtained from the shared memory message channel corresponding to the first stateful service, the coroutine 1 processes the at least one service request to obtain a processing result (i.e., key data) of the service request, that is, after the coroutine 1 has processed all the service requests in the task queue, a new coroutine corresponding to the coroutine 1 is created in the second stateful service, and the processing result of the service request is stored by the new coroutine, so that the new coroutine continues to process subsequent requests, and information interruption is avoided.

In some embodiments, obtaining at least one service request in a task queue of a coroutine comprises: when the first stateful service receives a migration request aiming at the coroutine, setting the state of the coroutine of the first stateful service into lossless exit, and acquiring at least one service request in a task queue of the coroutine from a shared memory message channel corresponding to the first stateful service; wherein, the migration request is used for indicating the first stateful service to perform the protocol migration.

For example, as shown in fig. 7, after registering the second stateful service (new stateful service), the scheduling node sends a notification message to the first stateful service (old stateful service) to notify the first stateful service to start protocol migration. When the first stateful service receives a migration request aiming at the coroutine, the state of the coroutine of the first stateful service is set to be in lossless exit, at least one service request in a task queue of the coroutine is acquired from a shared memory message channel corresponding to the first stateful service, the first stateful service processes coroutine residual messages (also called service requests or player requests), and after the first stateful service processes the coroutine residual messages, a coroutine migration success message is sent to a scheduling node to represent the coroutine migration success of the first stateful service, and a second stateful service can be logged in.

In some embodiments, before a new coroutine corresponding to the coroutine is created in the second stateful service, when no service request exists in a task queue of the coroutine, a notification message is sent to the second stateful service, and the notification message carries a processing result of the service request; based on the notification message, an operation is determined to be performed to create a new coroutine in the second stateful service that corresponds to the coroutine.

For example, as shown in fig. 7, after the first stateful service (old stateful service) processes the protocol residual message (also referred to as a service request or a player request), and the first stateful service finishes processing the protocol residual message (i.e., the service request does not exist in the task queue of the protocol), the scheduling node sends a protocol migration success message to the second stateful service (new stateful service), so as to notify that the protocol migration of the first stateful service is successful, and the second stateful service can be logged in. And the scheduling node sends a coroutine migration success message to the second stateful service, and the second stateful service initializes the coroutine after receiving the coroutine migration success message so as to create a new coroutine corresponding to the coroutine.

In some embodiments, state data of the coroutine is obtained, the state data comprising scene data of the virtual scene; and storing the state data to a new coroutine in the second stateful service after the migration.

For example, in the migration process of the first stateful service, state data (for example, scene data is needed in the game process) is acquired, and the state data is stored to a new schedule in the migrated second stateful service, so that the situation that data is missed and the game is down is avoided.

In some embodiments, before migrating the coroutine of the first stateful service into the second stateful service, determining the number of coroutine service requests; when the number of coroutine service requests is less than the number threshold, determining that an operation of migrating a coroutine of a first stateful service into a second stateful service is to be performed.

For example, although the service processing method provided by the embodiment of the present application has a fast migration speed and a small impact on the player, and the update is performed without waiting for a small number of online users, so that the real-time performance is good. However, in order to avoid unpredictable system errors, the migration operation can be triggered when the service requests are less, so that the migration burden is reduced as much as possible.

In some embodiments, before migrating the protocol of the first stateful service to the second stateful service, determining the network quality of the first stateful service in the operation process; when the network quality is greater than the quality threshold, determining that an operation of migrating the protocol of the first stateful service into the second stateful service is to be performed.

For example, although the service processing method provided by the embodiment of the present application has a fast migration speed and a small impact on the player, and is updated without waiting for a small number of online players, the real-time performance is good. However, in order to avoid unpredictable system errors, the migration operation can be triggered when the network quality is good, so that the safety and the speed of migration are improved as much as possible.

In step 104, the transferred coroutine of the second stateful service executes the corresponding coroutine service request.

For example, after the coroutine migration is successful, the first stateful service will not be available, and then the coroutine of the migrated second stateful service executes the corresponding coroutine service request to process the coroutine service request through the updated stateful service.

In some embodiments, in a first stateful service migration process, a new coroutine service request for a coroutine is cached to a scheduling node; and after the migration of the first stateful service is finished, the migrated second stateful service acquires a new coroutine service request from the scheduling node and executes the new coroutine service request.

For example, before the first stateful service migration, an old coroutine service request for coroutines is added into a task queue of a shared memory message channel, while in the first stateful service migration process, a new coroutine service request for coroutines is cached to a scheduling node, and after the first stateful service migration is completed, a second stateful service after migration acquires the new coroutine service request from the scheduling node and executes the new coroutine service request. Therefore, the new coroutine service request is cached firstly, and is executed after the migration is completed, so that the increase of the calculated amount in the migration process is avoided, and the migration speed is improved.

Next, an exemplary application of the embodiment of the present application in a practical application scenario will be described.

The embodiment of the application can be applied to service updating scenes of various games, such as a game of fighting, a racing game, a change game and the like.

The following description takes a virtual scene as an example:

with the rapid development of the mobile game industry in recent years, in order to cope with the problem that the consumption speed of game contents by players is too high, and to attract players and retain players, the game side is required to continuously update game contents. The updating of the state service is used as a main carrier of the game service, and the online updating technology is always the key point and the difficulty in the game background design.

In the related technology, all players are directly kicked by the halt updating so as to update the service, and all the services are unavailable during the halt updating, so that the experience of the players is seriously influenced; the service is gradually updated by adopting a gray release manner, but some compatibility problems need to be processed, such as special processing of some business logic under the condition that new and old versions exist at the same time, in addition, some redundant gray machine resources are needed in the updating process, and the gray release is time-consuming.

In order to solve the above problems, embodiments of the present application provide a method for updating stateful game background services (i.e., a service processing method) based on Golang protocol migration, where Golang is used as a programming language, the method has high real-time performance, has little impact on players, is friendly to operation and maintenance, and is suitable for online updating of most stateful game services.

It should be noted that the rich community ecology of the golden language, the excellent modern programming language design and the like attract a plurality of developers, and the golden language has wide application in various internet fields, particularly, the threshold of writing concurrent programs is greatly reduced by the language-level support protocol, and the development efficiency is greatly improved.

The method for updating the stateful game background service based on the Golang protocol migration provided by the embodiment of the application is specifically described as follows:

as shown in the framework diagram of fig. 6, the status data of the player is divided into login status data and game process data, wherein the login status data of the player is maintained on the scheduling node, and the backend process caches the status data of the player in the online process. The scheduling node communicates with the backend stateful services (including the old stateful service and the new stateful service) through a shared Memory Message PIPE (sharpe). The method comprises the steps that a service request of a game client is sent to a scheduling node firstly, the scheduling node routes the service request to a rear-end stateful service, response data are returned to players through the scheduling node after the rear-end stateful server finishes processing, wherein the rear-end stateful service is provided with a Golay protocol for processing the service request of the players and maintains the life cycle of player objects.

As shown in fig. 6, the go1 coroutine and the go2 coroutine in the old stateful service are coroutines already migrated and completed in the old stateful service, the go3 coroutine, the go4 coroutine and the go5 coroutine in the old stateful service are coroutines currently migrated in the old stateful service, the go1 coroutine and the go2 coroutine in the new stateful service are coroutines already migrated and completed in the new stateful service, and the go6 coroutine and the go7 coroutines in the new stateful service are new coroutines generated in the migration process (new players generated in the corresponding migration process).

As shown in fig. 7, the method for updating stateful game background services based on gold protocol migration provided in the embodiment of the present application includes four steps, which are respectively service registration, lossless migration of player-oriented protocol (i.e. gold protocol), exiting of old stateful service, and updating of state of scheduling node, and the four steps are specifically described below:

step 1, service registration: before a new stateful service (also called new stateful service) registers a service with a scheduling node, ownership of a shared memory message pipe must be obtained through file persistent lock, and then registration information is transmitted to the shared memory message pipe to complete registration of the new stateful service.

As shown in fig. 7, the service registration step specifically includes the following steps:

step 11, the old stateful service sends a heartbeat request to the scheduling node.

And step 12, after receiving the heartbeat request, the scheduling node sends a heartbeat response to the old stateful service.

The heartbeat request is a data packet sent to the scheduling node at intervals, and whether a communication link between the old state service and the scheduling node is connected or not is judged through the heartbeat response of the scheduling node.

And step 13, starting service by the newly-existing state service.

Step 14, the new stateful service sends a registration request (also called registration message) of the new stateful service to the scheduling node.

And step 15, the scheduling node sends a registration response of the new stateful service to the new stateful service.

Step 16, the scheduling node sets the new stateful service as available.

When the scheduling node determines that the registration request of the new stateful service is legal, a response of successful registration is returned to the new stateful service, the new stateful service is set to be available, and the fact that the migration flow based on the coroutine needs to be entered is represented.

Step 2, player-oriented collaborative lossless migration: when receiving a new service registration, the scheduling node will start to drive the player coroutines on the old stateful service to enter a coroutine-based migration flow by taking the coroutines as a unit.

As shown in FIG. 7, the player oriented protocol lossless migration step specifically comprises the following steps:

and step 21, the scheduling node sends a notification message to the old stateful service to notify the old stateful service to start protocol migration.

The notification message is used for indicating the old stateful service to perform the protocol migration.

Step 22, the scheduling node caches the player request sent to the coroutine during the migration process.

It should be noted that, during the migration process, new player requests may be additionally generated, and these player requests are not sent to the coroutines of the old stateful service, but are cached by the scheduling node, and after the migration is completed, are processed by the coroutines of the new stateful service.

Step 23, the legacy stateful service processes the session remainder message (i.e., the player request).

And 24, after the old stateful service processes the remaining coroutine messages, sending coroutine migration success messages to the scheduling nodes.

The protocol migration success message is used for representing the protocol migration success of the old stateful service, and the new stateful service can be logged in.

And step 25, the scheduling node sends a protocol migration success message to the new stateful service.

The protocol migration success message is used for representing protocol migration success of the old stateful service and indicating login of the new stateful service.

Step 26, the scheduling node sends the player request to the coroutine, which is cached in the migration process, to the new stateful service.

Step 27, the new stateful service initializes the coroutines and begins processing buffered messages (i.e., buffered player requests to coroutines).

And 3, exiting the old stateful service: the old stateful service checks the number of the player coroutines all the time after starting the coroutine migration, and automatically quits the process when the number of the player coroutines is reduced to 0.

As shown in fig. 7, the old stateful service exiting step specifically includes the following steps:

step 31, the old stateful service judges whether all coroutines have been successfully migrated.

And step 32, when all coroutines are successfully migrated, the old stateful service automatically exits the process.

Step 4, updating the state of the scheduling node: and after all the player coroutines are successfully migrated, the service state is modified to be in normal operation, and the old state service is set to be unavailable.

As shown in fig. 7, the step of updating the state by the scheduling node specifically includes the following steps:

step 41, the scheduling node sets the old stateful service as unavailable.

Step 42, the new stateful service sends a heartbeat request to the scheduling node.

And step 43, after receiving the heartbeat request, the scheduling node sends a heartbeat response to the new stateful service.

The heartbeat request is a data packet sent to the scheduling node at intervals, and whether a communication link between the new stateful service and the scheduling node is connected or not is judged through the heartbeat response of the scheduling node.

It should be noted that there are 4 shared memory message channels in 2 pairs between the scheduling node and each backend stateful service (including the new stateful service and the old stateful service), and communication between the backend stateful service and the scheduling node must be performed by monopolizing one of the shared memory message channels. Since the new stateful service and the old stateful service need to be operated simultaneously in the migration process, in order to distinguish the new stateful service from the old stateful service, it is necessary to distinguish the new stateful service from the old stateful service in terms of configuration. Once the configuration is differentiated, the service process Identification (ID) is differentiated, i.e. the service process reads a different configuration. Once the process ID is distinguished, the operation and maintenance daily operation is burdened. To solve the problem, in the embodiment of the present application, a file renewal lock (file lock for short) is introduced to solve the problem of distinguishing between a new stateful service and an old stateful service, 2 files are provided between each stateful service process and a scheduling node, and correspond to 2 pairs of shared memory message channels, where the file renewal lock is specifically described below:

As shown in fig. 8, the service registration step based on the file renewal lock specifically includes the following steps:

step 11, the new stateful service sends an ownership request to file 1 (clipipe 1).

Step 12, the new stateful service determines that file 1 is already occupied.

Before the new stateful service occupies file 1, file 1 is occupied by the old stateful service, and the shmppie 1 is occupied by the old stateful service.

Step 13, the new stateful service sends an ownership request to the file 2 (shmppie 2).

And step 14, the new stateful service determines that the file 2 is not occupied, and the file 2 is successfully occupied.

Before the new stateful service occupies the file 2, the file 2 is not occupied, and is in an idle state, the new stateful service successfully occupies the file 2, and the clipipe 2 is occupied by the new stateful service.

And step 15, the scheduling node initiates registration to the new stateful service through the clipipe 2.

It should be noted that after the stateful service is started (e.g. the new stateful service in fig. 8), the system function is sequentially called to try to occupy the file lock, and if the file is found to be unoccupied, the file ownership of the file is occupied at this time, and the version number of the occupant (i.e. the version number of the stateful service) and the expiration timestamp of the file lock are written. When the exclusive file is successful, a Golang protocol is required to be created to regularly update the expiration timestamp of the file. For example, the time interval for periodically updating the file's expiration timestamp is 30 seconds, while the file lock expiration timestamp is set to the current timestamp plus 60 seconds.

After the ownership of the file is successfully acquired, the new stateful service sends a registration message to the corresponding shared memory message channel to register the stateful service. In order to ensure that the function of the new stateful service is changed, the calling node performs coroutine migration according to the version number in the registration message and 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 in a service list, and the new stateful service is set to be in migration.

It should be noted that, after each player successfully logs in, a Golang protocol is created on the backend stateful service for processing the message of the player, where the stateful service and the protocol are in a one-to-many relationship. The coroutine has a task queue for storing the messages sent to the player by the scheduling node, and the coroutine completes corresponding functions by continuously processing the messages (player requests) in the task queue.

As shown in fig. 9, taking coroutine 1 as an example, the player-oriented coroutine lossless migration step is specifically described:

and step 21, the scheduling node sends a notification message to the old stateful service to notify the old stateful service to start the coroutine 1 migration.

Wherein, the notification message is used to instruct the old stateful service to perform coroutine 1 migration.

Step 22, the scheduling node caches the player request sent to coroutine 1 in the migration process.

It should be noted that, during the migration process, additional player requests of coroutine 1 may be generated, these player requests are not sent to coroutine 1 of the old stateful service, but are cached by the scheduling node, and after the migration of coroutine 1 is completed, coroutine 1 of the new stateful service processes the request.

Step 23, the old stateful service processes the remaining messages (i.e., player requests) in the coroutine 1 task queue.

And step 24, after the old stateful service processes the residual message of the coroutine 1, the coroutine 1 in the old stateful service exits without damage, and sends a successful message of the migration of the coroutine 1 to the scheduling node.

The protocol 1 migration success message is used for representing the protocol 1 migration success of the old stateful service, and the new stateful service can be logged in.

And step 25, the scheduling node sends a coroutine 1 migration success message to the new stateful service.

The protocol 1 migration success message is used for representing the protocol 1 migration success of the old stateful service and indicating the login of the new stateful service.

And step 26, the scheduling node sends the player request which is sent to coroutine 1 and is cached in the migration process to the new stateful service.

Step 27, the new stateful service creates a new coroutine (corresponding to coroutine 1) and starts processing the buffered messages (i.e., buffered player requests to coroutine 1).

It should be noted that, when entering migration, a scheduling node takes a coroutine as a unit, where one process carries one stateful service, one process serves multiple players, and one player corresponds to one coroutine, and then one process has multiple coroutines, and notifies a player on the stateful service at the back end that the coroutine enters a migration state. In addition, if the scheduling node does not receive the old stateful service to confirm that the player session has migrated to the new stateful service, all messages (i.e., player requests) addressed to the player session are buffered to the scheduling node, for example, the messages addressed to the player session 1 in fig. 9 are buffered to the scheduling node first.

After the old stateful service receives the coroutine migration notification of the scheduling node, when it is determined that the coroutine needs to be migrated to the new stateful service, the coroutine state is set to be in lossless exit, for example, coroutine 1 in the old stateful service is set to be in lossless exit in fig. 9. In the state of lossless exit, the player coroutine first completely processes all the remaining messages in the task queue, then stores the data, and stores the key data (for example, the processing result corresponding to the message) into the database. When all the key data are successfully stored, a notification message is sent to the scheduling node to notify the player that the session is ready to be migrated to the new stateful service, and meanwhile, part of state data of the player session (for example, data required in the game process and temporary data in the game process) is carried on the notification message.

When the scheduling node confirms that the player coroutine can be transferred to the new stateful service, a notification message is sent to the new stateful service, and meanwhile, the player request and part of state data cached in the coroutine transfer process are sent to the new stateful service. After receiving the notification message, the new stateful service creates a new co-program as a player service, saves state data and immediately processes a player request in the migration process.

At this point, the player session has completed the entire migration process. All online player sessions can be migrated to the new stateful service by repeating the above operation (protocol 1 migration process) for all player sessions on the old stateful service.

In summary, the embodiment of the present application provides a method for online updating of stateful services, in which the updating scheme only needs to start a new stateful service to automatically complete the updating of the new stateful service and quit the old stateful service; the whole updating process is player cooperative, the migration of each player cooperative is not influenced mutually, the migration speed is high, and the influence on the players is small; as the number of the new state service and the old state service in the whole migration process is basically consistent, no additional machine is required to be provided in the migration process, and the updating can be performed without waiting for a small number of online persons, so that the real-time performance is good.

The service processing method provided in the embodiment of the present application has been described with reference to the exemplary application and implementation of the electronic device provided in the embodiment of the present application, and a scheme for implementing service processing by matching each module in the service processing apparatus 465 provided in the embodiment of the present application is continuously described below.

An obtaining module 4651, configured to obtain a first stateful service for updating; a registration module 4652, configured to perform registration processing on a stateful service 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 4653, configured to migrate, in the running process of the first stateful service, the coroutine of the first stateful service to the second stateful service to obtain the second stateful service after migration; a processing module 4654, configured to execute the corresponding coroutine service request through the migrated coroutine of the second stateful service.

In some embodiments, the registration module 4652 is further configured to invoke a dispatch node based on a stateful service to be registered corresponding to the first stateful service; performing registration verification processing on the service to be registered with the state through the scheduling node; and when the registration verification process is passed, performing registration process on the service with the state to be registered to obtain the second service with the state.

In some embodiments, the registration module 4652 is further configured to determine 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 the shared memory message channel corresponding to the file lock.

In some embodiments, the registration module 4652 is further configured to determine a plurality of candidate file locks corresponding to the first stateful service based on the first stateful service; performing occupation processing on the candidate file lock based on the to-be-registered stateful service corresponding to the first stateful service; and when the candidate file lock is not occupied, taking the candidate file lock as the file lock of the state service to be registered, and writing the version number of the state service to be registered into the file lock.

In some embodiments, the registration module 4652 is further configured to determine a registration message of the stateful service to be registered, where the registration message includes 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.

In some embodiments, the registering module 4652 is further configured to register the to-be-registered stateful service to a service list to obtain the second stateful service, and set the state of the second stateful service in coroutine migration when the version number of the to-be-registered stateful service is greater than the version number of the registered stateful service.

In some embodiments, the migration module 4653 is further configured to perform the following for any coroutine in the first stateful service: the protocol is transferred to the second stateful service in a lossless mode, so that a new protocol in the second stateful service after the protocol is transferred is obtained, and the new protocol corresponds to the protocol one to one; when the number of the coroutines in the first stateful service is zero, setting the state of the second stateful service after the migration into a normal operation state, and setting the state of the first stateful service into an unavailable state.

In some embodiments, the migration module 4653 is further configured to obtain at least one service request in a 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; and creating a new coroutine corresponding to the coroutine in the second stateful service, and storing a processing result of the service request through the new coroutine.

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

In some embodiments, before creating a new coroutine corresponding to the coroutine in the second stateful service, the migration module 4653 is further configured to send a notification message to the second stateful service when the service request does not exist in a task queue of the coroutine, where the notification message carries a processing result of the service request; determining, based on the notification message, that an operation to create a new coroutine in the second stateful service corresponding to the coroutine is to be performed.

In some embodiments, the migration module 4653 is further configured to obtain state data of the coroutine, where the state data includes scene data of a virtual scene; and storing the state data to the new coroutine in the second stateful service after the migration.

In some embodiments, the processing module 4654 is further configured to, during the first stateful service migration, cache a new coroutine service request for the coroutine to a scheduling node; and after the migration of the first stateful service is completed, the migrated second stateful service acquires the new coroutine service request from the scheduling node and executes the new coroutine service request.

In some embodiments, before the migrating the coroutine of the first stateful service into the second stateful service, the migration module 4653 is further configured to determine a number of the coroutine service requests; when the number of coroutine service requests is less than a number threshold, determining to perform operations of migrating the coroutine of the first stateful service into the second stateful service.

In some embodiments, before the migrating the protocol of the first stateful service into the second stateful service, the migration module 4653 is further configured to determine a network quality during the running of the first stateful service; when the network quality is greater than a quality threshold, determining that an operation of migrating the coroutine of the first stateful service into the second stateful service is to be performed.

Embodiments of the present application provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the 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 in the embodiment of the present application.

Embodiments of the present application provide a computer-readable storage medium storing executable instructions, which when executed by a processor, cause the processor to perform a service processing method provided by embodiments of the present application, for example, the service processing method as shown in fig. 3-5.

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

In some embodiments, executable instructions may be written in any form of programming language (including compiled or interpreted languages), in the form of programs, software modules, scripts or code, 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.

By way of example, executable instructions may correspond, but do not necessarily have to correspond, to files in a file system, and may be stored in a portion of a file that holds 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 that store one or more modules, sub-programs, or portions of code).

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

The above description is only an example of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A method for service processing, the method comprising:

obtaining a first stateful service for updating;

and executing a corresponding coroutine service request through the transferred coroutine of the second stateful service.

2. The method of claim 1, wherein the registering the stateful service based on the first stateful service to obtain a second stateful service comprises:

calling a scheduling node based on the to-be-registered stateful service corresponding to the first stateful service;

3. The method of claim 2, wherein invoking the scheduling node based on the to-be-registered stateful service corresponding to the first stateful service comprises:

determining a file lock of the state service to be registered based on the state service to be registered corresponding to the first state service;

4. The method of claim 3, wherein the determining the file lock of the stateful service to be registered based on the stateful service to be registered corresponding to the first stateful service comprises:

determining, based on the first stateful service, a plurality of candidate file locks corresponding to the first stateful service;

5. The method of claim 3, wherein invoking the scheduling node based on the shared memory message channel corresponding to the file lock comprises:

determining a registration message of the state service to be registered, wherein the registration message comprises a version number of the state service to be registered;

6. The method according to claim 2, wherein the registering the to-be-registered stateful service to obtain the second stateful service when the registration verification process passes comprises:

and when the version number of the state service to be registered is greater than the version number of the registered state service, registering the state service to be registered to a service list to obtain a second state service, and setting the state of the second state service in coroutine migration.

7. The method of claim 1, wherein migrating the coroutine of the first stateful service to the second stateful service to obtain the migrated second stateful service comprises:

performing the following for any coroutine in the first stateful service:

8. The method of claim 7, wherein said migrating the protocol to the second stateful service without loss to obtain a new protocol in the migrated second stateful service comprises:

acquiring at least one service request in a task queue of the coroutine;

9. The method of claim 8, wherein obtaining at least one service request in a task queue of the coroutine comprises:

when the first stateful service receives a migration request aiming at the coroutine, setting the state of the coroutine of the first stateful service into lossless exit, and acquiring at least one service request in a task queue of the coroutine from a shared memory message channel corresponding to the first stateful service;

10. The method of claim 8, wherein prior to creating a new coroutine in the second stateful service corresponding to the coroutine, the method further comprises:

when the service request does not exist in the task queue of the coroutine, sending a notification message to the second stateful service, wherein the notification message carries a processing result of the service request;

11. The method of claim 7, further comprising:

acquiring state data of the coroutine, wherein the state data comprises scene data of a virtual scene;

12. The method of claim 1, further comprising:

caching a new coroutine service request aiming at the coroutine to a scheduling node in the first stateful service migration process;

13. The method of claim 1, wherein prior to migrating the protocol of the first stateful service into the second stateful service, the method further comprises:

determining the number of coroutine service requests;

when the number of coroutine service requests is less than a number threshold, determining to perform operations of migrating the coroutine of the first stateful service into the second stateful service.

14. The method of claim 1, wherein prior to migrating the protocol of the first stateful service into the second stateful service, the method further comprises:

determining the network quality in the first stateful service operation process;

when the network quality is greater than a quality threshold, determining that an operation of migrating the coroutine of the first stateful service into the second stateful service is to be performed.

15. A service processing apparatus, characterized in that the apparatus comprises:

the migration module is used for migrating the coroutine of the first stateful service to the second stateful service in the running process of the first stateful service to obtain the second stateful service after migration;

16. An electronic device, characterized in that the electronic device comprises:

a memory for storing executable instructions;

a processor for implementing the service processing method of any one of claims 1 to 14 when executing executable instructions stored in the memory.

17. A computer-readable storage medium storing executable instructions for implementing the service processing method of any one of claims 1 to 14 when executed by a processor.

18. A computer program product comprising a computer program or instructions, characterized in that the computer program or instructions, when executed by a processor, implement the service processing method of any of claims 1 to 14.