灰度发布方法和系统与流程

本发明涉及计算机处理领域，特别是涉及一种灰度发布方法和系统。

背景技术：

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。ABtest是依据系统中配置的分流策略进行分流工作的，在测试阶段，如果发现问题，往往需要在Redis服务器中新增分流策略，而每个分流策略都会对应一个策略解析文件和用户信息解析文件，由于传统的分流策略对应的策略解析文件和用户信息解析文件是存储在Nginx服务器的内存中的，所以若新增分流策略，则需要将新增分流策略对应的策略解析文件和用户信息解析文件上传到Nginx服务器，这个过程中需要重新加载(reload)或重启Nginx服务器，而重启Nginx服务器不仅耗时而且十分麻烦。

技术实现要素：

基于此，有必要针对上述问题，提出一种无需重启Nginx服务器就可以动态新增分流策略的灰度发布方法和装置。

一种灰度发布系统，所述系统包括：Redis服务器，用于接收上传的分流策略以及与所述分流策略对应的策略解析文件和用户信息解析文件并进行存储，其中，所述策略解析文件和用户信息解析文件是以字符串的形式进行存储的；Nginx服务器，用于查找Cache里面是否存在分流策略标识，若不存在，则从所述Redis服务器中预设的位置读取当前分流策略标识；所述Nginx服务器还用于根据所述当前分流策略标识查找内存中是否存在与所述当前分流策略标识对应的策略解析文件和用户信息解析文件，若不存在，则根据所述当前分流策略标识采用加载字符串的方式将所述Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中；所述Nginx服务器还用于根据所述策略解析文件解析出的分流策略进行发布。

在其中一个实施例中，所述Nginx服务器还用于根据所述当前分流策略标识查找与该当前分流策略标识对应的策略解析文件ID和用户信息解析文件ID，根据所述策略解析文件ID和用户信息解析文件ID通过加载字符串的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中并转换为Table的形式进行存储。

在其中一个实施例中，所述Nginx服务器还用于采用所述策略解析文件对相应的分流策略进行解析，解析出分流策略中至少一种参数信息与转发路径之间的对应关系，并将所述至少一种参数信息与转发路径之间的对应关系保存到Cache。

在其中一个实施例中，所述Nginx服务器还用于接收客户端发送的请求，提取所述请求中的用户信息，根据所述用户信息解析文件中预设的提取方式从所述用户信息中提取出至少一个参数信息，将提取出的至少一种参数信息作为用户特征，根据Cache中存储的至少一种参数信息与转发路径之间的对应关系确定出与所述用户特征对应的转发路径，根据所述转发路径进行对应的转发。

在其中一个实施例中，所述Nginx服务器还用于采用所述策略解析文件对相应的分流策略进行解析，解析出对应的百分比策略，根据所述百分比策略进行对应的发布。

一种灰度发布方法，所述方法包括：Nginx服务器根据预设的规则定时查找Cache里面是否存在分流策略标识，若不存在，则从所述Redis服务器中预设的位置读取当前分流策略标识；根据所述当前分流策略标识查找内存中是否存在与所述当前分流策略标识对应的策略解析文件和用户信息解析文件，若内存中不存在所述当前分流策略标识对应的策略解析文件和用户信息解析文件，则根据所述当前分流策略标识采用加载字符串的方式将所述Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中；根据所述策略解析文件解析出的分流策略进行发布。

在其中一个实施例中，所述若内存中不存在所述当前分流策略标识对应的策略解析文件和用户信息解析文件，则根据所述当前分流策略标识采用加载字符串的方式将所述Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中的步骤包括：若内存中不存在所述当前分流策略标识对应的策略解析文件和用户信息解析文件，则根据所述当前分流策略标识查找与该当前分流策略标识对应的策略解析文件ID和用户信息解析文件ID；根据所述策略解析文件ID和用户信息解析文件ID通过加载字符串的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中并转换为Table的形式进行存储。

在其中一个实施例中，所述根据所述策略解析文件解析出的分流策略进行发布的步骤包括：采用所述策略解析文件对相应的分流策略进行解析，解析出分流策略中至少一种参数信息与转发路径之间的对应关系，并将所述至少一种参数信息与转发路径之间的对应关系保存到Cache；根据Cache中的至少一种参数信息与转发路径之间的对应关系进行发布。

