云平台高效复用服务器资源的方法、装置以及云平台与流程

本发明涉及一种云平台高效复用服务器资源的方法、装置以及云平台。

背景技术：

随着云计算的普及，云服务平台在现代企业服务中迅速占领市场。与传统企业服务不同使用私有服务器不同，云服务平台提供商会在公有云上搭建具有大量服务器的集群来提供支撑服务，而海量的服务器集群也对企业服务提供商带来了前所未有的成本压力。在通常的做法中，云平台在处理客户的操作请求时，用户的操作请求都会随机的发送到业务逻辑服务器中。由于操作请求的种类较多，对CPU的占有率、内存占有率的要求均不相同，每一类请求有着非常大的差异性，当要处理海量请求时，将要求业务服务器集群中拥有大量的高性能服务器，才能处理高CPU占用率、高内存占用率的请求，这样带来极大的成本。

技术实现要素：

针对上述现有技术的不足，本发明所要解决的技术问题是：提供一种能够提供云平台影响速度、合理利用云平台资源的云平台高效复用服务器资源的方法、装置以及云平台。

为解决上述技术问题，本发明采用的一个技术方案是：提供一种云平台高效复用服务器资源的方法，所述云平台包括至少一Beta/灰度服务器、第一业务服务器集群、第二业务服务器集群以及至少一脚本处理机，所述方法包括以下步骤：

预先建立分类路由规则，将用户侧操作请求预先分为用户可见请求I、用户可见请求II、用户可见慢请求以及用户不可见请求；

接收用户侧的操作请求；

将接收到的用户侧的操作请求与预先分类的四类操作请求进行匹配对比，以确定接收到的操作请求的类别；

当匹配得到接收到的操作请求为用户可见请求I，则根据分类路由规则将该接收到的操作请求路由至第一业务服务器集群；当匹配得到接收到的操作请求为用户可见请求II，则根据分类路由规则将该接收到的操作请求路由至所述脚本处理机中；当匹配得到接收到的操作请求为用户可见慢请求，则根据分类路由规则将该接收到的操作请求路由至所述Beta/灰度服务器；当匹配得到接收到的操作请求为用户不可见请求，则根据分类路由规则将接收到的操作请求路由至第二业务服务器集群。

进一步的：

所述云平台还包括反向代理服务器；

反向代理服务器侧预先建立路由规则；

反向代理服务器接收用户侧的操作请求；

反向代理服务器将接收到的用户侧的操作请求与预先分类的四类操作请求进行匹配对比，以确定接收到的操作请求的类别；

当反向代理服务器匹配得到接收到的操作请求为用户可见请求I，则根据分类路由规则将该接收到的操作请求路由至第一业务服务器集群；当反向代理服务器匹配得到接收到的操作请求为用户可见请求II，则根据分类路由规则将该接收到的操作请求路由至所述脚本处理机中；当反向代理服务器匹配得到接收到的操作请求为用户可见慢请求，则根据分类路由规则将该接收到的操作请求路由至所述Beta/灰度服务器；当反向代理服务器匹配得到接收到的操作请求为用户不可见请求，则根据分类路由规则将接收到的操作请求路由至第二业务服务器集群。

进一步的，所述用户可见请求I为具有均衡的CPU内存占用率的操作请求。

进一步的，所述用户可见请求II为CPU占用率大于第一预设阈值、内存占用率低于第二预设阈值的操作请求。

进一步的所述用户可见慢请求为CPU占用率大于所述第一预设阈值或者内存占用率低于第三阈值的操作请求。

进一步的，所述用户不可见为具有访问量大于第四预设阈值的操作请求。

为解决上述技术问题，本发明采用的另一个技术方案是：提供一种云平台高效复用服务器资源的装置，包括：

分类路由规则建立模块，用于预先将用户侧操作请求预先分类为用户可见请求I、用户可见请求II、用户可见慢请求以及用户不可见请求；

接收模块，用于接收用户侧的操作请求；

匹配模块，用于将接收到的用户侧的操作请求与预先分类的四类操作请求进行匹配对比，以确定接收到的操作请求的类别；

