本发明属于云服务更新领域，特别涉及一种云服务系统的滚动更新方法。
背景技术：
云服务是基于互联网的相关服务的增加、使用和交付模式，云是网络、互联网的一种比喻说法。过去在图中通常用云来表示电信网，后来也用来表示互联网和底层基础设施的抽象。云服务指通过网络以按需、易扩展的方式获得所需服务。etcd是一个效率高、可靠性高、通用性好的分布式键值存储系统，主要用于共享配置和服务发现，它使用Go语言编写。etcd最初是专门为集群环境的服务发现和注册而设计的，etcd提供了数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等功能，可以方便的跟踪并管理集群节点的状态。
传统的云服务在更新的过程中，大多采用将云服务的所有副本放在更新服务器内更新，这样就存在着服务中断的缺陷，而且更新服务器由于同一时间要求更新的副本较多，造成瞬时负载过大等问题，因此亟需提出一种既可以保证云服务的不间断的对外提供服务，又不对更新服务器造成负载压力的云服务的更新方法。
技术实现要素：
本发明为了克服上述现有技术的不足，提供了一种云服务系统的滚动更新方法，通过该方法保证整个服务的更新过程中同一时间仅有一个服务副本与更新服务器发生交互，这样避免了服务中断和更新服务器瞬时负载过大的问题，保证了云服务系统的稳定性和可靠性。
为实现上述目的，本发明采用了以下技术措施：
一种云服务系统的滚动更新方法，包括以下步骤：
S1、需要更新版本的所有服务副本均向服务发现工具请求获得更新锁；
S2、所述服务发现工具向其中一个服务副本发出更新锁，所述服务发现工具一次只会发出一个更新锁，直至上一个更新锁解锁后才会向其他服务副本发出新的更新锁；
S3、获得更新锁的服务副本停止提供服务并通过所述更新服务器更新版本，没有获得更新锁的服务副本间隔一预设时间后再次向服务发现工具请求获得更新锁；
S4、版本更新结束的服务副本继续提供服务并向服务发现工具请求解锁更新锁；
S5、所述服务发现工具给予上述服务副本解锁更新锁，并向其他请求更新锁的服务副本中的一个发出新的更新锁。
优选的，所述服务副本根据如下方法判断自己是否需要更新版本：
S11、服务副本获得最新的版本信息；
S12、所述服务副本将最新的版本信息与自身的版本信息进行比对从而判断是否需要更新版本。
优选的，所述服务副本通过所述服务发现工具获得最新的版本信息。
优选的，所述滚动更新方法还包括以下步骤：所述服务发现工具向服务副本发出更新锁时，同时为所述更新锁设置生存周期，当所述更新锁生存周期结束时，即使服务副本尚未更新结束，该服务副本也会向所述服务发现工具请求解锁更新锁。
进一步的，所述服务发现工具为etcd或者consul或者zookeeper。
本发明的有益效果在于：
1)、本发明通过服务发现工具给请求更新的服务副本设定更新锁，使整个服务的所有服务副本中只有取得更新锁的服务副本会对自身进行更新，保证了同一时间只有一个服务副本处于更新中的状态，不会造成服务中断；同时所有服务副本错开时间逐个进行更新，每次只更新一个服务副本，逐步推进至整个服务集群，整个服务的更新过程中同一时间仅有一个副本与更新服务器发生交互，消除了传统云服务更新时对更新服务器造成的瞬时负载压力。增强了云服务系统的稳定性和可靠性。
2)、所述服务副本将最新的版本信息与自身的版本信息进行比对从而判断是否需要更新版本，因此本方法简单、有效、占用资源少。
附图说明
图1是现有技术中云服务系统的结构示意图；
图2为本发明云服务系统的滚动更新方法的一个实施例的结构流程图；
图3为本发明云服务系统的滚动更新方法的一个实施例的状态示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1所示，一般云服务系统包括若干个服务副本(服务副本1、服务副本2、…、服务副本n)为用户提供服务，通常还包括为各服务副本提供数据读写服务的服务发现工具和更新服务器，所述更新服务器为所述若干个服务副本更新版本。具体的，所述各服务副本与服务发现工具通过无线或者有线网络相连，所述各服务副本与更新服务器之间通过有线或者无线网络相连。当然，在实际应用中，服务发现工具、各服务副本和更新服务器并不一定被限制在各个独立的设备上，他们中的两个或数个也有可能共用同一个设备。
本发明实施例提供的云服务系统的滚动更新方法包括以下步骤：
S1、需要更新版本的所有服务副本均向服务发现工具请求获得更新锁；
S2、所述服务发现工具向其中一个服务副本发出更新锁，所述服务发现工具一次只会发出一个更新锁，直至上一个更新锁解锁后才会向其他服务副本发出新的更新锁；
S3、获得更新锁的服务副本停止提供服务并通过所述更新服务器更新版本，没有获得更新锁的服务副本间隔一预设时间后再次向服务发现工具请求获得更新锁；
S4、版本更新结束的服务副本继续提供服务并向服务发现工具请求解锁更新锁；
S5、所述服务发现工具给予上述服务副本解锁更新锁，并向其他请求更新锁的服务副本中的一个发出新的更新锁。
循环执行步骤S1～S5，所有服务副本逐次完成更新后，整个云服务系统更新完毕。
当某个服务副本需要更新版本时，并不会直接向更新服务器请求更新版本，而是尝试去服务发现工具取得更新锁。成功取得更新锁后才会向更新服务器请求更新版本，否则等待一个预设时间或者随机的延时后，再次尝试去取得更新锁，直到更新成功。一个服务副本更新完成后会重新对外提供服务，并向服务发现工具请求解锁更新锁。此时其余正在尝试申请更新锁的服务副本中的一个会成功取得更新锁，继续逐步更新的过程，最终完成整个云服务系统的更新。这样所有服务副本可以错开时间逐个进行更新，每次只更新一个服务副本，逐步推进至整个服务集群。
云服务系统的所有服务副本不会在同一时间一起更新从而中断服务，而是通过更新锁保证同一时间仅有一个服务副本处于更新状态，其余未处于更新状态的服务副本仍能正常对外提供服务。这样在整个云服务系统更新过程中，单一时刻仅有一个服务副本是失效的(即无法对外提供服务)，而对于包含n个服务副本的云服务系统而言，更新过程中始终都有至少n-1个能正常对外提供服务的服务副本存在，所以云服务系统本身一直是健康的、无中断的。
而且，整个云服务系统的更新过程中同一时间仅有一个服务副本与更新服务器发生交互，这样给更新服务器带来的压力是平缓的，消除了一般云服务系统更新时多节点并发请求对更新服务器造成的瞬时负载压力。
在本发明的所述服务副本根据如下方法判断自己是否需要更新版本：
S11、服务副本获得最新的版本信息；
S12、所述服务副本将最新的版本信息与自身的版本信息进行比对从而判断是否需要更新版本，因此本方法简单、有效、占用资源少。
所述服务副本通过所述服务发现工具获得最新的版本信息。所述服务副本也可以从其他一些统一的可信源处获得最新的版本信息。选择通过服务发现工具获得最新的版本信息，可以减少硬件配置，节约资源。
所述服务发现工具为etcd或者consul或者zookeeper。
进一步的，在本发明滚动更新方法的其他实施例中还包括以下步骤：所述服务发现工具向服务副本发出更新锁时，同时为所述更新锁设置生存周期，当所述更新锁生存周期结束时，即使服务副本尚未更新结束，该服务副本也会向所述服务发现工具请求解锁更新锁。
下面结合附图2说明本发明的优选实施例，当有服务副本发来更新锁请求时，所述服务发现工具会向所述服务副本发出更新锁，所述服务发现工具一次只会发出一个更新锁，直至上一个更新锁解锁后才会向其他服务副本发出新的更新锁。当有服务副本发来更新锁解锁请求时，所述服务发现工具会给予更新锁解锁。各服务副本上执行的操作如图2所示，具体包括以下步骤：
步骤10：服务副本通过服务发现工具获得最新的版本信息；
步骤20：所述服务副本将最新的版本信息与自身的版本信息进行比对；
步骤30：判断是否需要更新版本，如果需要更新执行步骤40，如果不需要更新，执行步骤10；
步骤40：向服务发现工具请求获得更新锁；
步骤50：如果获得更新锁执行步骤60，如果没有获得更新锁，间隔一预设时间后，再次执行步骤40；
步骤60：该服务副本停止提供服务并通过所述更新服务器更新版本；
步骤70：判断版本更新是否结束，如果版本更新结束执行步骤80，如果版本执行未结束执行步骤90；
步骤80：继续提供服务并向服务发现工具请求解锁更新锁；
步骤90：判断更新锁生存周期是否结束，如果结束执行步骤100；
步骤100：向服务发现工具请求解锁更新锁。
下面结合附图3说明云服务系统版本更新过程中，各服务副本的状态情况。假设所述云服务系统包括服务副本A、服务副本B和服务副本C。三个服务副本的版本都为1.0，正常运行并对外提供服务。此时etcd中标识该服务最新版本为2.0版，各服务副本通过与etcd的交互，得知自身版本落后，需要更新。
如图3(一)和图3(二)所示，所有服务副本向etcd请求更新锁，最终服务副本A成功取得更新锁，开始更新，更新过程中停止对外提供服务。服务副本B与服务副本C向etcd请求更新锁被否决，在经过一个随机的延时之后，它们会再次尝试请求更新锁。此时服务副本B与服务副本C仍正常运行，对外提供服务。在请求更新锁时，可以设置锁的TTL，使锁超时自动失效，防止单点更新故障。
如图3(三)所示，服务副本A完成了更新，版本变为2.0版与etcd服务中储存的最新版本一致，开始对外提供服务。此时服务副本A向etcd请求取消更新锁，随后，服务副本B获得了更新锁并开始更新过程，停止对外提供服务。而服务副本C仍未取得更新锁，继续保持现状。
如图3(四)所示，服务副本B也完成了更新，版本变为2.0版，此时服务副本B向etcd请求取消更新锁，随后，服务副本C获得了更新锁并开始更新过程，停止对外提供服务。
如图3(五)所示，经过一段时间后，云服务的所有服务副本都完成了更新，整个服务更新到了2.0版。在该服务更新的整体过程中，始终有服务副本对外提供服务，服务本身没有中断。并且更新过程中同一时间仅有一个服务副本与更新服务器交互，没有给更新服务器带来瞬时的并发请求负载。