在其中一个实施例中，所述方法还包括：接收客户端发送的请求，提取所述请求中的用户信息；根据所述用户信息解析文件中预设的提取方式从所述用户信息中提取出至少一个参数信息，将提取出的至少一种参数信息作为用户特征；根据Cache中存储的至少一种参数信息与转发路径之间的对应关系确定出与所述用户特征对应的转发路径，根据所述转发路径进行对应的转发。

在其中一个实施例中，所述根据所述策略解析文件解析出的分流策略进行发布的步骤包括：采用所述策略解析文件对相应的分流策略进行解析，解析出对应的百分比策略，根据所述百分比策略进行对应的发布。

上述灰度发布方法和系统，当需要新增分流策略时，只需要将新增分流策略对应的策略解析文件和用户信息解析文件转换为字符串上传到Redis服务器，Nginx服务器当需要使用新增的策略解析文件和用户信息解析文件时，则从Redis服务器中查找对应的新增策略解析文件和用户信息解析文件，然后采用加载字符串的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存，然后根据策略解析文件解析出的分流策略进行发布。在这个过程中，当需要新增分流策略时，只需要将与该分流策略对应的策略解析文件和用户信息解析文件转换成字符串存到Redis服务器，Nginx服务器能够动态的从Redis服务器中加载新增的策略解析文件和用户信息解析文件到内存中，不需要reload和重启Nginx服务器，简单易操作，节省时间，从而提高了相应的转发效率。

附图说明

图1为一个实施例中灰度发布系统的架构图；

图2为一个实施例中灰度发布方法的流程图；

图3为一个实施例中根据当前分流策略加载策略解析文件和用户信息解析文件的方法流程图；

图4为另一个实施例中灰度发布方法的流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，在一个实施例中，提出了一种灰度发布系统，该系统包括：Redis服务器102和Nginx服务器104；其中，

Redis服务器102，用于接收上传的分流策略以及与分流策略对应的策略解析文件和用户信息解析文件并进行存储，其中，策略解析文件和用户信息解析文件是以字符串的形式进行存储的。

具体的，ABtest(AB测试)是依据系统中配置的分流策略进行分流工作的，而针对每个分流策略系统都需要一个策略解析文件和一个用户信息解析文件；其中，策略解析文件用于对分流策略进行解析，解析出分流策略中用户特征和转发路径之间的对应关系。用户信息解析文件用于对获取到的用户信息进行解析，解析出用户信息中的用户特征，继而确定出与该用户特征对应的具体转发路径，根据该确定的转发路径进行转发。在本实施例中，当需要新增分流策略时，通过后台管理页面直接将分流策略和分流策略对应的策略解析文件和用户信息解析文件上传到Redis服务器，其中，需要将分流策略对应的策略解析文件和用户信息解析文件先转换为字符串的形式，然后再上传到Redis服务器，即在Redis服务器中策略解析文件和用户信息解析文件是以字符串的形式进行存储的。

Nginx服务器104，用于查找Cache里面是否存在分流策略标识，若不存在，则从Redis服务器中预设的位置读取当前分流策略标识。

在本实施例中，分流策略标识用来唯一标识一个分流策略，因为分流策略可能有多个，当前分流策略标识是指当前使用的分流策略所对应的标识。一般来说，在Nginx服务器的Cache(高速缓存存储器)中会存储有当前分流策略标识，但如果需要更换分流策略，那么首先要清空Cache里面的内容，也就是说，如果要使用新的分流策略，则需要清除Cache里面之前的分流策略标识，即当第一次使用新的分流策略时，Cache里面是不存在分流策略标识的。其中，Cache里面内容的清除可以采用专门的清空机制，即设置一个清空Cache里面内容的接口，通过该接口进行内容的清除。还可以为Cache里面的内容设置时效，比如，如果超过1分钟没有使用里面的分流策略标识，则自动清除Cache里面的分流策略标识。这里并不对如何清空Cache里面的内容作限制。具体的，Nginx服务器根据预设的规则定时查找Cache里面是否存在分流策略标识，若不存在，则很可能是更换了当前分流策略。而当前分流策略是在Redis服务器中设置的，所以，如果Cache里面不存在当前分流策略标识，则需要Nginx服务器从Redis服务器中预设的位置读取当前分流策略标识。具体的，Nginx服务器中存储了当前分流策略标识存在的位置(即地址)，根据该存储位置从Redis服务器中读取当前分流策略标识，并将读取到的当前分流策略标识保存到Cache，便于后续的分流转发。