操作请求路由模块，用于当所述匹配模块匹配得到接收到的操作请求为用户可见请求I时，根据分类路由规则将该接收到的操作请求路由至第一业务服务器集群；还用于当所述匹配模块匹配得到接收到的操作请求为用户可见请求II时，根据分类路由规则将该接收到的操作请求路由至所述脚本处理机中；还用于当匹配模块匹配得到接收到的操作请求为用户可见慢请求时，根据分类路由规则将该接收到的操作请求路由至所述Beta/灰度服务器；还用于当所述匹配模块匹配得到接收到的操作请求为用户不可见请求时，则根据分类路由规则将接收到的操作请求路由至第二业务服务器集群。

进一步的，所述用户可见请求I为具有均衡的CPU内存占用率的操作请求；所述用户可见请求II为CPU占用率大于第一预设阈值、内存占用率低于第二预设阈值的操作请求；所述用户可见慢请求为CPU占用率大于所述第一预设阈值或者内存占用率低于第三阈值的操作请求；所述用户不可见为具有访问量大于第四预设阈值的操作请求。

为解决上述技术问题，本发明采用的又一个技术方案是：提供一种云平台，包括：

至少一Beta/灰度服务器；

第一业务服务器集群；

第二业务服务器集群；

至少一脚本处理机；以及

反向代理服务器，所述反向代理服务器包括所述的云平台高效复用服务器资源的装置。

本发明的云平台高效利用服务器资源的方法、装置及云平台，与传统的仅使用业务服务器来处理用户侧的操作请求的方案相比，常用方案服务器作用单一，并且由于用户请求会随机的被路由到任意一台逻辑服务器上，因此对每一台逻辑服务器的性能都有很高的要求。在常用架构中，业务服务器集群需要大量高性能机器才能完成常规请求。而利用本发明的方法、装置及云平台，通过合理复用各种类型的服务器，降低了服务器集群所需求的服务器数量。而通过将不同的请求分类，也降低了单台服务器的性能需求，可以合理的将高性能与低性能服务器搭配，降低服务器成本。在降低成本的同时，甚至带来了更快的响应速度，从而带给用户的体验和满意度。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明云平台高效复用服务器资源的方法第一实施例的流程图。

图2是本发明云平台高效复用服务器资源装置一实施例的方框图。

图3是本发明云平台一实施例的方框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参见图1，图1是本发明云平台高效复用服务器资源的方法一实施例的流程图。所述云平台包括至少一Beta/灰度服务器、至少一脚本处理机、第一业务服务器集群、第二业务服务器集群以及反向代理服务器。本实施例的云平台高效复用服务器资源的方法中，利用云平台闲置时间较多的至少一Beta/灰度服务器、至少一脚本处理机来处理白天时间段的请求，可以分担云平台业务服务器集群的操作请求，减少云平台中业务服务器集群的负荷，加快整个云服务平台的处理速度、给用户带来更多好的体验和满意度。将业务服务器集群分为第一业务服务器集群及第二业务服务器集群，用以分别处理不同类别的用户请求。

本实施例的云服务平台以企业云服务平台为例进行阐述复用服务器资源的方法，在该实施例中，所述Beta/灰度服务器（测试服务器）为两台，所述脚本处理机为两台，所述第一业务服务器集群中的第一服务器以及第二业务服务器集群中的第二服务器均为若干台，例如均为10台等等。可理解的，在其他的实施例中，所述第一业务服务器、第二业务服务器的数量还可以不相同，例如第一业务服务器数量为8台，第二业务服务器数量为5台，不同实例中，根据云平台处理量的大小，Beta/灰度服务器以及脚本处理机的数量也可随实例需求而变化。

所述云平台高效复用服务器资源的方法包括以下步骤：

S101、预先建立分类路由规则，将用户侧操作请求预先分为用户可见请求I、用户可见请求II、用户可见慢请求以及用户不可见请求；具体在反向代理服务器侧建立分类路由规则；

一、所述用户可见请求I可以为具有均衡的CPU内存占用率或占用量的操作请求。该类请求通常用于完成大部分业务逻辑，用户需要该类请求快速返回。因此在建立分类路由规则的步骤中，将该用户可见请求I路由至第一服务器集群中。根据该类请求的性质、对CPU及内存的要求建立规则，将该类请求对应路由至第一业务服务器集群，该第一业务服务器集群需要完成全量功能，这类请求的请求量大需要极高的响应速度，因此会只处理用户可见请求1，利用第一业务服务器集群和第二业务服务器集群将所有高资源消耗和高访问量请求进行隔离，保证相应速度。

