一种微服务环境下基于业务预测动态扩容的方法与流程

1.本发明涉及一种微服务扩容领域，尤其涉及一种微服务环境下基于业务预测动态扩容的方法。


背景技术：

2.现有的微服务容器化部署，对微服务扩缩容是通过设置容器所使用硬件的一些硬件指标的阀值，例如设置cpu的使用率大于80％，内存的使用率大于80％等，当超过阀值的时候，系统就会增加部署微服务容器的数量来自动扩容，新增加一个或者几个容器来提供服务。
3.这种方式的主要问题包括：1)新增加的容器何时能够提供服务完全依赖于容器中微服务启动的时间长短，如果微服务启动时间比较长，则做业务处理的前端用户就会较长时间处于卡顿状态，影响用户体验，甚至影响核心业务的开展。而企业应用系统的一些微服务，设计的颗粒度比较大，还要做一些基础数据的加载预加载，因而启动的时间比较长，实时根据硬件指标的阀值进行扩容影响用户体验。
4.2)系统扩容的过程中会使用cpu，存储等硬件资源，如果根据硬件资源来做实时扩容，有可能因为硬件资源的问题导致扩容失败，不能事先进行资源的统筹分配。
5.3)存在性能的不稳定的毛刺现场。企业用户在使用的时候服务的压力短时间内(例如10s)达到一个峰值，但是这个峰值因为持续的时间短，达不到硬件扩容的要求，因此在这段时间内的性能就会存在不稳定的现象。
6.例如，一种在中国专利文献上公开的“业务服务扩缩容方法、装置、介质和电子设备”，其公告号cn112822298b，方法包括：接收业务请求，将业务请求转发至对应的业务服务；获取业务请求携带的指定接口标识信息以及预设关联关系，关系包括不同的业务服务的业务标识与每个业务服务的接口标识信息之间的映射关系；基于指定接口标识信息和预设关联关系，确定业务请求对应的目标业务标识；将目标业务标识添加入业务请求，将业务请求推送入消息队列；从消息队列获取多个业务请求，基于预设业务指标计算多个业务请求的业务指标参数；在业务指标参数满足预设扩缩容条件时，对目标业务标识指示的业务服务进行扩缩容。
7.该方案微服务通过设置一些硬件指标的阀值，实时扩缩容，由于微服务启动时间长，影响在高峰期用户的使用的体验，硬件使用效率低。


技术实现要素：