Nginx服务器104还用于根据当前分流策略标识查找内存中是否存在与当前分流策略标识对应的策略解析文件和用户信息解析文件，若不存在，则根据当前分流策略标识采用加载字符串的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中。

在本实施例中，Nginx服务器获取到当前分流策略标识后，首先，根据该当前分流策略标识查找内存中是否存在与当前分流策略标识对应的策略解析文件和用户信息解析文件，如果不存在，则说明该当前分流策略标识对应的分流策略为新增的分流策略，其对应的策略解析文件和用户信息解析文件以字符串的形式存在于Redis服务器。Nginx服务器需要通过加载字符串(loadString)的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中，其中，lua是一个可以嵌入到Nginx服务器配置文件中的动态脚本语言。具体的，Nginx服务器首先将以字符串形式存在的策略解析文件和用户信息解析文件加载到lua中，然后在lua中将以字符串形式存在的策略解析文件和用户信息解析文件转换为Table形式，然后存储到内存中。其中，Table形式是直接可以被Nginx服务器调用的形式。在本实施例中，由于Nginx服务器可以通过加载字符串的方式将存在与Redis服务器中的策略解析文件和用户信息解析文件加载到内存中，所以当需要新增文件时，只需要将新增文件转换为字符串，然后通过后台管理页面上传到Redis服务器，然后设置新的分流策略为当前分流策略即可实现分流策略的更新，不需要重启Nginx服务器。

Nginx服务器104还用于根据策略解析文件解析出的分流策略进行发布。

在本实施例中，当Nginx服务器将策略解析文件和用户信息解析文件加载到内存中后，就可以根据策略解析文件解析出的分流策略进行对应的灰度发布。具体的，Nginx服务器采用策略解析文件对相应的分流策略进行解析，能够得到分流策略具体的对应关系，即能够解析出分流策略中至少一种参数信息与转发路径(upstream)之间的对应关系。举个例子，如果分流策略中是根据城市信息来进行分流的，那么策略解析文件就能够将分流策略中城市信息与转发路径之间的对应关系解析出来，而对应的根据用户信息解析文件从用户信息中提取的用户特征也一定是城市信息，所以由解析出的城市信息与转发路径之间的对应关系就能够确定出与用户特征对应的转发路径。比如，解析出的城市信息与转发路径为：上海(SH)对应转发路径1，北京(BJ)对应转发路径2，其余城市对应转发路径3。如果提取到的用户特征是上海时，那么与该用户特征对应的转发路径就是1。将解析出的至少一种参数信息与转发路径之间的对应关系保存到Cache，这样当下一个用户请求过来时，可以直接用该解析好的分流策略进行分流转发。

在本实施例中，当需要新增分流策略时，只需要将新增分流策略对应的策略解析文件和用户信息解析文件转换为字符串上传到Redis服务器，Nginx服务器当需要使用新增的策略解析文件和用户信息解析文件时，则从Redis服务器中查找对应的新增策略解析文件和用户信息解析文件，然后采用加载字符串的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存，然后根据策略解析文件解析出的分流策略进行发布。在这个过程中，当需要新增分流策略时，只需要将与该分流策略对应的策略解析文件和用户信息解析文件转换成字符串存到Redis服务器，Nginx服务器能够动态的从Redis服务器中加载新增的策略解析文件和用户信息解析文件到内存中，不需要reload和重启Nginx服务器，简单易操作，节省时间，从而提高了相应的转发效率。

在一个实施例中，Nginx服务器还用于根据所述当前分流策略标识查找与该当前分流策略标识对应的策略解析文件ID和用户信息解析文件ID，根据所述策略解析文件ID和用户信息解析文件ID通过加载字符串的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中并转换为Table的形式进行存储。

