CN114968274B - 一种基于灰度发布的自动化快速部署前置机的方法及*** - Google Patents
一种基于灰度发布的自动化快速部署前置机的方法及*** Download PDFInfo
- Publication number
- CN114968274B CN114968274B CN202210902898.6A CN202210902898A CN114968274B CN 114968274 B CN114968274 B CN 114968274B CN 202210902898 A CN202210902898 A CN 202210902898A CN 114968274 B CN114968274 B CN 114968274B
- Authority
- CN
- China
- Prior art keywords
- end processor
- engineering
- sequence
- processor
- version
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 230000005540 biological transmission Effects 0.000 claims description 25
- 239000011159 matrix material Substances 0.000 claims description 20
- 230000006870 function Effects 0.000 claims description 14
- 238000012360 testing method Methods 0.000 claims description 14
- 238000012217 deletion Methods 0.000 claims description 12
- 230000037430 deletion Effects 0.000 claims description 12
- 238000004806 packaging method and process Methods 0.000 claims description 11
- 238000012986 modification Methods 0.000 claims description 8
- 230000004048 modification Effects 0.000 claims description 8
- 230000009467 reduction Effects 0.000 claims description 8
- 238000003066 decision tree Methods 0.000 claims description 6
- 238000012545 processing Methods 0.000 claims description 6
- 238000012935 Averaging Methods 0.000 claims description 4
- 238000012163 sequencing technique Methods 0.000 claims description 4
- 238000012795 verification Methods 0.000 claims description 4
- 241001270131 Agaricus moelleri Species 0.000 claims description 3
- 238000012544 monitoring process Methods 0.000 claims description 3
- 238000012856 packing Methods 0.000 claims description 3
- 230000007704 transition Effects 0.000 abstract description 2
- 230000008569 process Effects 0.000 description 21
- 239000003795 chemical substances by application Substances 0.000 description 7
- 238000010586 diagram Methods 0.000 description 5
- 230000007774 longterm Effects 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 239000002243 precursor Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明公开了一种基于灰度发布的自动化快速部署前置机的方法及***,包括用户管理模块、前置机工程配置模块、版本迭代模块和工程代码版本管理仓库,所述版本迭代模块与工程代码版本管理仓库、用户管理模块、前置机工程配置模块相连,通过工程代码版本管理仓库获取代码,进行当前代码的更新或回退,利用用户管理模块得到前置机的操作权限,从前置机工程配置模块获取工程配置参数,用于多个前置机的工程灰度发布,并调用其中的任务调度功能;本发明进行灰度发布,来保证整体***的稳定性,在初始灰度发布时发现、调整问题,以保证***前后版本能平稳过渡;引入任务调度功能,来缩短整体部署时间;通过动态检索操作员操作权限,规范操作员操作行为。
Description
技术领域
本发明涉及一种软件管理技术领域,尤其涉及一种基于灰度发布的自动化快速部署前置机的方法及***。
背景技术
随着软件行业的快速发展,工程应用越来越广泛,同一个工程应用往往会根据不同的环境参数、运行时的配置,部署在不同的前置机服务器上。而用于版本管理、工程部署的中心机只有一台服务器,如果前置机网络做了限制,只能用内网或者只能与中心机进行交互,则当需要工程版本更新时,需要在单个中心机服务器上根据不同环境分别打包前置机上的工程后再传输,将耗费大量的时间与内存空间。并且,在启动多个前置机工程中,将会导致不能同时更新,同时部署的问题,使得前置机上工程版本不一致,前置机之间无法互联响应。并有可能发生新的工程并不能同时兼容所有前置机,导致所有前置机服务器上的工程版本不一致,可能需要工程版本集体回退的情况。
这时候就需要进行灰度发布,使得工程版本之间可以平滑过渡。在发布的过程中进行A/B测试,即让一部分服务器继续使用上一个版本的工程,另一部分服务器可以优先使用下一版本的工程,保证整体***的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。目前市面上的发布***普遍没有用到灰度发布的功能,即使用到了也并未根据灰度发布的特点结合服务器的实际运行情况进行合理的自动化部署的任务调度,存在部署总体时间较长、效率低下,且无法回退的问题。
为此,我们提出一种基于灰度发布的自动化快速部署前置机的方法及***以解决上述技术问题。
发明内容
本发明为了解决上述技术问题,提供一种基于灰度发布的自动化快速部署前置机的方法及***。
本发明采用的技术方案如下:
一种基于灰度发布的自动化快速部署前置机的方法,包括以下步骤:
步骤S1:利用工程代码版本管理仓库对待部署的工程进行版本管理,所述工程代码版本管理仓库部署在远程服务器上;
步骤S2:登陆用户管理模块进行识别身份、验证多台前置机操作权限以及多台前置机工程配置的操作权限;
步骤S3:对前置机进行参数提取,根据提取的参数将所有前置机按序列排列,并将前置机序列在前的优先灰度发布部署;
步骤S4:当灰度发布部署10%部分前置机,则按顺序部署总前置机队列中前10%的前置机,并在部署完后做灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则继续灰度发布;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本,灰度发布结束;
步骤S5:当灰度发布部署10%-40%部分前置机,则需要对剩余90%前置机根据所述步骤S3重新排序,并按顺序部署剩余前置机中符合总前置机数量30%的排列靠前的前置机,并在部署完后做灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则继续灰度发布;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本,灰度发布结束;
步骤S6:当灰度发布需要发完剩余60%部分前置机,则需要对剩余前置机根据所述步骤S3重新排序,并按顺序部署剩余前置机,在部署完毕后进行灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则手动对未成功部署的前置机进行问题排查,人工更新部署;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本。
进一步地,所述步骤S3具体包括以下子步骤:
步骤S31:对每个前置机进行参数提取;
步骤S32:根据前置机当前CPU负载情况,使用决策树进行分类,按顺序得到多个初始序列;
步骤S33:在每个初始序列中结合前置机内存剩余量、更新包的大小和预计传输时间进行序列内的排序,得到序列;
步骤S34:确定各序列中的前置机序号,将所有前置机按所在序列顺序以及序列内的位置排列,并将前置机序列在前的优先灰度发布部署。
进一步地,所述步骤S31具体包括以下子步骤:
步骤S311:提取当前前置机内存剩余量;
步骤S312:提取网络带宽;
步骤S313:提取更新包的大小;
步骤S314:根据所述网络带宽和所述更新包的大小计算更新包预计传输时间。
进一步地,所述步骤S32具体为根据CPU平均负载和CPU内核数量,将待部署的前置机进行序列划分,划分情况分为以下四种;
一分钟的平均负载小于CPU内核数量的前置机划分为第一序列;
一分钟的平均负载大于等于CPU内核数量的前置机且五分钟的平均负载小于CPU内核数量的前置机划分为第二序列;
一分钟的平均负载大于等于CPU内核数量的前置机且五分钟的平均负载大于等于CPU内核数量的前置机以及十五分钟的平均负载小于CPU内核数量的前置机划分为第三序列;
剩余的前置机划分为第四序列。
进一步地,所述步骤S33具体包括以下子步骤:
步骤S331:将前置机内存剩余量、更新包的大小和预计传输时间组成矩阵;
步骤S332:将矩阵的每一行进行零均值化;
步骤S333:求出协方差矩阵;
步骤S334:求出协方差矩阵的特征值及对应的特征向量;
步骤S335:将特征向量按对应特征值大小从上到下按行排列成新的矩阵;
步骤S336:取降维到1维后的数据得到特征分量,计算各个前置机的预计总部署时间;
步骤S337:按预计总部署时间对前置机进行正序排列,总部署时间越短则前置机序号越前。
进一步地,所述部署的具体方法包括以下步骤:
步骤一:用户利用版本迭代模块,发送前置机工程自动化部署请求给中心机,所述中心机从所述工程代码版本管理仓库下载工程对应版本代码,并结合当前所述前置机的工程版本,生成工程更新包,使用ssh代理将所述工程更新包进行压缩;
步骤二:将压缩后的所述工程更新包传输到当前所述前置机的工程对应位置上并解压,得到解压后的更新包;
步骤三:用户从前置机工程配置模块将本次操作对应的前置机工程参数下拉到前置机工程目录下;
步骤四:用户向当前所述前置机发送最终更新工程的请求,当前所述前置机收到请求后将工程打包,并执行启动脚本将工程运行在docker容器中;
步骤五:当前所述前置机自动将用于打包的工程代码删除,完成工程部署。
进一步地,所述步骤一所述自动化部署请求包括将要部署的前置机地址信息、传输验证信息、前置机工程对应的环境和待部署工程的版本号。
进一步地,所述步骤三还包括当所述前置机需要在运行配置参数中进行调整,则用户进入前置机工程配置模块,进行对应所述前置机的配置参数管理;所述前置机的运行配置参数根据前置机和运行环境以键值对的形式存储在中心机的数据库中,对配置参数管理即为数据库层面的操作,将存储的运行配置参数传输到所述步骤二生成的前置机工程对应目录下,自动生成配置文件,以java工程为例,即在资源目录下生成后缀为.properties的文件。
进一步地,所述步骤四具体包括在前置机上使用ssh代理运行自动部署脚本,所述自动部署脚本步骤依次为:工程打包、容器停止运行、容器删除、镜像删除、新镜像重建、容器重建和容器运行。
本发明还提供一种基于灰度发布的自动化快速部署前置机的***,包括:用户管理模块、前置机工程配置模块、版本迭代模块和工程代码版本管理仓库,所述版本迭代模块与工程代码版本管理仓库、用户管理模块、前置机工程配置模块相连,通过工程代码版本管理仓库获取代码,进行当前代码的更新或回退,利用用户管理模块得到前置机的操作权限,从前置机工程配置模块获取工程配置参数,用于多个前置机的工程灰度发布,并调用其中的任务调度功能;
用户管理模块,用于对用户的增删查改操作,配置各个用户的操作权限,提高***版本迭代的安全性,提供登陆登出本***的功能,用户信息记录在中心机的后台数据库中;
前置机工程配置模块,用于区分各个前置机,各个环境下工程打包需要的配置信息,搭建工程正常运行所需要的环境,提供增删查改操作,以前置机编号、运行环境、配置条目键值对的形式统一存储在中心机的后台数据库中,每次自动化部署时,向版本迭代模块提供工程相应的配置参数;
版本迭代模块,用于监控并记录各个前置机的当前运行环境信息,作为用户远程管理、控制前置机、运用算法优化灰度发布顺序制定发布策略的基础,提供增删查改操作,前置机各环境版本迭代信息记录在中心机的后台数据库中;
工程代码版本管理仓库,用于存放、管理工程各版本代码。
本发明的有益效果是:
1、本发明通过动态检索操作员操作权限,规范操作员操作行为,动态管理前置机工程版本并根据环境赋予工程配置,结合各服务器实际运行情况,进行自动化部署,保证了***的安全性,灵活性,前置机服务器上工程的鲁棒性。
2、由于无法保证新版本能适配全部前置机服务器,本发明进行灰度发布,来保证整体***的稳定性,在初始灰度的时候就可以发现、调整问题,以保证***前后版本能平稳过渡。
3、由于前置机操作人员以及更高级的操作人员一次需要操作更新部署多台前置机服务器,而前置机在工程打包、传输、启动时耗时较多,为了使得灰度发布更快,本发明引入任务调度功能,来缩短整体部署时间。
附图说明
图1为本发明一种基于灰度发布的自动化快速部署前置机的方法流程图;
图2为本发明一种基于灰度发布的自动化快速部署前置机的***示意图;
图3为实施例多台前置机进行自动化部署方法示意图;
图4为实施例基于灰度发布的自动化部署前置机示意图;
图5为实施例任务调度进行发布的逻辑判断示意图;
图6为实施例基于决策树,结合平均负载(load average)和CPU内核数量将待更新的前置机进行序列划分的方式;
图7为实施例基于任务调度优先级算法,200M大小的更新包压缩文件的实际部署时间通过PCA降维后做的拟合示意图。
具体实施方式
以下对至少一个示例性实施例的描述实际上仅仅是说明性的,决不作为对本发明及其应用或使用的任何限制。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
参见图1,一种基于灰度发布的自动化快速部署前置机的方法,包括以下步骤:
步骤S1:利用工程代码版本管理仓库对待部署的工程进行版本管理,所述工程代码版本管理仓库部署在远程服务器上;
步骤S2:登陆用户管理模块进行识别身份、验证多台前置机操作权限以及多台前置机工程配置的操作权限;
步骤S3:对前置机进行参数提取,根据提取的参数将所有前置机按序列排列,并将前置机序列在前的优先灰度发布部署;
步骤S31:对每个前置机进行参数提取;
步骤S311:提取当前前置机内存剩余量;
步骤S312:提取网络带宽;
步骤S313:提取更新包的大小;
步骤S314:根据所述网络带宽和所述更新包的大小计算更新包预计传输时间。
步骤S32:根据前置机当前CPU负载情况,使用决策树进行分类,按顺序得到多个初始序列;
具体为根据CPU平均负载和CPU内核数量,将待部署的前置机进行序列划分,划分情况分为以下四种;
一分钟的平均负载小于CPU内核数量的前置机划分为第一序列;
一分钟的平均负载大于等于CPU内核数量的前置机且五分钟的平均负载小于CPU内核数量的前置机划分为第二序列;
一分钟的平均负载大于等于CPU内核数量的前置机且五分钟的平均负载大于等于CPU内核数量的前置机以及十五分钟的平均负载小于CPU内核数量的前置机划分为第三序列;
剩余的前置机划分为第四序列。
步骤S33:在每个初始序列中结合前置机内存剩余量、更新包的大小和预计传输时间进行序列内的排序,得到序列;
步骤S331:将前置机内存剩余量、更新包的大小和预计传输时间组成矩阵;
步骤S332:将矩阵的每一行进行零均值化;
步骤S333:求出协方差矩阵;
步骤S334:求出协方差矩阵的特征值及对应的特征向量;
步骤S335:将特征向量按对应特征值大小从上到下按行排列成新的矩阵;
步骤S336:取降维到1维后的数据得到特征分量,计算各个前置机的预计总部署时间;
步骤S337:按预计总部署时间对前置机进行正序排列,总部署时间越短则前置机序号越前。
步骤S34:确定各序列中的前置机序号,将所有前置机按所在序列顺序以及序列内的位置排列,并将前置机序列在前的优先灰度发布部署。
步骤S4:当灰度发布部署10%部分前置机,则按顺序部署总前置机队列中前10%的前置机,并在部署完后做灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则继续灰度发布;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本,灰度发布结束;
步骤S5:当灰度发布部署10%-40%部分前置机,则需要对剩余90%前置机根据所述步骤S3重新排序,并按顺序部署剩余前置机中符合总前置机数量30%的排列靠前的前置机,并在部署完后做灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则继续灰度发布;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本,灰度发布结束;
步骤S6:当灰度发布需要发完剩余60%部分前置机,则需要对剩余前置机根据所述步骤S3重新排序,并按顺序部署剩余前置机,在部署完毕后进行灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则手动对未成功部署的前置机进行问题排查,人工更新部署;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本。
所述部署的具体方法包括以下步骤:
步骤一:用户利用版本迭代模块,发送前置机工程自动化部署请求给中心机,所述中心机从所述工程代码版本管理仓库下载工程对应版本代码,并结合当前所述前置机的工程版本,生成工程更新包,使用ssh代理将所述工程更新包进行压缩;
所述自动化部署请求包括将要部署的前置机地址信息、传输验证信息、前置机工程对应的环境和待部署工程的版本号。
步骤二:将压缩后的所述工程更新包传输到当前所述前置机的工程对应位置上并解压,得到解压后的更新包;
步骤三:用户从前置机工程配置模块将本次操作对应的前置机工程参数下拉到前置机工程目录下;
还包括当所述前置机需要在运行配置参数中进行调整,则用户进入前置机工程配置模块,进行对应所述前置机的配置参数管理;所述前置机的运行配置参数根据前置机和运行环境以键值对的形式存储在中心机的数据库中,对配置参数管理即为数据库层面的操作,将存储的运行配置参数传输到所述步骤二生成的前置机工程对应目录下,自动生成配置文件,以java工程为例,即在资源目录下生成后缀为.properties的文件。
步骤四:用户向当前所述前置机发送最终更新工程的请求,当前所述前置机收到请求后将工程打包,并执行启动脚本将工程运行在docker容器中;
具体包括在前置机上使用ssh代理运行自动部署脚本,所述自动部署脚本步骤依次为:工程打包、容器停止运行、容器删除、镜像删除、新镜像重建、容器重建和容器运行。
步骤五:当前所述前置机自动将用于打包的工程代码删除,完成工程部署。
参见图2,一种基于灰度发布的自动化快速部署前置机的***,包括:用户管理模块、前置机工程配置模块、版本迭代模块和工程代码版本管理仓库,所述版本迭代模块与工程代码版本管理仓库、用户管理模块、前置机工程配置模块相连,通过工程代码版本管理仓库获取代码,进行当前代码的更新或回退,利用用户管理模块得到前置机的操作权限,从前置机工程配置模块获取工程配置参数,用于多个前置机的工程灰度发布,并调用其中的任务调度功能;
用户管理模块,用于对用户的增删查改操作,配置各个用户的操作权限,提高***版本迭代的安全性,提供登陆登出本***的功能,用户信息记录在中心机的后台数据库中;
高等级用户可以在用户管理模块管理低等级用户。例如,前置机管理员可以管理一般操作人员,进行操作权限的赋予与收回,用户新增与删除等操作,***管理员可以管理前置机管理员,赋予其前置机权限发放与收回等操作。
前置机工程配置模块,用于区分各个前置机,各个环境下工程打包需要的配置信息,搭建工程正常运行所需要的环境,提供增删查改操作,以前置机编号、运行环境、配置条目键值对的形式统一存储在中心机的后台数据库中,每次自动化部署时,向版本迭代模块提供工程相应的配置参数;
将工程内的配置文件拆分成多条,以前置机编号、运行环境、配置条目键值对的形式统一存储在中心机的后台数据库中。对配置进行修改转为对数据库进行修改,更新时通过访问数据库在前置机工程内重新生成配置文件。因此每次自动化部署时,必须向版本迭代模块提供工程相应的配置参数,供工程正常运行。
版本迭代模块,用于监控并记录各个前置机的当前运行环境信息,作为用户远程管理、控制前置机、运用算法优化灰度发布顺序制定发布策略的基础,提供增删查改操作,前置机各环境版本迭代信息记录在中心机的后台数据库中;
工程代码版本管理仓库,用于存放、管理工程各版本代码。
实施例:
参见图3-图5,步骤S1:利用工程代码版本管理仓库对待部署的工程进行版本管理,所述工程代码版本管理仓库部署在远程服务器上;
只对用户开放代码管理权限,确保工程代码的完整性、保密性和安全性;
用户需自行管理工程代码版本管理仓库内的代码主版本与分支版本,确保在发布过程中不会因为工程本身的原因导致出错。
步骤S2:登陆用户管理模块进行识别身份、验证多台前置机操作权限以及多台前置机工程配置的操作权限;
步骤S3:对前置机进行参数提取,根据提取的参数将所有前置机按序列排列,并将前置机序列在前的优先灰度发布部署;
步骤S31:对每个前置机进行参数提取;
前置机CPU运行情况、当前内存使用状态、网络带宽由web service获取。在被监测前置机服务器上运行一个进程,保持心跳连接,定时轮询检测信息,并实时发送给本***,而更新包的大小在更新包生成的时候做计算也能获取到。
***负载是***CPU繁忙程度的度量,即有多少进程在等待被CPU调度(进程等待队列的长度)。平均负载(load average)是一段时间内***的平均负载,这个一段时间一般取1分钟、5分钟、15分钟。我们提取当前平均负载(load average)参数,一共有3个参数,设为load1(i),load5(i),load15(i)。
前置机往往在一个CPU内部,包含多个CPU核心,这被称为多核CPU。在***负荷方面,必须考虑这台电脑CPU有几个核心。然后,把***负荷除以总的核心数,只要每个核心的负荷不超过1.0,就表明电脑正常运行。我们再提取当前前置机CPU内核数量,记为c(i);
步骤S311:提取当前前置机内存剩余量M(i),记为M(i);
步骤S312:提取网络带宽W(i);
步骤S313:提取更新包的大小U(i);
步骤S314:根据所述网络带宽和所述更新包的大小计算更新包预计传输时间T(i)= U(i) / W(i)。
步骤S32:根据前置机当前CPU负载情况,使用决策树进行分类,按顺序得到多个初始序列;
具体为根据CPU平均负载和CPU内核数量,将待部署的前置机进行序列划分,划分情况分为以下四种;
一分钟的平均负载小于CPU内核数量的前置机划分为第一序列;
一分钟的平均负载大于等于CPU内核数量的前置机且五分钟的平均负载小于CPU内核数量的前置机划分为第二序列;
一分钟的平均负载大于等于CPU内核数量的前置机且五分钟的平均负载大于等于CPU内核数量的前置机以及十五分钟的平均负载小于CPU内核数量的前置机划分为第三序列;
剩余的前置机划分为第四序列。
为了使得部署过程整体稳定,需要将当前CPU较为空闲的前置机进行工程先行部署。一般来说,平均负载(load average)是与CPU内核数量有关的。以一个单核的机器为例,load=0.5表示CPU还有一半的资源可以处理其他的线程请求,load=1表示CPU所有的资源都在处理请求,没有剩余的资源可以利用了,而load=2则表示CPU已经超负荷运作,另外还有一倍的线程正在等待处理。所以,对于单核机器来说,理想状态下,平均负载(loadaverage)要小于1。同理,对于多(n)核CPU来说,平均负载(load average)要小于n。
而平均负载(load average)一共有三个参数,分别代表1分钟、5分钟、15分钟的平均负载(load average),所以如何判断当前CPU真实运行负载,可以结合具体情况具体分析(n核):
1分钟Load > n,5分钟Load < n,15分钟Load < n:短期内繁忙,中、长期空闲,有可能是只是一个“抖动”,也有可能是***“拥塞前兆”。1分钟Load > n,5分钟Load > n,15分钟Load < n:短、中期内繁忙,长期空闲,***“开始拥塞”。
1分钟Load > n,5分钟Load > n,15分钟Load > n:短、中、长期都繁忙,***“正在拥塞”。
1分钟Load < n,5分钟Load > n,15分钟Load > n:短期内空闲,中、长期繁忙,***“拥塞正在恢复”。
因此,使用决策树,结合平均负载(load average)和CPU内核数量将待更新的前置机进行序列划分,参见图6所示。
将load1(i) < n的前置机划分为第一序列;
将load1(i) ≥ n且load5(i) < n的前置机划分为第二序列;
将load1(i) ≥ n且load5(i) ≥ n且load15(i) < n的前置机划分为第三序列;
将剩余的前置机划分为第四序列。
步骤S33:在每个初始序列中结合前置机内存剩余量、更新包的大小和预计传输时间进行序列内的排序,得到序列;
为了衡量前置机的负载高低,这里定义前置机的预计总部署时间E(i):
E(i)=H(M(i),U(i),U(i)/M(i))+T(i)
定义前置机的优先度E(i)主要由M(i)前置机内存剩余量,U(i)更新包大小,U(i)/M(i)内存读取更新包作用因子以及T(i) 更新包预计传输时间决定。
H(M(i),U(i),U(i)/M(i))中具体影响因素大小需要由实验测定。
举例,一个200M大小的更新包压缩文件经过多台前置机实际测量后(50台前置机重复测量),得到不同前置机参数下的实际更新部署时间。在这里引入PCA降维操作,通过H(M(i),U(i),U(i)/M(i))以及前置机实际部署时间,对三维数组提取数据主要特征分量。
步骤S331:将前置机内存剩余量、更新包的大小和预计传输时间组成3行200列矩阵;
步骤S332:将矩阵的每一行(代表一个属性字段)进行零均值化;
步骤S333:求出协方差矩阵;
步骤S334:求出协方差矩阵的特征值及对应的特征向量r;
步骤S335:将特征向量r按对应特征值大小从上到下按行排列成新的矩阵P;
步骤S336:取Y=PX即降维到1维后的数据得到特征分量(m(i),u(i),um(i)),计算各个前置机的预计总部署时间H(M(i),U(i),U(i)/M(i)) = (m(i),u(i),um(i))(M(i),U(i),U(i)/M(i));
步骤S337:按预计总部署时间对前置机进行正序排列,总部署时间越短则前置机序号越前。
参见图7,根据本发明的任务调度优先级算法,可以看出200M大小的压缩文件的实际部署时间排列顺序在通过PCA降维后拟合度较高。图中“降维后的数据”表示PCA降维后的一维数据与时间对应的点。
本地主机的硬件配置、内存容量以及工作频率决定了它一次只能同时进行为数不多个进程,即一次只能同时向为数不多的前置机进行部署作业。为了保证更多的前置机以更快的时间得到部署,按序号优先对预计总部署时间较短的前置机进行部署作业,等排序靠前的前置机部署完毕后依序进行之后的前置机工程部署作业。
举例:本地主机对于大工程部署作业一次只能同时对接5个前置机。首先分别向排序前5的前置机部署作业,占5个进程,等其中某个前置机部署作业完毕,进程空闲下来,即按顺序部署作业给排序第6的前置机。当又有前置机部署作业完毕,进程空闲下来后,即按顺序部署作业给排序第7的前置机,以此类推,直到进入调度***的所有前置机都进入部署作业或部署作业完毕的状态,调度功能执行完毕。
由于任务调度功能将较为空闲、所需更新包较小的前置机进行了优先传输,这些前置机在各自部署过程中所花时间相对较少,因此在整体部署过程中前10%以及前40%的前置机进行灰度测试的时间得到了缩减,做到了在初始灰度的时候就可以早发现、调整问题,提高了***的高效性与稳定性。对于剩下的60%的前置机来说,这种任务调度策略是以CPU负载低、内存剩余容量大的服务器做优先考虑的,也就是空闲的、部署速度快的机器优先发,也从另一个层面提高了部署***的高效性。
为了整个部署过程更加稳定、快捷,这里需要引入灰度发布的功能。在部署的过程中分段检查整体部署状况,各前置机工程是否正常运行。来判断当前更新版本是否与所有前置机适配,是否继续部署还是停止部署、并对之前已部署的前置机做版本回退的操作,以保证前置机工程版本一致,为了保证***前后版本能平稳过渡,避免过多前置机前后版本不适配导致***整体新版本部署失败的现象。
由于灰度发布过程是一个分阶段部署、检测的过程,在实际操作中,工程版本更新往往有很多意想不到的错误、结合前置机实际情况没有考虑到的地方,因此部署完后检测出大量错误,需要发生版本回退是很常见的情形。如果能更早更快地检测出问题,也就是在灰度发布10%、40%前两轮就检测出问题,而前置机在工程打包、传输时耗时较多,在这里引入任务调度功能,结合待部署的前置机实际情况来优化部署顺序,缩短部署整体时间,提高效率。
步骤S34:确定各序列中的前置机序号,将所有前置机按所在序列顺序以及序列内的位置排列,并将前置机序列在前的优先灰度发布部署。
步骤S4:当灰度发布部署10%部分前置机,则按顺序部署总前置机队列中前10%的前置机,并在部署完后做灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则继续灰度发布;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本,灰度发布结束;
步骤S5:当灰度发布部署10%-40%部分前置机,则需要对剩余90%前置机根据所述步骤S3重新排序,并按顺序部署剩余前置机中符合总前置机数量30%的排列靠前的前置机,并在部署完后做灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则继续灰度发布;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本,灰度发布结束;
步骤S6:当灰度发布需要发完剩余60%部分前置机,则需要对剩余前置机根据所述步骤S3重新排序,并按顺序部署剩余前置机,在部署完毕后进行灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则手动对未成功部署的前置机进行问题排查,人工更新部署;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本。
所述部署的具体方法包括以下步骤:
步骤一:用户利用版本迭代模块,发送前置机工程自动化部署请求给中心机,所述中心机从所述工程代码版本管理仓库下载工程对应版本代码,并结合当前所述前置机的工程版本,生成工程更新包,使用ssh代理将所述工程更新包进行压缩;
压缩成tar.gz的格式,使体积缩小,方便后续与前置机的文件传输;
所述自动化部署请求包括将要部署的前置机地址信息、传输验证信息、前置机工程对应的环境和待部署工程的版本号;
中心机根据请求中的版本号下载下来的工程文件夹,因为缺失了工程的运行配置参数所以不具备实际运行条件,只能用于打包传输。
以本机目前部署的java工程为例,未打包的工程更新包实际大小在2.2MB左右,打包之后在800KB左右,极大的提高了中心机与前置机之间的传输速度,同时也是为了提高在中心机与多台前置机之间传输这样的场景下传输的效率。
步骤二:将压缩后的所述工程更新包传输到当前所述前置机的工程对应位置上并解压,得到解压后的更新包;
此过程根据工程更新包的大小、压缩后tar.gz的大小以及当前前置机的带宽、当前前置机剩余内存大小以及剩余CPU负载会在时间上有较大差异,该过程使用ssh代理,通过scp传输,执行较为方便快捷。
步骤三:用户从前置机工程配置模块将本次操作对应的前置机工程参数下拉到前置机工程目录下;
还包括当所述前置机需要在运行配置参数中进行调整,则用户进入前置机工程配置模块,进行对应所述前置机的配置参数管理;所述前置机的运行配置参数根据前置机和运行环境以键值对的形式存储在中心机的数据库中,对配置参数管理即为数据库层面的操作,将存储的运行配置参数传输到所述步骤二生成的前置机工程对应目录下,自动生成配置文件,以java工程为例,即在资源目录下生成后缀为.properties的文件。
步骤四:用户向当前所述前置机发送最终更新工程的请求,当前所述前置机收到请求后将工程打包,并执行启动脚本将工程运行在docker容器中;
具体包括在前置机上使用ssh代理运行自动部署脚本,所述自动部署脚本步骤依次为:工程打包、容器停止运行、容器删除、镜像删除、新镜像重建、容器重建和容器运行。
步骤五:当前所述前置机自动将用于打包的工程代码删除,完成工程部署。
本发明规范了前置机自动部署过程中的一切操作技术信息,以及操作员信息。通过动态检索操作员操作权限,规范操作员操作行为,动态管理前置机工程版本并根据环境赋予工程配置,并提供实时后台日志查阅,保证了***的安全性,灵活性,前置机工程的鲁棒性。通过灰度发布结合任务调度功能合理优化部分前置机更新时间,缩短批量自动部署整体时间,提高本***效率,利用Vue前端技术框架,数据库使用了Oracle存储架构,具有处理速度快,安全级别高的特点。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种基于灰度发布的自动化快速部署前置机的方法,其特征在于,包括以下步骤:
步骤S1:利用工程代码版本管理仓库对待部署的工程进行版本管理,所述工程代码版本管理仓库部署在远程服务器上;
步骤S2:登陆用户管理模块进行识别身份、验证多台前置机操作权限以及多台前置机工程配置的操作权限;
步骤S3:对前置机进行参数提取,根据提取的参数将所有前置机按序列排列,并将前置机序列在前的优先灰度发布部署;
步骤S4:当灰度发布部署10%部分前置机,则按顺序部署总前置机队列中前10%的前置机,并在部署完后做灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则继续灰度发布;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本,灰度发布结束;
步骤S5:当灰度发布部署10%-40%部分前置机,则需要对剩余90%前置机根据所述步骤S3重新排序,并按顺序部署剩余前置机中符合总前置机数量30%的排列靠前的前置机,并在部署完后做灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则继续灰度发布;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本,灰度发布结束;
步骤S6:当灰度发布需要发完剩余60%部分前置机,则需要对剩余前置机根据所述步骤S3重新排序,并按顺序部署剩余前置机,在部署完毕后进行灰度测试,当满足新旧功能端口通畅和***整体运行稳定的前置机数量占比已部署前置机数量大于等于90%,则手动对未成功部署的前置机进行问题排查,人工更新部署;反之,则在已部署的前置机上进行版本回退,直至所有前置机上的工程回到之前的版本。
2.如权利要求1所述的一种基于灰度发布的自动化快速部署前置机的方法,其特征在于,所述步骤S3具体包括以下子步骤:
步骤S31:对每个前置机进行参数提取;
步骤S32:根据前置机当前CPU负载情况,使用决策树进行分类,按顺序得到多个初始序列;
步骤S33:在每个初始序列中结合前置机内存剩余量、更新包的大小和预计传输时间进行序列内的排序,得到序列;
步骤S34:确定各序列中的前置机序号,将所有前置机按所在序列顺序以及序列内的位置排列,并将前置机序列在前的优先灰度发布部署。
3.如权利要求2所述的一种基于灰度发布的自动化快速部署前置机的方法,其特征在于,所述步骤S31具体包括以下子步骤:
步骤S311:提取当前前置机内存剩余量;
步骤S312:提取网络带宽;
步骤S313:提取更新包的大小;
步骤S314:根据所述网络带宽和所述更新包的大小计算更新包预计传输时间。
4.如权利要求2所述的一种基于灰度发布的自动化快速部署前置机的方法,其特征在于,所述步骤S32具体为根据CPU平均负载和CPU内核数量,将待部署的前置机进行序列划分,划分情况分为以下四种;
一分钟的平均负载小于CPU内核数量的前置机划分为第一序列;
一分钟的平均负载大于等于CPU内核数量的前置机且五分钟的平均负载小于CPU内核数量的前置机划分为第二序列;
一分钟的平均负载大于等于CPU内核数量的前置机且五分钟的平均负载大于等于CPU内核数量的前置机以及十五分钟的平均负载小于CPU内核数量的前置机划分为第三序列;
剩余的前置机划分为第四序列。
5.如权利要求2所述的一种基于灰度发布的自动化快速部署前置机的方法,其特征在于,所述步骤S33具体包括以下子步骤:
步骤S331:将前置机内存剩余量、更新包的大小和预计传输时间组成矩阵;
步骤S332:将矩阵的每一行进行零均值化;
步骤S333:求出协方差矩阵;
步骤S334:求出协方差矩阵的特征值及对应的特征向量;
步骤S335:将特征向量按对应特征值大小从上到下按行排列成新的矩阵;
步骤S336:取降维到1维后的数据得到特征分量,计算各个前置机的预计总部署时间;
步骤S337:按预计总部署时间对前置机进行正序排列,总部署时间越短则前置机序号越前。
6.如权利要求1所述的一种基于灰度发布的自动化快速部署前置机的方法,其特征在于,所述部署的具体方法包括以下步骤:
步骤一:用户利用版本迭代模块,发送前置机工程自动化部署请求给中心机,所述中心机从所述工程代码版本管理仓库下载工程对应版本代码,并结合当前所述前置机的工程版本,生成工程更新包,使用ssh代理将所述工程更新包进行压缩;
步骤二:将压缩后的所述工程更新包传输到当前所述前置机的工程对应位置上并解压,得到解压后的更新包;
步骤三:用户从前置机工程配置模块将本次操作对应的前置机工程参数下拉到前置机工程目录下;
步骤四:用户向当前所述前置机发送最终更新工程的请求,当前所述前置机收到请求后将工程打包,并执行启动脚本将工程运行在docker容器中;
步骤五:当前所述前置机自动将用于打包的工程代码删除,完成工程部署。
7.如权利要求6所述的一种基于灰度发布的自动化快速部署前置机的方法,其特征在于,所述步骤一所述自动化部署请求包括将要部署的前置机地址信息、传输验证信息、前置机工程对应的环境和待部署工程的版本号。
8.如权利要求6所述的一种基于灰度发布的自动化快速部署前置机的方法,其特征在于,所述步骤三还包括当所述前置机需要在运行配置参数中进行调整,则用户进入前置机工程配置模块,进行对应所述前置机的配置参数管理;所述前置机的运行配置参数根据前置机和运行环境以键值对的形式存储在中心机的数据库中,对配置参数管理即为数据库层面的操作,将存储的运行配置参数传输到所述步骤二生成的前置机工程对应目录下,自动生成配置文件。
9.如权利要求6所述的一种基于灰度发布的自动化快速部署前置机的方法,其特征在于,所述步骤四具体包括在前置机上使用ssh代理运行自动部署脚本,所述自动部署脚本步骤依次为:工程打包、容器停止运行、容器删除、镜像删除、新镜像重建、容器重建和容器运行。
10.一种实现权利要求1-9任一项所述的基于灰度发布的自动化快速部署前置机的方法的***,其特征在于,包括:用户管理模块、前置机工程配置模块、版本迭代模块和工程代码版本管理仓库,所述版本迭代模块与工程代码版本管理仓库、用户管理模块、前置机工程配置模块相连,通过工程代码版本管理仓库获取代码,进行当前代码的更新或回退,利用用户管理模块得到前置机的操作权限,从前置机工程配置模块获取工程配置参数,用于多个前置机的工程灰度发布,并调用其中的任务调度功能;
用户管理模块,用于对用户的增删查改操作,配置各个用户的操作权限,提高***版本迭代的安全性,提供登陆登出本***的功能,用户信息记录在中心机的后台数据库中;
前置机工程配置模块,用于区分各个前置机,各个环境下工程打包需要的配置信息,搭建工程正常运行所需要的环境,提供增删查改操作,以前置机编号、运行环境、配置条目键值对的形式统一存储在中心机的后台数据库中,每次自动化部署时,向版本迭代模块提供工程相应的配置参数;
版本迭代模块,用于监控并记录各个前置机的当前运行环境信息,作为用户远程管理、控制前置机、运用算法优化灰度发布顺序制定发布策略的基础,提供增删查改操作,前置机各环境版本迭代信息记录在中心机的后台数据库中;
工程代码版本管理仓库,用于存放、管理工程各版本代码。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210902898.6A CN114968274B (zh) | 2022-07-29 | 2022-07-29 | 一种基于灰度发布的自动化快速部署前置机的方法及*** |
US18/360,840 US20240036860A1 (en) | 2022-07-29 | 2023-07-28 | Method and system for automatically and quickly deploying front-end processor based on gray release |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210902898.6A CN114968274B (zh) | 2022-07-29 | 2022-07-29 | 一种基于灰度发布的自动化快速部署前置机的方法及*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114968274A CN114968274A (zh) | 2022-08-30 |
CN114968274B true CN114968274B (zh) | 2022-11-08 |
Family
ID=82968619
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210902898.6A Active CN114968274B (zh) | 2022-07-29 | 2022-07-29 | 一种基于灰度发布的自动化快速部署前置机的方法及*** |
Country Status (2)
Country | Link |
---|---|
US (1) | US20240036860A1 (zh) |
CN (1) | CN114968274B (zh) |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105867990A (zh) * | 2015-11-20 | 2016-08-17 | 乐视云计算有限公司 | 软件开发一体化的方法及装置 |
US10346279B2 (en) * | 2017-07-25 | 2019-07-09 | Citrix Systems, Inc. | Method for optimized canary deployments for improved customer experience |
CN109240716B (zh) * | 2018-09-10 | 2022-10-25 | 福建星瑞格软件有限公司 | 一种大数据平台版本管理与快速迭代部署方法及*** |
CN109240669A (zh) * | 2018-10-26 | 2019-01-18 | 苏州浪潮智能软件有限公司 | 一种自动化集成部署软件开发模式 |
CN110071960A (zh) * | 2019-03-12 | 2019-07-30 | 平安科技(深圳)有限公司 | 管理灰度发布的方法、***、设备及存储介质 |
CN111158715B (zh) * | 2019-12-19 | 2024-02-06 | 中国平安财产保险股份有限公司 | 灰度发布控制方法及*** |
US11157253B1 (en) * | 2020-06-30 | 2021-10-26 | Td Ameritrade Ip Company, Inc. | Computer-automated software release and deployment architecture |
CN111767092B (zh) * | 2020-06-30 | 2023-05-12 | 深圳前海微众银行股份有限公司 | 作业执行方法、装置、***及计算机可读存储介质 |
CN111949311B (zh) * | 2020-08-12 | 2023-08-25 | 中国工商银行股份有限公司 | 灰度发布方法及*** |
CN112130892A (zh) * | 2020-09-23 | 2020-12-25 | 平安科技(深圳)有限公司 | 产品灰度发布方法、装置、设备及存储介质 |
CN112579289B (zh) * | 2020-12-21 | 2023-06-13 | 中电福富信息科技有限公司 | 一种可智能调度的分布式解析引擎方法及装置 |
US11599837B2 (en) * | 2020-12-30 | 2023-03-07 | Microsoft Technology Licensing, Llc | Method and system for selection of users in feature rollout |
CN112905199A (zh) * | 2021-02-04 | 2021-06-04 | 上海中通吉网络技术有限公司 | 代码更新检测方法及装置 |
CN113918276A (zh) * | 2021-09-17 | 2022-01-11 | 浪潮思科网络科技有限公司 | 一种基于容器的sdn控制器部署方法、设备及介质 |
CN114615135B (zh) * | 2022-02-18 | 2024-03-22 | 佐朋数科(深圳)信息技术有限责任公司 | 一种前端灰度发布方法、***及存储介质 |
-
2022
- 2022-07-29 CN CN202210902898.6A patent/CN114968274B/zh active Active
-
2023
- 2023-07-28 US US18/360,840 patent/US20240036860A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
US20240036860A1 (en) | 2024-02-01 |
CN114968274A (zh) | 2022-08-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11689638B2 (en) | Embedded database as a microservice for distributed container cloud platform | |
CN113918270B (zh) | 基于Kubernetes的云资源调度方法及*** | |
CN108845884B (zh) | 物理资源分配方法、装置、计算机设备和存储介质 | |
US6988139B1 (en) | Distributed computing of a job corresponding to a plurality of predefined tasks | |
US6708324B1 (en) | Extensible automated testing software | |
US7870424B2 (en) | Parallel computer system | |
US8352930B1 (en) | Software modification by group to minimize breakage | |
US6928378B2 (en) | Stress testing at low cost through parallel execution of unit tests | |
CN115048205B (zh) | Etl调度平台及其部署方法、计算机可读存储介质 | |
CN109634825B (zh) | 一种虚拟化平台稳定性测试方法 | |
WO2010044790A1 (en) | Batch processing system | |
CN110895488B (zh) | 任务调度方法及装置 | |
CN109981419A (zh) | 负载均衡特性的测试方法、装置、***、设备及存储介质 | |
CN112862098A (zh) | 一种集群训练任务处理的方法及*** | |
CN109902028A (zh) | Acl特性的自动化测试方法、装置、设备及存储介质 | |
CN114356750A (zh) | 测试方法、装置、计算机设备和存储介质 | |
CN113157411A (zh) | 一种基于Celery的可靠可配置任务***及装置 | |
CN109597764A (zh) | 一种目录配额的测试方法及相关装置 | |
CN114968274B (zh) | 一种基于灰度发布的自动化快速部署前置机的方法及*** | |
CN113608838A (zh) | 应用镜像文件的部署方法、装置、计算机设备和存储介质 | |
CN111399999B (zh) | 计算机资源处理方法、装置、可读存储介质和计算机设备 | |
CN109002263A (zh) | 存储容量的调整方法及装置 | |
CN112527642A (zh) | 性能测试指标数据的显示方法、装置、设备及存储介质 | |
CN113435489B (zh) | 部署***的方法、装置、计算机可读存储介质及处理器 | |
CN116149785A (zh) | Kubernetes Pod就地修改资源的方法及*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |