[发明专利]一种灰度发布的处理方法及系统

说明书

技术领域

本申请涉及网络技术，特别是涉及一种灰度发布的处理方法，以及，一种灰度发布的处理系统。

背景技术

灰度发布是平滑过渡的一种发布方式。例如，AB test就是一种灰度发布方式，可以让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大B的发布范围，最终把所有用户都迁移到B上来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

对于互联网产品，有一个特点就是不停的升级、升级、再升级。系统升级总是伴随着风险，新旧版本兼容的风险，用户使用习惯突然改变而造成用户流失的风险，系统宕机的风险。为了避免这些风险，很多产品都采用了灰度发布的策略，其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况时，很容易回退，避免造成大范围的影响。

具体来说，当增加新功能或采用改进技术的互联网产品上线发布前，如果新的发布影响面较大时，会考虑先切分部分用户流量进来，让这部分用户先体验新的互联网产品，开发人员可以根据这部分用户产生的数据对新的互联网产品进行不断优化，最终正式上线发布，然后再让所有用户使用。这种灰度发布方法降低了发布新功能的风险，实现了平滑的发布。

为了实现灰度发布，现有的处理方法是：对原有的功能代码进行修改，在原有代码中增加实现新功能或新技术的灰度代码，同时还保留原有代码中对旧功能或旧技术的处理代码，然后全量发布修改后的功能代码来替代原有代码。这套修改后的功能代码可以让部分用户流量切入进来使用灰度代码体验新功能或新技术，其余用户仍使用原有代码。在此过程中，随着新功能或新技术的不断完善，还会继续修改这套功能代码，直到正式上线。

上述方法虽然实现了灰度发布，但是在整个灰度发布过程中，每当灰度代码有完善时就需要修改整个功能代码，每次修改之后还要进行全量发布，工作量大，耗费时间，还需要技术人员非常了解原有的功能代码。对于系统中的多个项目应用，每个项目应用的改变都需要修改该项目的原有代码，更加花费时间，可能导致项目上线延期。而且，多次修改原有的功能代码无形中对原有代码的稳定性产生了冲击，提高了发布的风险。

发明内容

本申请的目的在于，提供了一种灰度发布的处理方法及系统，以解决目前的处理方法工作量大、发布风险高的问题。

为了解决上述问题，本申请公开了一种灰度发布的处理方法，包括：

将应用的稳定代码和灰度代码分别发布到不同服务器上，并加载该应用的灰度配置信息；

接收请求，并从请求的参数信息中提取用于灰度判断的灰度数据；

根据所述灰度配置信息对所述灰度数据进行判断，确定该请求是否参与灰度发布；

若参与，则将该请求分配到灰度代码所在的服务器处理；

若不参与，则将该请求分配到稳定代码所在的服务器处理。

优选的，所述方法还包括：若修改该应用的灰度代码，则重新将修改后的灰度代码发布到对应的服务器上；和/或，若修改该应用的灰度配置信息，则重新加载修改后的灰度配置信息。

优选的，所述灰度数据包含请求的网页链接地址信息，和/或请求的IP地址信息，和/或请求的Cookie信息。

优选的，根据所述灰度配置信息对所述灰度数据进行判断，确定该请求是否参与灰度发布，包括：判断灰度数据中请求的网页链接地址信息是否与灰度配置信息中设定的网页链接地址信息相匹配，若匹配，则确定该请求参与灰度发布；否则，确定该请求不参与灰度发布。

优选的，根据所述灰度配置信息对所述灰度数据进行判断，确定该请求是否参与灰度发布，包括：判断灰度数据中请求的IP地址信息是否在灰度配置信息设定的IP地址范围内，若是，则确定该请求参与灰度发布；否则，确定该请求不参与灰度发布。

优选的，根据所述灰度配置信息对所述灰度数据进行判断，确定该请求是否参与灰度发布，包括：判断灰度数据中请求的Cookie信息是否为当前有效Cookie，若是，则确定该请求参与灰度发布；否则，确定该请求不参与灰度发布。

优选的，根据所述灰度配置信息对所述灰度数据进行判断，确定该请求是否参与灰度发布，包括：判断灰度数据中请求的Cookie信息是否为当前有效Cookie，若是，则确定该请求参与灰度发布；否则，从所述请求的Cookie信息中提取用户标识信息，并查看缓存中对应该应用的灰度用户名单中是否包含该用户标识信息，若包含，则确定该请求参与灰度发布，若不包含，则确定该请求不参与灰度发布。