二、所述用户可见请求II可以是CPU占用率大于第一预设阈值、且内存占用率低于第二预设阈值的操作请求。该类请求用于完成特定业务逻辑，用户需要快速返回。因此，在建立分类路由规则的步骤中，将该用户可见请求II路由至脚本处理机中，由于脚本处理服务器一般只在特定时刻处理海量数据的分析与统计。因为资源限制，一般这类脚本会在凌晨进行处理。而在云服务平台访问峰值的白天段，这类服务器将会处于闲置状态。因此可以将特定操作请求路由到这类服务器，来充分利用资源进行处理。

本实施例中，所述CPU占用率大于第一预设阈值的操作请求被称为高CPU占用率的操作请求，所述内存占用率低于第二阈值的操作请求被称为低内存占用率的操作请求。所述第一预设阈值可以如此设定：单次操作请求处理时间大于2秒、且CPU占用率高于10%；第二预设阈值可以设定为3%。在其他的实施例中，也可以将内存占用率变换为内存占用量低于第二预设阈值，当所述内存占用量低于第二预设阈值时，该第二预设阈值可以被设定为50M左右。还可理解的，在不同的实施例中，根据业务服务器的配置、CPU处理能力的高低、内存的大小，第一预设阈值、第二预设阈值均可根据不同的服务器配置而变化。

具体结合实例，该用户可见请求II例如可以假设为：当用户需要通过本云平台展示的网页上创建单据，并且将该创建的单据转换为图片或者PDF，由于服务器将当前显示的页面转换为对应的PDF或其他格式，该请求所占用的CPU负载非常高、需要响应快，但工作量并不大，这种情况则可视为用户可见请求II。

三、所述用户可见慢请求可以为CPU占用率大于第一预设阈值或者内存占用率或占用量大于第三阈值的操作请求。该类请求通常用于完成特定的业务逻辑，占用大量的CPU或内存。用户需要该类请求立刻返回，但是对速度的期望值较低，并且请求量不大。因此，在建立分类路由规则的步骤中，将该用户可见慢请求路由至Beta/灰度服务器中，该Beta/灰度服务器进行本职工作时（即处理测试时），请求量较低，而且使用频率极低，只有在版本发布前才有使用需求。在大部分情况下，这类Beta/灰度服务器将处于闲置状态。因此我们会将上述用户可见慢请求路由到这类机器以进行复用。因为这类服务器一般只有内部人员使用，而且使用频次较低，因此在空闲状态时，处理同样低频次高资源占用的服务。

所述第一阈值的设定参见上述设定规则，当所述内存占用率大于第三阈值时，该第三阈值可以如此设定：单次请求的内存占用率大于6%。当判断条件为内存占用量时，该第三阈值可以如此设定：单次请求的内存占用率大于100M。在不同的实施例中，内存占用量的第三阈值、内存占用率的第三阈值可以根据不同实例进行设定，此处的举例说明并不用于限制本发明的保护范围。

在一些实施例中，所述用户可见慢请求还可以为CPU占用率大于第一预设阈值或者内存占用率或占用量大于第三阈值的操作请求且持续时间超过第五预设阈值（例如2秒等）时的操作请求。

具体结合实例，用户可见慢请求例如可以假设为：企业用户需要导入客户资料（例如上传EXCEL表格），服务器需要对导入的EXCEL表格进行解析，分析出表格的行列及相关数据，这类操作需要占用大量CPU或内存以及一定时间，那么该类请求则被视为上述用户可见慢请求。

四、所述用户不可见请求可以为具有访问量大于第四预设阈值的操作请求。这类请求通常用于数据收集和统计，具有非常高的访问量。然而因为对用户不可见，这类请求对响应速度并无要求。因此，在建立分类路由规则的步骤中，将该用户可见慢请求路由至第二业务服务器集群中，该第二业务服务器集群中每一服务器只需要处理用户不可见请求，因此只需要少量能够保持高连接量的机器，进行排队处理即可。将该类用户不可见请求与用户可见请求I隔离开，可以保证用户可见请求I不会因为用户不可见请求的数量而被延后处理。

具体结合实例，例如企业邮件服务器中，企业客户邮箱每次新收一封邮件时，邮箱内的收件箱内的未读邮件自动叠加1，因此需要每隔预定时间（例如5秒）访问一次 服务器，以实时更新未读邮件数量。

S102、反向代理服务器接收用户侧的操作请求；

例如接收用户侧发送邮件的操作请求、打开网页的操作请求等等。

S103、反向代理服务器将接收到的用户侧的操作请求与预先分类的四类操作请求进行匹配对比，以确定接收到的操作请求的类别；

