CN107158705B - 服务的更新方法和装置 - Google Patents

Abstract

本发明公开了一种服务的更新方法和装置。其中，该方法包括：在服务器上提供游戏应用服务，服务器为提供游戏应用服务所执行的可执行文件为第一可执行文件，游戏应用服务的上下文数据由第一可执行文件处理；接收到更新请求，更新请求用于请求对服务器提供的游戏应用服务进行更新；响应于更新请求，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件；在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据。本发明解决了相关技术中在对游戏服务器的游戏应用服务进行更新时需要中断所提供的游戏应用服务的技术问题。

Description

服务的更新方法和装置

技术领域

本发明涉及互联网领域，具体而言，涉及一种服务的更新方法和装置。

背景技术

大规模在线角色扮演游戏MMORPG(英文全称Massive Multi-User Online Role-Playing Game)作为一种历史悠久的游戏类型，在网游界中占有非常重要的地位。MMORPG服务器逻辑复杂，在超高的复杂度的前提下，既要保持高承载，又要保持高可用性，同时，在激烈竞争的市场条件下，和以往的单机游戏以年为周期的更新频率不同，MMORPG游戏的版本迭代更新十分频繁，为了更快的推出新内容吸引玩家，更新速度甚至可以达到一周一次。由于MMORPG的复杂性，高频率的更新会导致内容无法做到完整的测试覆盖，线上故障成为高概率事件。但同时，玩家对于服务质量的要求也在不断提升，为了满足玩家的需求，游戏服务器力求做到在线服务不中断。上述种种需求，对开发者以及运营者都是非常大的挑战，但是，目前还没有实现服务更新时保证服务不中断的技术方案。

针对相关技术中在对游戏服务器的游戏应用服务进行更新时需要中断所提供的游戏应用服务的技术问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种服务的更新方法和装置，以至少解决相关技术中在对游戏服务器的游戏应用服务进行更新时需要中断所提供的游戏应用服务的技术问题。

根据本发明实施例的一个方面，提供了一种服务的更新方法，该更新方法包括：在服务器上提供游戏应用服务，其中，服务器为提供游戏应用服务所执行的可执行文件为第一可执行文件，游戏应用服务的上下文数据由第一可执行文件处理；接收到更新请求，其中，更新请求用于请求对服务器提供的游戏应用服务进行更新；响应于更新请求，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件；在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据。

根据本发明实施例的另一方面，还提供了一种服务的更新装置，该更新装置包括：服务单元，用于在服务器上提供游戏应用服务，其中，服务器为提供游戏应用服务所执行的可执行文件为第一可执行文件，游戏应用服务的上下文数据由第一可执行文件处理；接收单元，用于接收到更新请求，其中，更新请求用于请求对服务器提供的游戏应用服务进行更新；更新单元，用于响应于更新请求，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件；处理单元，用于在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据。

在本发明实施例中，在接收到更新请求时，在服务器提供的游戏应用服务不中断的情况下，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件，在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据，可以解决相关技术中在对游戏服务器的游戏应用服务进行更新时需要中断所提供的游戏应用服务的技术问题，进而达到了对游戏服务器进行更新时不中断所提供的游戏服务的技术效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的服务的更新方法的硬件环境的示意图；

图2是根据本发明实施例的一种可选的服务的更新方法的流程图；

图3是根据本发明实施例的一种可选的服务架构的示意图；

图4是根据本发明实施例的一种可选的服务的更新方法的流程图；

图5是根据本发明实施例的一种可选的服务更新的示意图；

图6是根据本发明实施例的一种可选的服务的更新方法的流程图；

图7是根据本发明实施例的一种可选的服务的更新装置的示意图；以及

图8是根据本发明实施例的一种终端的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本发明实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

网络游戏，英文名称为Online Game，又称“在线游戏”，简称“网游”。指以互联网为传输媒介，以游戏运营商服务器和用户计算机为处理终端，以游戏客户端软件为信息交互窗口的旨在实现娱乐、休闲、交流和取得虚拟成就的具有可持续性的个体性多人在线游戏。

大规模在线角色扮演游戏(MMORPG)，英文全称Massive Multi-User OnlineRole-Playing Game，是一种游戏类型。在游戏中，玩家扮演虚拟世界中的一个或者几个队员角色在特定场景下进行游戏。

网络游戏客户端(Game Client)，是指与网络游戏服务器相对应，为客户提供本地服务的程序，一般安装在普通的用户机上，需要与服务端互相配合运行。

网络游戏服务器(Game Server)，是指与网络游戏客户端相对应、安装在IDC中、为网络游戏客户端提供数据转发与逻辑处理服务的软件程序。