在本实施例中，Nginx服务器获取到当前分流策略标识后，根据该当前分流策略标识在Redis服务器中查找与之对应的策略解析文件ID和用户信息解析文件ID。其中，ID用来唯一标识一个文件或内容。具体的，Redis服务器中预先存储了分流策略标识与策略解析文件ID和用户信息解析文件ID之间的对应关系，根据当前分流策略标识就可以在Redis服务器中查找到与该当前分流策略标识对应的策略解析文件ID和用户信息解析文件ID。Nginx服务器获取到策略解析文件ID和用户信息解析文件ID后，就可以在Redis服务器中根据策略解析文件ID和用户信息解析文件ID查找到对应的策略解析文件和用户信息解析文件，由于策略解析文件和用户信息解析文件在Redis服务器中是以字符串(String)的形式存在的，而字符串的形式是不能直接被调用的，所以需要通过将以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中，并在内存中将字符串(String)的形式转换为Table的形式进行存储，这样Nginx服务器就可以直接调用策略解析文件和用户信息解析文件对用户请求进行解析并确定对应的转发路径，也便于下次直接从内存中就可以调用对应的策略解析文件和用户信息解析文件。

在一个实施例中，Nginx服务器还用于采用策略解析文件对相应的分流策略进行解析，解析出分流策略中至少一种参数信息与转发路径之间的对应关系，并将至少一种参数信息与转发路径之间的对应关系保存到Cache。

在本实施例中，虽然分流策略中已经设置好了参数信息与转发路径之间的对应关系，但是由于在计算机里面是不能识别分流策略中的参数信息与转发路径之间的对应关系的，所以需要通过调用策略解析文件对相应的分流策略进行解析，解析出分流策略中的至少一种参数信息与转发路径之间的对应关系，将解析出的至少一种参数信息与转发路径之间的对应关系保存到Cache，这样当下一个用户请求过来时，可以直接用该解析好的分流策略进行分流转发。其中，参数信息根据类型以及对应的位置有多种，如果按类型一般常见的就有四种，一种的城市信息(City)，一种是UID信息，一种是IP信息，一种是URL信息。其中，UID信息根据提取位置不同，又可以分为UID后缀分流、指定特殊UID分流、UID用户段分流等。而分流策略又分为单级分流和多级分流。单级分流比较简单，就是指只需要参考一种参数信息就可以找到对应的转发路径。而多级分流则需要参考多种参数信息，其中，多级分流又分为并集和交集两种，所谓并集就是只要满足其中一个条件就可以实现分流的转发，而交集必须同时满足多个条件才可以实现分流的转发，以3级分流为例，第1级分流是城市的分流：分为2种，上海的(SH)，北京的(BJ)，其对应的分流策略为：SH的upstream(转发路径)是beta1，BJ的upstream是beta2；第2级分流是UID集合的分流：UID为123、124、125的upstream是beta1，UID为567、568、569的upstream是beta2；第3级分流是IP范围的分流：IP的long值范围是1000001～2000000的upstream是beta1，ip的long值范围是2000001～3000000的upstream是beta2；如果采用的是并集的方式，那么首先从用户信息中提取城市信息，如果能够提取到城市信息SH或BJ，则转发请求到beta1或beta2，不用再考虑UID和IP信息，如果提取不到城市信息，或者城市信息不在SH和BJ范围之内，则继续判断UID，如果UID是567，则转发请求到beta2，依次类推，只要满足一个转发条件就进行转发，不必再获取后面的信息。而如果采用的是交集的方式，则必须同时满足上面的三个相同的条件，即，如果获取到的城市信息是SH，其对应的upstream是beta1，还需要继续获取UID集合的信息和IP范围信息，且获取到的UID集合的信息对应的也是beta1，IP范围的信息必须对应的也是beta1时，才会将用户请求转发给beta1，如果获取不到相应的信息或者获取到的信息对应的upstream不一致，比如，获取到的城市信息是SH，而获取到的UID集合信息是567，由于两者分别对应beta1和beta2，没有同时满足三个条件，所以不能实现分流的转发，而在实际中一般不会单独采用交集的形式，而是采用交集和并集的方式。

