服务器同步更新的方法、装置、计算机设备及存储介质
技术领域
本申请涉及大数据处理,尤其涉及一种服务器同步更新的方法、装置、计算机设备及存储介质。
背景技术
在应用服务的整个运行期间,如何保证应用服务器稳定、不间断地运行,对于提供服务的企业来说是至关重要的,特别是在应用服务更新发布期间,如何实现新、老版本的平滑过渡,使得版本更新不影响用户的使用体验,是提供服务的企业迫切需要解决的问题。
以往在应用服务更新发布过程中,为了不影响用户的使用体验,往往会采用单节点更新发布模式,即在应用服务器内,采用一个节点到一个节点的单节点更新发布模式进行新版本的更新发布,虽然通过这种方式可以保证应用服务器较稳定完成更新发布,更新过程不影响用户使用,但是单节点更新发布模式需要开发人员通过手动修改节点配置来完成节点的更新发布,并且在开发人员完成节点的版本更新后,需要测试人员立即对节点进行功能测试,测试无误后,才确认节点的版本更新完成,开发人员继续更新应用服务器的其他节点,因此,采用单节点更新发布模式的整个更新过程比较复杂,效率较低,且严重耗费人力、物力,容易出错,一旦产生错误,将极大地影响用户体验。
发明内容
本申请实施例的目的在于提出一种服务器同步更新的方法、装置、计算机设备及存储介质,以解决现有应用服务更新发布过程采用的单节点更新发布模式的整个更新过程比较复杂,效率较低,且严重耗费人力、物力,容易出错,一旦产生错误,将极大地影响用户体验的问题。
为了解决上述技术问题,本申请实施例提供一种服务器同步更新的方法,服务器至少包括第一服务系统和第二服务系统,且在服务器正常运行状态下,第一服务系统和第二服务系统的用户流量占比为1:1,服务器同步更新的方法包括:
接收服务器的更新请求指令;
从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,其中,lua为嵌入到Nginx服务器配置文件中的动态脚本语言;
根据第一分流策略,将第一服务系统的用户流量转移到第二服务系统内;
对第一服务系统进行更新;
从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中;
根据第二分流策略,将第二服务系统的用户流量转移到更新完成后的第一服务系统中;
对第二服务系统进行更新。
进一步地,从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,具体包括:
对第一分流策略进行格式转化,以形成第一分流策略对应的lua脚本;
将第一分流策略对应的lua脚本更新到Nginx服务器的高速缓冲存储器中。
进一步地,根据第一分流策略,将第一服务系统的用户流量转移到第二服务系统内,具体为:
从高速缓冲存储器中加载第一分流策略对应的lua脚本,获取第一分流策略对应的分流信息;
根据第一分流策略对应的分流信息,调整服务器的API接口的配置信息,得到第一API接口;
通过第一API接口将第一服务系统的所有用户流量全部转移到第二服务系统内。
进一步地,在对第一服务系统进行更新之后,还包括:
模拟用户请求,其中,模拟用户请求携带有正常用户的传入参数;
向更新完成后的第一服务系统发起模拟用户请求,并得到模拟用户请求的响应结果;
判断响应结果与预设标准结果是否一致;
若响应结果与预设标准结果一致,则确定第一服务系统更新成功;
若响应结果与预设标准结果不一致,则确定第一服务系统更新失败。
进一步地,从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中,具体包括:
对第二分流策略进行格式转化,以形成第二分流策略对应的lua脚本;
将第二分流策略对应的lua脚本更新到Nginx服务器的高速缓冲存储器中。
进一步地,根据第二分流策略,将第二服务系统的用户流量转移到更新完成后的第一服务系统中,具体包括:
从高速缓冲存储器中加载第二分流策略对应的lua脚本,获取第二分流策略对应的分流信息;
根据第二分流策略对应的分流信息,调整服务器的API接口的配置信息,得到第二API接口;
通过第二API接口将第二服务系统的用户流量逐步转移到更新完成后的第一服务系统内,直至第二服务系统的所有用户流量全部转移到更新完成后的第一服务系统。
进一步地,在对第二服务系统进行更新之后,还包括:
从Redis服务器中读取预设的第三分流策略,并将读取到的第三分流策略以lua脚本形式加载到Nginx服务器中;
根据第三分流策略,将更新完成后的第二服务系统的用户流量转移到更新完成后的第一服务系统中。
为了解决上述技术问题,本申请实施例还提供一种服务器同步更新的装置,服务器至少包括第一服务系统和第二服务系统,且在服务器正常运行状态下,第一服务系统和第二服务系统的用户流量占比为1:1,服务器同步更新的装置包括:
指令接收模块,用于接收服务器的更新请求指令;
第一加载模块,用于从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,其中,lua脚本为嵌入到Nginx服务器配置文件中的动态脚本语言;
第一转移模块,用于根据第一分流策略,将第一服务系统的用户流量转移到第二服务系统内;
第一更新模块,用于对第一服务系统进行更新;
第二加载模块,用于从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中;
第二转移模块,用于根据第二分流策略,将第二服务系统的用户流量转移到更新完成后的第一服务系统中;
第二更新模块,用于对第二服务系统进行更新。
为了解决上述技术问题,本申请实施例还提供一种计算机设备,采用了如下所述的技术方案:
一种计算机设备,包括存储器和处理器,存储器中存储有计算机可读指令,处理器执行计算机可读指令时实现如上述任意一项所述的服务器同步更新的方法的步骤。
为了解决上述技术问题,本申请实施例还提供一种计算机可读存储介质,采用了如下所述的技术方案:
一种计算机可读存储介质,计算机可读存储介质上存储有计算机可读指令,计算机可读指令被处理器执行时实现如上述任意一项所述的服务器同步更新的方法的步骤。
与现有技术相比,本申请实施例主要有以下有益效果:
本申请公开了服务器同步更新的方法、装置、计算机设备及存储介质,应用于智慧政务领域中,所述方法在接收服务器的更新请求指令之后;从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,其中,lua脚本为嵌入到Nginx服务器配置文件中的动态脚本语言;Nginx服务器根据第一分流策略的分流信息,将第一服务系统的用户流量全部转移到第二服务系统内;对第一服务系统进行停机更新,此时所有用户均通过第二服务系统调用服务,因此第一服务系统停机更新不影响用户的使用体验;在第一服务系统更新完成后,从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中;Nginx服务器根据第二分流策略的分流信息,将第二服务系统的用户流量逐步转移到更新完成后的第一服务系统中;在第二服务系统的所有用户流量全部转移到更新完成后的第一服务系统内之后,对第二服务系统进行停机更新,此时所有用户均通过更新完成后的第一服务系统调用服务,因此第二服务系统停机更新不影响用户的使用体验。本申请通过在服务器内设置两个服务系统——第一服务系统和第二服务系统,在第一服务系统进行更新时,先将第一服务系统的所有用户流量全部转移到第二服务系统内,在第二服务系统更新时,先将第二服务系统的所有用户流量逐步转移到更新完成后的第一服务系统内,本申请可以实现服务器系统的不停机更新,在整个服务器的更新过程中,服务器用户可以正常调用服务,极大地提升了用户体验。
附图说明
为了更清楚地说明本申请中的方案,下面将对本申请实施例描述中所需要使用的附图作一个简单介绍,显而易见地,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请可以应用于其中的示例性系统架构图;
图2是根据本申请的一种服务器同步更新的方法的一个实施例的流程图;
图3是本申请的一种服务器同步更新的方法中根据第一分流策略进行分流的一个实施例的流程图;
图4是本申请的一种服务器同步更新的方法中模拟测试的一个实施例的流程图;
图5是根据本申请的一种服务器同步更新的装置的一个实施例的结构示意图;
图6是根据本申请的计算机设备的一个实施例的结构示意图。
具体实施方式
除非另有定义,本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同;本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的,不是旨在于限制本申请;本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形,意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象,而不是用于描述特定顺序。
在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其它实施例相结合。
为了使本技术领域的人员更好地理解本申请方案,下面将结合附图,对本申请实施例中的技术方案进行清楚、完整地描述。
如图1所示,系统架构100可以包括终端设备101、102、103,网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备101、102、103通过网络104与服务器105交互,以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用,例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。
终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备,包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving PictureExpertsGroup Audio Layer III,动态影像专家压缩标准音频层面3)、MP4(MovingPictureExperts Group Audio Layer IV,动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。
服务器105可以是提供各种服务的服务器,例如对终端设备101、102、103上显示的页面提供支持的后台服务器。
需要说明的是,本申请实施例所提供的服务器同步更新的方法一般由服务器执行,相应地,服务器同步更新的装置一般设置于服务器中。
应该理解,图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。
继续参考图2,示出了根据本申请的一种服务器同步更新的方法的一个实施例的流程图。一种服务器同步更新的方法,服务器至少包括第一服务系统和第二服务系统,且在服务器正常运行状态下,第一服务系统和第二服务系统的用户流量占比为1:1,方法包括:
S201,接收服务器的更新请求指令;
在本实施例中,服务器同步更新的方法运行于其上的电子设备(例如图1所示的服务器/终端设备)可以通过有线连接方式或者无线连接方式接收服务器的更新请求指令。需要指出的是,上述无线连接方式可以包括但不限于3G/4G连接、WiFi连接、蓝牙连接、WiMAX连接、Zigbee连接、UWB(ultra wideband)连接、以及其他现在已知或将来开发的无线连接方式。
S202,从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,其中,lua为嵌入到Nginx服务器配置文件中的动态脚本语言;
S203,根据第一分流策略,将第一服务系统的用户流量转移到第二服务系统内;
其中,Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,在BSD-like协议下发行,Nginx的特点是占有内存少,并发能力强,Nginx服务器能够接收应用服务器动态生成的更新请求指令,通过实时修改Nginx服务器的Cache高速缓冲存储器中的当前限流策略,实现应用服务器用户流量的调整。Redis服务器是一种高可用的存储服务器,读写性能优秀,可以存储包括string(字符串)、list(链表)、set(集合)、zset(sorted set--有序集合)和hash(哈希类型)等类型的数据文件,服务器的所有分流策略文件都以string(字符串)的格式储存在Redis服务器中。
具体的,在接收服务器的更新请求指令之后,从Redis服务器的预定位置读取预设的第一分流策略,并将读取到的第一分流策略上传达到lua内,第一分流策略在lua内完成格式转化,形成lua脚本,然后将第一分流策略以lua脚本形式加载到Nginx服务器中。
其中,第一分流策略由服务器的开发人员根据服务器的更新需求进行设定。在本申请一种具体的实施例中,第一分流策略为全部转移策略,即在服务器采用第一分流策略时,第一服务系统的所有用户流量在第一分流策略启用瞬间全部转移到第二服务系统内。
S204,对第一服务系统进行更新;
具体的,在Nginx服务器根据第一分流策略的分流信息,将第一服务系统的用户流量全部转移到第二服务系统内之后,对第一服务系统进行停机更新,此时所有用户均通过第二服务系统调用服务,因此第一服务系统停机更新不影响用户的使用体验
S205,从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中;
S206,根据第二分流策略,将第二服务系统的用户流量转移到更新完成后的第一服务系统中;
具体的,在第一服务系统更新完成后,从Redis服务器的预定位置读取预设的第二分流策略,并将读取到的第二分流策略上传达到lua内,第二分流策略在lua内完成格式转化,形成lua脚本,然后将第二分流策略以lua脚本形式加载到Nginx服务器中。
其中,第二分流策略由服务器的开发人员根据服务器的更新需求进行设定。在本申请一种具体的实施例中,第二分流策略为逐步转移策略,由于更新后的第一服务系统的稳定性未知,因此第二分流策略采用逐步转移策略,并且在用户转移过程中持续获取转移用户的反馈情况,监测更新后的第一服务系统的运行情况,来判断更新后的第一服务系统是否能满足用户需求,例如,如果转移用户普遍反馈对更新后的第一服务系统提供的服务不满意或系统监测更新后的第一服务系统的运行情况出现异常,则立即停止用户转移,并将已转移用户重新调回第二服务系统。本申请通过第二分流策略,将第二服务系统的用户流量在逐步转移到第二服务系统内,并实时通过转移用户的反馈情况和监测更新后的第一服务系统的运行情况,来判断更新后的第一服务系统是否能满足用户需求,提升了系统可用性和用户的使用体验。其中,开发人员可以根据具体项目需求自定义第二分流策略,例如,可以根据用户比例来设定第二分流策略,每次将第二服务系统内十分之一的用户量转移到更新后的第一服务系统。
S207,对第二服务系统进行更新。
具体的,在Nginx服务器根据第二分流策略的分流信息,将第二服务系统的用户流量逐步转移到更新完成后的第一服务系统中;并且在第二服务系统的所有用户流量全部转移到更新完成后的第一服务系统内之后,对第二服务系统进行停机更新,此时所有用户均通过更新完成后的第一服务系统调用服务,因此第二服务系统停机更新也不影响用户的使用体验。
本申请通过在服务器内设置两个服务系统——第一服务系统和第二服务系统,在第一服务系统进行更新时,先将第一服务系统的所有用户流量全部转移到第二服务系统内,在第二服务系统更新时,先将第二服务系统的所有用户流量逐步转移到更新完成后的第一服务系统内,本申请可以实现服务器系统的不停机更新,在整个服务器的更新过程中,服务器用户可以正常调用服务,极大地提升了用户体验。
进一步地,请参考图3,图3示出了本申请的一种服务器同步更新的方法中根据第一分流策略进行分流的一个实施例的流程图,从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,具体包括:
S301,对第一分流策略进行格式转化,以形成第一分流策略对应的lua脚本;
其中,分流策略在Redis服务器中是以string(字符串)的格式存在的,而String格式文件是不能直接被Nginx服务器调用的,需要将以String的格式存在的分流策略文件通过lua进行重新编译,将String的格式的分流策略文件转换为Table形式,然后通过lua加载到Nginx服务器中进行存储,Nginx服务器可以直接调用分流策略进行服务器用户流量的控制。
S302,将第一分流策略对应的lua脚本更新到Nginx服务器的高速缓冲存储器中。
一般来说,在Nginx服务器的高速缓存Cache中会存储有当前限流策略,但Cache每次只能存储一个限流策略,也就是说,如果要使用新的限流策略,则需要清除Cache里面存储的之前的限流策略,即当需要上传新的限流策略时,Cache里面是不允许存在限流策略的。其中,Cache里面的内容的清除可以采用专门的清空机制,即设置一个清空Cache里面内容的接口,通过该接口进行Cache内容的清除。优选地,还可以为Cache里面的清空机制设置时效,在本提案中,清空机制的时效可以是服务器更新周期,比如,服务器更新周期为一周一次,则清空机制的时效为一周,如果达到清空机制的时效,则自动清除Cache里面的限流策略,并接收新的限流策略。
高速缓冲存储器Cache,Cache是存在于Nginx服务器主存与CPU之间的一级存储器,由静态存储芯片(SRAM)组成,容量比较小但速度比主存高得多,接近于CPU的速度。在计算机存储系统的层次结构中,是介于中央处理器和主存储器之间的高速小容量存储器。它和主存储器一起构成一级的存储器。在本申请实施例中,Cache中存储有服务器的当前限流策略,通过修改Cache中存储的当前限流策略来实现修改服务器的分流情况。
具体的,在接收服务器的更新请求指令后,从Redis缓存器中读取预设的第一分流策略,并将第一分流策略上传到lua,通过lua对第一分流策略进行重新编译,形成lua脚本,将String的格式的分流策略文件转换为Table形式,最后将第一分流策略对应的lua脚本更新到高速缓冲存储器中。
进一步地,请继续参考图3,根据第一分流策略,将第一服务系统的用户流量转移到第二服务系统内,具体为:
S303,从高速缓冲存储器中加载第一分流策略对应的lua脚本,获取第一分流策略对应的分流信息;
S304,根据第一分流策略对应的分流信息,调整服务器的API接口的配置信息,得到第一API接口;
S305,通过第一API接口将第一服务系统的所有用户流量全部转移到第二服务系统内。
其中,API(Application Programming Interface,应用程序接口)是一些预先定义的函数,或指软件系统不同组成部分衔接的约定,API接口是操作系统或程序与外部进行连接的重要环节,在本提案中,通过API接口控制第一服务系统和第二服务系统用户访问流量,可以通过修改API接口的配置信息,控制服务器的用户访问。
具体的,Nginx服务器从高速缓冲存储器Cache中加载第一分流策略对应的lua脚本,并进行解析,获取第一分流策略对应的分流信息,根据第一分流策略对应的分流信息,调整服务器的API接口的配置信息,得到第一API接口,通过第一API接口将第一服务系统的所有用户流量全部转移到第二服务系统内。本申请通过第一分流策略对应的分流信息调整服务器的API接口的配置信息,通过修改API接口的配置信息,控制服务器的用户访问,实现了用户流量系统管理,不易出错。
进一步地,请参考图4,图4示出了本申请的一种服务器同步更新的方法中模拟测试的一个实施例的流程图,在对第一服务系统进行更新之后,还包括:
S401,模拟用户请求,其中,模拟用户请求携带有正常用户的传入参数;
S402,向更新完成后的第一服务系统发起模拟用户请求,并得到模拟用户请求的响应结果;
S403,判断响应结果与预设标准结果是否一致;
S404,若响应结果与预设标准结果一致,则确定第一服务系统更新成功;
S405,若响应结果与预设标准结果不一致,则确定第一服务系统更新失败。
其中,在第一服务系统更新完成后,以及将第二服务系统的用户流量转移到更新完成后的第一服务系统前,还需要对更新完成后的第一服务系统进行模拟测试。具体的,模拟用户请求,将模拟用户请求中的携带有正常用户的传入参数上传到更新完成后的第一服务系统中,通过传入参数调用服务,模拟服务调用过程,得到模拟用户请求的响应结果,将模拟用户请求的响应结果与预设标准结果是否一致,如果响应结果与预设标准结果一致,则确定第一服务系统更新成功,允许将第二服务系统的用户流量转移到更新完成后的第一服务系统中;如果响应结果与预设标准结果不一致,则确定第一服务系统更新失败,禁止将第二服务系统的用户流量转移到更新完成后的第一服务系统中,并提示开发人员对定第一服务系统进行重新更新。
进一步地,从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中,具体包括:
对第二分流策略进行格式转化,以形成第二分流策略对应的lua脚本;
将第二分流策略对应的lua脚本更新到Nginx服务器的高速缓冲存储器中。
具体的,在接收服务器的更新请求指令后,从Redis缓存器中读取预设的第二分流策略,并将第二分流策略上传到lua,通过lua对第二分流策略进行重新编译,形成lua脚本,将String的格式的分流策略文件转换为Table形式,最后将第二分流策略对应的lua脚本更新到高速缓冲存储器中。
进一步地,根据第二分流策略,将第二服务系统的用户流量转移到更新完成后的第一服务系统中,具体包括:
从高速缓冲存储器中加载第二分流策略对应的lua脚本,获取第二分流策略对应的分流信息;
根据第二分流策略对应的分流信息,调整服务器的API接口的配置信息,得到第二API接口;
通过第二API接口将第二服务系统的用户流量逐步转移到更新完成后的第一服务系统内,直至第二服务系统的所有用户流量全部转移到更新完成后的第一服务系统。
具体的,Nginx服务器从高速缓冲存储器Cache中加载第二分流策略对应的lua脚本,并进行解析,获取第二分流策略对应的分流信息,根据第二分流策略对应的分流信息,调整服务器的API接口的配置信息,得到第二API接口,通过第二API接口将第二服务系统的用户流量逐步转移到更新完成后的第一服务系统内,直至第二服务系统的所有用户流量全部转移到更新完成后的第一服务系统。本申请通过第二分流策略对应的分流信息调整服务器的API接口的配置信息,通过修改API接口的配置信息,控制服务器的用户访问。
其中,在第二服务系统更新完成后,以及将更新完成后的第一服务系统的用户流量部分转移到更新完成后的第二服务系统前,还需要对更新完成后的第二服务系统进行模拟测试。具体的,模拟用户请求,将模拟用户请求中的携带有正常用户的传入参数上传到更新完成后的第二服务系统中,通过传入参数调用服务,模拟服务调用过程,得到模拟用户请求的响应结果,将模拟用户请求的响应结果与预设标准结果是否一致,如果响应结果与预设标准结果一致,则确定第二服务系统更新成功,允许将更新完成后的第一服务系统的用户流量部分转移到更新完成后的第二服务系统中;如果响应结果与预设标准结果不一致,则确定第二服务系统更新失败,禁止将更新完成后的第一服务系统的用户流量部分转移到更新完成后的第二服务系统中,并提示开发人员对定第二服务系统进行重新更新。
进一步地,在对第二服务系统进行更新之后,还包括:
从Redis服务器中读取预设的第三分流策略,并将读取到的第三分流策略以lua脚本形式加载到Nginx服务器中;
根据第三分流策略,将更新完成后的第二服务系统的用户流量转移到更新完成后的第一服务系统中。
具体的,在第二服务系统更新完成之后,先通过模拟用户请求对更新完成的第二服务系统进行测试,测试完成后,从Redis服务器的预定位置读取预设的第三分流策略,并将读取到的第三分流策略上传达到lua内,第三分流策略在lua内完成格式转化,形成lua脚本,然后将第三分流策略以lua脚本形式加载到Nginx服务器中。根据第三分流策略的分流信息,将更新完成后的第一服务系统的用户流量部分转移到更新完成后的第二服务系统中。
其中,第一分流策略由服务器的开发人员根据服务器的更新需求进行设定。在本申请一种具体的实施例中,第三分流策略为均衡分流策略,即在服务器采用第三分流策略时,第一服务系统和第二服务系统内的用户流量实现均衡配置,即第一服务系统和第二服务系统的用户流量占比为1:1。
需要强调的是,为进一步保证上述更新请求指令的私密和安全性,上述更新请求指令还可以存储于一区块链的节点中。
本申请所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain),本质上是一个去中心化的数据库,是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机可读指令来指令相关的硬件来完成,该计算机可读指令可存储于一计算机可读取存储介质中,该计算机可读指令在执行时,可包括如上述各方法的实施例的流程。其中,前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)等非易失性存储介质,或随机存储记忆体(Random Access Memory,RAM)等。
应该理解的是,虽然附图的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,其可以以其他的顺序执行。而且,附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,其执行顺序也不必然是依次进行,而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
进一步参考图5,图5是根据本申请的一种服务器同步更新的装置的一个实施例的结构示意图,作为对上述图2所示服务器同步更新的方法的实现,本申请提供了一种服务器同步更新的装置的一个实施例,该装置实施例与图2所示的方法实施例相对应,该装置具体可以应用于各种电子设备中。
如图5所示,本实施例所述的一种服务器同步更新的装置包括:指令接收模块501、第一加载模块502、第一转移模块503、第一更新模块504、第二加载模块505、第二转移模块506以及第二更新模块507。其中:
指令接收模块501,用于接收服务器的更新请求指令;
第一加载模块502,用于从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,其中,lua为嵌入到Nginx服务器配置文件中的动态脚本语言;
第一转移模块503,用于根据第一分流策略,将第一服务系统的用户流量转移到第二服务系统内;
第一更新模块504,用于对第一服务系统进行更新;
第二加载模块505,用于从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中;
第二转移模块506,用于根据第二分流策略,将第二服务系统的用户流量转移到更新完成后的第一服务系统中;
第二更新模块507,用于对第二服务系统进行更新。
进一步地,第一加载模块502具体包括:
第一格式转化单元,用于对第一分流策略进行格式转化,以形成第一分流策略对应的lua脚本;
第一脚本更新单元,用于将第一分流策略对应的lua脚本更新到Nginx服务器的高速缓冲存储器中。
进一步地,第一转移模块503具体为:
第一分流信息获取单元,用于从高速缓冲存储器中加载第一分流策略对应的lua脚本,获取第一分流策略对应的分流信息;
第一调整单元,用于根据第一分流策略对应的分流信息,调整服务器的API接口的配置信息,得到第一API接口;
第一转移单元,用于通过第一API接口将第一服务系统的所有用户流量全部转移到第二服务系统内。
进一步地,该服务器同步更新的装置还包括:
模拟请求模块,用于模拟用户请求,其中,模拟用户请求携带有正常用户的传入参数;
请求发起模块,用于向更新完成后的第一服务系统发起模拟用户请求,并得到模拟用户请求的响应结果;
结果判断模块,用于将响应结果与预设标准结果是否一致;
第一判断模块,用于当响应结果与预设标准结果一致时,确定第一服务系统更新成功;
第二判断模块,用于当响应结果与预设标准结果不一致时,确定第一服务系统更新失败。
进一步地,第二加载模块505具体包括:
第二格式转化单元,用于对第二分流策略进行格式转化,以形成第二分流策略对应的lua脚本;
第二脚本更新单元,用于将第二分流策略对应的lua脚本更新到Nginx服务器的高速缓冲存储器中。
进一步地,第二转移模块506具体包括:
第二分流信息获取单元,用于从高速缓冲存储器中加载第二分流策略对应的lua脚本,获取第二分流策略对应的分流信息;
第二调整单元,用于根据第二分流策略对应的分流信息,调整服务器的API接口的配置信息,得到第二API接口;
第二转移单元,用于通过第二API接口将第二服务系统的用户流量逐步转移到更新完成后的第一服务系统内,直至第二服务系统的所有用户流量全部转移到更新完成后的第一服务系统。
进一步地,该服务器同步更新的装置还包括:
第三加载模块,用于从Redis服务器中读取预设的第三分流策略,并将读取到的第三分流策略以lua脚本形式加载到Nginx服务器中;
第三转移模块,用于根据第三分流策略,将更新完成后的第二服务系统的用户流量转移到更新完成后的第一服务系统中。
本申请公开了一种服务器同步更新的装置,应用于智慧政务领域中,通过本方案能够推动智慧城市的建设。服务器至少包括第一服务系统和第二服务系统,且在服务器正常运行状态下,第一服务系统和第二服务系统的用户流量占比为1:1,方法包括:指令接收模块501,用于接收服务器的更新请求指令;第一加载模块502,用于从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,其中,lua脚本为嵌入到Nginx服务器配置文件中的动态脚本语言;第一转移模块503,用于根据第一分流策略,将第一服务系统的用户流量转移到第二服务系统内;第一更新模块504,用于对第一服务系统进行更新;第二加载模块505,用于从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中;第二转移模块506,用于根据第二分流策略,将第二服务系统的用户流量转移到更新完成后的第一服务系统中;第二更新模块507,用于对第二服务系统进行更新。本申请通过在服务器内设置两个服务系统——第一服务系统和第二服务系统,在第一服务系统进行更新时,先将第一服务系统的所有用户流量全部转移到第二服务系统内,在第二服务系统更新时,先将第二服务系统的所有用户流量逐步转移到更新完成后的第一服务系统内,本申请可以实现服务器系统的不停机更新,在整个服务器的更新过程中,服务器用户可以正常调用服务,极大地提升了用户体验。
为解决上述技术问题,本申请实施例还提供计算机设备。具体请参阅图6,图6为本实施例计算机设备基本结构框图。
所述计算机设备6包括通过系统总线相互通信连接存储器61、处理器62、网络接口63。需要指出的是,图中仅示出了具有组件61-63的计算机设备6,但是应理解的是,并不要求实施所有示出的组件,可以替代的实施更多或者更少的组件。其中,本技术领域技术人员可以理解,这里的计算机设备是一种能够按照事先设定或存储的指令,自动进行数值计算和/或信息处理的设备,其硬件包括但不限于微处理器、专用集成电路(ApplicationSpecific Integrated Circuit,ASIC)、可编程门阵列(Field-ProgrammableGate Array,FPGA)、数字处理器(Digital Signal Processor,DSP)、嵌入式设备等。
所述计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。
所述存储器61至少包括一种类型的可读存储介质,所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如,SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中,所述存储器61可以是所述计算机设备6的内部存储单元,例如该计算机设备6的硬盘或内存。在另一些实施例中,所述存储器61也可以是所述计算机设备6的外部存储设备,例如该计算机设备6上配备的插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(FlashCard)等。当然,所述存储器61还可以既包括所述计算机设备6的内部存储单元也包括其外部存储设备。本实施例中,所述存储器61通常用于存储安装于所述计算机设备6的操作系统和各类应用软件,例如服务器同步更新的方法的计算机可读指令等。此外,所述存储器61还可以用于暂时地存储已经输出或者将要输出的各类数据。
所述处理器62在一些实施例中可以是中央处理器(Central Processing Unit,CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器62通常用于控制所述计算机设备6的总体操作。本实施例中,所述处理器62用于运行所述存储器61中存储的计算机可读指令或者处理数据,例如运行所述服务器同步更新的方法的计算机可读指令。
所述网络接口63可包括无线网络接口或有线网络接口,该网络接口63通常用于在所述计算机设备6与其他电子设备之间建立通信连接。
本申请公开了服务器同步更新的方法、装置、计算机设备及存储介质,所述方法在接收服务器的更新请求指令之后;从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,其中,lua脚本为嵌入到Nginx服务器配置文件中的动态脚本语言;Nginx服务器根据第一分流策略的分流信息,将第一服务系统的用户流量全部转移到第二服务系统内;对第一服务系统进行停机更新,此时所有用户均通过第二服务系统调用服务,因此第一服务系统停机更新不影响用户的使用体验;在第一服务系统更新完成后,从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中;Nginx服务器根据第二分流策略的分流信息,将第二服务系统的用户流量逐步转移到更新完成后的第一服务系统中;在第二服务系统的所有用户流量全部转移到更新完成后的第一服务系统内之后,对第二服务系统进行停机更新,此时所有用户均通过更新完成后的第一服务系统调用服务,因此第二服务系统停机更新不影响用户的使用体验。本申请通过在服务器内设置两个服务系统——第一服务系统和第二服务系统,在第一服务系统进行更新时,先将第一服务系统的所有用户流量全部转移到第二服务系统内,在第二服务系统更新时,先将第二服务系统的所有用户流量逐步转移到更新完成后的第一服务系统内,本申请可以实现服务器系统的不停机更新,在整个服务器的更新过程中,服务器用户可以正常调用服务,极大地提升了用户体验。
本申请还提供了另一种实施方式,即提供一种计算机可读存储介质,所述计算机可读存储介质存储有计算机可读指令,所述计算机可读指令可被至少一个处理器执行,以使所述至少一个处理器执行如上述的服务器同步更新的方法的步骤。
本申请公开了服务器同步更新的方法、装置、计算机设备及存储介质,所述方法在接收服务器的更新请求指令之后;从Redis服务器中读取预设的第一分流策略,并将读取到的第一分流策略以lua脚本形式加载到Nginx服务器中,其中,lua脚本为嵌入到Nginx服务器配置文件中的动态脚本语言;Nginx服务器根据第一分流策略的分流信息,将第一服务系统的用户流量全部转移到第二服务系统内;对第一服务系统进行停机更新,此时所有用户均通过第二服务系统调用服务,因此第一服务系统停机更新不影响用户的使用体验;在第一服务系统更新完成后,从Redis服务器中读取预设的第二分流策略,并将读取到的第二分流策略以lua脚本形式加载到Nginx服务器中;Nginx服务器根据第二分流策略的分流信息,将第二服务系统的用户流量逐步转移到更新完成后的第一服务系统中;在第二服务系统的所有用户流量全部转移到更新完成后的第一服务系统内之后,对第二服务系统进行停机更新,此时所有用户均通过更新完成后的第一服务系统调用服务,因此第二服务系统停机更新不影响用户的使用体验。本申请通过在服务器内设置两个服务系统——第一服务系统和第二服务系统,在第一服务系统进行更新时,先将第一服务系统的所有用户流量全部转移到第二服务系统内,在第二服务系统更新时,先将第二服务系统的所有用户流量逐步转移到更新完成后的第一服务系统内,本申请可以实现服务器系统的不停机更新,在整个服务器的更新过程中,服务器用户可以正常调用服务,极大地提升了用户体验。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本申请各个实施例所述的方法。
显然,以上所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例,附图中给出了本申请的较佳实施例,但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现,相反地,提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明,对于本领域的技术人员来而言,其依然可以对前述各具体实施方式所记载的技术方案进行修改,或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构,直接或间接运用在其他相关的技术领域,均同理在本申请专利保护范围之内。