节点处理方法及系统、节点、介质、计算设备与流程

本公开的实施方式涉及信息处理领域，更具体地，本公开的实施方式涉及一种节点处理方法及系统、节点、介质、计算设备。

背景技术：

本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

对于服务端来说，发布一般分为热部署和冷部署。对于冷部署来说，虽然重启进程可以较为彻底地清理上一个进程的资源，但是因为种种原因使得进程刚启动时会存在一些性能问题，导致部分请求处理失败或响应时间过长，影响用户体验，因此，通常采用预热来解决进程刚启动时性能较差的问题。然而，相关技术的预热处理中通常会出现为系统带来额外负担、数据污染以及存储资源开销较大等问题。

技术实现要素：

本公开期望提供一种节点处理方法及系统、节点、介质、计算设备，以至少解决上述技术问题。

本公开实施例的第一方面提供一种节点处理方法，所述方法包括：

在第一节点处于n个预热阶段中的第i个预热阶段的情况下，所述第一节点接收第二节点发来的健康询问请求；其中，n为大于等于2的整数，i为大于等于1且小于等于n的整数；所述第二节点为所述第一节点的上游节点中之一；

在所述第i个预热阶段对应的候选上游节点集合中包含所述第二节点的情况下，所述第一节点向所述第二节点发送第一类状态码；其中，所述第一类状态码用于指示所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于所述第一节点的上游节点的数量。

在本公开的一个实施例中，所述方法还包括：

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，所述第一节点向所述第二节点发送第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态。

在本公开的一个实施例中，所述在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，所述第一节点向所述第二节点发送第二类状态码，包括：

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若所述第一节点满足第一预设条件，则所述第一节点将所述第二节点的地址相关信息添加至第一集合，向所述第二节点反馈所述第二类状态码。

在本公开的一个实施例中，所述第一预设条件，包括：

开启了根据上游数量的百分比进行预热、关闭了根据上游节点的访问量排序确定允许通过的上游节点以及当前预热已用时长小于进行上游流量统计的等待时长；

或者，开启了根据上游数量的百分比进行预热、第二集合为空以及当前预热已用时长小于进行上游流量统计的等待时长；其中，所述第二集合为所述第一节点读取的按照预设访问量顺序排序的所述第一节点的上游节点集合

在本公开的一个实施例中，所述方法还包括：

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于所述第二节点的地址相关信息更新所述第i个预热阶段对应的候选上游节点集合得到所述第i个预热阶段对应的更新后的候选上游节点集合，向所述第二节点反馈第一类状态码。

在本公开的一个实施例中，所述方法还包括：

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若开启了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于第二集合中的至少一个上游节点更新所述第i个预热阶段对应的候选上游节点集合，得到所述第i个预热阶段对应的更新后的候选上游节点集合；

其中，所述第二集合为所述第一节点读取的按照预设访问量顺序排序的所述第一节点的上游节点集合。

在本公开的一个实施例中，所述方法还包括以下之一：

在所述第i个预热阶段对应的更新后的候选上游节点集合包含所述第二节点的情况下，所述第一节点向所述第二节点反馈第一类状态码；

在所述第i个预热阶段对应的更新后的候选上游节点集合不包含所述第二节点的情况下，所述第一节点向所述第二节点反馈第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态。

在本公开的一个实施例中，所述方法还包括：

在所述第一节点基于当前预热已用时长确定进入所述n个预热阶段的所述第i个预热阶段的情况下，所述第一节点基于预热策略确定所述第i个预热阶段对应的候选上游节点集合；

其中，所述预热策略中包含所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息。

在本公开的一个实施例中，所述第一节点基于预热策略确定所述第i个预热阶段对应的候选上游节点集合，包括：

所述第一节点基于所述预热策略中的所述第i个预热阶段对应的候选上游节点的数量相关信息，确定所述第i个预热阶段对应的候选上游节点的待添加数量；

所述第一节点基于所述候选上游节点的待添加数量确定所述第i个预热阶段对应的候选上游节点；

所述第一节点基于所述第i个预热阶段对应的候选上游节点，确定所述第i个预热阶段对应的候选上游节点集合。

在本公开的一个实施例中，所述方法还包括：

所述第一节点在确定进入所述n个预热阶段中的第一个预热阶段的情况下，基于预热策略确定所述n个预热阶段分别对应的候选上游节点集合；

其中，所述预热策略中包含所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息。

在本公开的一个实施例中，所述方法还包括：

所述第一节点基于当前预热已用时长以及预热策略中包含的所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息，确定所述第i个预热阶段所对应的第一数值；

基于所述第一数值，确定第i个预热阶段允许通过的上游节点的最大数量。

在本公开的一个实施例中，所述基于所述第一数值，确定所述第i个预热阶段允许通过的上游节点的最大数量，包括以下之一：

在关闭了根据上游数量的百分比进行预热的情况下，将所述第一数值作为所述第i个预热阶段允许通过的上游节点的最大数量；

在开启了根据上游数量的百分比进行预热的情况下，基于所述第一数值确定所述第i个预热阶段所对应的百分比，基于所述百分比以及所述第一节点所对应的上游节点的数量确定所述第i个预热阶段允许通过的上游节点的最大数量。

在本公开的一个实施例中，所述方法还包括：

在所述第一节点确定下线的情况下，若所述第一节点接收到第三节点发来的健康询问请求，则所述第一节点向所述第三节点发送第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态；所述第三节点为所述第一节点的上游节点中之一。

在本公开的一个实施例中，所述方法还包括：

所述第一节点接收到部署节点发来的上线请求；

在所述第一节点满足第二预设条件的情况下，所述第一节点向所述部署节点反馈上线成功状态码；

其中，所述第二预设条件包括：所述第一节点预热功能开启且预热完成；或者，所述第一节点预热功能关闭。

本公开实施例的第二方面提供一种节点处理方法，所述方法包括：

第二节点向第一节点发送健康询问请求；其中，所述第二节点为所述第一节点的上游节点中之一；

所述第二节点接收所述第一节点反馈的状态码；

在所述第一节点反馈的状态码为第一类状态码的情况下，所述第二节点确定所述第一节点处于能够处理所述第二节点的业务请求的状态。

在本公开的一个实施例中，所述第二节点向第一节点发送健康询问请求，包括：所述第二节点在所述第一节点对应的第j个询问时间间隔向所述第一节点发送第j个健康询问请求；其中，j为大于等于1的整数；

所述第二节点接收所述第一节点反馈的状态码，包括：所述第二节点接收所述第一节点针对所述第j个健康询问请求反馈的状态码。

在本公开的一个实施例中，在所述第一节点反馈的状态码为第一类状态码的情况下，所述第二节点确定所述第一节点处于能够处理所述第二节点的业务请求的状态，包括：

在所述第一节点针对连续l个健康询问请求反馈的状态码为第一类状态码的情况下，确定所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述l个健康询问请求中包含所述第j个健康询问请求；l为大于等于2的整数。

在本公开的一个实施例中，所述方法包括：

在所述第一节点针对连续r个健康询问请求反馈的状态码为第二类状态码的情况下，所述第二节点在第j+1个询问时间间隔向所述第一节点发送第j+1个健康询问请求；其中，所述r个健康询问请求中包含所述第j个健康询问请求；r为大于等于2的整数。

本公开实施例的第三方面提供一种节点处理系统，包括：第一节点、第二节点；其中，

所述第一节点，用于处于n个预热阶段中的第i个预热阶段的情况下，接收第二节点发来的健康询问请求；其中，n为大于等于2的整数，i为大于等于1且小于等于n的整数；所述第二节点为所述第一节点的上游节点中之一；在所述第i个预热阶段对应的候选上游节点集合中包含所述第二节点的情况下，向所述第二节点发送第一类状态码；其中，所述第一类状态码用于指示所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于所述第一节点的上游节点的数量；

所述第二节点，用于向第一节点发送健康询问请求；其中，所述第二节点为所述第一节点的m个上游节点中之一；m为大于等于1的整数；接收所述第一节点反馈的状态码；在所述第一节点反馈的状态码为第一类状态码的情况下，确定所述第一节点处于能够处理所述第二节点的业务请求的状态。

在本公开的一个实施例中，所述系统还包括：部署节点；其中，

所述部署节点，用于向第一节点发送上线请求，在接收到所述第一节点反馈的上线成功状态码的情况下，确定所述第一节点上线成功；

所述第一节点，用于接收所述部署节点发来的上线请求，在满足第二预设条件的情况下，向所述部署节点反馈上线成功状态码；其中，所述第二预设条件包括：所述第一节点预热功能开启且预热完成；或者，所述第一节点预热功能关闭。

在本公开的一个实施例中，所述部署节点，还用于在确定当前部署批次包含的待部署节点全部上线成功的情况下，确定下一个部署批次包含的待部署节点；其中，所述当前部署批次包含的待部署节点包括所述第一节点。

本公开实施例的第四方面提供一种第一节点，包括：

第一接口单元，用于在处于n个预热阶段中的第i个预热阶段的情况下，接收第二节点发来的健康询问请求；其中，n为大于等于2的整数，i为大于等于1且小于等于n的整数；所述第二节点为所述第一节点的上游节点中之一；

第一处理单元，用于在所述第i个预热阶段对应的候选上游节点集合中包含所述第二节点的情况下，控制通过所述第一接口单元向所述第二节点发送第一类状态码；其中，所述第一类状态码用于指示所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于所述第一节点的上游节点的数量。

在本公开的一个实施例中，所述第一处理单元，用于在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，控制通过所述第一接口单元向所述第二节点发送第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态。

在本公开的一个实施例中，所述第一处理单元，用于在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若所述第一节点满足第一预设条件，则将所述第二节点的地址相关信息添加至第一集合，控制通过所述第一接口单元向所述第二节点反馈所述第二类状态码。

在本公开的一个实施例中，所述第一预设条件，包括：

开启了根据上游数量的百分比进行预热、关闭了根据上游节点的访问量排序确定允许通过的上游节点以及当前预热已用时长小于进行上游流量统计的等待时长；

或者，开启了根据上游数量的百分比进行预热、第二集合为空以及当前预热已用时长小于进行上游流量统计的等待时长；其中，所述第二集合为所述第一节点读取的按照预设访问量顺序排序的所述第一节点的上游节点集合。

在本公开的一个实施例中，所述第一处理单元，用于在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于所述第二节点的地址相关信息更新所述第i个预热阶段对应的候选上游节点集合得到所述第i个预热阶段对应的更新后的候选上游节点集合，控制通过所述第一接口单元向所述第二节点反馈第一类状态码。

在本公开的一个实施例中，所述第一处理单元，用于在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若开启了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于第二集合中的至少一个上游节点更新所述第i个预热阶段对应的候选上游节点集合，得到所述第i个预热阶段对应的更新后的候选上游节点集合；

其中，所述第二集合为所述第一节点读取的按照预设访问量顺序排序的所述第一节点的上游节点集合。

在本公开的一个实施例中，所述第一处理单元，用于执行以下之一：

在所述第i个预热阶段对应的更新后的候选上游节点集合包含所述第二节点的情况下，控制通过所述第一接口单元向所述第二节点反馈第一类状态码；

在所述第i个预热阶段对应的更新后的候选上游节点集合不包含所述第二节点的情况下，控制通过所述第一接口单元向所述第二节点反馈第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态。

在本公开的一个实施例中，所述第一处理单元，用于在所述第一节点基于当前预热已用时长确定进入所述n个预热阶段的所述第i个预热阶段的情况下，基于预热策略确定所述第i个预热阶段对应的候选上游节点集合；

其中，所述预热策略中包含所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息。

在本公开的一个实施例中，所述第一处理单元，用于基于所述预热策略中的所述第i个预热阶段对应的候选上游节点的数量相关信息，确定所述第i个预热阶段对应的候选上游节点的待添加数量；基于所述候选上游节点的待添加数量确定所述第i个预热阶段对应的候选上游节点；基于所述第i个预热阶段对应的候选上游节点，确定所述第i个预热阶段对应的候选上游节点集合。

在本公开的一个实施例中，所述第一处理单元，用于在确定进入所述n个预热阶段中的第一个预热阶段的情况下，基于预热策略确定所述n个预热阶段分别对应的候选上游节点集合；

其中，所述预热策略中包含所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息。

在本公开的一个实施例中，所述第一处理单元，用于基于当前预热已用时长以及预热策略中包含的所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息，确定所述第i个预热阶段所对应的第一数值；基于所述第一数值，确定第i个预热阶段允许通过的上游节点的最大数量。

在本公开的一个实施例中，所述第一处理单元，用于执行以下之一：

在关闭了根据上游数量的百分比进行预热的情况下，将所述第一数值作为所述第i个预热阶段允许通过的上游节点的最大数量；

在开启了根据上游数量的百分比进行预热的情况下，基于所述第一数值确定所述第i个预热阶段所对应的百分比，基于所述百分比以及所述第一节点所对应的上游节点的数量确定所述第i个预热阶段允许通过的上游节点的最大数量。

在本公开的一个实施例中，所述第一处理单元，用于在所述第一节点确定下线的情况下，若通过第一接口单元接收到第三节点发来的健康询问请求，则控制通过所述第一接口单元向所述第三节点发送第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态；所述第三节点为所述第一节点的上游节点中之一。

在本公开的一个实施例中，所述第一节点还包括：

第二接口单元，用于接收到部署节点发来的上线请求；

所述第一处理单元，还用于在所述第一节点满足第二预设条件的情况下，控制通过所述第二接口单元向所述部署节点反馈上线成功状态码；

其中，所述第二预设条件包括：所述第一节点预热功能开启且预热完成；或者，所述第一节点预热功能关闭。

本公开实施例的第五方面提供一种第二节点，包括：

第三接口单元，用于向第一节点发送健康询问请求；其中，所述第二节点为所述第一节点的上游节点中之一；接收所述第一节点反馈的状态码；

第二处理单元，用于在所述第一节点反馈的状态码为第一类状态码的情况下，确定所述第一节点处于能够处理所述第二节点的业务请求的状态。

在本公开的一个实施例中，所述第三接口单元，用于在所述第一节点对应的第j个询问时间间隔向所述第一节点发送第j个健康询问请求；其中，j为大于等于1的整数；

以及，接收所述第一节点针对所述第j个健康询问请求反馈的状态码。

在本公开的一个实施例中，第二处理单元，用于在所述第一节点针对连续l个健康询问请求反馈的状态码为第一类状态码的情况下，确定所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述l个健康询问请求中包含所述第j个健康询问请求；l为大于等于2的整数。

在本公开的一个实施例中，第二处理单元，用于在所述第一节点针对连续r个健康询问请求反馈的状态码为第二类状态码的情况下，控制通过所述第三接口单元在第j+1个询问时间间隔向所述第一节点发送第j+1个健康询问请求；其中，所述r个健康询问请求中包含所述第j个健康询问请求；r为大于等于2的整数。

本公开实施例的第六方面提供一种介质，其存储有计算机程序，其特征在于，该程序被处理器执行时实现如前述实施例的方法。

本申请实施例的第七方面提供一种计算设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如前述实施例的方法。

根据本公开实施方式，通过在第一节点处于在n个预热阶段中的第i个预热阶段的情况下，根据第i个预热阶段对应的候选上游节点集合，确定是否向发来健康询问请求的第二节点即任意一个上游节点反馈第一类状态码以指示该第一节点当前处于可以处理该上游节点的业务请求的状态，进而可以基于这部分上游节点的真实业务请求执行预热。如此，可以避免现有技术中采用虚拟流量进行预热所带来的预热效果较差、依赖数据库或缓存等服务所带来的流量冲击等额外负担以及由于保存虚拟流量所带来的存储资源的开销较大等问题；并且由于本实施例提供的方案可以使得第一节点采用上游节点的真实业务请求进行预热，因此不需要考虑数据污染等问题，保证了预热的效果；此外，由于在预热阶段中对当前允许通过的上游节点的数量进行限制，因此上游节点的变更不会对第一节点的预热效果产生影响，也进一步保证了预热的效果。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：

图1示意性地示出了根据本公开一实施方式的节点处理方法流程图一；

图2示意性地示出了根据本公开一实施方式的第一节点处于不同预热阶段的处理场景示意图；

图3示意性地示出了根据本公开一实施方式的第一节点与部署节点以及上游节点之间的交互场景示意图；

图4示意性地示出了根据本公开一实施方式的节点处理方法流程图二；

图5示意性地示出了根据本公开一实施方式的节点处理系统组成结构示意图；

图6示意性地示出了根据本公开一实施方式的介质示意图；

图7示意性地示出了根据本公开一实施方式的第一节点的组成结构示意图；

图8示意性地示出了根据本公开一实施方式的第二节点的组成结构示意图；

图9示意性地示出了根据本公开一实施方式的计算设备结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提出了一种节点处理方法及系统、节点、介质、计算设备。

在本文中，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。

发明概述

本申请人发现，对于服务端来说，发布一般分为热部署和冷部署。对于冷部署来说，虽然重启进程可以较为彻底地清理上一个进程的资源，但是因为种种原因使得进程刚启动时会存在一些性能问题，导致部分请求处理失败或响应时间过长，影响用户体验，因此，通常采用预热来解决进程刚启动时性能较差的问题。然而，相关技术中通常采用虚拟流量进行预热，从而会出现为系统带来额外负担，数据污染以及存储资源开销较大等问题。

有鉴于此，本公开提供一种节点处理方法及系统、节点、介质、计算设备，其中方法包括：

在第一节点处于n个预热阶段中的第i个预热阶段的情况下，所述第一节点接收第二节点发来的健康询问请求；其中，n为大于等于2的整数，i为大于等于1且小于等于n的整数；所述第二节点为所述第一节点的上游节点中之一；

在所述第i个预热阶段对应的候选上游节点集合中包含所述第二节点的情况下，所述第一节点向所述第二节点发送第一类状态码；其中，所述第一类状态码用于指示所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于所述第一节点的上游节点的数量。

以及，

第二节点向第一节点发送健康询问请求；其中，所述第二节点为所述第一节点的上游节点中之一；

所述第二节点接收所述第一节点反馈的状态码；

在所述第一节点反馈的状态码为第一类状态码的情况下，所述第二节点确定所述第一节点处于能够处理所述第二节点的业务请求的状态。

如此，可以避免现有技术中采用虚拟流量进行预热所带来的预热效果较差、依赖数据库或缓存等服务所带来的流量冲击等额外负担以及由于保存虚拟流量所带来的存储资源的开销较大等问题；并且由于本实施例提供的方案可以使得第一节点采用上游节点的真实业务请求进行预热，因此不需要考虑数据污染等问题，保证了预热的效果；此外，由于在预热阶段中对当前允许通过的上游节点的数量进行限制，因此上游节点的变更不会对第一节点的预热效果产生影响，也进一步保证了预热的效果。

在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。

示例性方法

本公开的第一个方面提供一种节点处理方法，如图1所示，包括：

s101：在第一节点处于n个预热阶段中的第i个预热阶段的情况下，所述第一节点接收第二节点发来的健康询问请求；其中，n为大于等于2的整数，i为大于等于1且小于等于n的整数；所述第二节点为所述第一节点的上游节点中之一；

s102：在所述第i个预热阶段对应的候选上游节点集合中包含所述第二节点的情况下，所述第一节点向所述第二节点发送第一类状态码；其中，所述第一类状态码用于指示所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于所述第一节点的上游节点的数量。

本实施例提供的方案由第一节点执行，其中，所述第一节点可以为系统中待上线的任意一个节点或任意一个服务节点，示例性的，第一节点可以为nginx服务器。所述第一节点可以有一个或多个上游节点，关于第一节点的上游节点的数量本实施例中不做限定。

本实施例中将当前向第一节点发送健康询问请求的上游节点称为第二节点，所述第二节点可以为所述第一节点的上游节点中任意之一。比如，第一节点对应5个上游节点，分别为节点1、节点2～节点5，当前节点2向第一节点发送健康询问请求，该节点2可以为本实施例中的第二节点。

执行前述s101之前，可以包括：所述第一节点进行初始化处理。

其中，所述第一节点的初始化处理可以根据实际配置来确定，举例来说，可以包括有读取配置参数、初始化时间、初始化日志功能、创建内存池、绑定对应的tcp端口等等，本实施例不对其初始化处理中包含的具体内容进行限定以及穷举。

在所述第一节点进行初始化处理的过程中，所述第一节点的处理还可以包括：接收第二节点发来的健康询问请求，向所述第二节点发送第二类状态码；其中，所述第二类状态码用于表征所述第一节点处于不处理业务请求的状态。也就是说，在所述第一节点进行初始化处理的过程中，第一节点向任意一个发来健康询问请求的上游节点均反馈第二类状态码。