在一个实施例中，Nginx服务器还用于接收客户端发送的请求，提取请求中的用户信息，根据用户信息解析文件中预设的提取方式从所述用户信息中提取出至少一个参数信息，将提取出的至少一种参数信息作为用户特征，根据Cache中存储的至少一种参数信息与转发路径之间的对应关系确定出与用户特征对应的转发路径，根据转发路径进行对应的转发。

在本实施例中，Nginx服务器接收客户端发送的请求，提取该请求中的用户信息，根据之前存储在内存中的当前分流策略标识对应的用户信息解析文件对用户信息进行解析，提取出用户信息中提取出至少一个参数信息，然后将提取出的该至少一种参数信息作为用户特征。其中，用户特征的提取与对应的分流策略相关。具体的，若分流策略是根据城市信息(City)进行分流的，那么分流策略对应的用户信息解析文件自然是要提取该用户信息中的城市信息，该提取到的城市信息就是用户特征。当然分流策略进行分流可以依据一种参数信息，也可以同时依据多种参数信息，如果是根据多种参数信息来进行分流操作，那么需要从用户信息中提取出多种参数信息，比如，同时提取出城市信息和UID信息，如果提取不到城市信息和UID信息，还可能需要进一步提取IP信息。具体提取什么信息作为用户特征是由对应的分流策略来决定的。当提取到用户特征后，根据Cache中存储的至少一种参数信息与转发路径之间的对应关系确定出与该用户特征对应的转发路径，继而根据该转发路径进行对应的转发。

在一个实施例中，Nginx服务器还用于采用策略解析文件对相应的分流策略进行解析，解析出对应的百分比策略，根据所述百分比策略进行对应的发布。

在本实施例中，分流策略是根据百分比策略进行转发的，Nginx服务器采用策略解析文件对相应的分流策略进行解析，解析出具体的百分比策略，即将百分之多少转发给路径A，将百分之多少转发给路径B。具体的，比如有2组upstream，分别是beta1和beta2，可以设置30％的请求到beta1，70％的请求到beta2，然后根据百分比策略进行对应的发布。此外，为了保证同一用户总是能够转发到相同的路径，因此，需要引入客户号作为参数，将相同客户号在百分比不变的情况下，用户请求总是转发到相同的upstream，因此只有在大量请求的理想情况下，才可能达到30％和70％的分配策略。

如图2所示，在一个实施例中，提出了一种灰度发布方法，该方法包括：

步骤202，Nginx服务器根据预设的规则定时查找Cache里面是否存在分流策略标识，若存在，则直接进入步骤206，若不存在，则进入步骤204。

步骤204，从Redis服务器中预设的位置读取当前分流策略标识。

在本实施例中，分流策略标识用来唯一标识一个分流策略，因为分流策略可能有多个，当前分流策略标识是指当前使用的分流策略所对应的标识。一般来说，在Nginx服务器的Cache(高速缓存存储器)中会存储有当前分流策略标识，但如果需要更换分流策略，那么首先要清空Cache里面的内容，也就是说，如果要使用新的分流策略，则需要清除Cache里面之前的分流策略标识，即当第一次使用新的分流策略时，Cache里面是不存在分流策略标识的。其中，Cache里面内容的清除可以采用专门的清空机制，即设置一个清空Cache里面内容的接口，通过该接口进行内容的清除。还可以为Cache里面的内容设置时效，比如，如果超过1分钟没有使用里面的分流策略标识，则自动清除Cache里面的分流策略标识。这里并不对如何清空Cache里面的内容作限制。具体的，Nginx服务器根据预设的规则定时查找Cache里面是否存在分流策略标识，若不存在，则很可能是更换了当前分流策略。而当前分流策略是在Redis服务器中设置的，所以，如果Cache里面不存在当前分流策略标识，则需要Nginx服务器从Redis服务器中预设的位置读取当前分流策略标识。具体的，Nginx服务器中存储了当前分流策略标识存在的位置(即地址)，根据该存储位置从Redis服务器中读取当前分流策略标识，并将读取到的当前分流策略标识保存到Cache，便于后续的分流转发。

步骤206，根据当前分流策略标识查找内存中是否存在与当前分流策略标识对应的策略解析文件和用户信息解析文件，若存在，则直接进入步骤210，若不存在，则进入步骤208。