IDC为互联网内容提供商(ICP)、企业、媒体和各类网站提供大规模、高质量、安全可靠的专业化服务器托管、空间租用、网络批发带宽以及ASP、EC等业务。IDC是对入驻(Hosting)企业、商户或网站服务器群托管的场所；是各种模式电子商务赖以安全运作的基础设施，也是支持企业及其商业联盟(其分销商、供应商、客户等)实施价值链管理的平台。

强状态进程，指进程运行过程中，需要记录存储大量的上下文数据的一种进程。此类进程向外提供的服务依赖于上下文数据，一旦进程崩溃丢失数据，则在线服务将中断。

弱状态进程，弱状态进程是指，运行过程中，不记录或者只记录很少量的上下文数据的一种进程。此类进程对外提供的服务不依赖于或者弱依赖于上下文数据。即使进程崩溃，由于不需要保存数据(或者数据可以在重启进程时简单恢复)，只需要重启进程，即可恢复在线服务。

服务器可用性，指服务器整体对外提供服务的稳定性的一种度量。

热更新，热更新即为在程序不停止提供服务的情况下，完成功能的升级或者切换的一种方法。

宕机，指操作系统无法从一个严重系统错误中恢复过来，或系统硬件层面出问题，以致系统长时间无响应，而不得不重新启动计算机的现象。它属于电脑运作的一种正常现象，任何电脑都会出现这种情况。

动态链接库文件，是一种不可执行的二进制程序文件，它允许程序共享执行特殊任务所必需的代码和其他资源。Windows提供的DLL文件中包含了允许基于Windows的程序在Windows环境下操作的许多函数和资源。Linux系统中常常是“.so”的文件。

实施例1

根据本发明实施例，提供了一种服务的更新方法的方法实施例。

可选地，在本实施例中，上述服务的更新方法可以应用于如图1所示的由服务器102和终端104所构成的硬件环境中。如图1所示，服务器102通过网络与终端104进行连接，上述网络包括但不限于：广域网、城域网或局域网，终端104并不限定于PC、手机、平板电脑等。本发明实施例的服务的更新方法可以由服务器102来执行，也可以由终端104来执行，还可以是由服务器102和终端104共同执行。其中，终端104执行本发明实施例的服务的更新方法也可以是由安装在其上的客户端来执行。

当本发明实施例的服务的更新方法由服务器或终端来执行时，直接在服务器或终端执行与服务的更新方法对应的程序即可。

当本发明实施例的服务的更新方法由服务器和终端来共同执行时，需要二者进行相关信息的交互，如终端将更新请求发送给服务器。再由服务器来执行相关的步骤，下面结合图2进行详细说明：

图2是根据本发明实施例的一种可选的服务的更新方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤S202，在服务器上提供游戏应用服务，服务器为提供游戏应用服务所执行的可执行文件为第一可执行文件，游戏应用服务的上下文数据由第一可执行文件处理。

上述的服务器为用于提供游戏应用服务的服务器，可在游戏设备上安装游戏应用的客户端，再由服务器为游戏设备上的游戏应用提供服务。

用户可以直接在服务器上对所提供的游戏应用服务进行管理(包括更新、删除、暂停等)，也可以通过与服务器通讯连接的其它终端来对其进行管理。

步骤S204，接收到更新请求，更新请求用于请求对服务器提供的游戏应用服务进行更新。

上述的更新请求即用户在终端或者在服务器上进行更新时所触发的请求。

可选地，上述更新请求还是可以是服务器或终端自动触发的，如服务器或终端按照预先设置的定时更新策略自动触发的更新请求。

步骤S206，响应于更新请求，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件。

需要说明的是，服务器是在提供的游戏应用服务不中断的情况下，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件。

上述的游戏应用服务不中断包括两个方面：其一是服务器本身能够在不中断或者中断时间极短(几乎可以忽略不计)的情况下，持续为用户提供游戏服务；其二是在游戏设备上感知不到游戏应用服务的中断，例如在游戏的过程中进行更新时，用户可以不中断地进行游戏，而不丢失游戏数据。

从方案实际实现的过程来看，在接收到更新请求前，游戏应用服务所执行的可执行文件为第一可执行文件，也即游戏应用服务由第一可执行文件提供，在将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件的过程中，也即完成更新之前，游戏应用服务可继续由第一可执行文件提供(也即在第二可执行文件正是提供游戏应用服务前，游戏应用服务可以由第一可执行文件提供)，在完成更新时，游戏应用服务由第二可执行文件提供，从而实现游戏应用服务的不中断。

上述的可执行文件为在服务器上可执行的文件，具体类型可以根据服务器所采用的操作系统确定，例如在服务器的操作系统为windows时，对应的可执行文件为windows系统所支持的可执行文件(如“.exe”文件)；在服务器的操作系统为linux时，对应的可执行文件为linux系统所支持的可执行文件(如用字符“x”标识的文件)。