本实施例中所述第二类状态码可以为预先配置的，比如，可以预先配置“4xx”状态码为第二类状态码，其中“4xx”表示以4开头的任意一种状态码均为第二类状态码；又比如，可以预先配置“403”状态码为第二类状态码。

所述第一节点在初始化处理完成之后，执行s101，也就是在第一节点处于n个预热阶段中的第i个预热阶段的情况下，所述第一节点接收第二节点发来的健康询问请求。其中，第i个预热阶段为n个预热阶段中的任意一个预热阶段。

这里，所述第i个预热阶段中i的取值，也就是第一节点处于n个预热阶段中的第几个预热阶段的确定方式可以是：所述第一节点基于当前预热已用时长以及预热策略中包含的n个预热阶段分别对应的预热时长，确定当前处于所述n个预热阶段的第i个预热阶段。

其中，所述预热策略中至少包括：所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息。

举例来说，在预热策略中配置3个预热阶段分别对应的预热时长为“0-20秒”、“20-40秒”以及“40-60秒”，当前预热已用时长为10秒，则确定当前处于3个预热阶段中的第1个预热阶段。

另外，关于所述预热策略中所述n个预热阶段分别对应的候选上游节点的数量相关信息还需要说明的是，相邻两个预热阶段对应的候选上游节点的数量的差值不会设置的太大，也就是可以设置相邻两个预热阶段对应的候选上游节点的数量的差值小于预设数量门限值，比如数量差值小于10，或者百分比差值小于15％。这是为了防止在上一阶段设置了较多的非活跃上游节点导致没起到预热效果，而下一阶段进来太多的活跃上游节点所造成的预热不充分导致的性能问题。

所述第二节点发送的所述健康询问请求，可以为所述第二节点基于询问时间间隔周期性的发送所述健康询问请求；所述询问时间间隔的时长可以根据实际情况设置，比如可以设置为1秒钟，当然还可以更长或更短，这里不对其进行穷举。相应的，本实施例中所述第一节点接收第二节点发来的健康询问请求可以指的是所述第一节点接收到第二节点在任意一个询问时间间隔发来的健康询问请求。

在所述第一节点接收第二节点发来的健康询问请求之后，还可以包括：所述第一节点判断在所述第i个预热阶段对应的候选上游节点集合中是否包含所述第二节点，若包含，则执行s102，即在所述第i个预热阶段对应的候选上游节点集合中包含所述第二节点的情况下，所述第一节点向所述第二节点发送第一类状态码。

其中，所述第一类状态码可以为预先配置的，比如，可以预先配置“2xx”或“3xx”状态码为第一类状态码，也就是以3或2开头的任意一种状态码均为第一类状态码；又比如，可以预先配置“200”状态码为第一类状态码。

所述第一类状态码用于指示所述第一节点处于能够处理所述第二节点的业务请求的状态。也就是说，若第一节点向第二节点反馈第一类状态码，则表示第一节点能够处理第二节点发来的业务请求。

需要指出的是，不论当前的第i个预热阶段为n个预热阶段中的哪个预热阶段，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于所述第一节点的上游节点的数量。

所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量大于第i-1个预热阶段对应的候选上游节点集合中的候选上游节点的数量，和/或，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i+1个预热阶段对应的候选上游节点集合中的候选上游节点的数量。举例来说，n为3，i为1的情况下，所述第1个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第2个预热阶段对应的候选上游节点集合中的候选上游节点的数量；n为3，i为2的情况下，所述第2个预热阶段对应的候选上游节点集合中的候选上游节点的数量大于第1个预热阶段对应的候选上游节点集合中的候选上游节点的数量，所述第2个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第3个预热阶段对应的候选上游节点集合中的候选上游节点的数量；n为3，i为3的情况下，所述第3个预热阶段对应的候选上游节点集合中的候选上游节点的数量大于第2个预热阶段对应的候选上游节点集合中的候选上游节点的数量。

所述第i个预热阶段对应的候选上游节点集合中可以包含至少一个候选上游节点分别对应的地址相关信息。其中，所述地址相关信息可以为候选上游节点的ip(internetprotocol，互联网协议)地址。比如，i等于1，第1个预热阶段对应的候选上游节点集合包含候选上游节点1的ip地址1，以及候选上游节点2的ip地址2。

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，可以存在多种处理方式以确定向第二节点发送的状态码，下面分别进行说明：

处理方式一、

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，所述第一节点向所述第二节点发送第二类状态码。

也就是说，第一节点在接收到任意一个上游节点即第二节点发来的健康询问请求的时候，基于所述第二节点的地址相关信息，判断在当前阶段对应的候选上游节点集合中是否包含有该第二节点的地址相关信息；若包含，则可以向第二节点发送第一类状态码；若不包含，则可以向第二节点发送第二类状态码。

处理方式二、

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若所述第一节点满足第一预设条件，则所述第一节点将所述第二节点的地址相关信息添加至第一集合，向所述第二节点反馈所述第二类状态码。

所述第一预设条件，包括：

开启了根据上游数量的百分比进行预热、关闭了根据上游节点的访问量排序确定允许通过的上游节点以及当前预热已用时长小于进行上游流量统计的等待时长；

或者，开启了根据上游数量的百分比进行预热、第二集合为空以及当前预热已用时长小于进行上游流量统计的等待时长；其中，所述第二集合为所述第一节点读取的按照预设访问量顺序排序的所述第一节点的上游节点集合。

其中，所述第一集合与第二集合的获取方式不同，第一集合与第二集合中包含的上游节点的数量可以相同也可以不同。所述第一集合可以为第一节点在进行上游流量统计的等待时长中统计发来健康询问请求的上游节点所组成的集合。所述第二集合为所述第一节点读取的按照预设访问量顺序排序的所述第一节点的上游节点集合，这里，所述预设访问量顺序可以是按照访问量从大到小的顺序；也就是说，第二集合可以为第一节点在初始化处理的时候读取的上游节点集合，并且第二集合中包含的上游节点是按照访问量从大到小排序的。

关于第二集合还需要说明的是，第二集合可以为第一节点在本次上线处理之前生成的，比如，第一节点可以在预设时间段开启并按照上游节点的地址相关信息(即ip地址)进行请求量聚合并排序生成或更新第二集合，并将第二集合保存在本地硬盘；在第一节点本次需要上线执行初始化处理的时候从本地硬盘中查找是否保存有第二集合，若保存有所述第二集合则读取所述第二集合。其中，所述预设时间段可以根据实际情况设置，比如可以是每天的某一段时间，示例性的可以是每天晚上11点到12点。

本实施例获取或使用上述第二集合的原因是由于上游流量分布可能较为复杂，上游节点可能分为多集群面向不同场景。比如有些可能面向管控端只有管理员使用，有些可能面向用户侧承受百万级甚至亿级日活流量，因此上游节点的流量不一定均衡，而如果预热时选取到的上游节点是流量很少的节点那可能会对预热效果有所影响，所以本实施例通过预先对第一节点的上游节点的流量进行统计以及排序，则可以在预热阶段中基于第二集合中按照访问量从大到小排序后的上游节点进行预热，从而保证预热效果较好。

还需要说明的是，在第一节点可以预先设置是否根据上游数量的百分比进行预热，比如该配置字段可以为percent。关于根据上游数量的百分比进行预热的开启或关闭，可以通过对上述配置字段设置不同的值来实现，比如1可以表示开启，0可以表示关闭；又或者，ture表示开启，false表示关闭等等。若开启了根据上游数量的百分比进行预热，则第一节点可以基于其上游节点的总数量以及预热策略中包含的当前所处的预热阶段(第i个预热阶段)所对应的百分比来确定当前所处的预热阶段(第i个预热阶段)允许通过的上游节点的最大数量；若关闭了根据上游数量的百分比进行预热，则第一节点可以将预热策略中包含的当前所处的预热阶段(第i个预热阶段)所对应的绝对数量作为当前所处的预热阶段(第i个预热阶段)允许通过的上游节点的最大数量。

在第一节点还可以预先设置是否根据上游节点的访问量排序确定允许通过的上游节点，比如该配置字段可以为“sort”字段。关于根据上游节点的访问量排序确定允许通过的上游节点的开启或关闭，可以通过对上述配置字段设置不同的值来实现，比如1可以表示开启，0可以表示关闭；又或者，ture表示开启，false表示关闭等等。若开启了根据上游节点的访问量排序确定通过的上游节点，则第一节点可以基于上游节点的访问量排序从大到小的顺序，确定当前预热阶段允许通过的上游节点；若关闭了根据上游节点的访问量排序确定通过的上游节点，则第一节点需要在进行上游流量统计的等待时长内进行第一集合的统计。

在第一节点还可以预先设置进行上游流量统计的等待时长，可以表示为“percentwait”。该等待时长的具体长度可以根据实际情况进行设置，比如可以为10秒钟。

前述已经说明所述第二节点可以为第一节点的任意一个上游节点，也就是在第一节点接收到任意一个上游节点发来的健康询问请求的时候，若该上游节点不包含在所述第i个预热阶段对应的候选上游节点集合，第一节点开启了根据上游数量的百分比进行预热、关闭了根据上游节点的访问量排序确定允许通过的上游节点并且当前预热已用时长小于进行上游流量统计的等待时长，则所述第一节点将该上游节点的地址相关信息添加至第一集合中；直至当前预热已用时长不小于进行上游流量统计的等待时长为止。

又或者，在第一节点接收到任意一个上游节点发来的健康询问请求的时候，若该上游节点不包含在所述第i个预热阶段对应的候选上游节点集合，并且第一节点开启了根据上游数量的百分比进行预热、第二集合为空以及当前预热已用时长小于进行上游流量统计的等待时长，则所述第一节点将发来健康询问请求的上游节点的地址相关信息添加至第一集合中；直至当前预热已用时长不小于进行上游流量统计的等待时长为止。

其中，所述第二节点的地址相关信息可以为所述第二节点的ip地址。

也就是说，在确定所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的时候，进一步结合第一预设条件进行判断，在满足第一预设条件的时候，向第二节点反馈第二类状态码，并同时将第二节点的地址相关信息添加至第一集合；在不满足第一预设条件的时候，直接向第二节点反馈第二类状态码。

处理方式三、

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于所述第二节点的地址相关信息更新所述第i个预热阶段对应的候选上游节点集合得到所述第i个预热阶段对应的更新后的候选上游节点集合，向所述第二节点反馈第一类状态码。

