一种基于云集群的应用更新的方法及装置与流程

1.本技术涉及信息技术领域，尤其涉及一种基于云集群的应用更新的方法及装置。


背景技术：

2.近年来，云计算技术的进步推动了互联网行业的快速发展，云计算本身的资源池化、自助服务、服务计量等特性也得到了广泛使用。这里，通过云计算技术可以向用户提供不同的云计算服务，例如基础设施即服务(infrastructure as a service，iaas)，iaas可以为用户提供虚拟化的计算、存储、网络等基础设施资源。
3.随着云计算和互联网相关技术的不断发展，应用更新的方式已经从传统的下载
‑
更新变更为在线更新，云集群只需要在发布新版本后，将老版本的用户断开连接，重新连接到新版本中即可供用户使用最新版的应用。
4.现有技术中，由于新版本存在不稳定、不健全的问题，因此业界通常会采用灰度发布的方式进行新老版本的交替。灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。即让一部分用户继续用产品特性a(老版本)，一部分用户开始用产品特性b(新版本)，如果用户对b没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到b上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
5.然而，在灰度发布的过程中，新老版本往往是随机切换或暴力切换，如果切换的数量庞大，短时期内会带来很大的流量脉冲，导致云集群大面积宕机，同时，暴力切换会使得部分习惯于老版本的用户突然之间强制切换到新版本，用户体验感差，容易带来用户投诉或用户流失问题。


技术实现要素：