上述的可执行文件即用于提供游戏应用服务的可执行文件，具体可以通过执行该可执行文件来提供游戏应用服务。

步骤S208，在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据。

也即，在可执行文件的更新完成之后，由第二可执行文件使用之前由第一可执行文件处理的上下文数据，按照以前的上下文数据继续为游戏设备提供服务，对于终端而言，游戏应用的过程中所使用的数据(上下文数据)并未发生改变，即使发生服务更新，也不会影响当前的游戏，可继续使用更新前的游戏数据进行游戏，这样服务器就可在不间断服务的情况下进行服务更新。

通过上述步骤S202至步骤S208，在接收到更新请求时，在服务器提供的游戏应用服务不中断的情况下，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件，在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据，可以解决相关技术中在对游戏服务器的游戏应用服务进行更新时需要中断所提供的游戏应用服务的技术问题，进而达到了对游戏服务器进行更新时不中断所提供的游戏服务的技术效果。

本申请的方法可以应用于各类游戏应用服务的更新，下面以MMORPG类游戏为例进行说明。

由于MMORPG的复杂性，高频率的更新会导致内容无法做到完整的测试覆盖，线上故障成为高概率事件，但同时，玩家对于服务质量的要求也在不断提升，为了满足玩家的需求，游戏服务器力求做到7x24小时(一周二十四小时)在线提供服务而不中断，上述种种需求，对开发者以及运营者都是非常大的挑战。在这些要求下，MMORPG服务器的实现往往不是一个简单的进程，而是一套复杂的大规模分布式系统，典型的MMORPG服务器构架如图3所示：

包括主服务器(公共服务器MASTER)上的目录服务、版本升级、帐号服务、存储服务器(及其热备设备)，以及用于管理这些服务的客户端CLIENT，主服务器用于管理相应的从服务器(如玄海岸服)，从服务器用于具体提供相关的游戏服务，其包括帐号服务(与相应的数据库连接)、接入层、邮件服务(与相应的数据库连接)、场景交换服务等。

区别于休闲类的ACG游戏(动漫风格游戏的简称，诸如卡牌、三消类游戏)，MMORPG游戏逻辑复杂，诸如场景服务器(scene)、全局服务器(world)等进程都是强状态进程，需要在内存中保存大量实时的复杂运行数据，因为这些强状态进程的存在，MMORPG游戏服务器的在线更新非常难以实现。

当强状态的服务器程序在线上运行出现问题时，如果直接更新程序文件并重启，会造成内存中的数据丢失，导致服务中断，因此无法进行在线更新程序文件的热更新。如何在不影响用户体验的情况下进行强状态服务器的在线热更新修复，一直是业界难题。

本申请提出了一种可以适用于强状态服务器的热更新方案，可以在用户无感知的情况下，实现对于强状态的服务器进程的在线热更新，且对开发侧的额外要求非常低，极大增强了系统的可用性以及可维护性，对于提高服务质量有着重要的意义。下面结合具体步骤详述本发明的实施例：

在步骤S204提供的技术方案中，服务器接收到对服务器提供的游戏应用服务进行更新的更新请求。

在步骤S206提供的技术方案中，在服务器提供的游戏应用服务不中断的情况下，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件包括：

步骤S2062，在服务器上创建用于执行第二可执行文件的第二进程；

步骤S2064，使用第二进程接替第一进程，继续对存储在共享存储空间中的游戏应用服务的上下文数据进行处理，第一进程是用于执行第一可执行文件的进程。

其中，在步骤S2062中，在服务器上创建用于执行第二可执行文件的第二进程时，可通过预设方式启动第二可执行文件，以创建用于执行第二可执行文件的第二进程，启动后的第二可执行文件在第二进程上执行，预设方式为第一可执行文件停止执行之后，在第一进程上恢复执行第一可执行文件所使用的方式。

上述的预设方式为第一进程上恢复执行第一可执行文件所使用的方式，不同的操作系统对应的方式不同，例如在linux操作系统中，可以使用resume方法来进行恢复。

需要说明的是，resume方法为恢复第一进程时使用的方法，而使用resume方法来创建第二进程，对于服务器而言，相当于还是按照以前的可执行文件来创建进程，只是对于服务器而言的可执行文件已经由第一可执行文件替换为了第二可执行文件，但是由于是采用resume的方式创建的，第二进程可以保留与第一进程相同的相关参数，而不用重新进行相关设置。

在步骤S2064中，在使用第二进程接替第一进程，继续对存储在共享存储空间中的游戏应用服务的上下文数据进行处理时，服务器使用第二进程继续对存储在共享存储空间中的第一上下文数据进行处理，在使用第二进程接替第一进程之前，存储在共享存储空间中的游戏应用服务的上下文数据已被第一进程处理为第一上下文数据。