本处理方式中，在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，通过配置字段来判断是否关闭了根据上游节点的访问量排序确定允许通过的上游节点且判断所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量是否小于第i个预热阶段允许通过的上游节点的最大数量；

若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则可以向第二节点反馈第一类状态码，并同时可以将所述第二节点的相关信息添加至所述第i个预热阶段对应的候选上游节点集合中，得到所述第i个预热阶段对应的更新后的候选上游节点集合。

举例来说，i为2，第2个预热阶段对应的候选上游节点集合所包含的候选上游节点的数量为3个，第2个预热阶段允许通过的上游节点的最大数量为5个；第一节点接收到第二节点发来的健康询问请求，该第二节点未包含在当前所在的第2个预热阶段对应的候选上游节点集合中，但是由于第一节点关闭了根据上游节点的访问量排序确定允许通过的上游节点并且第2个预热阶段对应的候选上游节点集合所包含的候选上游节点的数量为3没有达到第2个预热阶段允许通过的上游节点的最大数量5，则第一节点向第二节点发送200状态码，并且将第二节点的ip地址添加至第2个预热阶段对应的候选上游节点集合中。

另外，还可以包括：在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量不小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点向所述第二节点反馈第二类状态码。

还需要说明的是，处理方式三与处理方式二可以同时使用，比如，在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，判断所述第一节点是否满足第一预设条件；

若所述第一节点满足第一预设条件，则所述第一节点将所述第二节点的地址相关信息添加至第一集合，向所述第二节点反馈所述第二类状态码；

若所述第一节点不满足第一预设条件，则判断所述第一节点是否关闭了根据上游节点的访问量排序确定允许通过的上游节点，并且判断所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量；

若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于所述第二节点的地址相关信息更新所述第i个预热阶段对应的候选上游节点集合得到所述第i个预热阶段对应的更新后的候选上游节点集合，向所述第二节点反馈第一类状态码；

若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量不小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点向所述第二节点反馈第二类状态码。

处理方式四、

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若开启了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于第二集合中的至少一个上游节点更新所述第i个预热阶段对应的候选上游节点集合，得到所述第i个预热阶段对应的更新后的候选上游节点集合。

本处理方式与前述处理方式二以及处理方式三不同在于，本处理方式开启了根据上游节点的访问量排序确定允许通过的上游节点，也就是需要基于上游节点的访问量排序选取允许通过的上游节点的方式。

另外，还可以包括：在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若开启了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量不小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点向所述第二节点反馈第二类状态码。

其中，所述第一节点基于第二集合中的至少一个上游节点更新所述第i个预热阶段对应的候选上游节点集合，得到所述第i个预热阶段对应的更新后的候选上游节点集合，可以包括：

所述第一节点基于第二集合中上游节点的排序，选取当前排序最高且未包含在所述第i个预热阶段对应的候选上游节点集合中的一个上游节点作为待添加候选上游节点，将所述待添加候选上游节点添加至所述第i个预热阶段对应的候选上游节点集合，得到所述第i个预热阶段对应的更新后的候选上游节点集合；之后，再次判断所述第i个预热阶段对应的更新后的候选上游节点集合中的候选上游节点的数量是否小于第i个预热阶段允许通过的上游节点的最大数量，若不小于，则当前所述第i个预热阶段对应的更新后的候选上游节点集合为最终确定的所述第i个预热阶段对应的更新后的候选上游节点集合；若小于，则继续基于第二集合中上游节点的排序，选取当前排序最高且未包含在所述第i个预热阶段对应的候选上游节点集合中的一个上游节点作为待添加候选上游节点，将所述待添加候选上游节点添加至所述第i个预热阶段对应的更新后的候选上游节点集合。如此循环，直至所述第i个预热阶段对应的更新后的候选上游节点集合中的候选上游节点的数量不小于第i个预热阶段允许通过的上游节点的最大数量为止。

前述实施例已经说明，第二集合中包含的上游节点为基于访问量从大到小的顺序排序后的上游节点，因此，基于第二集合中的上游节点更新所述第i个预热阶段对应的候选上游节点集合后，还可以保证所述第i个预热阶段对应的更新后的候选上游节点集合中包含的候选上游节点也为访问量相对较高的上游节点。

得到上述所述第i个预热阶段对应的更新后的候选上游节点集合之后，还可以包括：

在所述第i个预热阶段对应的更新后的候选上游节点集合包含所述第二节点的情况下，所述第一节点向所述第二节点反馈第一类状态码；

在所述第i个预热阶段对应的更新后的候选上游节点集合不包含所述第二节点的情况下，所述第一节点向所述第二节点反馈第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态。

还需要指出，上述处理方式二、处理方式三以及处理方式四也可以结合使用，比如：

在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，判断所述第一节点是否满足第一预设条件；

若所述第一节点满足第一预设条件，则所述第一节点将所述第二节点的地址相关信息添加至第一集合，向所述第二节点反馈所述第二类状态码；

若所述第一节点不满足第一预设条件，则判断所述第一节点是否关闭了根据上游节点的访问量排序确定允许通过的上游节点，并且判断所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量；

若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于所述第二节点的地址相关信息更新所述第i个预热阶段对应的候选上游节点集合得到所述第i个预热阶段对应的更新后的候选上游节点集合，向所述第二节点反馈第一类状态码；

若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量不小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点向所述第二节点反馈第二类状态码；

若开启了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于第二集合中的至少一个上游节点更新所述第i个预热阶段对应的候选上游节点集合，得到所述第i个预热阶段对应的更新后的候选上游节点集合，再判断在所述第i个预热阶段对应的更新后的候选上游节点集合中是否包含所述第二节点，若包含，则所述第一节点向所述第二节点反馈第一类状态码，否则，所述第一节点向所述第二节点反馈第二类状态码；

若开启了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量不小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点向所述第二节点反馈第二类状态码。

以上实施例中，涉及到关于在所述第i个预热阶段对应的候选上游节点集合、第i个预热阶段允许通过的上游节点的最大数量，关于这两个参数的确定方式，在以下实施例分别做进一步说明。

关于确定所述第i个预热阶段对应的候选上游节点集合的方式，可以包括以下两种：

方式1、在所述第一节点基于当前预热已用时长确定进入所述n个预热阶段的所述第i个预热阶段的情况下，所述第一节点基于预热策略确定所述第i个预热阶段对应的候选上游节点集合；

其中，所述预热策略中包含所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息。

本方式中，第一节点在每进入一个新的预热阶段开始的时候，确定该新的预热阶段所对应的候选上游节点集合。

在所述第一节点进入预热状态之后，可以基于预热策略以及基于当前预热已用时长确定当前所处的预热阶段为第几个预热阶段。具体的，若当前预热已用时长为j秒，且j等于预热策略中第i个预热阶段的最小预热时长，则确定进入所述n个预热阶段的第i个预热阶段，基于预热策略确定所述第i个预热阶段对应的候选上游节点集合；其中，j为大于等于0的正数。比如，假设预热策略中包含3个预热阶段，以及3个预热阶段中每一个预热阶段所对应的预热时长，比如，第1个预热阶段的预热时长为0-20秒钟，第2个预热阶段的预热时长为20-40秒钟，第3个预热阶段的预热时长为40-60秒；相应的，若当前预热已用时长为0秒，则可以确定进入n个预热阶段中的第1个预热阶段，此时基于预热策略确定所述第1个预热阶段对应的候选上游节点集合。

所述第一节点基于预热策略确定所述第i个预热阶段对应的候选上游节点集合，包括：

所述第一节点基于所述预热策略中的所述第i个预热阶段对应的候选上游节点的数量相关信息，确定所述第i个预热阶段对应的候选上游节点的待添加数量；

所述第一节点基于所述候选上游节点的待添加数量确定所述第i个预热阶段对应的候选上游节点；

所述第一节点基于所述第i个预热阶段对应的候选上游节点，确定所述第i个预热阶段对应的候选上游节点集合。

其中，所述基于所述预热策略中的所述第i个预热阶段对应的候选上游节点的数量相关信息，确定所述第i个预热阶段对应的候选上游节点的待添加数量，可以包括：

若所述预热策略中的所述第i个预热阶段对应的候选上游节点的数量相关信息为数值，则将该数值作为所述第i个预热阶段对应的候选上游节点的待添加数量；

若所述预热策略中的所述第i个预热阶段对应的候选上游节点的数量相关信息为百分比，则基于该百分比以及预先获取的第一集合中包含的上游节点的数量进行计算得到第i个预热阶段对应的候选上游节点的待添加数量。

所述第一节点基于所述候选上游节点的待添加数量确定所述第i个预热阶段对应的候选上游节点，可以包括：

在开启了根据上游节点的访问量排序确定允许通过的上游节点的情况下，所述第一节点基于所述候选上游节点的待添加数量，从第一集合中按照排序从高到低的顺序，选取待添加数量个上游节点，作为所述第i个预热阶段对应的候选上游节点；

在关闭了根据上游节点的访问量排序确定允许通过的上游节点的情况下，所述第一节点基于所述候选上游节点的待添加数量，随机从第一节点的上游节点中，选取待添加数量个上游节点作为所述第i个预热阶段对应的候选上游节点。

所述第一节点基于所述第i个预热阶段对应的候选上游节点，确定所述第i个预热阶段对应的候选上游节点集合，可以包括：

在i等于1的情况下，所述第一节点将所述第1个预热阶段对应的候选上游节点作为所述第1个预热阶段对应的候选上游节点集合；

在i大于1的情况下，所述第一节点将所述第i个预热阶段对应的候选上游节点添加至第i-1个预热阶段对应的候选上游节点集合中，得到所述第i个预热阶段对应的候选上游节点集合。

也就是说，若当前预热阶段为第1个预热阶段，则将当前确定的候选上游节点作为第1个预热阶段的候选上游节点集合的全部候选上游节点。若当前预热阶段为其他预热阶段，则在前一个预热阶段对应的候选上游节点集合的基础上，添加当前阶段确定的候选上游节点，得到当前阶段所对应的候选上游节点集合。换句话说，预热阶段对应的候选上游节点集合中包含的候选上游节点是累加的。

方式2、所述第一节点在确定进入所述n个预热阶段中的第一个预热阶段的情况下，基于预热策略确定所述n个预热阶段分别对应的候选上游节点集合；其中，所述预热策略中包含所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息。