8.本发明主要解决现有技术微服务启动时间长，影响在高峰期用户的使用的体验的问题；提供一种微服务环境下基于业务预测动态扩容的方法，通过对业务系统的业务日志数据进行采集，动态分析出某类业务处理的高峰低谷时间段，在高峰期到来之前预先分配业务对应微服务需要的资源，自动调整好业务微服务下对应容器的数量，提供给更好的用
户体验与硬件使用效率。
9.本发明的上述技术问题主要是通过下述技术方案得以解决的：一种微服务环境下基于业务预测动态扩容的方法，包括以下步骤：s1：将一个或多个微服务的业务数据通过指定的日志格式写入日志库；业务预测动态扩缩容引擎将每个微服务对应的容器运行数据写入到日志库；s2：业务预测动态扩缩容引擎根据日志库中的日志计算指标，生成业务统计数据；s3：根据历史同期的微服务容器数，结合日志库的业务统计数据与容器的运行数据，定时计算当天的微服务扩缩容；s4：将一天均分为若干个周期，根据实时获取的业务数据日志和容器运行运输，实时计算下一周期的微服务扩缩容。
10.本方案根据集团企业用户处理业务存在高峰低谷这一客观事实，通过对业务系统的业务日志数据进行采集，就可以动态的分析出某类业务处理的高峰低谷时间段，在高峰期到来之前预先分配业务对应微服务所需要的资源，自动调整好业务微服务对应容器的数量，容器预先分配，因此即使容器中的微服务启动时间长，在业务高峰期到来之前也已经启动完成，不会影响在高峰期用户的使用的体验。由于是在业务高峰期没有来到的时候就进行扩容了，对于扩容需要的硬件资源可以统筹的安排，如果资源不够的情况可以有足够的时间可以硬件资源的扩容。在业务的高峰没有来到的时候进行扩容，扩容的机制算法是按照满足最高性能的要求来进行扩容的，因此对业务高峰期已经有了充分的预估，并已经进行了扩容了，因此不会出现性能毛刺现象。
11.作为优选，所述的指定的日志格式为【记录主键，功能url，调用功能的用户，请求id，微服务名称，记录日志的时间，响应的时间】。系统功能对应的一个或者多个微服务将指定的日志格式写入到日志系统；方便后续查询统计计算。
12.作为优选，所述的容器运行数据的日志格式为【记录主键，记录日志的时间，微服务名称，cup的使用率，内存使用率】。业务预测动态扩缩容引擎按每秒的频率查询微服务容器内部的监控代理服务，将每个微服务对应的容器的资源使用情况，主要是cpu使用率，内存的使用率，写入到日志系统。方便后续查询计算。
13.作为优选，所述的指标包括每分钟的系统功能请求数；每分钟内系统功能响应时间的平均数、最大值、最小值和中值，以及大于平均数的记录数、大于阈值的记录数；每分钟微服务容器的cpu使用情况的平均值、最大值、最小值、以及大于平均数的记录数、大于阈值的记录数。业务预测动态扩缩容引擎每天定时与相对实时相结合的方式计算日志系统中的数据，计算出要扩缩容的计划，内容是指定微服务的容器的数量。
14.作为优选，所述的步骤s3包括以下步骤：s301：每天0点读取微服务列表，循环所有微服务；s302：读取微服务对应的上个月同天的微服务容器数量，计算当前微服务容器数据与上个月同天的微服务容器数量的差值ε；ε＝c
n-c若差值ε≥0，直接进入步骤s4；若差值ε＜0，进入步骤s303；
其中，cn为微服务当前的容器数量；c为微服务在上个月同天的容器数量；c
′s为定时计算的最终微服务容器数量；为向上取整运算；s303：读取微服务在日志库中的业务统计数据与容器的运行数据；s304：根据微服务的响应时间以及容器运行数据与上个月同天比较，若超过阈值，则按扩容规则进行扩容。
15.定时计算，根据历史数据计算当天是否是高峰时期，进行微服务容器的扩缩容计算。
16.作为优选，根据微服务的响应时间进行扩容；微服务在上个月同天的容器数量下，判断微服务中服务响应时间的中值是否有超过规定响应时间阈值的130％，如有则需要扩容，否则不需要扩容；该扩容规则为：其中，c
′z为定时根据微服务的响应时间进行扩容后的容器数量；c为微服务在上个月同天的容器数量；zm为微服务中服务响应时间的中值；z为微服务中服务响应时间的阈值；为向上取整运算；根据微服务的容器运行数据进行扩容；微服务在上个月同天的容器数量下，判断微服务容器的cpu使用率超过指定的阈值的持续时间占整个cpu服务时间的比例，若占比超过额定比例，则进行扩容，否则不进行扩容；该扩容规则为：其中，c
′
t
为定时根据微服务的容器运行数据进行扩容后的容器数量；c为微服务在上个月同天的容器数量；tm为微服务容器的cpu使用率超过指定的阈值的持续时间；t为整个cpu服务时间；为向上取整运算；定时计算的最终微服务容器数量为：c
′s＝max(c
′z，c
′
t
)其中，c
′s为定时计算的最终微服务容器数量。
17.根据同期历史数据计算定量计算微服务的扩缩容。
18.作为优选，以每个小时为一个周期，所述的步骤s4具体包括以下步骤：s401：每个小时读取微服务列表，循环计算所有的微服务；s402：读取前一个小时的历史数据；s403：根据实时获取微服务的响应时间、请求总数和容器的使用率与上一周期比较，若超过阈值，则按扩容规则进行扩容。
19.实时进行微服务扩缩容预测计算，提高预测精度。erp等管理系统的数据处理均是有连续性的，前一个小时的业务会对下一个小时的业务处理产生直接影响，当天每小时均会对前一小时的历史数据进行计算，汇总分析业务日志数据与容器内的cpu，内存使用率等数据，通过计算来决定下一个小时容器的数量。
20.作为优选，所述的历史数据为本微服务的前一个小时的历史数据或相关上下游业务的微服务的前一个小时的历史数据。由于企业用户的业务使用过程中，相关上游的一个微服务的请求数增加，也会导致后续下游业务的微服务的请求数的增加。
21.作为优选，根据微服务的响应时间进行扩容；判断当前微服务中服务响应时间的中值是否有超过上一周期微服务中服务响应时间的中值的130％，如有则需要扩容，否则不需要扩容；该扩容规则为：其中，c
′
zh
为实时根据微服务的响应时间进行扩容后的容器数量；ch为微服务在上一周期的容器数量；zm为微服务中服务响应时间的中值；zh为上一周期微服务中服务响应时间的中值；为向上取整运算；根据微服务的请求总数进行扩容；判断每分钟微服务的请求总数是否有超过上一周期的微服务的请求总数的130％，如有，则需要扩容；否则不需要扩容；该扩容规则为：其中，c
′q为根据微服务的请求总数进行扩容后的容器数量；c为微服务在上一周期的容器数量；qm为每分钟微服务的请求总数；q为上一周期的微服务的请求总数；为向上取整运算。
22.根据实时获取微服务的响应时间和请求总数定量预测微服务容器数量。
23.作为优选，根据微服务的容器的使用率进行扩容；将上一周期以及当前周期的微服务中容器中cup使用率拟合成曲线，以时间为x轴，以cpu使用率为y轴；构建比较框，以一分钟的时间段为宽度分别构建左右边框，以该时间段内的最大值为上边框，以该时间段内的最小值为下边框；判断当前周期与上一周期的同一时间段内，曲线与下边框之间面积的面积比；其中，p
si
为一个周期内第i个时间段面积比；s
ni
为当前周期第i个时间段曲线与下边框之间的面积；s
li
为上一周期第i个时间段曲线与下边框之间的面积；
判断p
si
大于等于130％的数量是否大于20个；若是，则需要扩容；否则不需要扩容；该扩容规则为：其中，c
′u为根据微服务的容器的使用率进行扩容后的容器数量；c为微服务在上一周期的容器数量；n
p
为p
si
大于等于130％的数量；α为比例系数；为向上取整运算；其中，k为当前周期的时间段总数；实时计算的最终微服务容器数量为：c
′r＝max(c
′
zh
，c
′q，c
′u)其中，c
′r为实时计算的最终微服务容器数量。
24.定量实时预测微服务容量。
25.本发明的有益效果是：1.结合业务统计数据进行预扩容，在业务高峰期还没有来到之前就已经做好扩容工作，提供更好的使用用户的系统操作体验。
26.2.基于业务数据统计分析与硬件相给合的扩容模式，更加的高效，同时提高硬件的使用率。
27.3.通过定时与实时两种方式动态的对微服务部署容器的扩缩容预测，使得预测结果更加精准。
附图说明
28.图1是本发明的业务预测动态扩容的方法流程图。
具体实施方式
29.下面通过实施例，并结合附图，对本发明的技术方案作进一步具体的说明。
30.实施例：本实施例的一种微服务环境下基于业务预测动态扩容的方法，如图1所示，包括以下步骤：s1：将一个或多个微服务的业务数据通过指定的日志格式写入日志库。
31.指定的日志格式为【记录主键，功能url，调用功能的用户，请求id，微服务名称，记录日志的时间，响应的时间】。
32.业务预测动态扩缩容引擎将每个微服务对应的容器运行数据写入到日志库。
33.业务预测动态扩缩容引擎按每秒的频率查询微服务容器内部的监控代理服务，将每个微服务对应的容器的资源使用情况，主要是cpu使用率，内存的使用率，写入到日志系统。容器运行数据的日志格式为【记录主键，记录日志的时间，微服务名称，cup的使用率，内存使用率】。
34.s2：业务预测动态扩缩容引擎根据日志库中的日志计算指标，生成业务统计数据。
35.业务预测动态扩缩容引擎每天定时与相对实时相结合的方式计算日志系统中的数据，计算出要扩缩容的计划，内容是指定微服务的容器的数量。业务预测动态扩缩容引擎是整个系统的核心，它的主要作用主要有两个：a)根据日志计算一些指标，生成统计数据的快照。
36.b)根据指标与算法获得每个微服务进行扩缩容的计划，并且在指定时间点执行这些计划，调用创建容器的命令来进行微服务扩缩容。
37.指标包括：每分钟的系统功能请求数；每分钟内系统功能响应时间的平均数、最大值、最小值和中值，以及大于平均数的记录数、大于阈值的记录数；每分钟微服务容器的cpu使用情况的平均值、最大值、最小值、以及大于平均数的记录数、大于阈值的记录数。
38.s3：根据历史同期的微服务容器数，结合日志库的业务统计数据与容器的运行数据，定时计算当天的微服务扩缩容。
39.s301：每天0点读取微服务列表，循环所有微服务。
40.s302：读取微服务对应的上个月同天的微服务容器数量，计算当前微服务容器数据与上个月同天的微服务容器数量的差值ε；ε＝c
n-c若差值ε≥0，直接进入步骤s4；若差值ε＜0，进入步骤s303；其中，cn为微服务当前的容器数量；c为微服务在上个月同天的容器数量；c
′s为定时计算的最终微服务容器数量；为向上取整运算。
41.s303：读取微服务在日志库中的业务统计数据与容器的运行数据。
42.s304：根据微服务的响应时间以及容器运行数据与上个月同天比较，若超过阈值，则按扩容规则进行扩容。
43.根据微服务的响应时间进行扩容：微服务在上个月同天的容器数量下，判断微服务中服务响应时间的中值是否有超过规定响应时间阈值的130％，如有则需要扩容，否则不需要扩容。
44.该扩容规则为：其中，c
′z为定时根据微服务的响应时间进行扩容后的容器数量；c为微服务在上个月同天的容器数量；zm为微服务中服务响应时间的中值；z为微服务中服务响应时间的阈值；
为向上取整运算。
45.例如当前微服务部署容器的个数是3，响应中值总数高于规定阈值的30％，则增加的容器数量是3+3*30％＝3.9，向上取整后就是4个，微服务的这容器数量就会当前的3个容器扩充到4个容器。
46.根据微服务的容器运行数据进行扩容：微服务在上个月同天的容器数量下，判断微服务容器的cpu使用率超过指定的阈值(cpu使用率60％)的持续时间占整个cpu服务时间的比例，若占比超过额定比例，则进行扩容，否则不进行扩容。
47.该扩容规则为：其中，c
′
t
为定时根据微服务的容器运行数据进行扩容后的容器数量；c为微服务在上个月同天的容器数量；tm为微服务容器的cpu使用率超过指定的阈值的持续时间；t为整个cpu服务时间；为向上取整运算。
48.定时计算的最终微服务容器数量为：c
′s＝max(c
′z，c
′
t
)其中，c
′s为定时计算的最终微服务容器数量。
49.定量的定时计算，根据历史数据预测计算当天是否是高峰时期，进行微服务容器的扩缩容计算。在到达高峰期前进行微服务扩缩容。
50.s4：将一天均分为若干个周期，根据实时获取的业务数据日志和容器运行运输，实时计算下一周期的微服务扩缩容。
51.在本实施例中，以每个小时为一个周期。erp等管理系统的数据处理均是有连续性的，前一个小时的业务会对下一个小时的业务处理产生直接影响，当天每小时均会对前一小时的历史数据进行计算，汇总分析业务日志数据与容器内的cpu，内存使用率等数据，通过计算来决定下一个小时容器的数量。
52.s401：每个小时读取微服务列表，循环计算所有的微服务。
53.s402：读取前一个小时的历史数据。
54.读取一个小时前的历史数据，在本实施例中，历史数据是本微服务的前一个小时的数据，或是相关的微服务的数据，由于企业用户的业务使用过程中，相关上游的一个微服务的请求数增加，也会导致后续下游业务的微服务的请求数的增加，所以能够读取相关的业务日志数据来预判。
55.s403：根据实时获取微服务的响应时间、请求总数和容器的使用率与上一周期比较，若超过阈值，则按扩容规则进行扩容。
56.根据微服务的响应时间进行扩容：判断当前微服务中服务响应时间的中值是否有超过上一周期微服务中服务响应时间的中值的130％，如有则需要扩容，否则不需要扩容。
57.该扩容规则为：
其中，c
′
zh
为实时根据微服务的响应时间进行扩容后的容器数量；ch为微服务在上一周期的容器数量；zm为微服务中服务响应时间的中值；zh为上一周期微服务中服务响应时间的中值；为向上取整运算。
58.根据微服务的请求总数进行扩容：判断每分钟微服务的请求总数是否有超过上一周期的微服务的请求总数的130％，如有，则需要扩容；否则不需要扩容。
59.该扩容规则为：其中，c
′q为根据微服务的请求总数进行扩容后的容器数量；c为微服务在上一周期的容器数量；qm为每分钟微服务的请求总数；q为上一周期的微服务的请求总数；为向上取整运算。
60.微服务容器增加的数量，是通过当前容器的数量乘以扩容规则中历史同期请求总数的比例，计算结果向上取整。例如当前微服务部署容器的个数是3，请求总数大于历史同期数据的30％，则增加的容器数量是3+3*30％＝3.9，向上取整后就是4个，微服务的这容器数量就会当前的3个容器扩充到4个容器。
61.根据微服务的容器的使用率进行扩容：将上一周期以及当前周期的微服务中容器中cup使用率拟合成曲线，以时间为x轴，以cpu使用率为y轴。
62.构建比较框，以一分钟的时间段为宽度分别构建左右边框，以该时间段内的最大值为上边框，以该时间段内的最小值为下边框。
63.判断当前周期与上一周期的同一时间段内，曲线与下边框之间面积的面积比：其中，p
si
为一个周期内第i个时间段面积比；s
ni
为当前周期第i个时间段曲线与下边框之间的面积；s
li
为上一周期第i个时间段曲线与下边框之间的面积。
64.判断p
si
大于等于130％的数量是否大于20个；若是，则需要扩容；否则不需要扩容；该扩容规则为：其中，c
′u为根据微服务的容器的使用率进行扩容后的容器数量；
c为微服务在上一周期的容器数量；n
p
为p
si
大于等于130％的数量；α为比例系数；为向上取整运算；其中，k为当前周期的时间段总数；实时计算的最终微服务容器数量为：c
′r＝max(c
′
zh
，c
′q，c
′u)其中，c
′r为实时计算的最终微服务容器数量。
65.通过定量的实时计算，预测下一个小时的微服务容器数量，在下一周期高峰到来前进行容器数量的调整。
66.s5：在指定的时间节点进行微服务对应容器的扩缩容操作。
67.本方案根据集团企业用户处理业务存在高峰低谷这一客观事实，通过对业务系统的业务日志数据进行采集，就可以动态的分析出某类业务处理的高峰低谷时间段，在高峰期到来之前预先分配业务对应微服务所需要的资源，自动调整好业务微服务对应容器的数量，容器预先分配，因此即使容器中的微服务启动时间长，在业务高峰期到来之前也已经启动完成，不会影响在高峰期用户的使用的体验。
68.由于是在业务高峰期没有来到的时候就进行扩容了，对于扩容需要的硬件资源可以统筹的安排，如果资源不够的情况可以有足够的时间可以硬件资源的扩容。
69.在业务的高峰没有来到的时候进行扩容，扩容的机制算法是按照满足最高性能的要求来进行扩容的，因此对业务高峰期已经有了充分的预估，并已经进行了扩容了，因此不会出现性能毛刺现象。
70.应理解，实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本技术所附权利要求书所限定的范围。