可选地，在执行步骤S2062的在服务器上创建用于执行第二可执行文件的第二进程的同时或之后，建立第二进程与共享存储空间之间的关联关系，这样，在服务器使用第二进程继续对存储在共享存储空间中的第一上下文数据进行处理时，可从与第二进程具有关联关系的共享存储空间获取第一上下文数据；然后使用第二进程继续对第一上下文数据进行处理。

需要说明的是，在将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件之前，当第一可执行文件还在执行时，将第一进程对游戏应用服务的上下文数据的处理结果(即第一上下文数据)存储在共享存储空间中，以便于在发生游戏应用服务更新时，保证数据不会丢失，便于利用这些数据持续为用户提供服务，使得用户得到的服务不会中断，也即不使用新的游戏上下文数据重新开始游戏。

同理，对于第二进程而言，在使用第二进程接替第一进程，继续对存储在共享存储空间中的游戏应用服务的上下文数据进行处理之后，可将第二上下文数据存储在共享存储空间中，存储在共享存储空间中的游戏应用服务的第一上下文数据已被第二进程处理为第二上下文数据。便于在发生游戏应用服务更新时，保证数据不会丢失。

在步骤S208提供的技术方案中，以更新可执行文件的完成时刻为时间参考点，在将第一可执行文件更新为第二可执行文件之前，游戏应用服务的上下文数据由第一可执行文件处理，即第一可执行文件提供游戏应用服务，在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据，即第二可执行文件提供游戏应用服务。具体如何完成更新已经在前述内容中进行描述，在此不再赘述。

作为一种可选的实施例，针对原有方案的诸多缺陷，本申请提出了一种基于swapresume机制的强状态服务器进程在线热更新方案，下面结合图4和图5详述本申请的实施例：

步骤S402，进程运行过程中的上下文数据都存储于Share Memory(即共享内容)中。

步骤S404，当需要更新时，制作新的程序文件，上传至服务器替换原有程序文件(即为程序文件的交换swap过程)。

例如，如图5所示，在宕机发生时，定位到问题，并根据问题提供新的可执行文件(用于解决该问题)，然后将该可执行文件上传至服务器，以替换老的可执行文件，等待下次宕机时拉起(即下次关机重启时运行新的可执行文件)。宕机发生时使用新程序自动拉起，以恢复服务故障修复。

步骤S406，运维kill掉(即结束)当前老的正在运行的目标进程，然后以resume方式启动新的程序文件。

可选地，也可在宕机发生时，使用新的可执行文件(即程序)自动拉起运行。

上述的Resume方法用于继续执行已经挂起的线程。

步骤S408，新进程被使用attach方法贴附到原有share memory上，读取原有的上下文数据，接替老的目标进程继续提供服务(即为resume)。从而可以对故障进行修复，并恢复服务。

可选地，可以预先启动新的程序文件(即第二可执行文件)，并使用attach方法将新进程(即第二进程)贴附到原有share memory(即共享内存空间)上，在kill掉旧进程(第一进程)的同时，运行新进程，以保证服务的不中断。

在本申请的技术方案中，可针对性地对原有系统进行优化，在产品侧对玩家无影响，玩家无感知；由于提升了系统的整体可用性，当服务器出现故障时，玩家受影响的范围和时间会被缩小，客观上提升了玩家的游戏体验与整体服务质量，提升了游戏容灾能力与可用性，提升了应急响应能力，使得在线服务质量更高。

另外，本申请的方案对于开发侧的影响较少，将关键数据存储于Share Memory中即可，无需额外的注意事项，对开发人员要求低，对正常的开发流程无影响。

本发明还提供了一种优选实施例，该优选实施例可以在更新上下文数据时使用。

在Linux系统下，提供了共享库文件的功能，为了达到软件模块化的目的，可把逻辑上紧密相关的功能集中在一起，编译到的共享库中，这样做既有利于代码的管理，也便于模块的复用。同时，共享库的方式也有利于应用升级，某些时候，仅仅更新数个共享库文件就可以完成整个应用的升级，降低了升级时的开销。

共享库文件是由主程序文件运行时，使用dlopen(可用于使用指定模式打开指定的动态链接库文件)动态挂载的，这就意味着通过一些特别的操作，可以在更新共享库文件后，利用dlopen动态重新挂载更新过后的共享库文件，实现在线热更新。

具体在应用上述方法时，可以在步骤S208完成之后，在需要对游戏应用服务进行更新时，对第二进程的动态链接库文件直接进行更新。

利用该方法时，可以将需要更新的内容或者逻辑放置在第二进程的动态链接库文件中，下面结合图6详述本申请的实施例：