与方式1不同之处在于，方式2中，第一节点在确定进入第一个预热阶段的时候，就确定n个预热阶段中全部预热阶段分别对应的候选上游节点集合。这样，相比于方式1而言，方式2的处理可以减少每一个预热阶段开始的时候需要执行的处理内容，提升每一个预热阶段的处理效率。

具体来说，可以包括：

在开启了根据上游数量的百分比进行预热且开启了根据上游节点的访问量排序确定允许通过的上游节点的情况下，所述第一节点基于预热策略中包含的n个预热阶段分别对应的候选上游节点的数量相关信息确定所述n个预热阶段分别对应的百分比，基于n个预热阶段分别对应的百分比以及预先获取的第二集合，确定n个预热阶段分别对应的候选上游节点的数量；基于n个预热阶段分别对应的候选上游节点的数量，从第一集合中确定n个预热阶段分别对应的候选上游节点集合。

在关闭了根据上游数量的百分比进行预热且开启了根据上游节点的访问量排序确定允许通过的上游节点的情况下，所述第一节点基于预热策略中包含的n个预热阶段分别对应的候选上游节点的数量相关信息确定所述n个预热阶段分别对应的候选上游节点的数量；基于n个预热阶段分别对应的候选上游节点的数量，从第一集合中确定n个预热阶段分别对应的候选上游节点集合。

在开启了根据上游数量的百分比进行预热且关闭了根据上游节点的访问量排序确定允许通过的上游节点的情况下，所述第一节点基于预热策略中包含的n个预热阶段分别对应的候选上游节点的数量相关信息确定所述n个预热阶段分别对应的百分比，基于n个预热阶段分别对应的百分比，以及第一节点的上游节点总数，确定n个预热阶段分别对应的候选上游节点的数量；基于n个预热阶段分别对应的候选上游节点的数量，确定n个预热阶段分别对应的候选上游节点集合。其中，第一节点的上游节点的总数可以是在进行上游流量统计的等待时长中统计得到的第一集合中包含的上游节点的总数。

在关闭了根据上游数量的百分比进行预热且关闭了根据上游节点的访问量排序确定允许通过的上游节点的情况下，所述第一节点基于预热策略中包含的n个预热阶段分别对应的候选上游节点的数量相关信息确定n个预热阶段分别对应的候选上游节点的数量；基于n个预热阶段分别对应的候选上游节点的数量，从第一节点的上游节点中随机选取n个预热阶段分别对应的候选上游节点集合。

需要指出的是，预热策略中包含的n个预热阶段分别对应的候选上游节点的数量相关信息，可以有以下几种情况：

第一种情况中，预热策略中包含的n个预热阶段分别对应的候选上游节点的允许通过的数量相关信息，比如，每一个预热阶段对应的候选上游节点的允许通过的最大数量或最大百分比。

这种情况下，预热策略中的每一个预热阶段对应的候选上游节点的最大数量中可以包含前一个预热阶段对应的候选上游节点的数量。比如，第1个预热阶段对应的候选上游节点的最大数量为2个，第2个预热阶段对应的候选上游节点的最大数量为10个，则第2个预热阶段对应的候选上游节点中包含有第1个预热阶段对应的候选上游节点，即第2个预热阶段相比与第1个预热阶段，增加了8个新的候选上游节点。

第二种情况，预热策略中包含的n个预热阶段分别对应的候选上游节点的允许通过的数量相关信息，比如，每一个预热阶段对应的候选上游节点的允许通过的新增数量或新增百分比。

这种情况下，预热策略中的每一个预热阶段对应的候选上游节点的新增数量中不包含前一个预热阶段对应的候选上游节点的数量。比如，第1个预热阶段对应的候选上游节点的最大数量为2个，第2个预热阶段对应的候选上游节点的新增数量为8个，则第2个预热阶段相比与第1个预热阶段增加了8个新的候选上游节点，第2个预热阶段对应的候选上游节点的总数量为10个。

关于确定第i个预热阶段允许通过的上游节点的最大数量的方式，可以包括：

所述第一节点基于当前预热已用时长以及预热策略中包含的所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息，确定所述第i个预热阶段所对应的第一数值；

基于所述第一数值，确定第i个预热阶段允许通过的上游节点的最大数量。

所述第一节点基于当前预热已用时长以及预热策略中包含的所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息，确定所述第i个预热阶段所对应的第一数值，可以包括：

所述第一节点基于当前预热已用时长以及预热策略中包含的n个预热阶段分别对应的预热时长，确定当前所处的第i个预热阶段；从预热策略中获取第i个预热阶段所对应的候选上游节点的数量相关信息，将所述数量相关信息作为所述第i个预热阶段所对应的第一数值。

这里，所述预热策略中所包含的n个预热阶段分别对应的预热时长，可以是n个预热阶段分别对应的最大预热时长。比如，n为3，在预热策略中包含了“20秒”、“40秒”以及“60秒”作为3个预热阶段分别对应的最大预热时长；相应的，若当前预热已用时长为30秒，则在预热策略中选取比30秒大且时间差值最小的预热时长所对应的预热阶段作为当前所在的预热阶段，进而将这个预热阶段所对应的数量相关信息作为第一数值。或者，所述预热策略中所包含的n个预热阶段分别对应的预热时长，可以是n个预热阶段分别对应的预热时长区间。比如，n为3，在预热策略中包含了“大于等于0秒且小于等于20秒”、“大于20秒小于等于40秒”以及“大于40秒且小于等于60秒”作为3个预热阶段分别对应的预热时长区间；相应的，若当前预热已用时长为30秒，则将预热策略中“大于20秒小于等于40秒”这个预热时长区间所对应的预热阶段作为当前所在的预热阶段，进而将这个预热阶段所对应的数量相关信息作为第一数值。

所述基于所述第一数值，确定所述第i个预热阶段允许通过的上游节点的最大数量，包括以下之一：

在关闭了根据上游数量的百分比进行预热的情况下，将所述第一数值作为所述第i个预热阶段允许通过的上游节点的最大数量；

在开启了根据上游数量的百分比进行预热的情况下，基于所述第一数值确定所述第i个预热阶段所对应的百分比，基于所述百分比以及所述第一节点所对应的上游节点的数量确定所述第i个预热阶段允许通过的上游节点的最大数量。

其中，在开启了根据上游数量的百分比进行预热的情况下，基于所述第一数值确定所述第i个预热阶段所对应的百分比，基于所述百分比以及所述第一节点所对应的上游节点的数量确定所述第i个预热阶段允许通过的上游节点的最大数量，可以指的是：在开启了根据上游数量的百分比进行预热的情况下，将所述第一数值除以100得到所述第i个预热阶段所对应的百分比；

判断当前是否开启了根据上游节点的访问量排序确定允许通过的上游节点并且判断第二集合是否非空；

若开启了根据上游节点的访问量排序确定允许通过的上游节点并且第二集合非空，则基于所述百分比与所述第二集合中包含的上游节点的数量相乘，得到所述第i个预热阶段允许通过的上游节点的最大数量；

若关闭了根据上游节点的访问量排序确定允许通过的上游节点和/或第二集合为空，则基于所述百分比与所述第一集合中包含的上游节点的数量相乘，得到所述第i个预热阶段允许通过的上游节点的最大数量。

这里，第一集合以及第二集合的获取方式以及内容在前述实施例已经说明，这里不做赘述。

前述实施例中提到第一节点的预热策略为预先配置并保存的，并且第一节点会预先配置进行上游流量统计的等待时长，根据上游节点的访问量排序确定允许通过的上游节点的开启或关闭，根据上游数量的百分比进行预热的开启或关闭，以及进行第二集合的统计的相关配置。下面针对第一节点预先配置或保存(比如可以存储在treemap(树图)中)的相关配置字段或配置文件进行示例性说明如下：

其中，nginxpreheatactive配置字段用于表示预热功能的开关，若本配置字段设置为false，即预热功能关闭，则第一节点不执行预热处理。

percent配置字段用于表示是否根据上游数量的百分比进行预热。这个配置字段的设置是考虑了上游节点可能扩缩容的情况，如果按绝对数量进行配置时，当上游发生大幅度扩缩容，可能会对预热效果造成影响，而percent配置字段设置为true后，即需要统计到上游总数信息，所以是否将percent配置字段设置为true，以开启根据上游数量的百分比进行预热需要根据实际情况来设置。

percentwait配置字段用于表示进行上游流量统计的等待时长；当percent配置字段设置为true，即开启了根据上游数量的百分比进行预热，且本地磁盘没有上游流量记录即第二集合时，第一节点进入预热阶段的时候会根据进行上游流量统计的等待时长将发来健康询问请求的上游节点进行数量统计以得到上游节点总数(即第一集合)。最终放开上游节点健康检查状态时，根据第一集合中包含的上游节点绝对数量去确定每一个预热阶段允许通过的上游节点的最大数量；若只配置开启了根据上游数量的百分比进行预热但没有上游节点的总数，就无法计算每一个预热阶段允许通过的上游节点的最大数量，因此本实施例中通过设置本配置字段来保证在没有获取到第二集合的情况下，仍然可以统计得到上游节点的数量，以执行后续的预热阶段的处理。

sort配置字段用于表示是否根据上游节点的访问量排序确定允许通过的上游节点；当sort配置字段为true(即开启了根据上游节点的访问量排序确定允许通过的上游节点)且本地磁盘有上游节点流量记录(第二集合)时，才会在任意一个预热阶段中根据上游节点流量从大到小放开健康检查。

recordactive配置字段用于表示是否开启上游节点流量记录功能；若本配置字段设置为ture或1，即开启了上游节点流量记录功能，则第一节点会预先统计第二集合并保存在本地硬盘。

recordcron配置字段用于表示记录流量的定时任务的触发时间，本配置字段可以采用cron表达式来表示，cron表达式中从左到右每一位分别表示的为秒、分、时、日期、周、月以及年份，比如上述示例中"0021**？*"表示每天的21点0分0秒。

recordduration配置字段用于表示记录流量的定时任务的持续时间，比如上述示例中的“60”，其单位可以为秒。

recorddir配置字段用于表示上游流量记录所存储的文件，也就是记录或保存第二集合的文件的路径可以为“/home/appops/gateway/nginx.record”。