在本实施例中，Nginx服务器获取到当前分流策略标识后，首先，根据该当前分流策略标识查找内存中是否存在与当前分流策略标识对应的策略解析文件和用户信息解析文件，如果不存在，则说明该当前分流策略标识对应的分流策略为新增的分流策略，其对应的策略解析文件和用户信息解析文件以字符串的形式存在于Redis服务器。具体的，当需要新增分流策略时，通过后台管理页面直接将分流策略和分流策略对应的策略解析文件和用户信息解析文件上传到Redis服务器，其中，需要将分流策略对应的策略解析文件和用户信息解析文件先转换为字符串的形式，然后再上传到Redis服务器。在Redis服务器中策略解析文件和用户信息解析文件是以字符串的形式进行存储的。

步骤208，根据当前分流策略标识采用加载字符串的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中。

在本实施例中，Nginx服务器需要通过加载字符串(loadString)的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中，其中，lua是一个可以嵌入到Nginx服务器配置文件中的动态脚本语言。具体的，Nginx服务器首先将以字符串形式存在的策略解析文件和用户信息解析文件加载到lua中，然后在lua中将以字符串形式存在的策略解析文件和用户信息解析文件转换为Table形式，然后存储到内存中，其中，Table形式是直接可以被Nginx服务器调用的形式。在本实施例中，由于策略解析文件和用户信息解析文件最初是以字符串的形式存在Redis服务器中的，而不是直接存储在Nginx服务器中，所以当需要新增文件时，只需要将新增文件转换为字符串，然后通过后台管理页面上传到Redis服务器，然后设置新的分流策略为当前分流策略即可实现分流策略的更新。

步骤210，根据策略解析文件解析出的分流策略进行发布。

在本实施例中，当Nginx服务器将策略解析文件和用户信息解析文件加载到内存中后，就可以根据策略解析文件解析出的分流策略进行对应的灰度发布。具体的，Nginx服务器采用策略解析文件对相应的分流策略进行解析，能够得到分流策略具体的对应关系，即能够解析出分流策略中至少一种参数信息与转发路径(upstream)之间的对应关系。举个例子，如果分流策略中是根据城市信息来进行分流的，那么策略解析文件就能够将分流策略中城市信息与转发路径之间的对应关系解析出来，而对应的根据用户信息解析文件从用户信息中提取的用户特征也一定是城市信息，所以由解析出的城市信息与转发路径之间的对应关系就能够确定出与用户特征对应的转发路径。比如，解析出的城市信息与转发路径为：上海(SH)对应转发路径1，北京(BJ)对应转发路径2，其余城市对应转发路径3。如果提取到的用户特征是上海时，那么与该用户特征对应的转发路径就是1。将解析出的至少一种参数信息与转发路径之间的对应关系保存到Cache，这样当下一个用户请求过来时，可以直接用该解析好的分流策略进行分流转发。

在本实施例中，当需要新增分流策略时，只需要将新增分流策略对应的策略解析文件和用户信息解析文件转换为字符串上传到Redis服务器，Nginx服务器当需要使用新增的策略解析文件和用户信息解析文件时，则从Redis服务器中查找对应的新增策略解析文件和用户信息解析文件，然后采用加载字符串的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存，然后根据策略解析文件解析出的分流策略进行发布。在这个过程中，当需要新增分流策略时，只需要将与该分流策略对应的策略解析文件和用户信息解析文件转换成字符串存到Redis服务器，Nginx服务器能够动态的从Redis服务器中加载新增的策略解析文件和用户信息解析文件到内存中，不需要reload和重启Nginx服务器，简单易操作，节省时间，从而提高了相应的转发效率。

如图3所示，在一个实施例中，根据当前分流策略标识采用加载字符串的方式将所述Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中的步骤208包括：

步骤208A，根据当前分流策略标识查找与该当前分流策略标识对应的策略解析文件ID和用户信息解析文件ID。

在本实施例中，Nginx服务器获取到当前分流策略标识后，根据该当前分流策略标识在Redis服务器中查找与之对应的策略解析文件ID和用户信息解析文件ID。其中，ID用来唯一标识一个文件或内容。具体的，Redis服务器中预先存储了分流策略标识与策略解析文件ID和用户信息解析文件ID之间的对应关系，根据当前分流策略标识就可以在Redis服务器中查找到与该当前分流策略标识对应的策略解析文件ID和用户信息解析文件ID。