需要说明的是，基于共享库文件的在线热更新适用于较小的升级，以完成不重启的更新。更新过程中，由一个独立升级程序U来负责触发目标应用(由进程T来执行)挂载新的共享库文件L。

步骤S602，升级程序U找到进程T的dlopen函数的入口地址。

步骤S604，升级进程U执行attach系统调用，贴附到进程T上。向进程T的堆栈里压入新的共享库文件L的名字，再把dlopen函数的入口地址赋值给PC寄存器。

上述的attach是一种Linux下的将一个对象贴附到另一个对象上的方法。PC是16位程序计数器，专门用于在CPU取指令期间的寻址程序存储器。

步骤S606，让目标进程T继续运行，由于PC寄存器保存的是dlopen函数的入口地址，这样，在目标进程T空间里，dlopen函数被调用，新的共享库文件L被目标进程T装载。

步骤S608，新的共享库文件L在被装载时，利用dlsym函数在目标进程T中找到被替换函数的地址，设置被替换函数的代码空间为可写状态。

dlsym函数用于根据动态链接库操作句柄与符号，返回符号对应的地址，使用这个函数不但可以获取函数地址，也可以获取变量地址。

步骤S610，将汇编指令0xCC和0xC3写入被替换函数入口。显然，由于INT 3的存在，当目标进程T调用这个被替换函数时，就会触发一次SIGTRAP信号，SIGTRAP信号是当子进程执行到这个断点INT 3的时候，产生的信号。

上述的0xCC是汇编INT 3的指令码，0xC3是汇编RET的指令码(0xC3是64位系统的指令码)。

步骤S612，新的共享库文件L在被装载时，调用sigaction函数接管SIGTRAP信号。在信号处理函数中，调用用于代替被替换函数的新函数。

上述的sigaction函数的功能是检查或修改与指定信号相关联的处理动作。

通过上述步骤，新的共享库L的函数替代了目标进程T中原先使用的旧函数，每当目标进程T试图调用被替换函数时，都会触发SIGTRAP信号，然后，信号处理函数调用新的函数，这个过程将一直存在于进程T的整个生存周期中。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述服务的更新方法的服务的更新装置。图7是根据本发明实施例的一种可选的服务的更新装置的示意图，如图7所示，该装置可以包括：服务单元72、接收单元74、更新单元76以及处理单元78。

服务单元72，用于在服务器上提供游戏应用服务，其中，服务器为提供游戏应用服务所执行的可执行文件为第一可执行文件，游戏应用服务的上下文数据由第一可执行文件处理。

上述的服务器为用于提供游戏应用服务的服务器，可在游戏设备上安装游戏应用的客户端，再由服务器为游戏设备上的游戏应用提供服务。

用户可以直接在服务器上对所提供的游戏应用服务进行管理(包括更新、删除、暂停等)，也可以通过与服务器通讯连接的其它终端来对其进行管理。

接收单元74，用于接收到更新请求，更新请求用于请求对服务器提供的游戏应用服务进行更新。

上述的更新请求即用户在终端或者在服务器上进行更新时所触发的请求。

可选地，上述更新请求还是可以是服务器或终端自动触发的，如服务器或终端按照预先设置的定时更新策略自动触发的更新请求。

更新单元76，用于响应于更新请求，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件，在将第一可执行文件更新为第二可执行文件之前，游戏应用服务的上下文数据由第一可执行文件处理。

需要说明的是，服务器是在提供的游戏应用服务不中断的情况下，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件。

上述的游戏应用服务不中断包括两个方面：其一是服务器本身能够在不中断或者中断时间极短(几乎可以忽略不计)的情况下，持续为用户提供游戏服务；其二是在游戏设备上感知不到游戏应用服务的中断，例如在游戏的过程中进行更新时，用户可以不中断地进行游戏，而不丢失游戏数据。

从方案实际实现的过程来看，在接收到更新请求前，游戏应用服务所执行的可执行文件为第一可执行文件，也即游戏应用服务由第一可执行文件提供，在将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件的过程中，也即完成更新之前，游戏应用服务可继续由第一可执行文件提供，在完成更新时，游戏应用服务可由第二可执行文件提供(也即在第二可执行文件正是提供游戏应用服务前，游戏应用服务可以由第一可执行文件提供)，从而实现游戏应用服务的不中断。

上述的可执行文件为在服务器上可执行的文件，具体类型可以根据服务器所采用的操作系统确定，例如在服务器的操作系统为windows时，对应的可执行文件为windows系统所支持的可执行文件(如“.exe”文件)；在服务器的操作系统为linux时，对应的可执行文件为linux系统所支持的可执行文件(如用字符“x”标识的文件)。

上述的可执行文件即用于提供游戏应用服务的可执行文件，具体可以通过执行该可执行文件来提供游戏应用服务。

处理单元78，用于在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据。