timeconfig配置字段用于表示预热策略；在预热策略中的“20”“40”以及“60”分别表示每一个预热阶段所对应的预热时长，本示例中具体可以为每一个预热阶段所对应的最大预热时长(或称为higherentry)；“3”“10”以及“20”则为每一个预热阶段分别对应的数量相关信息，在percent配置字段为true(即开启了根据上游数量的百分比进行预热)时数量相关信息的值为百分比，否则为绝对数量。第一节点可以根据当前预热已用时长从上述预热策略中确定其对应的最大预热时长(即higherentry)，进而确定当前预热阶段允许通过的上游节点的最大数量。如果根据当前预热已用时长从上述预热策略中确定其对应的最大预热时长为空，则第一节点可以确定当前预热完成。

示例性的，对本实施例中第一节点处于n个预热阶段中的第i个预热阶段的情况下，接收到任意一个上游节点即第二节点发来的健康询问请求的时候第一节点进行处理进行说明，首先针对代码中包含的相关字段进行定义：

serveralive字段表示第一节点的初始化处理是否完成，“！serveralive”表示第一节点的初始化处理未完成；

nginxpreheatactive字段表示第一节点的预热功能是否关闭；

preheatcomplete字段表示第一节点的预热是否完成；

config字段表示第一节点配置的预热策略；

whitefrontendset字段表示第一节点的当前第i个预热阶段对应的候选上游节点集合；

sortedips字段表示第一节点的初始化处理时读入的上游节点集合即第二集合，该第二集合根据上游节点的访问量从大到小的顺序已排序；

tmpips字段表示第一节点的所有上游的ip集合即第一集合。

基于上述代码中包含的相关字段的说明，对本实施例中第一节点处于n个预热阶段中的第i个预热阶段的情况下，接收到任意一个上游节点即第二节点发来的健康询问请求的时候第一节点进行处理的代码进一步示例性的说明如下：

本实施例中所述第一节点在n个预热阶段中的任意一个预热阶段均采用以上方式进行处理，在第一节点完成全部n个预热阶段的处理之后所述第一节点上线。结合图2，对系统中新启动的一个服务节点即第一节点在n个预热阶段中的第i个预热阶段的处理做示例性说明，第一节点上游会有多个上游节点，比如图2上下方中示意出的4个nginx节点(分别为nginx1～nginx4)均为第一节点的上游节点。第一节点在n个预热阶段中的第i个预热阶段中，只对全部上游节点中的部分上游节点发来的健康询问请求(又或者称为健康检查)反馈第一类状态码(如200状态码)，对其余上游节点的健康询问请求均反馈第二类状态码(如403状态码)。比如，n为3，图2中上下两侧分别示意出i为1以及i为2两个预热阶段的处理，图2上方为i为1，也就是第一个预热阶段中，第一节点仅允许通过1个上游节点(即图2上方的nginx1)，因此在图2上方中第一节点接收到nginx1发来的健康询问请求的时候，返回200，而针对其他ngnix的健康询问请求第一节点均反馈403。图2下方为第二个预热阶段，第一节点允许通过2个上游节点，分别为图2下方的nginx1、nginx3，因此，图2下方示意中第一节点接收到nginx1以及nginx3发来的健康询问请求的时候，返回200，而针对其他ngnix的健康询问请求第一节点均反馈403。如此执行直至完成3个预热阶段的处理之后第一节点上线。

在所述第一节点上线后，所述第一节点仍然可以在任意时刻接受上游节点发来的健康询问请求，在第一节点接收到任意一个上游节点发来的健康询问请求的时候均向上游节点反馈第一类状态码。还需要指出的是，第一节点成功上线之后，可以接收任意上游节点发来的业务请求并对该业务请求进行后续处理，这里不对第一节点处理业务请求的方式进行详细说明。

另外，在第一节点确定下线的时候，还可以包括：在所述第一节点确定下线的情况下，若所述第一节点接收到第三节点发来的健康询问请求，则所述第一节点向所述第三节点发送第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态；所述第三节点为所述第一节点的上游节点中之一。

其中，所述第三节点与前述实施例中的第二节点可以相同也可以不同。

关于第一节点是否确定下线可以根据实际情况来确定，比如可以人为设置第一节点下线，又或者，可以是通过部署节点通知第一节点进行下线等等，这里不对其进行穷举。本实施例仅重点关注第一节点确定下线之后的处理，也就是，第一节点确定下线之后，会向所有发来健康询问请求的上游节点均反馈第二类状态码，以通知上游节点当前不进行任何业务请求的处理。还需要理解的是，第一节点确认下线的时候，可能会存在部分未完成处理的历史业务请求，第一节点会在完成全部历史业务请求的处理之后完成下线。

这样，上游节点通过向下游节点即第一节点发送健康询问请求以进行健康检查，从而可以使得上游节点及时发现有问题的或下线的下游节点并及时剔除，极大减少服务端受损时间。并且健康检查还能帮助服务端实现优雅上下线。并且第一节点在最终下线前会通过向发来健康询问请求的上游节点均反馈第二类状态码以将自己的状态设置为已下线从而使上游节点不再继续发送请求，然后处理完当前堆积的历史业务请求后再销毁资源和结束进程，从而做到无损发布。

另外，以上仅针对第一节点在初始化处理、预热阶段、上线以及下线的处理中与上游节点(即第二节点或第三节点)之间的交互进行了说明，实际处理中，第一节点除了与上游节点进行交互之外还会与部署节点进行交互，具体说明如下：

所述第一节点接收到部署节点发来的上线请求；

在所述第一节点满足第二预设条件的情况下，所述第一节点向所述部署节点反馈上线成功状态码；

其中，所述第二预设条件包括：所述第一节点预热功能开启且预热完成；或者，所述第一节点预热功能关闭。

其中，所述预热完成的确定方式可以包括：所述第i个预热阶段允许通过的上游节点的最大数量为空的情况下，确定预热完成；或者，可以是当前预热已用时长超过预热策略中的最大预热时长。

所述第一节点进行初始化处理的过程中，所述第一节点与部署节点的交互可以包括：所述第一节点进行初始化处理的过程中，若接收到所述部署节点发来的访问检查接口的请求，则向所述部署节点发送连接拒绝信息。也就是说，在第一节点进行初始化处理的过程中，未完成绑定对应的tcp接口，因此对部署节点发来的全部的访问检查接口的请求均反馈连接拒绝信息。

在所述第一节点完成初始化处理的情况下，所述第一节点若接收到所述部署节点发来的访问检查接口的请求，则向所述部署节点反馈连接成功的信息。

进一步地，部署节点在接收到第一节点针对访问检查接口的请求反馈的连接成功的信息的情况下，可以开始向所述第一节点发送上线请求；相应的，所述第一节点在确定初始化完成、第一次接收到所述部署节点发来的上线请求的情况下，所述第一节点确定进入预热阶段。

需要理解的是，部署节点发送上线请求给第一节点，且所述第一节点处于预热状态的情况下，所述第一节点向所述部署节点反馈上线不成功状态码(或上线失败状态码)。

其中，所述上线成功状态码以及上线失败状态码可以根据实际情况进行设定，比如上线成功状态码可以为2xx状态码或者203状态码；上线失败状态码可以为403状态码或4xx状态码。

示例性的，针对第一节点在接收到部署节点发来的上线请求之后的处理逻辑进行说明，需要理解的是，以下代码中的相关字段的定义与前述实施例中第一节点处理第二节点发来的健康询问请求的相关代码中的定义是相同的只是不做赘述，具体说明如下：

最后，结合图3，对本实施例中第一节点初始化处理以及预热的过程中与上游节点(如图3中的nginx表示第一节点的全部上游节点)和与部署节点之间的交互进行示例性说明：

部署节点在第一节点的检查阶段会不断访问第一节点的check(检查)接口，也就是如图3中所示部署节点向第一节点发送访问检查接口的请求(或称为访问check接口)；此时，由于第一节点处于初始化处理中，也就是初始化未完成，没有绑定对应的tcp端口，所以这时的第一节点向部署节点均反馈连接拒绝信息(或称为connectionrefused)。

当第一节点初始化完成，也就是第一节点bind(绑定)对应的tcp端口后，若接收到部署节点发来的访问检查接口的请求，则向部署节点反馈连接成功信息(或success)。在第一节点初始化完成进入预热阶段之前，所述第一节点对所有上游节点nginx的健康询问请求均反馈第二类状态码即健康检查失败(或表示处于不处理业务请求的状态)，相应的，不会有任何上游节点将业务请求发送到第一节点上。

部署节点接收到第一节点发来的连接成功信息之后进入第一节点的上线(online)阶段。相应的，部署节点向第一节点发online(上线)请求(或称为访问上线接口的请求)，第一节点进入预热阶段(即前述n个预热阶段)，由于第一节点未完成预热，因此第一节点向部署节点反馈上线失败状态码(即图3中所示的403状态码)。当第一节点进入预热阶段后，可以对部分nginx节点发来的健康询问请求反馈第一类状态码200(即健康检查成功，或表示处于能够处理对应上游节点的业务请求的状态)，相应的，上述第一节点可以接收并处理这部分nginx发来的业务请求，在预热阶段中，第一节点可以用这些少量的真实请求完成预热，由于压力小，即使启动的时候性能较差，第一节点也能正常提供服务不影响用户体验。

第一节点预热完成后，第一节点对全部上游节点nginx均反馈第一类状态码，以表征第一节点的健康检查全部成功即处于能够处理业务请求的状态，第一节点正常提供服务。另外，在第一节点预热完成后，若接收到部署节点发来的上线请求，则向部署节点反馈上线成功状态码(比如可以为203，或图3中所示的success)，相应的，部署节点认为该第一节点发布完成，可以去继续发布下一批节点。需要指出的是，当部署节点按批发布时，必须等上一批服务节点都发布成功才能进入下一批发布。不然可能会造成多批节点都处于发布或预热状态，使得未在发布状态的节点承受过多流量。

可见，本实施例通过在第一节点处于在n个预热阶段中的第i个预热阶段的情况下，根据第i个预热阶段对应的候选上游节点集合，确定是否向发来健康询问请求的第二节点即任意一个上游节点反馈第一类状态码以指示该第一节点当前处于可以处理该上游节点的业务请求的状态；由于第i个预热阶段的候选上游节点集合中包含的候选上游节点的数量是小于第一节点的上游节点的数量的，因此第一节点在任意一个预热阶段仅会向部分上游节点反馈第一类状态码，进而可以基于这部分上游节点的真实业务请求执行预热。如此，可以避免现有技术中采用虚拟流量进行预热所带来的预热效果较差、依赖数据库或缓存等服务所带来的流量冲击等额外负担以及由于保存虚拟流量所带来的存储资源的开销较大等问题；并且由于本实施例提供的方案可以使得第一节点采用上游节点的真实业务请求进行预热，因此不需要考虑数据污染等问题，保证了预热的效果；此外，由于在预热阶段中对当前允许通过的上游节点的数量进行限制，因此上游节点的变更不会对第一节点的预热效果产生影响，也进一步保证了预热的效果。