本步骤中，按照上述预先建立的分类规则，识别用户侧的操作请求为四类中的哪一类请求。

S104、当反向代理服务器匹配得到接收到的操作请求为用户可见请求I，则根据分类路由规则将该接收到的操作请求路由至第一业务服务器集群；当反向代理服务器匹配得到接收到的操作请求为用户可见请求II，则根据分类路由规则将该接收到的操作请求路由至所述脚本处理机中；当反向代理服务器匹配得到接收到的操作请求为用户可见慢请求，则根据分类路由规则将该接收到的操作请求路由至所述Beta/灰度服务器；当反向代理服务器匹配得到接收到的操作请求为用户不可见请求，则根据分类路由规则将接收到的操作请求路由至第二业务服务器集群。

本发明实施方式，与传统的仅使用业务服务器来处理用户侧的操作请求的方案相比，常用方案服务器作用单一，并且由于用户请求会随机的被路由到任意一台逻辑服务器上，因此对每一台逻辑服务器的性能都有很高的要求。在常用架构中，业务服务器集群需要大量高性能机器才能完成常规请求。而利用本实施方式的方法，通过合理复用各种类型的服务器，降低了服务器集群所需求的服务器数量。而通过将不同的请求分类，也降低了单台服务器的性能需求，可以合理的将高性能与低性能服务器搭配，降低服务器成本。在降低成本的同时，甚至带来了更快的响应速度，从而带给用户的体验和满意度。

请参见图2，图2是本发明云平台高效复用服务器资源的装置一实施例的方框图。本实施例的云平台高效复用服务器资源的装置内置于反向代理服务器内，包括：

分类路由规则建立模块，用于预先将用户侧操作请求预先分类为用户可见请求I、用户可见请求II、用户可见慢请求以及用户不可见请求；

接收模块，用于接收用户侧的操作请求；

匹配模块，用于将接收到的用户侧的操作请求与预先分类的四类操作请求进行匹配对比，以确定接收到的操作请求的类别；

操作请求路由模块，用于当所述匹配模块匹配得到接收到的操作请求为用户可见请求I时，根据分类路由规则将该接收到的操作请求路由至第一业务服务器集群；还用于当所述匹配模块匹配得到接收到的操作请求为用户可见请求II时，根据分类路由规则将该接收到的操作请求路由至所述脚本处理机中；还用于当匹配模块匹配得到接收到的操作请求为用户可见慢请求时，根据分类路由规则将该接收到的操作请求路由至所述Beta/灰度服务器；还用于当所述匹配模块匹配得到接收到的操作请求为用户不可见请求时，则根据分类路由规则将接收到的操作请求路由至第二业务服务器集群。其中：

一、所述用户可见请求I可以为具有均衡的CPU内存占用率或占用量的操作请求。该类请求通常用于完成大部分业务逻辑，用户需要该类请求快速返回。因此在建立分类路由规则的步骤中，将该用户可见请求I路由至第一服务器集群中。根据该类请求的性质、对CPU及内存的要求建立规则将，将该类请求对应路由至第一业务服务器集群，该第一业务服务器集群需要完成全量功能，这类请求的请求量大需要极高的响应速度，因此会只处理用户可见请求1，利用第一业务服务器集群和第二业务服务器集群将所有高资源消耗和高访问量请求进行隔离，保证相应速度。

二、所述用户可见请求II可以是CPU占用率大于第一预设阈值、且内存占用率低于第二预设阈值的操作请求。该类请求用于完成特定业务逻辑，用户需要快速返回。因此，在建立分类路由规则的步骤中，将该用户可见请求II路由至脚本处理机中，由于脚本处理服务器一般只在特定时刻处理海量数据的分析与统计。因为资源限制，一般这类脚本会在凌晨进行处理。而在云服务平台访问峰值的白天段，这类服务器将会处于闲置状态。因此可以将特定操作请求路由到这类服务器，来充分利用资源进行处理。

本实施例中，所述CPU占用率大于第一预设阈值的操作请求被称为高CPU占用率的操作请求，所述内存占用率低于第二阈值的操作请求被称为低内存占用率的操作请求。所述第一预设阈值可以如此设定：单次操作请求处理时间大于2秒、且CPU占用率高于10%；第二预设阈值可以设定为3%。在其他的实施例中，也可以将内存占用率变换为内存占用量低于第二预设阈值，当所述内存占用率低于第二预设阈值时，该第二预设阈值可以被设定为50M左右。还可理解的，在不同的实施例中，根据业务服务器的配置、CPU处理能力的高低、内存的大小，第一预设阈值、第二预设阈值均可根据不同的服务器配置而变化。