也即，在可执行文件的更新完成之后，由第二可执行文件使用之前由第一可执行文件处理的上下文数据，按照以前的上下文数据继续为游戏设备提供服务，对于终端而言，游戏应用的过程中所使用的数据(上下文数据)并未发生改变，即使发生服务更新，也不会影响当前的游戏，可继续使用更新前的游戏数据进行游戏，这样服务器就可在不间断服务的情况下进行服务更新。

需要说明的是，该实施例中的服务单元72可以用于执行本申请实施例1中的步骤S202，该实施例中的接收单元74可以用于执行本申请实施例1中的步骤S204，该实施例中的更新单元76可以用于执行本申请实施例1中的步骤S206，该实施例中的处理单元78可以用于执行本申请实施例1中的步骤S208。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

通过上述模块，在接收到更新请求时，在服务器提供的游戏应用服务不中断的情况下，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件，在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据，可以解决相关技术中在对游戏服务器的游戏应用服务进行更新时需要中断所提供的游戏应用服务的技术问题，进而达到了对游戏服务器进行更新时不中断所提供的游戏服务的技术效果。

本申请的装置可以应用于各类游戏应用服务的更新，下面以MMORPG类游戏为例进行说明。

由于MMORPG的复杂性，高频率的更新会导致内容无法做到完整的测试覆盖，线上故障成为高概率事件，但同时，玩家对于服务质量的要求也在不断提升，为了满足玩家的需求，游戏服务器力求做到7x24小时(一周二十四小时)在线提供服务而不中断，上述种种需求，对开发者以及运营者都是非常大的挑战。在这些要求下，MMORPG服务器的实现往往不是一个简单的进程，而是一套复杂的大规模分布式系统，典型的MMORPG服务器构架如图3所示：

包括主服务器(公共服务器MASTER)上的目录服务、版本升级、帐号服务、存储服务器(及其热备设备)，以及用于管理这些服务的客户端CLIENT，主服务器用于管理相应的从服务器(如玄海岸服)，从服务器用于具体提供相关的游戏服务，其包括帐号服务(与相应的数据库连接)、接入层、邮件服务(与相应的数据库连接)、场景交换服务等。

区别于休闲类的ACG游戏(动漫风格游戏的简称，诸如卡牌、三消类游戏)，MMORPG游戏逻辑复杂，诸如场景服务器(scene)、全局服务器(world)等进程都是强状态进程，需要在内存中保存大量实时的复杂运行数据，因为这些强状态进程的存在，MMORPG游戏服务器的在线更新非常难以实现。

当强状态的服务器程序在线上运行出现问题时，如果直接更新程序文件并重启，会造成内存中的数据丢失，导致服务中断，因此无法进行在线更新程序文件的热更新。如何在不影响用户体验的情况下进行强状态服务器的在线热更新修复，一直是业界难题。

本申请提出了一种可以适用于强状态服务器的热更新方案，可以在用户无感知的情况下，实现对于强状态的服务器进程的在线热更新，且对开发侧的额外要求非常低，极大增强了系统的可用性以及可维护性，对于提高服务质量有着重要的意义。

可选地，上述的更新单元包括：创建模块，用于创建用于执行第二可执行文件的第二进程；处理模块，用于使用第二进程接替第一进程，继续对存储在共享存储空间中的游戏应用服务的上下文数据进行处理，其中，第一进程是用于执行第一可执行文件的进程。

可选地，上述的处理模块还用于：使用第二进程继续对存储在共享存储空间中的第一上下文数据进行处理，其中，在使用第二进程接替第一进程之前，存储在共享存储空间中的游戏应用服务的上下文数据已被第一进程处理为第一上下文数据。

可选地，更新单元还包括：关联模块，用于在创建用于执行第二可执行文件的第二进程的同时或之后，建立第二进程与共享存储空间之间的关联关系；处理模块还用于：从与第二进程具有关联关系的共享存储空间获取第一上下文数据；使用第二进程继续对第一上下文数据进行处理。

可选地，该装置还可以存储单元，用于在使用第二进程接替第一进程，继续对存储在共享存储空间中的游戏应用服务的上下文数据进行处理之后，将第二上下文数据存储在共享存储空间中，其中，存储在共享存储空间中的游戏应用服务的第一上下文数据已被第二进程处理为第二上下文数据。

可选地，创建模块还用于：通过预设方式启动第二可执行文件，以创建用于执行第二可执行文件的第二进程，其中，启动后的第二可执行文件在第二进程上执行，预设方式为第一可执行文件停止执行之后，在第一进程上恢复执行第一可执行文件所使用的方式。

在上述实施例中，所涉及的单元或模块时与前述方法实施例中的方法步骤所对应的，这些单元或模块的具体工作方式可以参照前述的方法实施例，在此不再赘述。