本公开的第二个方面提供一种节点处理方法，如图4所示，包括：

s401：第二节点向第一节点发送健康询问请求；其中，所述第二节点为所述第一节点的上游节点中之一；

s402：所述第二节点接收所述第一节点反馈的状态码；

s403：在所述第一节点反馈的状态码为第一类状态码的情况下，所述第二节点确定所述第一节点处于能够处理所述第二节点的业务请求的状态。

本实施例可以应用于第二节点，该第二节点可以为第一节点的任意一个上游节点。

上述s401中，所述第二节点向第一节点发送健康询问请求，可以包括：所述第二节点在所述第一节点对应的第j个询问时间间隔向所述第一节点发送第j个健康询问请求；其中，j为大于等于1的整数。

也就是说，第二节点可以是周期性向第一节点发送健康询问请求的；所述询问时间间隔可以根据实际情况进行设置，比如可以为1秒(s)。

相应的，s402中，所述第二节点接收所述第一节点反馈的状态码，可以包括：所述第二节点接收所述第一节点针对所述第j个健康询问请求反馈的状态码。

也就是说，第二节点在每次向第一节点发送健康询问请求的时候，均会接收到第一节点针对该次发送的健康询问请求反馈的状态码。

s403中，在所述第一节点反馈的状态码为第一类状态码的情况下，所述第二节点确定所述第一节点处于能够处理所述第二节点的业务请求的状态，包括：

在所述第一节点针对连续l个健康询问请求反馈的状态码为第一类状态码的情况下，确定所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述l个健康询问请求中包含所述第j个健康询问请求；l为大于等于2的整数。

其中，所述第一节点针对连续l个健康询问请求反馈的状态码为第一类状态码，指的是，所述第一节点针对连续l个健康询问请求反馈的状态码均为第一类状态码。这里，关于第一类状态码的定义与前述第一个方面实施例中的说明相同，可以根据实际情况设置，比如可以是2xx或者可以是203。

l可以根据实际情况设置，比如，可以将l设置为2，或者可以为3。

举例来说，第二节点在连续2个询问时间间隔向第一节点发送健康询问请求，第一节点针对这连续的2个健康询问请求的反馈均为第一类状态码的情况下，所述第二节点可以确认第一节点健康检查成功，也就是第一节点可以接收第二节点发送的业务请求。

需要指出的是，在完成上述s403之后，第二节点可以在需要向第一节点发送业务请求的时候将该业务请求发送至第一节点，以使得第一节点基于第二节点发送的真实的业务请求进行预热。

另外，还可以包括：在所述第一节点针对连续r个健康询问请求反馈的状态码为第二类状态码的情况下，所述第二节点在第j+1个询问时间间隔向所述第一节点发送第j+1个健康询问请求；其中，所述r个健康询问请求中包含所述第j个健康询问请求；r为大于等于2的整数。

其中，所述第一节点针对连续r个健康询问请求反馈的状态码为第二类状态码，指的是，所述第一节点针对连续r个健康询问请求反馈的状态码均为第二类状态码。这里，关于第二类状态码的定义与前述第一个方面实施例中的说明相同，可以根据实际情况设置，比如可以是4xx或者可以是400。

r可以根据实际情况设置，比如，可以将r设置为3，或者可以为4，或更多或更少，这里不进行穷举。

举例来说，第二节点在连续3个询问时间间隔向第一节点发送健康询问请求，第一节点针对这连续的3个健康询问请求的反馈均为第二类状态码的情况下，所述第二节点可以确认第一节点健康检查失败，也就是第一节点不接收第二节点发送的业务请求，第二节点也就不会向第一节点发送业务请求，而是继续在下一个询问时间间隔向第一节点再次发送健康询问请求。

也就是说，所述第二节点判断所述第一节点针对连续l个健康询问请求反馈的状态码是否均为第一类状态码，若是，则执行s403；

否则，所述第二节点判断所述第一节点针对连续r个健康询问请求反馈的状态码是否均为第二类状态码；在所述第一节点针对连续r个健康询问请求反馈的状态码为第二类状态码的情况下，所述第二节点在第j+1个询问时间间隔向所述第一节点发送第j+1个健康询问请求；其中，所述r个健康询问请求中包含所述第j个健康询问请求；r为大于等于2的整数。

示例性的，第二节点中执行上述处理的相关代码可以包括：

“checkinterval＝1000rise＝2fall＝3timeout＝1000type＝httpdefault_down＝false；

check_http_send"head/health/statushttp/1.0\r\n\r\n"；

check_http_expect_alivehttp_2xxhttp_3xx；”

其中，“interval＝1000”表示第二节点(比如可以为nginx)轮询(或周期性询问)下游健康状态的询问时间间隔为1000毫秒即1秒；“rise＝2”表示连续两次反馈第一类状态码表示健康检查成功即能够向第一节点发送业务请求；“fall＝3”表示连续3次反馈第二类状态码表示健康检查失败不能够向第一节点发送业务请求；“timeout＝1000”表示反馈超时的最大时长为1秒；“type＝http”表示请求类型为http请求；“default_down＝false”表示默认状态为失败(也就是健康检查失败不能向第一节点发送业务请求)；“check_http_send"head/health/statushttp/1.0\r\n\r\n"”表示健康询问请求的具体内容；“check_http_expect_alivehttp_2xxhttp_3xx”表示返回状态码为2xx或3xx认为健康检查成功，也就是说返回其他状态码或超时或连接拒绝等认为健康检查失败。

可见，本实施例通过在第一节点处于在预热阶段中，只有在上游节点接收到第一节点针对健康询问请求反馈第一类状态码的情况下才可以向第一节点发送业务请求。如此，可以避免现有技术中不采用真实流量进行预热所带来的预热效果较差、依赖数据库或缓存等服务所带来的流量冲击以及由于流量记录所带来的存储资源的开销较大等问题；并且由于本实施例提供的方案可以使得第一节点采用上游节点的真实业务请求进行预热，因此不需要考虑数据污染等问题，保证了预热的效果；此外，由于在预热阶段中对当前允许通过的上游节点的数量进行限制，因此上游节点的变更不会对第一节点的预热效果产生影响，也进一步保证了预热的效果。

示例性系统

在介绍了本公开示例性实施方式的方法之后，接下来，对本公开示例性实施方式的节点处理系统进行说明。

本公开的第三个方面提供一种节点处理系统，参考图5，包括：一种节点处理系统，包括：第一节点51、第二节点52；其中，

所述第一节点51，用于处于n个预热阶段中的第i个预热阶段的情况下，接收第二节点发来的健康询问请求；其中，n为大于等于2的整数，i为大于等于1且小于等于n的整数；所述第二节点为所述第一节点的上游节点中之一；在所述第i个预热阶段对应的候选上游节点集合中包含所述第二节点的情况下，向所述第二节点发送第一类状态码；其中，所述第一类状态码用于指示所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于所述第一节点的上游节点的数量；

所述第二节点52，用于向第一节点发送健康询问请求；其中，所述第二节点为所述第一节点的m个上游节点中之一；m为大于等于1的整数；接收所述第一节点反馈的状态码；在所述第一节点反馈的状态码为第一类状态码的情况下，确定所述第一节点处于能够处理所述第二节点的业务请求的状态。

所述系统还包括：部署节点53；其中，

所述部署节点53，用于向第一节点发送上线请求，在接收到所述第一节点反馈的上线成功状态码的情况下，确定所述第一节点上线成功；

所述第一节点51，用于接收所述部署节点发来的上线请求，在满足第二预设条件的情况下，向所述部署节点反馈上线成功状态码；其中，所述第二预设条件包括：所述第一节点预热功能开启且预热完成；或者，所述第一节点预热功能关闭。

所述部署节点53，还用于向第一节点发送访问检查接口的请求；所述第一节点51，具体用于进行初始化处理的过程中，若接收到所述部署节点发来的访问检查接口的请求，则向所述部署节点发送连接拒绝信息。

所述第一节点51，具体用于完成初始化处理的情况下，若接收到所述部署节点发来的访问检查接口的请求，则向所述部署节点反馈连接成功的信息。部署节点53，还用于在接收到第一节点针对访问检查接口的请求反馈的连接成功的信息的情况下，可以开始向所述第一节点发送上线请求。

其中，所述上线成功状态码以及上线失败状态码可以根据实际情况进行设定，比如上线成功状态码可以为2xx状态码或者203状态码；上线失败状态码可以为403状态码或4xx状态码。

所述部署节点53，还用于在确定当前部署批次包含的待部署节点全部上线成功的情况下，确定下一个部署批次包含的待部署节点；其中，所述当前部署批次包含的待部署节点包括所述第一节点。

也就是说，部署节点可以按批发布节点，所述部署节点须等上一批服务节点都发布成功才能进入下一批发布。

本实施例中第一节点、第二节点以及部署节点的具体处理与前述第一方面以及第二方面的实施例中的处理相同，因此不做重复说明。

可见，本实施例通过在第一节点处于在n个预热阶段中的第i个预热阶段的情况下，根据第i个预热阶段对应的候选上游节点集合，确定是否向发来健康询问请求的第二节点即任意一个上游节点反馈第一类状态码以指示该第一节点当前处于可以处理该上游节点的业务请求的状态；由于第i个预热阶段的候选上游节点集合中包含的候选上游节点的数量是小于第一节点的上游节点的数量的，因此第一节点在任意一个预热阶段仅会向部分上游节点反馈第一类状态码，进而可以基于这部分上游节点的真实业务请求执行预热。如此，可以避免现有技术中不采用真实流量进行预热所带来的预热效果较差、依赖数据库或缓存等服务所带来的流量冲击以及由于流量记录所带来的存储资源的开销较大等问题；并且由于本实施例提供的方案可以使得第一节点采用上游节点的真实业务请求进行预热，因此不需要考虑数据污染等问题，保证了预热的效果；此外，由于在预热阶段中对当前允许通过的上游节点的数量进行限制，因此上游节点的变更不会对第一节点的预热效果产生影响，也进一步保证了预热的效果。