步骤208B，根据策略解析文件ID和用户信息解析文件ID通过加载字符串的方式将Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中并转换为Table的形式进行存储。

在本实施例中，Nginx服务器获取到策略解析文件ID和用户信息解析文件ID后，就可以在Redis服务器中根据策略解析文件ID和用户信息解析文件ID查找到对应的策略解析文件和用户信息解析文件，由于策略解析文件和用户信息解析文件在Redis服务器中是以字符串(String)的形式存在的，而字符串的形式是不能直接被调用的，所以需要通过将以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中，并在内存中将字符串(String)的形式转换为Table的形式进行存储，这样Nginx服务器就可以直接调用策略解析文件和用户信息解析文件对用户请求进行解析并确定对应的转发路径，也便于下次直接从内存中就可以调用对应的策略解析文件和用户信息解析文件。

在一个实施例中，根据策略解析文件解析出的分流策略进行发布的步骤包括：采用所述策略解析文件对相应的分流策略进行解析，解析出分流策略中至少一种参数信息与转发路径之间的对应关系，并将所述至少一种参数信息与转发路径之间的对应关系保存到Cache，根据Cache中的至少一种参数信息与转发路径之间的对应关系进行发布。

在本实施例中，虽然分流策略中已经设置好了参数信息与转发路径之间的对应关系，但是由于在计算机里面是不能识别分流策略中的参数信息与转发路径之间的对应关系的，所以需要通过调用策略解析文件对相应的分流策略进行解析，解析出分流策略中的至少一种参数信息与转发路径之间的对应关系，将解析出的至少一种参数信息与转发路径之间的对应关系保存到Cache，这样当下一个用户请求过来时，可以直接用该解析好的分流策略进行分流转发。其中，参数信息根据类型以及对应的位置有多种，如果按类型一般常见的就有四种，一种的城市信息(City)，一种是UID信息，一种是IP信息，一种是URL信息。其中，UID信息根据提取位置不同，又可以分为UID后缀分流、指定特殊UID分流、UID用户段分流等。而分流策略又分为单级分流和多级分流。单级分流比较简单，就是指只需要参考一种参数信息就可以找到对应的转发路径。而多级分流则需要参考多种参数信息，其中，多级分流又分为并集和交集两种，所谓并集就是只要满足其中一个条件就可以实现分流的转发，而交集必须同时满足多个条件才可以实现分流的转发，以3级分流为例，第1级分流是城市的分流：分为2种，上海的(SH)，北京的(BJ)，其对应的分流策略为：SH的upstream(转发路径)是beta1，BJ的upstream是beta2；第2级分流是UID集合的分流：UID为123、124、125的upstream是beta1，UID为567、568、569的upstream是beta2；第3级分流是IP范围的分流：IP的long值范围是1000001～2000000的upstream是beta1，ip的long值范围是2000001～3000000的upstream是beta2；如果采用的是并集的方式，那么首先从用户信息中提取城市信息，如果能够提取到城市信息SH或BJ，则转发请求到beta1或beta2，不用再考虑UID和IP信息，如果提取不到城市信息，或者城市信息不在SH和BJ范围之内，则继续判断UID，如果UID是567，则转发请求到beta2，依次类推，只要满足一个转发条件就进行转发，不必再获取后面的信息。而如果采用的是交集的方式，则必须同时满足上面的三个相同的条件，即，如果获取到的城市信息是SH，其对应的upstream是beta1，还需要继续获取UID集合的信息和IP范围信息，且获取到的UID集合的信息对应的也是beta1，IP范围的信息必须对应的也是beta1时，才会将用户请求转发给beta1，如果获取不到相应的信息或者获取到的信息对应的upstream不一致，比如，获取到的城市信息是SH，而获取到的UID集合信息是567，由于两者分别对应beta1和beta2，没有同时满足三个条件，所以不能实现分流的转发，而在实际中一般不会单独采用交集的形式，而是采用交集和并集的方式。

如图4所示，在一个实施例中，上述灰度发布方法还包括：