在本申请的技术方案中，可针对性地对原有系统进行优化，在产品侧对玩家无影响，玩家无感知；由于提升了系统的整体可用性，当服务器出现故障时，玩家受影响的范围和时间会被缩小，客观上提升了玩家的游戏体验与整体服务质量，提升了游戏容灾能力与可用性，提升了应急响应能力，使得在线服务质量更高。

另外，本申请的方案对于开发侧的影响较少，将关键数据存储于Share Memory中即可，无需额外的注意事项，对开发人员要求低，对正常的开发流程无影响。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

实施例3

根据本发明实施例，还提供了一种用于实施上述服务的更新方法的服务器或终端(即上述的电子装置)。

图8是根据本发明实施例的一种终端的结构框图，如图8所示，该终端可以包括：一个或多个(图中仅示出一个)处理器801、存储器803、以及传输装置805，如图8所示，该终端还可以包括输入输出设备807。

其中，存储器803可用于存储软件程序以及模块，如本发明实施例中的服务的更新方法和装置对应的程序指令/模块，处理器801通过运行存储在存储器803内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的服务的更新方法。存储器803可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器803可进一步包括相对于处理器801远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置805用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置805包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置805为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器803用于存储应用程序。

处理器801可以通过传输装置805调用存储器803存储的应用程序，以执行下述步骤：在服务器上提供游戏应用服务，其中，服务器为提供游戏应用服务所执行的可执行文件为第一可执行文件，游戏应用服务的上下文数据由第一可执行文件处理；接收到更新请求，其中，更新请求用于请求对服务器提供的游戏应用服务进行更新；响应于更新请求，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件；在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据。

处理器801还用于执行下述步骤：创建用于执行第二可执行文件的第二进程；使用第二进程接替第一进程，继续对存储在共享存储空间中的游戏应用服务的上下文数据进行处理，其中，第一进程是用于执行第一可执行文件的进程。

采用本发明实施例，在接收到更新请求时，在服务器提供的游戏应用服务不中断的情况下，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件，在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据，可以解决相关技术中在对游戏服务器的游戏应用服务进行更新时需要中断所提供的游戏应用服务的技术问题，进而达到了对游戏服务器进行更新时不中断所提供的游戏服务的技术效果。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图8所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices，MID)、PAD等终端设备。图8其并不对上述电子装置的结构造成限定。例如，终端还可包括比图8中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图8所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

实施例4

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行服务的更新方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

S11，在服务器上提供游戏应用服务，服务器为提供游戏应用服务所执行的可执行文件为第一可执行文件，游戏应用服务的上下文数据由第一可执行文件处理；

S12，接收到更新请求，更新请求用于请求对服务器提供的游戏应用服务进行更新；

S13，响应于更新请求，在服务器提供的游戏应用服务不中断的情况下，将服务器为提供游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件，其中，在将第一可执行文件更新为第二可执行文件之前，游戏应用服务的上下文数据由第一可执行文件处理；

S14，在将第一可执行文件更新为第二可执行文件之后，通过第二可执行文件处理游戏应用服务的上下文数据。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

S21，创建用于执行第二可执行文件的第二进程；

S22，使用第二进程接替第一进程，继续对存储在共享存储空间中的游戏应用服务的上下文数据进行处理，其中，第一进程是用于执行第一可执行文件的进程。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (14)

1.一种服务的更新方法，其特征在于，包括：

在服务器上提供游戏应用服务，其中，所述服务器为提供所述游戏应用服务所执行的可执行文件为第一可执行文件，所述游戏应用服务的上下文数据由所述第一可执行文件处理；

接收到更新请求，其中，所述更新请求用于请求对所述服务器提供的所述游戏应用服务进行更新；

响应于所述更新请求，将所述服务器为提供所述游戏应用服务所执行的可执行文件由所述第一可执行文件更新为第二可执行文件；

在将所述第一可执行文件更新为所述第二可执行文件之后，通过所述第二可执行文件处理所述游戏应用服务的上下文数据；

其中，在将所述服务器为提供所述游戏应用服务所执行的可执行文件由所述第一可执行文件更新为第二可执行文件的过程中，完成更新之前，所述游戏应用服务由所述第一可执行文件提供，在完成更新时，所述游戏应用服务由所述第二可执行文件提供，以使所述游戏应用服务不中断。

2.根据权利要求1所述的方法，其特征在于，将所述服务器为提供所述游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件包括：

创建用于执行所述第二可执行文件的第二进程；

使用所述第二进程接替第一进程，继续对存储在共享存储空间中的所述游戏应用服务的上下文数据进行处理，其中，所述第一进程是用于执行所述第一可执行文件的进程。

3.根据权利要求2所述的方法，其特征在于，使用所述第二进程接替第一进程，继续对存储在所述共享存储空间中的所述游戏应用服务的上下文数据进行处理包括：