示例性介质

在介绍了本公开示例性实施方式的方法之后，接下来，参考图6对本公开示例性实施方式的介质进行说明。

在一些可能的实施方式中，本公开的各个方面还可以实现为一种计算机可读介质，其上存储有程序，当程序被处理器执行时用于实现本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的节点处理方法中的步骤。

具体地，上述处理器执行上述程序时用于实现如下步骤：

在第一节点处于n个预热阶段中的第i个预热阶段的情况下，所述第一节点接收第二节点发来的健康询问请求；其中，n为大于等于2的整数，i为大于等于1且小于等于n的整数；所述第二节点为所述第一节点的上游节点中之一；

在所述第i个预热阶段对应的候选上游节点集合中包含所述第二节点的情况下，所述第一节点向所述第二节点发送第一类状态码；其中，所述第一类状态码用于指示所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于所述第一节点的上游节点的数量。

以及，

第二节点向第一节点发送健康询问请求；其中，所述第二节点为所述第一节点的上游节点中之一；

所述第二节点接收所述第一节点反馈的状态码；

在所述第一节点反馈的状态码为第一类状态码的情况下，所述第二节点确定所述第一节点处于能够处理所述第二节点的业务请求的状态。

需要说明的是：上述的介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于：电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。

如图6所示，描述了根据本公开的实施方式的介质600，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序，并可以在设备上运行。然而，本公开不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于：电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络—包括局域网(lan)或广域网(wan)—连接到用户计算设备。

示例性装置

在介绍了本公开示例性实施方式的方法之后，接下来，对本公开示例性实施方式的装置进行说明。

本公开的第四个方面提供一种第一节点，如图7所示，包括：

第一接口单元71，用于在处于n个预热阶段中的第i个预热阶段的情况下，接收第二节点发来的健康询问请求；其中，n为大于等于2的整数，i为大于等于1且小于等于n的整数；所述第二节点为所述第一节点的上游节点中之一；

第一处理单元72，用于在所述第i个预热阶段对应的候选上游节点集合中包含所述第二节点的情况下，控制通过所述第一接口单元向所述第二节点发送第一类状态码；其中，所述第一类状态码用于指示所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于所述第一节点的上游节点的数量。

在本公开的一个实施例中，所述第一处理单元71，用于在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，控制通过所述第一接口单元向所述第二节点发送第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态。

在本公开的一个实施例中，所述第一处理单元71，用于在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若所述第一节点满足第一预设条件，则将所述第二节点的地址相关信息添加至第一集合，控制通过所述第一接口单元72向所述第二节点反馈所述第二类状态码。

在本公开的一个实施例中，所述第一预设条件，包括：

开启了根据上游数量的百分比进行预热、关闭了根据上游节点的访问量排序确定允许通过的上游节点以及当前预热已用时长小于进行上游流量统计的等待时长；

或者，开启了根据上游数量的百分比进行预热、第二集合为空以及当前预热已用时长小于进行上游流量统计的等待时长；其中，所述第二集合为所述第一节点读取的按照预设访问量顺序排序的所述第一节点的上游节点集合。

在本公开的一个实施例中，所述第一处理单元71，用于在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若关闭了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于所述第二节点的地址相关信息更新所述第i个预热阶段对应的候选上游节点集合得到所述第i个预热阶段对应的更新后的候选上游节点集合，控制通过所述第一接口单元72向所述第二节点反馈第一类状态码。

在本公开的一个实施例中，所述第一处理单元71，用于在所述第i个预热阶段对应的候选上游节点集合中不包含所述第二节点的情况下，若开启了根据上游节点的访问量排序确定允许通过的上游节点且所述第i个预热阶段对应的候选上游节点集合中的候选上游节点的数量小于第i个预热阶段允许通过的上游节点的最大数量，则所述第一节点基于第二集合中的至少一个上游节点更新所述第i个预热阶段对应的候选上游节点集合，得到所述第i个预热阶段对应的更新后的候选上游节点集合；

其中，所述第二集合为所述第一节点读取的按照预设访问量顺序排序的所述第一节点的上游节点集合。

在本公开的一个实施例中，所述第一处理单元71，用于执行以下之一：

在所述第i个预热阶段对应的更新后的候选上游节点集合包含所述第二节点的情况下，控制通过所述第一接口单元向所述第二节点反馈第一类状态码；

在所述第i个预热阶段对应的更新后的候选上游节点集合不包含所述第二节点的情况下，控制通过所述第一接口单元向所述第二节点反馈第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态。

在本公开的一个实施例中，所述第一处理单元71，用于在所述第一节点基于当前预热已用时长确定进入所述n个预热阶段的所述第i个预热阶段的情况下，基于预热策略确定所述第i个预热阶段对应的候选上游节点集合；

其中，所述预热策略中包含所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息。

在本公开的一个实施例中，所述第一处理单元71，用于基于所述预热策略中的所述第i个预热阶段对应的候选上游节点的数量相关信息，确定所述第i个预热阶段对应的候选上游节点的待添加数量；基于所述候选上游节点的待添加数量确定所述第i个预热阶段对应的候选上游节点；基于所述第i个预热阶段对应的候选上游节点，确定所述第i个预热阶段对应的候选上游节点集合。

在本公开的一个实施例中，所述第一处理单元71，用于在确定进入所述n个预热阶段中的第一个预热阶段的情况下，基于预热策略确定所述n个预热阶段分别对应的候选上游节点集合；

其中，所述预热策略中包含所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息。

在本公开的一个实施例中，所述第一处理单元71，用于基于当前预热已用时长以及预热策略中包含的所述n个预热阶段分别对应的预热时长以及候选上游节点的数量相关信息，确定所述第i个预热阶段所对应的第一数值；基于所述第一数值，确定第i个预热阶段允许通过的上游节点的最大数量。

在本公开的一个实施例中，所述第一处理单元71，用于执行以下之一：

在关闭了根据上游数量的百分比进行预热的情况下，将所述第一数值作为所述第i个预热阶段允许通过的上游节点的最大数量；

在开启了根据上游数量的百分比进行预热的情况下，基于所述第一数值确定所述第i个预热阶段所对应的百分比，基于所述百分比以及所述第一节点所对应的上游节点的数量确定所述第i个预热阶段允许通过的上游节点的最大数量。

在本公开的一个实施例中，所述第一处理单元71，用于在所述第一节点确定下线的情况下，若通过第一接口单元接收到第三节点发来的健康询问请求，则控制通过所述第一接口单元72向所述第三节点发送第二类状态码；其中，所述第二类状态码用于指示所述第一节点处于不处理业务请求的状态；所述第三节点为所述第一节点的上游节点中之一。

在本公开的一个实施例中，所述第一节点还包括：

第二接口单元73，用于接收到部署节点发来的上线请求；

所述第一处理单元71，还用于在所述第一节点满足第二预设条件的情况下，控制通过所述第二接口单元向所述部署节点反馈上线成功状态码；

其中，所述第二预设条件包括：所述第一节点预热功能开启且预热完成；或者，所述第一节点预热功能关闭。

本公开实施例的第五方面提供一种第二节点，如图8所示，包括：

第三接口单元81，用于向第一节点发送健康询问请求；其中，所述第二节点为所述第一节点的上游节点中之一；接收所述第一节点反馈的状态码；

第二处理单元82，用于在所述第一节点反馈的状态码为第一类状态码的情况下，确定所述第一节点处于能够处理所述第二节点的业务请求的状态。

在本公开的一个实施例中，所述第三接口单元81，用于在所述第一节点对应的第j个询问时间间隔向所述第一节点发送第j个健康询问请求；其中，j为大于等于1的整数；

以及，接收所述第一节点针对所述第j个健康询问请求反馈的状态码。

在本公开的一个实施例中，第二处理单元82，用于在所述第一节点针对连续l个健康询问请求反馈的状态码为第一类状态码的情况下，确定所述第一节点处于能够处理所述第二节点的业务请求的状态；其中，所述l个健康询问请求中包含所述第j个健康询问请求；l为大于等于2的整数。

在本公开的一个实施例中，第二处理单元82，用于在所述第一节点针对连续r个健康询问请求反馈的状态码为第二类状态码的情况下，控制通过所述第三接口单元在第j+1个询问时间间隔向所述第一节点发送第j+1个健康询问请求；其中，所述r个健康询问请求中包含所述第j个健康询问请求；r为大于等于2的整数。

根据本公开实施方式，可以避免现有技术中采用虚拟流量进行预热所带来的预热效果较差、依赖数据库或缓存等服务所带来的流量冲击等额外负担以及由于保存虚拟流量所带来的存储资源的开销较大等问题；并且由于本实施例提供的方案可以使得第一节点采用上游节点的真实业务请求进行预热，因此不需要考虑数据污染等问题，保证了预热的效果；此外，由于在预热阶段中对当前允许通过的上游节点的数量进行限制，因此上游节点的变更不会对第一节点的预热效果产生影响，也进一步保证了预热的效果。

示例性计算设备

在介绍了本公开示例性实施方式的方法、介质和装置之后，接下来，参考图9对本公开示例性实施方式的计算设备进行说明。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施方式中，根据本公开实施方式的计算设备可以至少包括至少一个处理单元以及至少一个存储单元。其中，存储单元存储有程序代码，当程序代码被处理单元执行时，使得处理单元执行本说明书上述“示例性方法”部分中描述的根据本公开的各种示例性实施方式的节点处理方法中的步骤。

下面参照图9来描述根据本公开的这种实施方式的计算设备900。图9显示的计算设备900仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，计算设备900以通用计算设备的形式表现。计算设备900的组件可以包括但不限于：上述至少一个处理单元901、上述至少一个存储单元902，连接不同系统组件(包括处理单元901和存储单元902)的总线903。

总线903包括数据总线、控制总线和地址总线。

存储单元902可以包括易失性存储器形式的可读介质，例如随机存取存储器(ram)9021和/或高速缓存存储器9022，可以进一步包括非易失性存储器形式的可读介质，例如只读存储器(rom)9023。

存储单元902还可以包括具有一组(至少一个)程序模块9024的程序/实用工具9025，这样的程序模块9024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算设备900也可以与一个或多个外部设备904(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(i/o)接口905进行。并且，计算设备900还可以通过网络适配器906与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图9所示，网络适配器906通过总线903与计算设备900的其它模块通信。应当理解，尽管图中未示出，可以结合计算设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了第一节点或第二节点的若干单元/模块或子单元/子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。