具体结合实例，该用户可见请求II例如可以假设为：当用户需要通过本云平台展示的网页上创建单据，并且将该创建的单据转换为图片或者PDF，由于服务器将当前显示的页面转换为对应的PDF或其他格式，该请求所占用的CPU负载非常高、需要响应快，但工作量并不大，这种情况则可视为用户可见请求II。

三、所述用户可见慢请求可以为CPU占用率大于第一预设阈值或者内存占用率或占用量大于第三阈值的操作请求。该类请求通常用于完成特定的业务逻辑，占用大量的CPU或内存。用户需要该类请求立刻返回，但是对速度的期望值较低，并且请求量不大。因此，在建立分类路由规则的步骤中，将该用户可见慢请求路由至Beta/灰度服务器中，该Beta/灰度服务器进行本职工作时（即处理测试时），请求量较低，而且使用频率极低，只有在版本发布前才有使用需求。在大部分情况下，这类Beta/灰度服务器将处于闲置状态。因此我们会将上述用户可见慢请求路由到这类机器，进行复用。因为这类服务器一般只有内部人员使用，而且使用频次较低。因此在空闲状态时，处理同样低频次高资源占用的服务。

所述第一阈值的设定参见上述设定规则，当所述内存占用率大于第三阈值时，该第三阈值可以如此设定：单次请求的内存占用率大于6%。当判断条件为内存占用量时，该第三阈值可以如此设定：单次请求的内存占用量大于100M；在不同的实施例中，内存占用量的第三阈值、内存占用率的第三阈值可以根据不同实例进行设定，此处的举例说明并不用于限制本发明的保护范围。

在一些实施例中，所述用户可见慢请求还可以为CPU占用率大于第一预设阈值或者内存占用率或占用量大于第三阈值的操作请求且持续时间超过第五预设阈值（例如2秒等）时的操作请求。

具体结合实例，用户可见慢请求例如可以假设为：企业用户需要导入客户资料（例如上传EXCEL表格），服务器需要对导入的EXCEL表格进行解析，分析出表格的行列及相关数据，这类操作需要占用大量CPU或内存以及一定时间，那么该类请求则被视为上述用户可见慢请求。

四、所述用户不可见请求可以为具有访问量大于第四预设阈值的操作请求。这类请求通常用于数据收集和统计，具有非常高的访问量。然而因为对用户不可见，这类请求对响应速度并无要求。因此，在建立分类路由规则的步骤中，将该用户可见慢请求路由至第二业务服务器集群中，该第二业务服务器集群中每一服务器只需要处理用户不可见请求，因此只需要少量能够保持高连接量的机器，进行排队处理即可。将该类用户不可见请求与用户可见请求I隔离开，可以保证用户可见请求I不会因为用户不可见请求的数量而被延后处理。

具体结合实例，例如企业邮件服务器中，企业客户邮箱每次新收一封邮件时，邮箱内的收件箱内的未读邮件自动叠加1，因此需要每隔预定时间（例如5秒）访问一次 服务器，以实时更新未读邮件数量。

请参见图3，本发明还公开了一种云平台，包括至少一Beta/灰度服务器、第一业务服务器集群、第二业务服务器集群、至少一脚本处理机；以及反向代理服务器，所述反向代理服务器上述高效得胜服务器资源的装置。其中：

所述第一业务服务器集群中的每一第一业务服务器用于接收并处理所述反向代理服务器路由至其中的用户可见请求I；所述第二业务服务器集群中的每一第二业务服务器用于接收并处理所述反向代理服务器路由至其中的用户不可见请求；所述Beta/灰度服务器用于接收并处理所述反向代理服务器路由至其中的用户可见慢请求；所述脚本处理机用户接收并处理所述反向代理服务器路由至其中的用户可见请求II。

本发明实施方式，将会通过以上原理来合理的分配请求，高效的复用服务器资源，提高平台内所有服务器的利用率，根据操作请求的类别分配至对应的服务器进行处理，最大化的利用服务器，在同等数量的业务服务器集群的情况下，能够更快的处理用户请求，提升客户的体验和满意度。

以上仅为本发明的实施方式，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。