使用所述第二进程继续对存储在所述共享存储空间中的第一上下文数据进行处理，其中，在使用所述第二进程接替第一进程之前，存储在所述共享存储空间中的所述游戏应用服务的上下文数据已被所述第一进程处理为所述第一上下文数据。

4.根据权利要求3所述的方法，其特征在于，

在创建用于执行所述第二可执行文件的第二进程的同时或之后，所述方法还包括：建立所述第二进程与所述共享存储空间之间的关联关系；

使用所述第二进程继续对存储在所述共享存储空间中的第一上下文数据进行处理包括：从与所述第二进程具有关联关系的所述共享存储空间获取所述第一上下文数据；使用所述第二进程继续对所述第一上下文数据进行处理。

5.根据权利要求2所述的方法，其特征在于，在使用所述第二进程接替第一进程，继续对存储在所述共享存储空间中的所述游戏应用服务的上下文数据进行处理之后，所述方法还包括：

将第二上下文数据存储在所述共享存储空间中，其中，存储在所述共享存储空间中的所述游戏应用服务的第一上下文数据已被所述第二进程处理为所述第二上下文数据。

6.根据权利要求2所述的方法，其特征在于，创建用于执行所述第二可执行文件的第二进程包括：

通过预设方式启动所述第二可执行文件，以创建用于执行所述第二可执行文件的所述第二进程，其中，启动后的所述第二可执行文件在所述第二进程上执行，所述预设方式为所述第一可执行文件停止执行之后，在所述第一进程上恢复执行所述第一可执行文件所使用的方式。

7.一种服务的更新装置，其特征在于，包括：

服务单元，用于在服务器上提供游戏应用服务，其中，所述服务器为提供所述游戏应用服务所执行的可执行文件为第一可执行文件，所述游戏应用服务的上下文数据由所述第一可执行文件处理；

接收单元，用于接收到更新请求，其中，所述更新请求用于请求对所述服务器提供的所述游戏应用服务进行更新；

更新单元，用于响应于所述更新请求，将所述服务器为提供所述游戏应用服务所执行的可执行文件由第一可执行文件更新为第二可执行文件；

处理单元，用于在将所述第一可执行文件更新为所述第二可执行文件之后，通过所述第二可执行文件处理所述游戏应用服务的上下文数据；

其中，在将所述服务器为提供所述游戏应用服务所执行的可执行文件由所述第一可执行文件更新为第二可执行文件的过程中，完成更新之前，所述游戏应用服务由所述第一可执行文件提供，在完成更新时，所述游戏应用服务由所述第二可执行文件提供，以使所述游戏应用服务不中断。

8.根据权利要求7所述的装置，其特征在于，所述更新单元包括：

创建模块，用于创建用于执行所述第二可执行文件的第二进程；

处理模块，用于使用所述第二进程接替第一进程，继续对存储在共享存储空间中的所述游戏应用服务的上下文数据进行处理，其中，所述第一进程是用于执行所述第一可执行文件的进程。

9.根据权利要求8所述的装置，其特征在于，所述处理模块还用于：

使用所述第二进程继续对存储在所述共享存储空间中的第一上下文数据进行处理，其中，在使用所述第二进程接替第一进程之前，存储在所述共享存储空间中的所述游戏应用服务的上下文数据已被所述第一进程处理为所述第一上下文数据。

10.根据权利要求9所述的装置，其特征在于，

所述更新单元还包括：关联模块，用于在创建用于执行所述第二可执行文件的第二进程的同时或之后，建立所述第二进程与所述共享存储空间之间的关联关系；

所述处理模块还用于：从与所述第二进程具有关联关系的所述共享存储空间获取所述第一上下文数据；使用所述第二进程继续对所述第一上下文数据进行处理。

11.根据权利要求8所述的装置，其特征在于，所述装置还包括：

存储单元，用于在使用所述第二进程接替第一进程，继续对存储在所述共享存储空间中的所述游戏应用服务的上下文数据进行处理之后，将第二上下文数据存储在所述共享存储空间中，其中，存储在所述共享存储空间中的所述游戏应用服务的第一上下文数据已被所述第二进程处理为所述第二上下文数据。

12.根据权利要求8所述的装置，其特征在于，所述创建模块还用于：

通过预设方式启动所述第二可执行文件，以创建用于执行所述第二可执行文件的所述第二进程，其中，启动后的所述第二可执行文件在所述第二进程上执行，所述预设方式为所述第一可执行文件停止执行之后，在所述第一进程上恢复执行所述第一可执行文件所使用的方式。

13.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序运行时执行所述权利要求1至6中任一项所述的方法。

14.一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器通过所述计算机程序执行所述权利要求1至6中任一项所述的方法。