一种软件服务保障系统及方法与流程

1.本发明涉及一种服务保障系统及方法，尤其是一种软件服务保障系统及方法。


背景技术：

2.在互联网的时代中，随着应用服务越来越多，特别是在商品促销，商品秒杀，核酸报告集中查询，高考成绩查询等业务场景时，如何有效地保证服务在大量用户访问时，系统仍然能够进行有效正确的工作是当前面临的重要问题。每个业务系统都有高峰期和低谷期，所以，当一个业务系统集群规模很大的时候，很多机器资源都是浪费的，如何能够有效的实现机器资源的借调，有效并充分的进行资源利用，进而可以更好的为企业节约成本。服务保障是对软件服务进行资源容量进行管理和划分，目前的服务保障系统功能单一，缺少系统监控、资源预测和容量分配等功能；同时在资源分配时没有考虑到软硬件类型和业务类型，机器过载时没有有效的应用配置策略，导致资源分配不合理，应用服务稳定性差。


技术实现要素：

3.发明目的：本发明的目的是提供一种合理分配资源，保障应用服务稳定性的软件服务保障系统，本发明的第二目的是提供一种软件服务保障方法，以解决上述技术问题。
4.技术方案：本发明所述的软件服务保障系统，包括软硬件信息注册服务单元和软件服务配置服务单元；
5.所述软硬件信息注册服务单元根据服务器硬件的属性、磁盘及内存容量将所述硬件划分其适合处理的软件服务类型，为服务器标记相应的软件服务类别标签；将软件服务及软件服务之间的关系录入图数据库中，根据软件服务特性为软件服务标记相应的软件服务属性标签；所述软件服务特性包括软件服务的访问特性、接口响应时间和历史资源容量风险；
6.所述软件服务配置服务单元将需要进行服务保障的软件服务进行镜像制作，根据硬件的软件服务类别标签和软件服务的软件服务属性标签对待上线管理的软件服务进行部署，上下游业务部署至不同的服务器；
7.所述软件服务配置服务单元实时监控软件服务的访问量，当任意一个软件服务的访问量超过第一阈值，若服务器资源存在空余，则根据硬件的软件服务类别标签和软件服务的软件服务属性标签选择合适的服务器，通过横向扩展的方法将该软件服务部署在该服务器节点中，否则根据软件服务优先级从低到高，选择访问量不超过第二阈值的软件服务进行下线以释放资源，将释放的资源合并至该软件服务，使软件服务稳定运行。
8.进一步地，所述软硬件信息注册服务单元根据cpu核数数量为cpu标记高、中、低标签，根据内存容量大小为内存标记高、中、低标签，根据硬盘类型为硬盘标记高、中、低标签；
9.所述为服务器标记相应的软件服务类别标签包括：为内存标签和硬盘标签均为高的服务器标记io密集型任务标签；为cpu标签为高的服务器标记cpu密集型任务标签；为cpu标签和内存标签均为高的服务器标记缓存服务标签；为cpu标签和内存标签均为中或高、硬
盘标签为高且硬盘容量不低于1t的服务器标记数据库服务标签；为cpu标签、内存标签和硬盘标签均为低且硬盘容量不低于10t的服务器标记文件服务标签。
10.进一步地，所述为软件服务标记相应的软件服务属性标签包括：为关键路径上无法降级的核心软件服务标记核心服务标签，所述核心软件服务根据重要程度划分优先级；为存在接口对响应时间敏感的软件服务标记低延迟软件服务标签；为在历史运行中出现过访问量超过第一阈值的软件服务标记重点检测服务标签。
11.进一步地，所述软件服务配置服务单元中，若下线的软件服务达到所有软件服务数量的50％时，通过开启限流开关、降级开关和熔断开关进行服务保障。
12.进一步地，还包括全链路压测服务单元，所述全链路压测服务单元在访问低峰时，通过模拟用户和模拟数据来模拟访问请求进行链路压力测试，在测试过程中监控性能指标，当待保障的软件服务的响应延迟大于第五阈值时停止测试；
13.进行所述链路压力测试前将所述模拟数据与服务器的真实数据进行数据隔离。
14.进一步地，还包括智能预测资源保障服务单元，所述智能预测资源保障服务单元对每个软件服务训练机器学习模型来预测容量峰值，训练完成后选择某个时间点上所有软件服务每秒处理的事务数为基础，不断增加事务数，直到任意一个软件服务的预测cpu使用率超过第三阈值，对此时的软件服务利用所述全链路压测服务单元进行链路压力测试，若cpu使用率的测试结果与预测结果相比的误差率高于第四阈值，则重新进行模型训练，否则该cpu使用率的预测容量结果为该软件服务的容量峰值。
15.进一步地，还包括指标采集监控服务单元，所述指标采集监控服务单元在每个服务器节点部署agent代理采集器，来采集硬件指标和软件服务指标，监控指标是否在阈值范围内，对超出阈值范围的指标进行集中式告警。
16.本发明所述的软件服务保障方法，包括如下内容：
17.根据服务器硬件的属性、磁盘及内存容量将所述硬件划分其适合处理的软件服务类型，为服务器标记相应的软件服务类别标签；将软件服务及软件服务之间的关系录入图数据库中，根据软件服务特性为软件服务标记相应的软件服务属性标签；所述软件服务特性包括软件服务的访问特性、接口响应时间和历史资源容量风险；
18.将需要进行服务保障的软件服务进行镜像制作，根据硬件的软件服务类别标签和软件服务的软件服务属性标签对待上线管理的软件服务进行部署，上下游业务部署至不同的服务器；
19.实时监控软件服务的访问量，当任意一个软件服务的访问量超过第一阈值，若服务器资源存在空余，则通过横向扩展的方法将该软件服务部署在新的服务器节点中，否则根据软件服务优先级从低到高，选择访问量不超过第二阈值的软件服务进行下线以释放资源，将释放的资源合并至该软件服务，使软件服务稳定运行。
20.本发明所述的电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述计算机程序被加载至处理器时实现所述的软件服务保障方法。
21.本发明所述的计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现所述的软件服务保障方法。
22.有益效果：与现有技术相比，本发明的优点在于：(1)利用输入硬件的基本信息，软件服务所关心的基本特性，对硬件服务器及业务应用服务的标签化，并通过图谱构建起业
务的上下游依赖关系，方便用户清晰查看，在部署的过程中结合之前的软硬件智能组合标签，利用反亲和性及虚拟地址等特性进行智能化部署，合理分配服务器资源；(2)在系统运行的过程中，通过实时监控指标流量，查看其是否出现系统过载，如果出现系统过载，则优先进行容量处理，优先通过横向扩展或者缩减其他资源之后再进行扩展，当无法完成软件服务容量扩展时，可以通过动态的打开开关进行动态控制，通过限流，限制节点上下游流量。或者降级，关闭非核心功能服务，或者熔断，拒绝或者主动断开远端连接请求，直至系统负载恢复之后，再重新进行系统服务，通过上述方式，极大的保证了软件服务的稳定性。
附图说明
23.图1为本发明的软件服务保障系统架构图。
24.图2为本发明的软硬件信息注册服务流程图。
25.图3为本发明的指标采集监控服务流程图。
26.图4为本发明的全链路压测服务流程图。
27.图5为本发明的智能预测资源保障服务流程图。
28.图6为本发明的软件服务配置服务流程图。
具体实施方式
29.下面结合附图对本发明的技术方案作进一步说明。
30.如图1所示，所述软件服务保障系统包括软硬件信息注册服务单元、软件服务配置服务单元、全链路压测服务单元、智能预测资源保障服务单元和指标采集监控服务单元。
31.(1)软硬件信息注册服务单元
32.(1.1)服务器配置服务
33.软硬件信息注册服务单元根据服务器自身的特点，对不同的服务器进行不同的打标签服务，当有新的应用服务需要部署时，登记相应的软件服务所需资源，以及该软件服务所依赖的软件服务，便于后期集中调度和管理。
34.首先录入服务器中的cpu型号，cpu个数，cpu主频，cpu逻辑核数；其次录入内存的容量大小，一般是64gb，128gb，256gb；硬盘的类别，是ssd固态硬盘，还是sas盘，或者是sata盘，录入网卡配置，是千兆网卡，还是万兆网卡。不同的配置，对应的服务器的标签是不同的。对服务器中硬件的信息进行集中划分，分别贴上高、中、低的硬件基本标签。
35.cpu的标签判断标准是：小于等于16核标记为低；大于16核，小于等于64核标记为中；大于64核标记为高。内存的标签判断标准是：小于等于32g标记为低；大于32g，小于等于128g标记为中；大于128g标记为高。硬盘的标签判断标准是：硬盘类别是sata盘，标记为低；硬盘类别是sas盘，标记为中；硬盘类别是ssd，标记为高。
36.会存在有些服务器的配置各方面都非常高，所以可能会被标记多个标签。进行软件服务选择时，优先从只有一个标签的服务器中进行选择，否则从多个标签中随机选择满足要求的服务器。
37.将上述硬件基本标签进行一定的整合之后，根据其处理的任务类型为服务器标记不同的软件服务类别标签。大量文件读写，db读写，网络请求等操作需要频繁的磁盘io，属于io密集型任务，因此将内存标签为高，硬盘标签为高的服务器，标记为适合io密集型任务
的标签；而cpu核数多，并且cpu主频很高的服务器，适合处理计算型的任务，比如对象序列化、位图索引的构建和json字符的解析等，这些任务需要大量的cpu资源，属于cpu密集型任务，因此将cpu标签为高的服务器标记为cpu密集型的标签；针对内存标签高，cpu标签高的服务器，标记为缓存服务的标签；
38.针对cpu核数多(cpu标签为中或者高，内存标签为中或者高)，硬盘标签为高，硬盘容量不低于1t的服务器，标记为数据库服务的标签；而只是硬盘标签为低，并且容量大小不低于10t，cpu标签为低，内存标签为低，标记为文件服务的标签。
39.(1.2)软件服务的登记梳理服务
40.针对一些需要进行服务保障的系统，梳理其当前活动所涉及的所有服务和其依赖的服务，确定其保障的范围，在进行服务登记时，整个数据的存储会依赖于图数据库引擎，首先确定关键路径上面的核心服务，标记为核心服务标签，当前关键路径上面的核心服务指的是无法被降级的服务，将服务与服务之间的关系录入图数据库中，并将上游系统或者下游系统用图数据库中的边进行连接，并标记好方向，确定其上下游关系。其次需要录入该服务是否有明显的峰值特征，这类服务在高峰期和低峰期的流量差异会非常的大，这种流量的差异容易引发服务容量的风险，当该服务被标记为核心服务标签之后，该容量保障系统检测该软件服务的频率会变高。
41.录入存在对接口响应时间敏感的软件服务，标记为低延迟软件服务标签，一些底层服务会被同一请求调用很多次，一旦响应时间上升，那么总的响应时间会被放大很多倍。
42.在已经录入系统的链路服务中，标记历史上某个服务是否出现资源容量问题，或者是当前服务在高峰期运行中已经存在容量风险了，出现过或存在容量风险的软件服务标记为重点检测服务标签。
43.当这些信息都录入到登记梳理服务后，所有相关信息都会汇聚到一张图谱上，通过该图谱，服务与服务之间的依赖连通性，以及软件服务的特性都会一目了然。
44.(2)指标采集监控服务单元
45.指标采集监控服务单元录入需要具体监控的指标，主要包括服务器指标或者是服务性能指标，并制定该指标的监控规则及告警规则，当监控指标出现异常时进行集中式告警。
46.首先录入需要进行采集的指标，其中主要分为两部分，一部分是硬件监控指标，包括cpu使用率、磁盘使用率、内存使用率、磁盘的读写效率等；另一部分是软件服务指标，包括接口响应时间、缓存命中率、数据库索引命中率、每秒的请求数和每秒的处理事务数等。指标采集过程是通过在每个节点上部署agent代理采集器进行集中式采集，该采集器中内置各类采集api接口，如linux操作系统接口，采集器通过该接口获取当前的cpu、内存、网络、磁盘等指标，并通过数据库api接口访问数据库获取当前数据库的访问指标。对于新部署的软件服务需要统一集成监控工具模块来对应用服务监控，获取当前服务的应用状态、线程以及对虚拟机中堆的使用情况等指标信息。将采集的指标信息，直接推送至大数据平台中。
47.在采集的过程中需要尽可能多的采集，不光是业务服务端的服务器需要进行采集，其进行压力测试端的服务器也需要进行采集，因为有时进行性能压力后期测试时，当访问压力上去之后，其服务端的响应时间并没有很明显的增加，有时瓶颈并不是软件服务端，
而是在施压服务器这端，压力测试服务器出现了性能瓶颈，当需要为业务服务提供更多的压力时，其施压服务器本身能提供的压力有限，这样无法测试出其业务服务真实的请求访问数。针对采集完各类指标会进行综合分析，比如并不是cpu使用率越低，代表的当前的服务器负载就很低，有可能瓶颈在磁盘。cpu出现大量的io等待，这时整体的系统负载还是很高的。需要结合cpu、磁盘、内存、网络等多方指标一起进行判定，业务方的指标，如响应时间，指定的规则一般不是以平均值进行判定，而是选择分位线进行判断，主要其平均值会弱化一些耗时较长的请求，导致容量资源问题被隐藏，一般会将所有的请求时间进行排序，然后选取第95％或者99％的最后一个响应时间，作为该响应时间。举例说明，假设目前有1000个请求，其中90％的请求的响应时间是100ms，而10％的请求的响应时间是250ms，其平均响应时间是(900
×
100+100
×
250)/1000＝115ms，而已经10％的响应延迟已经超过200ms，实际上已经有10％的用户已经受到了影响。直接从平均响应时长是看不出问题的。但是响应时间应该在一个合理的阈值之间，才是正常的。如果某个服务的接口响应时间很短，说明该服务可能也是有问题的，可能程序出现了链路调用的异常，触发了降级操作，这样大量的操作是不会走正常逻辑的，而是直接运行处理异常逻辑，这时接口也会快速返回，这时响应时间就会很短。所以对于软件服务的核心接口，其响应时间需要在一个合理的阈值范围内，不能太高或者太低。
48.指标采集监控服务对全部采集指标进行分类排序及归类，将指标出现过高或者过低的服务和服务器列举出来，如果整体服务出现毛刺的现象，相关指标出现了尖锐的抖动，说明某些服务在某些场景下可能性能欠佳。对于指标信息处理方式并不相同，指标分析服务对于偶尔出现的指标异常，会通过调整指标采集规则，比如自动进行增大采集频率，而明显出现的服务异常，比如磁盘无法进行读写，会直接对异常指标进行告警标记，并推送运维人员。再由运维人员判断该服务是否需要进行干预或者进行服务器维修。
49.(3)全链路压测服务单元
50.全链路压测服务单元基于真实环境对软件服务进行全方位的测试，通过执行策略选取，数据隔离，服务建模，服务模拟，压测数据实时采集，对服务资源容量进行测试，保证线上的资源容量可以满足当前业务需要。
51.压测服务是在流量的低峰进行，当软件服务中的每秒请求数和每秒处理的事务数很低的时候，就可以进行全链路压测。一般全链路压测会直接在生产环境中进行，但是使用的用户不是真实存在的用户，而是模拟的用户。
52.(3.1)开关配置
53.在压测之前，需要动态地让软件服务打开或关闭一些开关，由于测试的用户是虚拟用户，不一定是真实存在的，那么真实的验证情况是不会让其通过的，所以需要将其验证开关关闭。打开数据前置隔离开关，有些数据为了防止数据进入大数据平台中，整个基于大数据平台建设的数据仓库，是面向主题，稳定性的，为了减少对大数据集群中数据的修改，需要打开数据前置隔离开关，通过隔离策略让其不进入数据仓库。
54.(3.2)数据隔离
55.由于整个全链路的测试是基于生产环境的，那么需要将模拟数据和正式数据进行隔离，防止模拟数据影响到真实数据。一般针对业务的复杂程度，在服务保障系统中选择不同的方式进行隔离，一般分为逻辑隔离和物理隔离。逻辑隔离，选择数据表中的类型字段，
新增一个模拟类型的信息，然后基于这个模拟信息进行全链路的测试。但是这种方式只能适合比较简单的业务模型，如果业务模型很复杂，不同的业务表需要使用不同类型的字段，表与表之间一般都会多对一，或者多对多的关联关系，一旦关系复杂就会导致模拟数据影响到了真实数据，从而导致数据错乱。第二种方式，采用物理隔离的方式，通过选择数据库中间件，对原先的表或者库进行镜像操作，复制数据之后，再对整体的数据进行偏移，保证源数据和模拟数据相互都不进行干扰。
56.(3.3)流程模拟
57.流程的模拟，主要分为两类，一类是数据模拟，一类是服务模拟。
58.数据模拟是指，通过对真实数据进行映射，按照等比例缩放，选取贴近真实业务场景进行模拟，在服务保障系统中配置模拟的数据比例，一般限制其比例不低于10％，避免数据量过少，可能会导致部分缓存分片或者数据分片过热。其中业务属性及用户属性也需要保持相同比例，比如普通用户和付费用户在真实环境中的比例是1：20，那么进行数据模拟时，也需要按照1：20的比例进行模拟。服务模拟是指，针对一些第三方服务的调用，比如银行交易的确认，不方便发送真实的请求，这时只能对请求识别之后，进行服务模拟，模拟正常的请求返回。
59.在流程访问的过程中，需要借助数据库中间件进行请求拦截与解析，对于发送的读请求，由于本身读取数据并不会对数据库造成影响，所以可以直接将数据查询请求去底层命中其真实数据；而针对写请求，由于会在数据库层面新增数据，所以需要通过数据库中间件将请求发送至镜像表或者镜像库。当完成链路测试之后，需要将数据及时进行清理操作。
60.在进行压测时，实时的监控本身施压的服务保障系统以及待保障的软件服务系统，将采集到的监控指标数据实时推送至消息中间件服务，服务保障系统会实时的消费采集的指标信息，并将信息推送至数据库中。如果在压测的过程中，出现待保障的软件服务系统负载过高，如访问延迟大于200ms的情况，会通过服务保障平台停止压力测试，保证系统的稳定性。
61.(4)智能预测资源保障服务单元
62.动态选取相关监控指标，使用机器学习算法，建立服务的容量负载与服务器本身的监控关系，以便服务保障系统可以更好的进行容量预估，保证业务稳定运行。
63.首先对监控服务器资源指标数据和服务性能数据进行清洗，去除无效数据和噪点数据，让所有的采集数据都规范化，有利于后期的模型训练。其次进行特征选取，从服务资源配置、cpu使用率、磁盘的使用率等和软件服务本身的性能指标如每秒能处理的请求数、响应时间等，找到硬件资源配置和软件服务本身指标的相关性，从而来对未来的流量进行预估操作。
64.使用了机器学习等相关算法来对模型进行训练，其主要算法包含了线性回归算法，逻辑回归算法，及决策树等相关算法。其数据准备过程大致如下：将原始的数据集分成n份，从划分的n份数据集中选择一部分作为测试集，其他的数据集作为训练集，用训练集来训练模型，然后用测试集来验证模型的输出结果，计算模型的准确度。本实施例中n取8～10，整体的预测效果会比较好。由于每个服务的依赖服务是不相同的，所以针对每个服务，都需要单独训练出一个模型，在训练的过程中，会使用皮尔逊相关系数，来判断指标与指标
之间的相关性，在分析的过程中，只考虑强相关和弱相关的因子，不考虑不相关的因子。处理弱相关的因子时，可以考虑使用过滤法，去掉取值变化小或者不变的特征，因为该特征对实际的取值影响很小，并对强相关因子进行排列组合，逐步找到最优组合。
65.通过上述方法，通过模型训练，可以得到软件服务的每秒能够处理的事务数和服务器的cpu使用率是强相关，在特征训练的过程中，并不是选取的特征越多越好，这样容易出现过拟合的现象，应选取尽可能少的特征，具有代表性即可。
66.有时cpu使用率和每秒处理的事务数并不能有效的进行拟合。这时，可以使用两种方式来进行解决，一种是使用降维工作将所依赖的服务合并成一个服务，不然特征过多的话，模型不容易收敛。第二种方式建立概率表，通过某个cpu使用率所对应的每秒处理事务数所出现的频率，出现频率最高的数据往往是准确的，能代表实际的情况，那么就选择出现频次高的数据进行训练。
67.在实际的使用过程中，需要结合全链路压测服务才能更好的对服务进行预测。首先，针对日常数据选择每秒处理事务数和cpu使用率进行模型训练。模型训练完成之后，选择日常软件服务某个时间点的数据，选取这个时间点上所有的服务每秒处理的事务数，然后利用之前已经训练出的模型，不断的增加每个服务的每秒能处理的事务数的数据量，注意在增加每秒处理的事务数时不能一次性增加太多，这样会造成所有的服务到达了容器的瓶颈，可以一开始通过随机值，然后用二分的方法不断用上一次的结果更新随机值，做到快速收敛的效果，从而得到各自的cpu使用率，直到某个关键服务的cpu使用率已经超过了85％，表明已经超过了系统能够承载最大的容量，这时，对服务列表进行排序生成一个列表。然后使用全链路压测服务进行压力测试，实时收集每个服务的每秒能处理的事务数和当前服务器的cpu的使用率，之后比较当全链路施压达到相同下每秒处理的事务数下的cpu的使用率和之前模型的预测的是否存在差异，如果cpu使用率的预测值和测试值误差率低于5％，说明资源预测保障较准确，否则说明全链路场景下有失真，这时需要将压测时数据输入给模型进行持续性学习，不断通过全链路压测的数据来对调整模型，检验模型的准确性，达到相互促进的效果。误差率＝(预测值-测试值)/测试值。
68.(5)软件服务配置服务单元
69.通过对软件服务进行配置集中抽离，并实施存算分离，让其实现动态扩缩容的特性，可以更好的使用服务保障系统进行横向扩展，做到软件服务的自身高可用。
70.针对需要进行服务保障的软件服务，需要先进行配置抽离，将核心的配置文件存放到指定的分布式文件系统中，并将服务进行容器化，当容器启动的时候，可以直接从分布式文件系统中进行加载，简化启动步骤，其中接口保障的开关都保留在配置文件中。对于一些计算类的软件服务或引擎能够做到存算分离，当计算资源不够时，可以快速的部署计算资源，当需要加快存储访问时，可以通过添加固态硬盘的方式来对存储访问进行提速。
71.在进行软件服务配置时，需要能做到对上下游依赖负责，上游服务需要对下游服务进行负责，先确定录入其上下游服务的调用量和被调用量，利用软件服务类别标签和软件服务属性标签，将软件服务和及其依赖的软件服务进行部署，服务部署会动态的选择之前标记好的服务器进行动态部署，并利用反亲和性，保证其相关核心服务不部署到一台服务器上面，以免出现软件服务之间的相互影响。
72.在软件服务运行过程中，通过虚拟ip技术，用户直接访问虚拟ip，其后台可能对应
的是1～n个集群，不同的软件服务可以交叉访问并隔离。当指标采集监控服务单元通过实时采集性能指标信息，发现其流量呈上升的趋势，当达到刚开始配置的每秒的访问量的80％时，服务保障系统会判断整个服务器的资源是否有空余，如果有空余则结合软件服务类别标签和软件服务属性标签，选择合适的服务器进行扩容部署，将软件服务部署在新的节点中，从而降低每个服务器节点的负载。如果没有空余，则按照软件服务重要程度从低到高进行排序，依次判断是否有软件服务只达到了预分配资源的30％以下，如果存在这样的软件服务，说明当前这个软件服务负载很低，可以合并一些服务器，动态下线删除其中的空闲软件服务，释放一部分资源，然后再让资源不足的服务器进行扩容。直到判断下线的软件服务服务的数量超过整个集群软件服务数量的50％，再采用限流、降级和熔断的方法进行资源配置，方法为：
73.动态修改上游软件服务的配置文件，打开限流开关，上游服务读取到动态配置文件之后并进行请求限流，通过拒绝一部分服务流量强行控制服务负载。为了保证整个链路的健壮性，当下游服务请求次数超过预先设置的请求容量阈值的80％时，会优先进行容量扩展，也会动态的打开限流开关，进行防御性保障。整个服务保障系统会全程的对业务链路进行监控，如果发现打开限流开关的下游，其承载的流量还是持续性的增长，会优先打开下游的动态降级开关，下游服务收到降级指令之后，会将不重要的功能停掉，以此释放的这部分资源去支撑核心功能应用，其中降级策略一般进行逐级降级，一般第一层降级是不会影响用户使用的，比如降低一些个性化推荐或者开始不记录审查日志，但是第二层降级会影响到具体用户使用，比如不做强一致性的校验，查询具体订单只能查询最近7天的。如果打开降级开关之后，也不能降低下游服务的服务器负载，下游处理每个请求的时间延迟依然变大，当响应延迟超过正常延迟的50％时，会触发打开熔断开关，比如一般要求响应延迟为200ms，那么当响应延迟超过300ms的时候，会触发打开熔断开关，拒绝部分新的访问请求，降低对下游的请求访问，保证原先请求能够正确的处理完成，当请求负载下降之后，再将其熔断开关关闭，之后再逐步关闭其他开关，逐步恢复正常访问。
74.基于同样的发明构思，本发明所述的软件服务保障方法具体包括如下步骤：
75.1)如图2所示，软硬件信息注册服务流程为：
76.1.1)准备录入基本信息。
77.1.2)判断需要录入的信息是硬件服务信息还是软件服务信息，不同服务信息对应的录入信息不同。
78.1.3)如果录入的是硬件服务信息，需要录入硬件的基本属性，比如cpu，内存，磁盘，网络等基本参数。根据cpu核数、内存容量和硬盘类型为服务器标记硬件基本标签，然后结合硬件基本标签为服务器标记软件服务类别标签。
79.1.4)如果录入的是软件服务信息，需要录入服务的上下游关系，并输入其依赖的基础组件，比如依赖数据库服务，大数据组件等，还需要录入软件服务是否有对响应时间敏感，或者历史上出现过线上故障等，对软件服务标记软件服务属性标签。
80.1.5)完成上述标记之后，将软硬件基本信息录入至图数据库中，并在图数据库中构建服务图谱，方便后期用户通过图谱观察整个服务的上下游信息，以及当出现问题时，进行问题跟踪。
81.2)如图3所示，指标采集监控服务流程为：
82.2.1)录入采集指标及其计算方式。
83.2.2)根据需要采集的指标及其指标的计算方式来对软件服务器和施压服务器进行采集，采集的指标主要分为硬件监控指标和软件服务指标。
84.2.3)将采集完成的数据统一入库于大数据平台中。
85.2.4)完成数据采集之后，由指标采集分析平台制定指标分析规则。比如结合服务器的多项指标进行综合分析判断，而不是所有业务指标都取平均值作为判断。
86.2.5)将指标分类排序分析之后，针对不同的指标数值进行不同的处理方式，不是严重的异常信息，或者其服务不是核心关键服务，可以调整采集规则，提高采集指标范围或者频率，而针对相对严重的指标数据将其告警直接推送至运维人员，运维人员收到告警信息后，直接进行人工干预。
87.3)如图4所示，全链路压测服务为：
88.3.1)在软件服务层面设置一些开关，如关闭验证开关，打开数据前置隔离开关。
89.3.2)选定合适的数据隔离策略，针对简单的业务模型使用逻辑类型隔离，但是针对复杂的业务模型，如相关数据表之间的勾稽关系很复杂，一般选取物理镜像隔离，可以使用镜像表或者是镜像库。
90.3.3)进行软件服务流程模拟，数据模拟的过程中，需要按照不同业务属性的数据进行等比例缩放，不然会造成业务场景测试不全面的情况，对于一些需要第三方服务配合的调用，这时需要进行服务模拟，模拟第三方服务调用成功或者失败，并观察其软件服务能够正常运行。
91.3.4)在整个全链路压测的过程中，需要实时进行服务器性能指标的采集及软件服务指标的采集，并将数据由消息中间件进行缓冲，最终推送至数据库中，运维人员针对入库的指标数据进行分析，判断整个核心链路的访问瓶颈。
92.3.5)由于整个全链路压测一般是在生产环境中进行，虽然选择在业务的低峰操作，但是如果在测试的过程中出现了，系统负载指标超过了预设的阈值，就需要进行人工干预，停止压测，并做好数据清理工作。
93.4)如图5所示，智能预测资源保障服务流程为：
94.4.1)对采集的服务器性能数据，软件服务性能数据进行数据清洗，去除无效数据，通过概率表选择出现频次最高的数据。
95.4.2)通过对指标进行选取，对指标数据进行排列组合，按照服务进行模型训练。
96.4.3)在模型训练的过程中，可以通过特征排列，或者数据分块训练，取出相关性系数很低的指标，并针对数据指标选取过多的问题，进行数据降维等操作。
97.4.4)完成模型训练，建立模型，选择日常数据的负载数据，预测其服务在高峰时的负载。
98.4.5)对预测的服务链路进行全链路压测，并结合之前的服务在高峰期时的负载，判断其数据的有效性。
99.4.6)如果两者数据差异较小，说明模型吻合，如果数据差异很大，出现失真，需要将全链路压测的数据也一并输入到模型中进行训练，持续优化模型，达到校准的目的。
100.5)如图6所示，软件服务配置服务流程为：
101.5.1)对需要进行服务保障的软件服务进行镜像制作，将其服务的核心配置进行抽
离，并将其服务进行容器化，做到存算分离。
102.5.2)配置软件服务的上游及下游的依赖关系，确定服务与服务之间的调用链。
103.5.3)针对待上线管理的软件服务进行智能化部署，根据之前的服务器的软件服务类别标签和软件服务属性标签，动态选择最适合的服务器进行部署，并根据服务器的反亲和性，不会在同一台服务器上部署上下游服务，利用虚拟ip技术，对业务应用服务进行多副本部署，达到负载均衡。
104.5.4)在应用服务运行的过程中，进行服务器及软件服务指标监控，判断其服务是否存在过载的现象，如果没有出现服务过载的现象，则继续进行指标监控。
105.5.5)如果出现了软件服务过载的情况，优先进行容量处理，一般采用的是扩容来进行处理，当整个集群比较空闲时，采用的是横向扩容的方式进行动态降低软件服务负载，而如果整个集群都没有过多的资源进行扩展时，会将整个集群中的应用服务的重要程度按照倒序进行排序，并依次判断该低重要性服务的负载是否小于30％，如果小于30％，那么会释放当前的业务资源用于扩容，如果扩容成功则继续进行指标监控，如果扩容失败，则从列表中选择第二台服务器进行判断，当选择应用服务判断的个数超过整个集群中应用服务个数50％以上时，仍无法降低整体集群的负载，则停止判断，扩容失败。如果扩容成功，则继续进行指标监控。
106.5.6)如果扩容失败，则需要通过开关来进行服务保障，优先通过当前服务以及上游服务的流量，将请求降低，如果负载仍然很高，则暂时关闭一些非核心业务，进行降级操作，以此保证核心业务的操作。如果访问延迟高于规定延迟的50％或者核心服务已宕机，则采用打开熔断开关的方式，停止外部对核心服务继续访问。
107.5.7)待服务恢复后，再逐步关闭开关。
108.基于同样的发明构思，所述的电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述计算机程序被加载至处理器时实现所述的软件服务保障方法。
109.基于同样的发明构思，所述的计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现所述的软件服务保障方法。
110.所述计算机可读存储媒体可包括ram、rom、eeprom、cd-rom或其它光盘存储装置、磁盘存储装置或其它磁性存储装置、快闪存储器或可用来存储指令或数据结构的形式的所要程序代码并且可由计算机存取的任何其它媒体。
111.处理器用于执行存储器存储的计算机程序，以实现上述实施例涉及的方法中的各个步骤。