步骤402，Nginx服务器根据预设的规则定时查找Cache里面是否存在分流策略标识，若存在，则直接进入步骤406，若不存在，则进入步骤404。

步骤404，从Redis服务器中预设的位置读取当前分流策略标识。

步骤406，根据当前分流策略标识查找内存中是否存在与当前分流策略标识对应的策略解析文件和用户信息解析文件，若存在，则直接进入步骤410，若不存在，则进入步骤408。

步骤408，根据当前分流策略标识采用加载字符串的方式将所述Redis服务器中的以字符串形式存在的策略解析文件和用户信息解析文件通过lua加载到内存中。

步骤410，采用策略解析文件对相应的分流策略进行解析，解析出分流策略中至少一种参数信息与转发路径之间的对应关系，并将所述至少一种参数信息与转发路径之间的对应关系保存到Cache。

步骤412，接收客户端发送的请求，提取请求中的用户信息。

在本实施例中，Nginx服务器接收客户端发送的请求，提取该请求中的用户信息。其中，用户信息包括城市信息、IP地址信息，UID信息，remote地址信息等中的至少一种。

步骤414，根据用户信息解析文件中预设的提取方式从用户信息中提取出至少一个参数信息，将提取出的至少一种参数信息作为用户特征。

在本实施例中，Nginx服务器根据内存中的当前分流策略标识对应的用户信息解析文件对用户信息进行解析，根据预设的提取方式从用户信息中提取出至少一个参数信息，然后将提取出的该至少一种参数信息作为用户特征。其中，用户特征的提取与对应的分流策略相关。具体的，若分流策略是根据城市信息(City)进行分流的，那么分流策略对应的用户信息解析文件自然是要提取该用户信息中的城市信息，该提取到的城市信息就是用户特征。当然分流策略进行分流可以依据一种参数信息，也可以同时依据多种参数信息，如果是根据多种参数信息来进行分流操作，那么需要从用户信息中提取出多种参数信息，比如，同时提取出城市信息和UID信息，如果提取不到城市信息和UID信息，还可能需要进一步提取IP信息。具体提取什么信息作为用户特征是由对应的分流策略来决定的。

步骤416，根据Cache中存储的至少一种参数信息与转发路径之间的对应关系确定出与用户特征对应的转发路径，根据转发路径进行对应的转发。

在本实施例中，当提取到用户特征后，根据Cache中存储的至少一种参数信息与转发路径之间的对应关系确定出与该用户特征对应的转发路径，继而根据该转发路径进行对应的转发。以多级分流为例，采用交集和并集的方式的分流策略。其中，第1级分流包括2个策略，是交集的关系：策略ID为0的是城市信息，上海(SH)的upstream是beta1，北京(BJ)的upstream是beta2；策略ID为1的是UID集合分流，UID为123、124、125的upstream是beta1，UID为567、568、569的upstream是beta2；第2级分流与第1级分流是并集的关系，第2级分流只有1个策略：策略为2的是ip范围的分流，ip的long值范围是1000001～2000000的upstream是beta1，ip的long值范围是2000001～3000000的upstream是beta2；在该实施例中，如果用户信息中的城市信息是SH，且UID为123，则走第1级分流，转发请求到beta1，如果用户信息中的城市信息是SH，而UID为567，由于各自转发的upstream不一致，不符合第1级分流策略，则继续走第2级分流策略，如果IP的long值是1200000，则转发请求到beta1。

在一个实施例中，根据策略解析文件解析出的分流策略进行发布的步骤包括：采用策略解析文件对相应的分流策略进行解析，解析出对应的百分比策略，根据百分比策略进行对应的发布。

在本实施例中，分流策略是根据百分比策略进行转发的，Nginx服务器采用策略解析文件对相应的分流策略进行解析，解析出具体的百分比策略，即将百分之多少转发给路径A，将百分之多少转发给路径B。具体的，比如有2组upstream，分别是beta1和beta2，可以设置30％的请求到beta1，70％的请求到beta2，然后根据百分比策略进行对应的发布。此外，为了保证同一用户总是能够转发到相同的路径，因此，需要引入客户号作为参数，将相同客户号在百分比不变的情况下，用户请求总是转发到相同的upstream，因此只有在大量请求的理想情况下，才可能达到30％和70％的分配策略。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。