6.本发明实施例提供一种基于云集群的应用更新的方法，用于解决现有技术中新老版本随机切换或暴力切换导致云集群宕机的问题。
7.本发明实施例提供一种基于云集群的应用更新的方法，包括：
8.多个用户终端与云集群中的应用实例建立长连接；
9.所述云集群获取所述应用的第一更新版本，所述第一更新版本为第一测试版本，所述第一测试版本的开发进度为第一进度；
10.所述云集群基于负载均衡策略及终端分流策略，将所述多个用户终端中的第一用户终端集群进行分离，并断开所述第一用户终端集群连接的所述应用实例，重新长连接至第一更新版本的所述应用，其中，所述第一用户终端集群的用户终端数量大于2且小于所述多个用户终端的数量；
11.所述云集群获取所述应用的第二更新版本，所述第二更新版本为第二测试版本，所述第二测试版本的开发进度为第二进度；
12.所述云集群基于所述负载均衡策略及终端分流策略，将所述多个用户终端以及所述第一用户终端集群进行分离，分离出第二用户终端集群，并将所述第二用户终端集群重
新长连接至第二更新版本的所述应用，其中，所述第二用户终端集群的用户终端数量大于2且小于所述多个用户终端的数量；
13.所述云集群获取所述应用的第n更新版本，所述第n更新版本为最终发布版本，并将所述多个用户终端依次重新与第n更新版本的所述应用建立长连接，其中n为大于等于3的正整数。
14.可选地，所述负载均衡策略包括：
15.获取所述云集群中多个云服务器的资源占用率，并将所述多个云服务器按照资源占用率由高到低进行排序；
16.依次将所述多个用户终端和/或所述第n
‑
1个用户终端集群流量分流至所述多个云服务器中，其中，每一个云服务器分流到的用户终端数量与所述对应的云服务器资源占用率排名成反比；
17.所述终端分流策略包括：对所述用户终端按照用户自然属性及终端性能进行评估，将所述用户终端分为优先更新集群及劣后更新集群，以便优先将所述优先更新集群中的用户终端重新长连接至第n
‑
1更新版本的所述应用。
18.可选地，所述负载均衡策略还包括：
19.增加相邻版本协同标识，所述标识用于显示所述相邻版本之间的更新功能数及更新代码量；
20.若所述更新功能数和/或更新代码量高于预设阈值，将所述多个用户终端按照预设比例进行分流，并将所述分流出的所述用户终端重新长连接至第n
‑
1更新版本的所述应用。
21.可选地，所述负载均衡策略包括：
22.增加相邻版本差异化标识，所述差异化标识用于指示相邻版本之间的差异；
23.基于所述差异化标识，确定所述多个用户终端的分流比例。
24.可选地，所述负载均衡策略包括：
25.获取相邻版本之间的发布进度的增量，基于所述增量，确定所述多个用户终端的分流比例。
26.可选地，所述方法还包括：
27.在所述多个用户终端中选择第一用户终端，在所述第一用户终端内部建立双线程，
28.基于第一线程，所述第一用户终端与所述第一更新版本的应用建立连接；
29.基于第二线程，所述第一用户终端与所述第二更新版本的应用建立双连接。
30.可选地，所述重新长连接至第一更新版本的所述应用之后，所述方法还包括：
31.获取所述第一更新版本的第一意见反馈，并将所述第一意见反馈信息回落至所述云集群，以便云集群获取速第一意见反馈后生成所述应用的第二更新版本。
32.可选地，所述将所述第二用户终端集群重新长连接至第二更新版本的所述应用之后，所述方法还包括：
33.获取所述第二更新版本的第二意见反馈，并将所述第二意见反馈信息回落至所述云集群，以便云集群获取速第二意见反馈后生成所述应用的第三更新版本。
34.可选地，所述云集群中包括搭载所述应用的多个云服务器，所述应用以容器的形
式部署在kubernetes集群中。
35.本发明实施例还包括一种装置，其特征在于，包括存储器和处理器，所述存储器上存储有计算机可执行指令，所述处理器运行所述存储器上的计算机可执行指令时实现上述方法。
36.本发明实施例提供的方法及装置，通过负载均衡策略及终端分流策略，云集群分批分次地将筛选出的用户终端进行不同开发进度的应用程序的版本使用体验，同时控制云集群的资源占用率，使其不会发生较大规模的流量波动，降低云集群宕机的风险；同时云集群将用户终端分级分类，将优先级别高的用户终端优先进行更新，降低部分用户对新版本投诉的几率，提升用户体验。
附图说明
37.为了更清楚地说明本发明实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍。
38.图1为一个实施例中云架构系统框图；
39.图2为一个实施例中基于云集群的应用更新的方法流程图；
40.图3a为一个实施例中负载均衡策略逻辑示意图；
41.图3b为一个实施例中终端分流策略逻辑示意图；
42.图4为一个实施例中装置的硬件组成示意图。
具体实施方式
43.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
44.应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
45.还应当理解，在此本技术说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本技术。如在本技术说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。
46.还应当进一步理解，在本技术说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
47.如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
[0048]
图1是本发明实施例提供的一种云集群架构，如图1所示，云集群包括多个云服务器，其内部存储有同一应用的不同版本v1
‑
vn,其中v1是老版本，v2
‑
v
n
‑1是开发过程中的多个更新版本，vn为正式发布版本。多个用户终端组成了用户总集群，需要进行v2版本更新
时，基于负载均衡策略和终端分流策略，从用户终端总集群中分离出第一集群，并将第一集群的用户终端进行v2版本的更新，需要进行v3版本的更新时，则从用户终端总集群以及第一集群中，分离出第二集群进行v3版本的更新。此外，每一次更新之后，云服务器需要获取更新版本的使用体验，以实时调整新版本的开发。
[0049]
图2是本发明实施例的一种基于云集群的应用更新的方法流程图，本发明实施例提供的方法，具体为：
[0050]
s101、多个用户终端与云集群中的应用实例建立长连接；
[0051]
云集群包括多个云服务器，该多个云服务器与多个用户终端进行通信，云集群中存储有应用实例，在云集群与多个用户终端建立通信的过程中，将应用实例推送给该多个用户终端，用户终端建立长连接，并进行该应用的使用。
[0052]
应用实例是指某一特定类型的应用，例如手机用户终端上常见的几类app应用，每一个用户终端获取同一类应用的一个应用实例，每一个应用实例具备一个id，该id与用户终端的id一一对应。
[0053]
s102、所述云集群获取所述应用的第一更新版本，所述第一更新版本为第一测试版本，所述第一测试版本的开发进度为第一进度；
[0054]
对于应用产品的开发阶段而言，通常有如下几个阶段：
[0055]
alpha：alpha是内部测试版,一般不向外部发布,会有很多错误。
[0056]
beta:该版本相对于alpha版已有了很大的改进，消除了严重的错误，但还是存在着一缺陷，需要经过多次测试来进一步消除。这个阶段的版本会一直加入新的功能。
[0057]
rc：(release candidate)是发行候选版本。和beta版最大的差别在于beta阶段会一直加入新的功能，但是到了rc版本，几乎就不会加入新的功能了，而主要着重于除错。rc版本是最终发放给用户的最接近正式版的版本，发行后改正错误后就是正式版了，就是正式版之前的最后一个测试版。
[0058]
release:最终版本，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。
[0059]
在本发明实施例中，更新版本是指beta版本，对于不同的测试版本其开发进度不一样，添加的功能也不同，对于beta版本中，可以按照开发进度10％，20％，50％等定义三个不同的更新版本v1,v2和v3，也可以按照不同的开发进度定义更多不同的更新版本，当开发进度到100％时，意味着该版本处于rc版本或release版本，将大面积进行应用的更新。
[0060]
为了方便说明，应用的第一更新版本定义为beta v1版，对应开发进度为k1，第二更新版本定义为beta v2版，对应开发进度为k2。以此类推，开发进度为100％的最终发布版本定义为re版。
[0061]
s103、所述云集群基于负载均衡策略及终端分流策略，将所述多个用户终端中的第一用户终端集群进行分离，并断开所述第一用户终端集群连接的所述应用实例，重新长连接至第一更新版本的所述应用，其中，所述第一用户终端集群的用户终端数量大于2且小于所述多个用户终端的数量；
[0062]
为了平衡大规模应用更新带来的流量峰值问题，本发明实施例中设置了负载均衡策略，同时为了平衡不同用户对于应用更新的需求喜好程度，本发明实施例设置了终端分流策略，对于不同用户终端是否需要进行版本更新的使用进行了一系列的策略上的考量。
[0063]
负载均衡策略本质上是为了平衡各个云服务器的负载，负载均衡的策略可以是：
[0064]
获取所述云集群中多个云服务器的资源占用率，并将所述多个云服务器按照资源占用率由高到低进行排序；
[0065]
依次将所述多个用户终端和/或所述第n
‑
1个用户终端集群流量分流至所述多个云服务器中，其中，每一个云服务器分流到的用户终端数量与所述对应的云服务器资源占用率排名成反比。
[0066]
图3a是负载均衡策略的逻辑示意图，如图3a所示，云集群包括5个云服务器，编号从a到e，其资源利用率分别为90％，80％，70％，60％和50％，则按照资源占用率从高到低排名后，名次分别是云服务器a
‑
云服务器b
‑
云服务器c
‑
云服务器d
‑
云服务器e；因此，在导流策略上，资源占用率低的云服务器可以导流多一些，而资源占用率高的云服务器导流只能少一些。而导流的源头则是连接到老版本的用户终端和/或已经更新了第n
‑
1版的用户终端，例如，连接了老版本的用户终端集群为a集群，已经更新了第n
‑
1版的用户集群为b集群(更新了beta v1版的用户集群)、c集群(更新了beta v2版的用户集群)和d集群(更新了beta v2版的用户集群)，负载均衡策略就需要将a,b,c,d四个集群的用户终端分流到上述不同的云服务器中，按照“相对空闲的云服务器多分用户终端流量，相对饱和的云服务器少分或不分用户终端流量”的原则进行划分。例如，云服务器a只分配集群a的部分流量，而云服务器b分配集群a和集群b，云服务器e则分配集群b,c,d的流量。
[0067]
此外，负载均衡解决的是云服务器分流端的问题，而终端分流策略解决的是哪一些终端需要版本更新，哪一些终端不需要版本更新的问题，两个策略相辅相成，各自从不同角度精细化进行分流。
[0068]
终端分流策略的逻辑是基于用户的自然属性和终端性能，评估是否具备更新的条件，以及更新之后对用户的影响。
[0069]
用户的自然属性包括用户的年龄、性别、兴趣爱好及应用更新频率等，如果该用户是年纪较小，应用更新频率快，且乐于对应用更新发表评论，则该用户活跃度较高(活跃度可基于用户的自然属性，按照自然属性与不同权值的加权运算求取)，适合推送不同应用的版本更新；反之，如果该用户年纪较大，且对于某一类应用接触时间短，几乎不进行应用的更新，则该用户不适合推送应用的版本更新。
[0070]
终端性能则是用户终端对于更新版本的应用的硬件支持条件，如果某一终端的内存只有512mb，而该更新版本的应用流畅运行至少需要1g内存，那么显然该终端性能不支持新版本的应用，不适合推送新版本。
[0071]
具体地，终端分流策略包括：对所述用户终端按照用户自然属性及终端性能进行评估，将所述用户终端分为优先更新集群及劣后更新集群，以便优先将所述优先更新集群中的用户终端重新长连接至第n
‑
1更新版本的所述应用，并且不对劣后更新集群进行版本的更新。其中，优先更新集群要满足两个条件，第一是该用户终端对应的用户活跃度超过预定的阈值，第二是该用户终端的性能满足流畅运行更新版应用的最低硬件条件，如果二者任一项达不到，则属于劣后更新集群。
[0072]
如图3b所示，终端分流策略逻辑为：将用户终端1
‑
5分别进行评估，评估维度包括用户活跃度以及终端性能，示例性地，用户活跃度＝用户年龄的倒数*权值1+用户历史更新频率*权值2+用户兴趣爱好广泛程度*权值3+用户对应用使用的反馈频率*权值4。终端性能
取值为0或1，0代表不能满足更新版应用的最低硬件要求，1代表满足更新版应用的最低硬件要求，通过用户活跃度*终端性能与阈值比较，超过或等于该阈值则该用户终端属于优先更新集群，低于该阈值则属于劣后更新集群。
[0073]
因此，结合负载均衡策略和终端分流策略的结果，负载均衡策略中，将用户终端分流给不同的云服务器，这里的用户终端只能是优先更新集群中的用户终端，而不是劣后更新集群的用户终端。
[0074]
此外，在本发明实施例中，负载均衡策略还包括：
[0075]
增加相邻版本协同标识，所述标识用于显示所述相邻版本之间的更新功能数及更新代码量；
[0076]
若所述更新功能数和/或更新代码量高于预设阈值，将所述多个用户终端按照预设比例进行分流，并将所述分流出的所述用户终端重新长连接至第n
‑
1更新版本的所述应用。即，如果v1版本和v2版本的差异量(实现功能数或内部实现的逻辑的差异)较大，那么不应将v1版本的用户或老版本的用户直接更新为v2版本，而只选取其中预设比例的一部分进行更新，保持其更新的平滑度。
[0077]
可选地，所述负载均衡策略还可以包括：
[0078]
增加相邻版本差异化标识，所述差异化标识用于指示相邻版本之间的差异；
[0079]
基于所述差异化标识，确定所述多个用户终端的分流比例。即，不同版本的差异与分流比例一一对应。
[0080]
可选地，所述负载均衡策略还可以包括：
[0081]
获取相邻版本之间的发布进度的增量δ，基于所述增量，确定所述多个用户终端的分流比例。例如，v1的发布进度为10％，v2的分布进度为20％，则增量为20％
‑
10％＝10％。
[0082]
其中，所述重新长连接至第一更新版本的所述应用之后，云集群还需要收集第一更新版本的反馈意见,具体地，用户终端获取所述第一更新版本的第一意见反馈，并将所述第一意见反馈信息回落(fallback)至所述云集群，以便云集群获取速第一意见反馈后生成所述应用的第二更新版本。
[0083]
s104、所述云集群获取所述应用的第二更新版本，所述第二更新版本为第二测试版本，所述第二测试版本的开发进度为第二进度；
[0084]
s105、所述云集群基于所述负载均衡策略及终端分流策略，将所述多个用户终端以及所述第一用户终端集群进行分离，分离出第二用户终端集群，并将所述第二用户终端集群重新长连接至第二更新版本的所述应用，其中，所述第二用户终端集群的用户终端数量大于2且小于所述多个用户终端的数量；
[0085]
需要说明的是，需要更新该第二更新版本的用户终端，基于负载均衡策略和终端分流策略，不仅可以从连接了老版本的用户终端中筛选，还可以从连接了第一更新版本的用户终端中筛选。
[0086]
此外，所述将所述第二用户终端集群重新长连接至第二更新版本的所述应用之后，云集群持续收集反馈意见，具体地，获取所述第二更新版本的第二意见反馈，并将所述第二意见反馈信息回落(fallback)至所述云集群，以便云集群获取速第二意见反馈后生成所述应用的第三更新版本。
[0087]
s106、所述云集群获取所述应用的第n更新版本，所述第n更新版本为最终发布re版本，并将所述多个用户终端依次重新与第n更新版本的所述应用建立长连接，其中n为大于等于3的正整数。
[0088]
需要说明的是，在本发明实施例中，版本更新可以采用双线程的方式进行，既在不断开第一版本连接的同时，还可以通过双线程连接第二版本。具体地，本发明实施例中，在所述多个用户终端中选择第一用户终端，在所述第一用户终端内部建立双线程，基于第一线程，所述第一用户终端与所述第一更新版本的应用建立连接；基于第二线程，所述第一用户终端与所述第二更新版本的应用建立双连接。
[0089]
此外，云集群中包括搭载所述应用的多个云服务器，所述应用以容器的形式部署在kubernetes集群中。
[0090]
本发明实施例提供的方法，通过负载均衡策略及终端分流策略，云集群分批分次地将筛选出的用户终端进行不同开发进度的应用程序的版本使用体验，同时控制云集群的资源占用率，使其不会发生较大规模的流量波动，降低云集群宕机的风险；同时云集群将用户终端分级分类，将优先级别高的用户终端优先进行更新，降低部分用户对新版本投诉的几率，提升用户体验。
[0091]
本发明实施例还包括一种装置，其特征在于，包括存储器和处理器，所述存储器上存储有计算机可执行指令，所述处理器运行所述存储器上的计算机可执行指令时实现上述方法。
[0092]
本发明实施例提供的方法及装置，通过在开发环境中下载运行环境中的多个微服务镜像，并对该微服务镜像进行分离、调试、集合、整合和更新，既能提高微服务的调试效率，又能及时对功能异常的微服务进行更新，提升稳定性。
[0093]
本发明实施例还提供一种计算机可读存储介质，其上存储有计算机可执行指令，该计算机可执行指令用于执行上述实施例中的方法。
[0094]
本发明实施例还提供一种装置，包括存储器和处理器，所述存储器上存储有计算机可执行指令，所述处理器运行所述存储器上的计算机可执行指令时实现上述方法。
[0095]
图4为一个实施例中装置的硬件组成示意图。可以理解的是，图4仅仅示出了装置的简化设计。在实际应用中，装置还可以分别包含必要的其他元件，包含但不限于任意数量的输入/输出系统、处理器、控制器、存储器等，而所有可以实现本技术实施例的大数据管理方法的装置都在本技术的保护范围之内。
[0096]
存储器包括但不限于是随机存储记忆体(random access memory，ram)、只读存储器(read至only memory，rom)、可擦除可编程只读存储器(erasable programmable read only memory，eprom)、或便携式只读存储器(compact disc read至only memory，cd至rom)，该存储器用于相关指令及数据。
[0097]
输入系统用于输入数据和/或信号，以及输出系统用于输出数据和/或信号。输出系统和输入系统可以是独立的器件，也可以是一个整体的器件。
[0098]
处理器可以包括是一个或多个处理器，例如包括一个或多个中央处理器(central processing unit，cpu)，在处理器是一个cpu的情况下，该cpu可以是单核cpu，也可以是多核cpu。处理器还可以包括一个或多个专用处理器，专用处理器可以包括gpu、fpga等，用于进行加速处理。
[0099]
存储器用于存储网络设备的程序代码和数据。
[0100]
处理器用于调用该存储器中的程序代码和数据，执行上述方法实施例中的步骤。具体可参见方法实施例中的描述，在此不再赘述。
[0101]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，该单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。所显示或讨论的相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，系统或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0102]
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0103]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本技术实施例的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程系统。该计算机指令可以存储在计算机可读存储介质中，或者通过该计算机可读存储介质进行传输。该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是只读存储器(read至only memory，rom)，或随机存储存储器(random access memory，ram)，或磁性介质，例如，软盘、硬盘、磁带、磁碟、或光介质，例如，数字通用光盘(digital versatile disc，dvd)、或者半导体介质，例如，固态硬盘(solid state disk，ssd)等。
[0104]
以上仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以权利要求的保护范围为准。