CN113014651A - 灰度发布方法、应用服务器及灰度发布系统 - Google Patents
灰度发布方法、应用服务器及灰度发布系统 Download PDFInfo
- Publication number
- CN113014651A CN113014651A CN202110233005.9A CN202110233005A CN113014651A CN 113014651 A CN113014651 A CN 113014651A CN 202110233005 A CN202110233005 A CN 202110233005A CN 113014651 A CN113014651 A CN 113014651A
- Authority
- CN
- China
- Prior art keywords
- gray
- server
- request
- gray scale
- application server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
本申请实施例提供一种灰度发布方法、应用服务器及灰度发布系统，可用于金融技术领域，方法包括：接收服务请求；若确定自身为非灰度集群内的应用服务器，则根据请求路径自预设的灰度规则中获取对应的灰度关键信息；基于灰度关键信息和请求参数确定服务请求是否与灰度规则匹配成功，若是则获取灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求；将新的服务请求转发至灰度集群内的应用服务器，以使灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。本申请能够有效提高灰度发布过程的处理效率，能够有效降低灰度发布过程中系统开销及负担，并能够有效缩短处理流程，提高整体系统处理链路的稳定性。
Description
技术领域
本申请涉及数据处理技术领域，特别涉及金融技术领域，具体涉及灰度发布方法、应用服务器及灰度发布系统。
背景技术
伴随着移动互联网的发展以及人工智能、大数据、5G等新技术在金融领域的创新应用，商业银行科技系统的对客服务效率和质量都得到了极大提升。商业银行科技系统的持续升级迭代，在为客户提供更多便捷、优质金融服务的同时，也对自身系统的稳定性提出了更高的要求。为了避免迭代的新版本程序因可能的不完善给客户带来损失，目前包括商业银行在内的大部分企业都会采取灰度发布的方法。
目前，灰度发布方法的主要方式包括：代码层逻辑灰度、网络或WEB层灰度以及自定义路由灰度等发布方式，然而，代码层逻辑灰度发布方式的工作量大且耗费时间，同时频繁修改、发布会对整体系统的稳定性带来一定风险；网络或WEB层灰度发布方式仅适合设计比较简单的灰度规则，如果灰度规则或灰度筛选程序过于复杂，会无形中增加网络服务器及WEB服务器的系统开销及负担，影响网络分流及WEB接入转发效率；自定义路由灰度发布方式由于增加了路由服务器节点或代理服务器，人为延长了系统处理流程，降低了整体系统处理链路的稳定性，尤其是在分布式系统中，部署在应用服务器前的路由服务器很容易成为影响分布式系统处理性能的瓶颈点。
由此可知，无论是现有的哪一种灰度发布方法，均存在无法同时解决效率低下、占用系统开销大及系统稳定性较差的问题。
发明内容
针对现有技术中的问题，本申请提供一种灰度发布方法、应用服务器及灰度发布系统，能够有效提高灰度发布过程的处理效率，能够有效降低灰度发布过程中系统开销及负担，并能够有效缩短处理流程，提高整体系统处理链路的稳定性。
为解决上述技术问题，本申请提供以下技术方案：
第一方面，本申请提供一种灰度发布方法，包括：
接收服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数；
若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息；
基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求；
将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。
进一步地，还包括：
若确定所述服务请求与所述灰度规则匹配失败，则自行执行所述服务请求对应的请求业务；
其中，当前的所述目标服务端标识为非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址；
所述非灰度服务端标识唯一对应有预先存储的灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址。
进一步地，在所述接收服务请求之后，还包括：
读取本地环境变量的值，并根据该环境变量的值判断自身所属集群为非灰度集群或灰度集群；
若确定自身为灰度集群内的应用服务器，则执行自身接收到的服务请求对应的请求业务；
其中，当前的所述目标服务端标识为灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址；
所述灰度服务端标识唯一对应有预先获取的非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址。
进一步地，所述根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息，包括：
将所述请求路径作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息。
进一步地，所述将所述请求路径作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息，包括：
根据所述请求路径及请求参数生成第一哈希变量；
其中，该第一哈希变量的键值对的关键字包括所述请求路径，该第一哈希变量的键值对的值包括第二哈希变量；所述第二哈希变量的键值对的关键字包括所述请求参数的类型，该第二哈希变量的键值对的值包括所述请求参数的值；
将所述第一哈希变量作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息的第三哈希变量；
其中，所述第三哈希变量的键值对的关键字包括灰度名称属性值，该第三哈希变量的键值对的值包括灰度参数元素的文本节点信息。
进一步地，所述基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，包括：
根据所述第二哈希变量定义一布尔型变量，且该布尔型变量的初始状态为执行成功；
分别轮询所述第三哈希变量和所述第二哈希变量，以确认所述第三哈希变量和所述第二哈希变量各自对应的键值对的值是否匹配成功，若匹配失败，则将布尔型变量的状态修改为执行失败；
根据当前所述布尔型变量的状态确定所述服务请求是否与所述灰度规则匹配成功。
进一步地，所述分别轮询所述第三哈希变量和所述第二哈希变量，以确认所述第三哈希变量和所述第二哈希变量各自对应的键值对的值是否匹配成功，包括：
执行第一层轮询：轮询所述第三哈希变量，且将当前轮询均获取所述第三哈希变量中的一条关键字，并将当前轮询到的所述第三哈希变量中的关键字对应的值记录为第一比较值；
执行第二层轮询：以所述第三哈希变量中的关键字为匹配条件，与所述第二哈希变量中的关键字进行匹配，若匹配成功，则将匹配到的所述第二哈希变量中的关键字对应的值记录为第二比较值；确定所述第一比较值与所述第二比较值是否匹配成功，若所述第一比较值与所述第二比较值匹配成功，则返回执行所述第一层轮询；若第一比较值与所述第二比较值匹配失败，则结束第一层轮询和第二层轮询，并将所述布尔型变量的状态修改为执行失败。
第二方面，本申请提供一种应用服务器，包括：
请求接收模块，用于接收服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数；
规则获取模块，用于若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息；
规则匹配模块，用于基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求；
转发执行模块，用于将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。
第三方面，本申请提供一种灰度发布系统，包括：负载均衡服务器、非灰度集群、灰度集群和灰度规则服务器；
所述非灰度集群和所述灰度集群中均包含有WEB服务器和与所述WEB服务器通信连接的应用服务器，所述应用服务器用于实现所述的灰度发布方法；
所述负载均衡服务器用于接收客户端设备发送的服务请求，若所述服务请求中的目标服务端标识为非灰度服务端标识，则将该服务请求发送至所述非灰度集群内的WEB服务器；若所述服务请求中的目标服务端标识为灰度服务端标识，则将该服务请求发送至所述灰度集群内的WEB服务器；
各个所述WEB服务器分别与所述负载均衡服务器之间通信连接，所述WEB服务器用于将接收自所述负载均衡服务器的所述服务请求转发至所属集群中的一所述应用服务器；
各个所述应用服务器分别与所述灰度规则服务器之间通信连接，所述灰度规则服务器用于存储所述灰度规则。
第四方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的灰度发布方法。
第五方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的灰度发布方法。
由上述技术方案可知，本申请提供的一种灰度发布方法、应用服务器及灰度发布系统，方法包括：接收服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数；若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息；基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求；将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务，由应用服务器自行确定自身是灰度服务器还是非灰度服务器，并由应用服务器根据自身角色自行判断当前的服务请求是否符合灰度规则，若非灰度服务器接收到的服务请求符合灰度规则，则由非灰度服务器将服务请求转发至灰度服务器进行处理，能够有效实现自动灰度发布，且能够有效提高灰度发布过程的处理效率，能够有效降低工作量及时间成本，同时能够适用于各类型的灰度规则，尤其针对复杂的灰度规则，不会占用过大的系统开销，能够有效降低灰度发布过程中系统开销及负担，并能够有效提高网络分流及WEB接入转发效率；还由于整个灰度发布方法由应用服务器自行执行，因此没有产生新的服务器节点或代理服务器，进而能够有效缩短系统处理流程，并能够有效提高整体系统处理链路的稳定性，尤其适用于分布式系统，能够有效保证分布式系统的处理性能。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例中的灰度发布方法的第一种流程示意图。
图2是本申请实施例中的灰度发布方法的第二种流程示意图。
图3是本申请实施例中的灰度发布方法的第三种流程示意图。
图4是本申请实施例中的灰度发布方法的第四种流程示意图。
图5是本申请实施例中的灰度发布方法中步骤210的具体流程示意图。
图6是本申请实施例中的灰度发布方法中步骤300的具体流程示意图。
图7是本申请实施例中的灰度发布方法中步骤320的具体流程示意图。
图8是本申请实施例中的应用服务器的第一种结构示意图。
图9是本申请实施例中的应用服务器的第二种结构示意图。
图10是本申请实施例中的应用服务器的第三种结构示意图。
图11是本申请实施例中的灰度发布系统的结构示意图。
图12是本申请应用实例中的灰度发布系统的逻辑结构示意图。
图13是本申请应用实例中的灰度规则服务器的功能示意图。
图14是本申请应用实例中的非灰度集群中应用服务器的程序代码部署示意图。
图15是本申请应用实例中的灰度集群中应用服务器的程序代码部署示意图。
图16是本申请实施例中的电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
需要说明的是，本申请公开的灰度发布方法、应用服务器及灰度发布系统可用于金融技术领域，也可用于除金融技术领域之外的任意领域，本申请公开的灰度发布方法、应用服务器及灰度发布系统的应用领域不做限定。
灰度发布方法的主要思路是在系统中同时保留新旧两个版本的程序，当期增加的新功能或采用新技术的产品仅存在于新程序中，新程序投产后会考虑先切部分用户流量进来，让这部分用户优先体验新的产品或功能，开发人员可以根据这部分用户产生的数据对新的产品或功能进行不断优化，最终正式上线发布并让所有用户使用。灰度发布方法可以降低新程序的风险，实现新功能或产品平滑的发布，已经成为应用系统稳定的重要保障。目前业界灰度发布方法主要有以下三种，现分别进行介绍：
(1)代码层逻辑灰度：对原有的功能代码进行修改，在原有代码中增加实现新功能或新技术的灰度代码，同时还保留原有代码中对旧功能或旧技术的处理代码，然后全量发布修改后的功能代码来替代原有代码。这套修改后的功能代码可以让部分用户流量切入进来使用体验，其余用户仍使用原有代码；
(2)网络或WEB层灰度：旧代码和新代码在不同应用服务器中独立分开部署，同时在DNS、负载均衡等网络服务器或WEB服务器中设置灰度规则(或有单独的灰度规则服务器)和灰度筛选程序，实际生产运行中根据灰度规则进行过滤，命中规则的请求转发至部署新代码的应用服务器处理，未命中的转发至部署旧代码的应用服务器处理；
(3)自定义路由灰度：旧代码和新代码在不同应用服务器中独立分开部署，同时在应用服务器前增加路由服务器，路由服务器中设计灰度筛选代码，读取实现本地或灰度规则服务器中配置的灰度规则并进行判断，命中规则的请求转发至部署新代码的应用服务器处理，未命中的转发至部署旧代码的应用服务器处理；
其中，第(1)种灰度发布方法虽然实现了灰度发布，但每当灰度代码有修改时就需要修改并发布整个功能代码，工作量大且耗费时间，同时频繁修改、发布会对整体系统的稳定性带来一定风险；第(2)种在DNS、负载均衡等网络服务器或WEB服务器中增加灰度规则及灰度筛选程序的方法，因网络服务器或WEB服务器在整体系统架构中承担的功能较为具体和单一，仅适合设计比较简单的灰度规则，如按地区、IP等，如果灰度规则或灰度筛选程序过于复杂，会无形中增加网络服务器及WEB服务器的系统开销及负担，影响网络分流及WEB接入转发效率；第(3)种自定义路由是业界运用较多的一种方法，但这种方法通过增加路由服务器节点，人为延长了系统处理流程，降低了整体系统处理链路的稳定性，尤其是在分布式系统中，部署在应用服务器前的路由服务器很容易成为影响分布式系统处理性能的瓶颈点。
基于此，针对现有的灰度发布方法存在的无法同时解决效率低下、占用系统开销大及系统稳定性较差的问题，本申请分别提供一种灰度发布方法、应用服务器、灰度发布系统、电子设备和计算机可读存储介质，由应用服务器自行确定自身是灰度服务器还是非灰度服务器，并由应用服务器根据自身角色自行判断当前的服务请求是否符合灰度规则，若非灰度服务器接收到的服务请求符合灰度规则，则由非灰度服务器将服务请求转发至灰度服务器进行处理，能够有效实现自动灰度发布，且能够有效提高灰度发布过程的处理效率，能够有效降低工作量及时间成本，同时能够适用于各类型的灰度规则，尤其针对复杂的灰度规则，不会占用过大的系统开销，能够有效降低灰度发布过程中系统开销及负担，并能够有效提高网络分流及WEB接入转发效率；还由于整个灰度发布方法由应用服务器自行执行，因此没有产生新的服务器节点或代理服务器，进而能够有效缩短系统处理流程，并能够有效提高整体系统处理链路的稳定性，尤其适用于分布式系统，能够有效保证分布式系统的处理性能。
基于上述内容，本申请还提供一种用于实现本申请一个或多个实施例中提供的灰度发布方法的应用服务器，该应用服务器可以自行或通过其他负载均衡服务器及所属集群内的WEB服务器等与客户端设备之间通信连接，以接收客户端设备发送的服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数；若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息；基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求；将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务，而后将对应的处理结果自行或通过WEB服务器和负载均衡服务器发送至所述客户端设备，以使用户自客户端设备获知服务请求的处理结果，进而有效提高交易等服务处理的效率及准确性。
在本申请的一个或多个实施例中，所述服务请求可以基于目标系统的可实现功能进行选取，在一种举例中，所述服务请求可以为用户通过客户端设备发送的交易请求等，通过本申请实施例提供的灰度发布方法、应用服务器和灰度发布系统确定目标应用服务器之后，目标应用服务器根据对应的业务处理逻辑对所述交易请求对应的请求业务进行处理。
可以理解的是，所述客户端设备可以包括智能手机、平板电子设备、网络机顶盒、便携式计算机、台式电脑、个人数字助理(PDA)、车载设备、智能穿戴设备等。其中，所述智能穿戴设备可以包括智能眼镜、智能手表、智能手环等。
在另一种实际应用情形中，前述的应用服务器进行灰度发布的部分可以在如上述内容的服务器中执行，也可以所有的操作都在所述客户端设备中完成。具体可以根据所述客户端设备的处理能力，以及用户使用场景的限制等进行选择。本申请对此不作限定。若所有的操作都在所述客户端设备中完成，所述客户端设备还可以包括处理器，用于灰度发布的具体处理。
上述的客户端设备可以具有通信模块(即通信单元)，可以与远程的服务器进行通信连接，实现与所述服务器的数据传输。所述服务器可以包括任务调度中心一侧的服务器，其他的实施场景中也可以包括中间平台的服务器，例如与任务调度中心服务器有通信链接的第三方服务器平台的服务器。所述的服务器可以包括单台计算机设备，也可以包括多个服务器组成的服务器集群，或者分布式装置的服务器结构。
上述服务器与所述客户端设备之间可以使用任何合适的网络协议进行通信，包括在本申请提交日尚未开发出的网络协议。所述网络协议例如可以包括TCP/IP协议、UDP/IP协议、HTTP协议、HTTPS协议等。当然，所述网络协议例如还可以包括在上述协议之上使用的RPC协议(Remote Procedure Call Protocol，远程过程调用协议)、REST协议(Representational State Transfer，表述性状态转移协议)等。
具体通过下述各个实施例及应用实例分别进行详细说明。
为了解决现有的灰度发布方法存在的无法同时解决效率低下、占用系统开销大及系统稳定性较差等问题，本申请提供一种灰度发布方法的实施例，参见图1，基于应用服务器执行的所述灰度发布方法具体包含有如下内容：
步骤100：接收服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数。
在步骤100的一种情形中，若所述服务请求为客户端设备发出的，则由于客户端设备默认发出非灰度域名地址，那么当前的服务请求中的所述目标服务端标识可以为非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址；其中，第一IP地址可以由DNS服务器根据非灰度域名地址发送至客户端设备，且在DNS服务器中，不但存储有非灰度域名地址和第一IP地址之间的对应关系，还存有所述灰度服务端标识唯一对应有预先获取的灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址。
举例来说：DNS服务器中除了已有的服务端的非灰度域名地址与IP的对应关系，需要增加一个灰度域名地址与IP地址的对应关系，可以定义为“非灰域名地址：IP地址1”、“灰度域名地址：IP地址2”，其中，IP地址1即为第一IP地址的举例，IP地址2即为第二IP地址的举例，第一IP地址与第二IP地址是不同的地址。
基于此，接收到服务请求的当前应用服务器可以直接根据读取服务请求中的域名地址为非灰度域名地址还是灰度域名地址来判断自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，即，若接收到服务请求的当前应用服务器读取服务请求中的域名地址为非灰度域名地址，则判定自身属于非灰度集群内的应用服务器。但是，应用该方式的应用服务器若无法区分非灰度域名地址和灰度域名地址，则无法准确判断自身所述集群。基于此，在一种更为优选的实现方式中，应用服务器可以通过判断自身所处环境来确定自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，环境判断的具体过程在后续实施例中详细说明。
在步骤100的另一种情形中，若所述服务请求为非灰度集群中的应用服务器经由负载均衡服务器发出的，即在执行步骤400及步骤500后生成并发送的新的服务请求，例如可以为生成并发送一个新URL请求，则基于步骤400可知该服务请求中的目标服务端标识为：与用户自客户端设备发出的非灰度服务端标识相对应的灰度服务端标识，则此时，接收到该服务请求的应用服务器可以直接根据读取服务请求中的域名地址为非灰度域名地址还是灰度域名地址来判断自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，即，若接收到服务请求的当前应用服务器读取服务请求中的域名地址为灰度域名地址，则判定自身属于灰度集群内的应用服务器。但与非灰度集群内的应用服务器相类似的是：应用该方式的应用服务器若无法区分非灰度域名地址和灰度域名地址，则无法准确判断自身所述集群。基于此，在一种更为优选的实现方式中，应用服务器可以通过判断自身所处环境来确定自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，环境判断的具体过程在后续步骤010对应的实施例中详细说明。
步骤200：若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息。
可以理解的是，所述灰度关键信息至少可以包含有存储在灰度规则中的灰度名称属性值和灰度参数元素的文本节点信息。
步骤300：基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则执行步骤400：获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求。
步骤500：将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。
在步骤300中，确定自身为非灰度集群内的应用服务器会构造成一个新的URL请求；新请求信息(灰度域名格式)会自动经过DNS服务器进行层层解析，因目标银行已提前在DNS侧维护了灰度域名对应的IP地址，所以DNS会根据请求信息中的灰度域名，返回其对应的IP地址给客户端；客户端拿到IP地址后，向该IP地址上送交易请求信息；由于该IP地址是的灰度IP，负载均衡服务器会根据负载均衡策略自动将请求信息转发至灰度集群；灰度集群的WEB服务器接收到转发的请求信息，继续通过负载均衡或随机的方式转发到灰度集群的某个应用服务器处理，以实现自非灰度集群内的WEB服务器转发至负载均衡服务器的过程。当然，根据具体实际应用请求，确定自身为非灰度集群内的应用服务器也可以自行将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。
从上述描述可知，本申请实施例提供的灰度发布方法，由应用服务器自行确定自身是灰度服务器还是非灰度服务器，并由应用服务器根据自身角色自行判断当前的服务请求是否符合灰度规则，若非灰度服务器接收到的服务请求符合灰度规则，则由非灰度服务器将服务请求转发至灰度服务器进行处理，能够有效实现自动灰度发布，且能够有效提高灰度发布过程的处理效率，能够有效降低工作量及时间成本，同时能够适用于各类型的灰度规则，尤其针对复杂的灰度规则，不会占用过大的系统开销，能够有效降低灰度发布过程中系统开销及负担，并能够有效提高网络分流及WEB接入转发效率；还由于整个灰度发布方法由应用服务器自行执行，因此没有产生新的服务器节点或代理服务器，进而能够有效缩短系统处理流程，并能够有效提高整体系统处理链路的稳定性，尤其适用于分布式系统，能够有效保证分布式系统的处理性能。
为了有效提高灰度发布的智能化程度及处理效率，在本申请提供的灰度发布方法的一个实施例，参见图2，在所述步骤300之后，所述灰度发布方法还具体包含有如下内容：
步骤600：若确定所述服务请求与所述灰度规则匹配失败，则自行执行所述服务请求对应的请求业务，其中，当前的所述目标服务端标识为非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址；所述非灰度服务端标识唯一对应有预先存储的灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址。
在步骤600中，若确定所述服务请求与所述灰度规则匹配失败，则说明当前的服务请求对应的请求业务并不在灰度集群中的应用服务器的处理范畴内，因此需要有接收到该服务请求的非灰度集群内的应用服务器自行处理。
从上述描述可知，本申请实施例提供的灰度发布方法，确定自身为非灰度服务器的应用服务器，在确定当前的服务请求不符合灰度规则后，能够自行直接执行该服务请求对应的服务请求业务，进而能够有效提高灰度发布的智能化程度及处理效率，有效提高灰度发布的适应全面性及可靠性。
为了进一步提高服务请求处理的效率，在本申请提供的灰度发布方法的一个实施例，参见图3，在所述步骤100之后，所述灰度发布方法还具体包含有如下内容：
步骤010：读取本地环境变量的值，并根据该环境变量的值判断自身所属集群为非灰度集群或灰度集群。
在步骤010中，灰度集群与非灰度集群在物理上隔离部署，均包含各自的WEB服务器与应用服务器，同时两个集群均可通过与灰度规则服务器交互获取灰度规则；运维人员可通过手工或自动化脚本的方式，在非灰度集群和灰度集群每个应用服务器中，都增加一个自定义的环境变量grayTag，其中非灰度集群下应用服务器的grayTag值为0，灰度集群下应用服务器的grayTag值为1。
步骤020：若确定自身为灰度集群内的应用服务器，则执行自身接收到的服务请求对应的请求业务；其中，当前的所述目标服务端标识为灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址；所述灰度服务端标识唯一对应有预先获取的非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址。
从上述描述可知，本申请实施例提供的灰度发布方法，已确定自身为灰度服务器的应用服务器，说明其当前接收到的服务请求服务已经被非灰度服务器确定为符合灰度规则的服务请求，因此灰度服务期无需再判断当前的服务请求是否符合灰度规则，直接进行该服务请求对应的服务请求业务的执行即可，进而能够有效减少灰度服务器的运行消耗，并能够进一步提高服务请求处理的效率，进一步有效提高灰度发布的适应全面性及可靠性。
为了提高对灰度规则进行修改及增减等变更操作的便捷性，在本申请提供的灰度发布方法的一个实施例，参见图4，所述灰度发布方法中的步骤200具体包含有如下内容：
步骤210：将所述请求路径作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息。
从上述描述可知，本申请实施例提供的灰度发布方法，通过设置灰度规则服务器，并调用灰度规则服务器的接口，能够有效提高灰度规则获取的效率及准确性，且灰度规则服务器独立设置，能够有效提高对灰度规则进行修改及增减等变更操作的便捷性，进而进一步提高灰度发布过程的有效性及应用全面性。
为了提高对灰度规则进行修改及增减等变更操作的便捷性，在本申请提供的灰度发布方法的一个实施例，参见图5，所述灰度发布方法中的步骤210具体包含有如下内容：
步骤211：根据所述请求路径及请求参数生成第一哈希变量；其中，该第一哈希变量的键值对的关键字包括所述请求路径，该第一哈希变量的键值对的值包括第二哈希变量；所述第二哈希变量的键值对的关键字包括所述请求参数的类型，该第二哈希变量的键值对的值包括所述请求参数的值。
具体来说，可以对服务请求进行数据解析，从而提取得到服务请求数据中的关键要素(请求路径及请求参数/参数值)，并将关键要素构造成为一个HashMap类型的变量，记为第一哈希变量HashMap1，其中，请求路径为HashMap1的key，请求参数/参数值作为HashMap1的value，HashMap1的value也为HashMap类型，记为第二哈希变量HashMap2，其中每个请求参数作为HashMap2的一个key，参数值作为key所对应的value。
步骤212：将所述第一哈希变量作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息的第三哈希变量；其中，所述第三哈希变量的键值对的关键字包括灰度名称属性值，该第三哈希变量的键值对的值包括灰度参数元素的文本节点信息。
具体来说，接收得到的第一哈希变量HashMap1作为输入参数，调用灰度规则服务器上的规则获取服务化接口，服务化接口读取本地rule.xml文件，以HashMap1对象的key(请求路径)为条件，获取根节点grayRules下属性名称和key匹配的子元素grayRule；然后获取grayRule下每个grayParam元素的grayName属性值以及元素的文本节点信息，构造成一个新HashMap，定义为第三哈希变量HashMap3，其中的grayName属性值作为HashMap3的key，元素的文本节点信息作为关键字key对应的值value。
从上述描述可知，本申请实施例提供的灰度发布方法，通过哈希变量的应用，能够提高调取灰度规则服务器中灰度规则的便捷性及效率，进而能够进一步提高灰度发布的便捷性及效率。
为了进一步提高灰度发布的效率及准确性，在本申请提供的灰度发布方法的一个实施例，参见图6，所述灰度发布方法中的步骤300具体包含有如下内容：
步骤310：根据所述第二哈希变量定义一布尔型变量，且该布尔型变量的初始状态为执行成功。
步骤320：分别轮询所述第三哈希变量和所述第二哈希变量，以确认所述第三哈希变量和所述第二哈希变量各自对应的键值对的值是否匹配成功，若匹配失败，则将布尔型变量的状态修改为执行失败。
步骤330：根据当前所述布尔型变量的状态确定所述服务请求是否与所述灰度规则匹配成功。
具体来说，首先利用请求路径获取HashMap1中的value(即HashMap2)，并定义一个布尔型变量，布尔型变量值默认为执行成功True，然后分两层分别轮询HashMap3、HashMap2，若所述服务请求与所述灰度规则匹配成功，则布尔型变量值不变，为执行成功True；若所述服务请求与所述灰度规则匹配失败，则将布尔型变量值置为执行失败False。
从上述描述可知，本申请实施例提供的灰度发布方法，通过应用布尔型变量，能够提高判断所述服务请求是否与所述灰度规则匹配成功的效率及准确性，进而能够进一步提高灰度发布的效率及准确性。
为了进一步提高灰度发布的效率及准确性，在本申请提供的灰度发布方法的一个实施例，参见图7，所述灰度发布方法中的步骤320具体包含有如下内容：
步骤321：执行第一层轮询：轮询所述第三哈希变量，且将当前轮询均获取所述第三哈希变量中的一条关键字，并将当前轮询到的所述第三哈希变量中的关键字对应的值记录为第一比较值；
步骤322：执行第二层轮询：以所述第三哈希变量中的关键字为匹配条件，与所述第二哈希变量中的关键字进行匹配，若匹配成功，则将匹配到的所述第二哈希变量中的关键字对应的值记录为第二比较值；并执行步骤323；
步骤323：判断所述第一比较值与所述第二比较值是否匹配成功；
若所述第一比较值与所述第二比较值匹配成功，则返回执行步骤321：所述第一层轮询；若第一比较值与所述第二比较值匹配失败，则执行步骤324；
步骤324：结束第一层轮询和第二层轮询，并将所述布尔型变量的状态修改为执行失败。
具体来说：分两层分别轮询HashMap3、HashMap2的具体过程为：
第一层：轮询HashMap3，每次轮询均获取HashMap3中的一条key，记为key_A，其对应的value值，记为value_A；
第二层：以key_A为匹配条件，与HashMap2中的key进行匹配，如匹配成功则返回key对应的value，记为value_B；若value_B与value_A匹配成功，则跳出至第一层继续轮询，如value_B与value_A匹配失败，则将布尔型变量值置为False，同时跳出整个两层轮询。
从上述描述可知，本申请实施例提供的灰度发布方法，通过二层轮询的设置方式，能够提高判断所述第三哈希变量和所述第二哈希变量各自对应的键值对的值是否匹配成功的效率及准确性，进而能够进一步提高灰度发布的效率及准确性。
从软件层面来说，为了解决现有的灰度发布方法存在的无法同时解决效率低下、占用系统开销大及系统稳定性较差等问题，本申请提供一种用于执行所述灰度发布方法中全部或部分内容的应用服务器的实施例，参见图8，所述应用服务器具体包含有如下内容：
请求接收模块10，用于接收服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数。
在请求接收模块10的一种情形中，若所述服务请求为客户端设备发出的，则由于客户端设备默认发出非灰度域名地址，那么当前的服务请求中的所述目标服务端标识可以为非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址；其中，第一IP地址可以由DNS服务器根据非灰度域名地址发送至客户端设备，且在DNS服务器中，不但存储有非灰度域名地址和第一IP地址之间的对应关系，还存有所述灰度服务端标识唯一对应有预先获取的灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址。
举例来说：DNS服务器中除了已有的服务端的非灰度域名地址与IP的对应关系，需要增加一个灰度域名地址与IP地址的对应关系，可以定义为“非灰域名地址：IP地址1”、“灰度域名地址：IP地址2”，其中，IP地址1即为第一IP地址的举例，IP地址2即为第二IP地址的举例，第一IP地址与第二IP地址是不同的地址。
基于此，接收到服务请求的当前应用服务器可以直接根据读取服务请求中的域名地址为非灰度域名地址还是灰度域名地址来判断自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，即，若接收到服务请求的当前应用服务器读取服务请求中的域名地址为非灰度域名地址，则判定自身属于非灰度集群内的应用服务器。但是，应用该方式的应用服务器若无法区分非灰度域名地址和灰度域名地址，则无法准确判断自身所述集群。基于此，在一种更为优选的实现方式中，应用服务器可以通过判断自身所处环境来确定自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器。
在请求接收模块10的另一种情形中，若所述服务请求为非灰度集群中的应用服务器经由负载均衡服务器发出的，即在执行新请求构建模块40及转发执行模块50后生成并发送的新的服务请求，例如可以为生成并发送一个新URL请求，则基于新请求构建模块40可知该服务请求中的目标服务端标识为：与用户自客户端设备发出的非灰度服务端标识相对应的灰度服务端标识，则此时，接收到该服务请求的应用服务器可以直接根据读取服务请求中的域名地址为非灰度域名地址还是灰度域名地址来判断自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，即，若接收到服务请求的当前应用服务器读取服务请求中的域名地址为灰度域名地址，则判定自身属于灰度集群内的应用服务器。但与非灰度集群内的应用服务器相类似的是：应用该方式的应用服务器若无法区分非灰度域名地址和灰度域名地址，则无法准确判断自身所述集群。基于此，在一种更为优选的实现方式中，应用服务器可以通过判断自身所处环境来确定自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器。
规则获取模块20，用于若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息。
可以理解的是，所述灰度关键信息至少可以包含有存储在灰度规则中的灰度名称属性值和灰度参数元素的文本节点信息。
规则匹配模块30，用于基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则由新请求构建模块40执行：获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求。
转发执行模块50，用于将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。
本申请提供的应用服务器的实施例具体可以用于执行上述实施例中的灰度发布方法的实施例的处理流程，其功能在此不再赘述，可以参照上述方法实施例的详细描述。
从上述描述可知，本申请实施例提供的应用服务器，由应用服务器自行确定自身是灰度服务器还是非灰度服务器，并由应用服务器根据自身角色自行判断当前的服务请求是否符合灰度规则，若非灰度服务器接收到的服务请求符合灰度规则，则由非灰度服务器将服务请求转发至灰度服务器进行处理，能够有效实现自动灰度发布，且能够有效提高灰度发布过程的处理效率，能够有效降低工作量及时间成本，同时能够适用于各类型的灰度规则，尤其针对复杂的灰度规则，不会占用过大的系统开销，能够有效降低灰度发布过程中系统开销及负担，并能够有效提高网络分流及WEB接入转发效率；还由于整个灰度发布方法由应用服务器自行执行，因此没有产生新的服务器节点或代理服务器，进而能够有效缩短系统处理流程，并能够有效提高整体系统处理链路的稳定性，尤其适用于分布式系统，能够有效保证分布式系统的处理性能。
为了有效提高灰度发布的智能化程度及处理效率，在本申请提供的应用服务器的一个实施例，参见图9，所述应用服务器还具体包含有如下内容：
非灰度执行模块60，用于若确定所述服务请求与所述灰度规则匹配失败，则自行执行所述服务请求对应的请求业务；其中，当前的所述目标服务端标识为非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址；所述非灰度服务端标识唯一对应有预先存储的灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址。
在非灰度执行模块60中，若确定所述服务请求与所述灰度规则匹配失败，则说明当前的服务请求对应的请求业务并不在灰度集群中的应用服务器的处理范畴内，因此需要有接收到该服务请求的非灰度集群内的应用服务器自行处理。
从上述描述可知，本申请实施例提供的应用服务器，确定自身为非灰度服务器的应用服务器，在确定当前的服务请求不符合灰度规则后，能够自行直接执行该服务请求对应的服务请求业务，进而能够有效提高灰度发布的智能化程度及处理效率，有效提高灰度发布的适应全面性及可靠性。
为了进一步提高服务请求处理的效率，在本申请提供的应用服务器的一个实施例，参见图10，所述应用服务器还具体包含有如下内容：
环境读取模块01，用于读取本地环境变量的值，并根据该环境变量的值判断自身所属集群为非灰度集群或灰度集群。
在环境读取模块01中，灰度集群与非灰度集群在物理上隔离部署，均包含各自的WEB服务器与应用服务器，同时两个集群均可通过与灰度规则服务器交互获取灰度规则；运维人员可通过手工或自动化脚本的方式，在非灰度集群和灰度集群每个应用服务器中，都增加一个自定义的环境变量grayTag，其中非灰度集群下应用服务器的grayTag值为0，灰度集群下应用服务器的grayTag值为1。
灰度执行模块02，用于若确定自身为灰度集群内的应用服务器，则执行自身接收到的服务请求对应的请求业务；其中，当前的所述目标服务端标识为灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址；所述灰度服务端标识唯一对应有预先获取的非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址。
从上述描述可知，本申请实施例提供的应用服务器，已确定自身为灰度服务器的应用服务器，说明其当前接收到的服务请求服务已经被非灰度服务器确定为符合灰度规则的服务请求，因此灰度服务期无需再判断当前的服务请求是否符合灰度规则，直接进行该服务请求对应的服务请求业务的执行即可，进而能够有效减少灰度服务器的运行消耗，并能够进一步提高服务请求处理的效率，进一步有效提高灰度发布的适应全面性及可靠性。
为了提高对灰度规则进行修改及增减等变更操作的便捷性，在本申请提供的应用服务器的一个实施例，所述应用服务器中的规则获取模块20具体用于执行下述内容：
步骤210：将所述请求路径作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息。
从上述描述可知，本申请实施例提供的应用服务器，通过设置灰度规则服务器，并调用灰度规则服务器的接口，能够有效提高灰度规则获取的效率及准确性，且灰度规则服务器独立设置，能够有效提高对灰度规则进行修改及增减等变更操作的便捷性，进而进一步提高灰度发布过程的有效性及应用全面性。
为了提高对灰度规则进行修改及增减等变更操作的便捷性，在本申请提供的应用服务器的一个实施例，所述应用服务器中的规则获取模块20还具体用于执行下述内容：
步骤211：根据所述请求路径及请求参数生成第一哈希变量；其中，该第一哈希变量的键值对的关键字包括所述请求路径，该第一哈希变量的键值对的值包括第二哈希变量；所述第二哈希变量的键值对的关键字包括所述请求参数的类型，该第二哈希变量的键值对的值包括所述请求参数的值。
具体来说，可以对服务请求进行数据解析，从而提取得到服务请求数据中的关键要素(请求路径及请求参数/参数值)，并将关键要素构造成为一个HashMap类型的变量，记为第一哈希变量HashMap1，其中，请求路径为HashMap1的key，请求参数/参数值作为HashMap1的value，HashMap1的value也为HashMap类型，记为第二哈希变量HashMap2，其中每个请求参数作为HashMap2的一个key，参数值作为key所对应的value。
步骤212：将所述第一哈希变量作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息的第三哈希变量；其中，所述第三哈希变量的键值对的关键字包括灰度名称属性值，该第三哈希变量的键值对的值包括灰度参数元素的文本节点信息。
具体来说，接收得到的第一哈希变量HashMap1作为输入参数，调用灰度规则服务器上的规则获取服务化接口，服务化接口读取本地rule.xml文件，以HashMap1对象的key(请求路径)为条件，获取根节点grayRules下属性名称和key匹配的子元素grayRule；然后获取grayRule下每个grayParam元素的grayName属性值以及元素的文本节点信息，构造成一个新HashMap，定义为第三哈希变量HashMap3，其中的grayName属性值作为HashMap3的key，元素的文本节点信息作为关键字key对应的值value。
从上述描述可知，本申请实施例提供的应用服务器，通过哈希变量的应用，能够提高调取灰度规则服务器中灰度规则的便捷性及效率，进而能够进一步提高灰度发布的便捷性及效率。
为了进一步提高灰度发布的效率及准确性，在本申请提供的应用服务器的一个实施例，所述应用服务器中的规则匹配模块30具体用于执行下述内容：
步骤310：根据所述第二哈希变量定义一布尔型变量，且该布尔型变量的初始状态为执行成功。
步骤320：分别轮询所述第三哈希变量和所述第二哈希变量，以确认所述第三哈希变量和所述第二哈希变量各自对应的键值对的值是否匹配成功，若匹配失败，则将布尔型变量的状态修改为执行失败。
步骤330：根据当前所述布尔型变量的状态确定所述服务请求是否与所述灰度规则匹配成功。
具体来说，首先利用请求路径获取HashMap1中的value(即HashMap2)，并定义一个布尔型变量，布尔型变量值默认为执行成功True，然后分两层分别轮询HashMap3、HashMap2，若所述服务请求与所述灰度规则匹配成功，则布尔型变量值不变，为执行成功True；若所述服务请求与所述灰度规则匹配失败，则将布尔型变量值置为执行失败False。
从上述描述可知，本申请实施例提供的应用服务器，通过应用布尔型变量，能够提高判断所述服务请求是否与所述灰度规则匹配成功的效率及准确性，进而能够进一步提高灰度发布的效率及准确性。
为了进一步提高灰度发布的效率及准确性，在本申请提供的应用服务器的一个实施例，所述应用服务器中的规则匹配模块30还具体用于执行下述内容：
步骤321：执行第一层轮询：轮询所述第三哈希变量，且将当前轮询均获取所述第三哈希变量中的一条关键字，并将当前轮询到的所述第三哈希变量中的关键字对应的值记录为第一比较值；
步骤322：执行第二层轮询：以所述第三哈希变量中的关键字为匹配条件，与所述第二哈希变量中的关键字进行匹配，若匹配成功，则将匹配到的所述第二哈希变量中的关键字对应的值记录为第二比较值；并执行步骤323；
步骤323：判断所述第一比较值与所述第二比较值是否匹配成功；
若所述第一比较值与所述第二比较值匹配成功，则返回执行步骤321：所述第一层轮询；若第一比较值与所述第二比较值匹配失败，则执行步骤324；
步骤324：结束第一层轮询和第二层轮询，并将所述布尔型变量的状态修改为执行失败。
具体来说：分两层分别轮询HashMap3、HashMap2的具体过程为：
第一层：轮询HashMap3，每次轮询均获取HashMap3中的一条key，记为key_A，其对应的value值，记为value_A；
第二层：以key_A为匹配条件，与HashMap2中的key进行匹配，如匹配成功则返回key对应的value，记为value_B；若value_B与value_A匹配成功，则跳出至第一层继续轮询，如value_B与value_A匹配失败，则将布尔型变量值置为False，同时跳出整个两层轮询。
从上述描述可知，本申请实施例提供的应用服务器，通过二层轮询的设置方式，能够提高判断所述第三哈希变量和所述第二哈希变量各自对应的键值对的值是否匹配成功的效率及准确性，进而能够进一步提高灰度发布的效率及准确性。
基于上述灰度发布方法和/或应用服务器的实施例，本申请还提供一种灰度发布系统的实施例，参见图11，所述灰度发布系统包括：负载均衡服务器、非灰度集群、灰度集群和灰度规则服务器；
所述非灰度集群和所述灰度集群中均包含有WEB服务器和与所述WEB服务器通信连接的应用服务器，所述应用服务器用于所述的灰度发布方法；在一种举例中，非灰度集群中可以包含有应用服务器A至D，灰度集群中包含有应用服务器E和应用服务器。
所述负载均衡服务器用于接收客户端设备发送的服务请求，若所述服务请求中的目标服务端标识为非灰度服务端标识，则将该服务请求发送至所述非灰度集群内的WEB服务器；若所述服务请求中的目标服务端标识为灰度服务端标识，则将该服务请求发送至所述灰度集群内的WEB服务器；
各个所述WEB服务器分别与所述负载均衡服务器之间通信连接，所述WEB服务器用于将接收自所述负载均衡服务器的所述服务请求转发至所属集群中的一所述应用服务器；
各个所述应用服务器分别与所述灰度规则服务器之间通信连接，所述灰度规则服务器用于存储所述灰度规则。
本申请提供的灰度发布系统的实施例具体可以用于执行上述实施例中的灰度发布方法和/或应用服务器的实施例的处理流程，其功能在此不再赘述，可以参照上述灰度发布方法和/或应用服务器实施例的详细描述。
从上述描述可知，本申请实施例提供的灰度发布系统，由应用服务器自行确定自身是灰度服务器还是非灰度服务器，并由应用服务器根据自身角色自行判断当前的服务请求是否符合灰度规则，若非灰度服务器接收到的服务请求符合灰度规则，则由非灰度服务器将服务请求转发至灰度服务器进行处理，能够有效实现自动灰度发布，且能够有效提高灰度发布过程的处理效率，能够有效降低工作量及时间成本，同时能够适用于各类型的灰度规则，尤其针对复杂的灰度规则，不会占用过大的系统开销，能够有效降低灰度发布过程中系统开销及负担，并能够有效提高网络分流及WEB接入转发效率；还由于整个灰度发布方法由应用服务器自行执行，因此没有产生新的服务器节点或代理服务器，进而能够有效缩短系统处理流程，并能够有效提高整体系统处理链路的稳定性，尤其适用于分布式系统，能够有效保证分布式系统的处理性能。
为了进一步说明书本方案，本申请还提供一种灰度发布方法及系统的具体应用实例，主要解决现有灰度发布方法带来的功能代码修改、发布工作量大且耗费时间、以及服务器系统开销大和系统稳定性不足等技术问题。
参见图12，所述灰度发布系统主要描述如下：
(1)客户端：是指发起交易请求的终端，具体可以是PC或移动APP中安装的本地程序，一般通过满足http协议的URL形式发起请求，请求中包括服务端域名地址、请求路径及请求参数，其中域名地址为非灰度域名地址。
(2)DNS服务器：用来解析域名的服务器，可以解析得到客户端请求中域名对应的IP地址，并将IP地址返回给客户端；DNS服务器中除了已有的服务端非灰域名与IP的对应关系，需要增加一个灰度域名地址与IP地址的对应关系，可以定义为“非灰域名地址：IP地址1”、“灰度域名地址：IP地址2”(IP地址1与IP地址2是不同的地址)。
(3)负载均衡服务器：用来将客户端的请求，按照某种转发的策略，均匀的分发到后端多台服务器上，从而提高系统的服务能力；本申请应用实例中负载均衡采取硬件方式实现，例如使用F5，在F5中配置两个IP地址，分别与DNS服务器中配置的IP地址1、IP地址2保持一致；同时在F5上定义对应关系，使F5上IP地址1接收的请求负载至非灰度集群，IP地址2负载至灰度集群。
(4)非灰度集群：即存量生产上已部署，且在正常运行中的WEB服务器、应用服务器及其上安装的程序(旧程序，以下简称非灰程序)；WEB服务器与应用服务器中间也可以通过内网DNS或F5实现负载均衡，使WEB服务器与应用服务器存在一对多的关系；其中WEB服务器用来接入上游F5转发的客户端请求，并将请求直接转发或经负载均衡转发给后端应用服务器；应用服务器接收WEB服务器转发的客户端请求，并对请求路径及请求参数进行解析，解析后根据业务程序逻辑进行后续处理。
(5)灰度集群：即为灰度发布而新部署的集群，包括WEB服务器、应用服务器及其上安装的程序(新程序，以下简称灰度程序)。灰度集群与非灰度集群在物理上隔离部署，均包含各自的WEB服务器与应用服务器，同时两个集群均可通过与灰度规则服务器交互获取灰度规则；运维人员可通过手工或自动化脚本的方式，在非灰度集群和灰度集群每个应用服务器中，都增加一个自定义的环境变量grayTag，其中非灰度集群下应用服务器的grayTag值为0，灰度集群下应用服务器的grayTag值为1。
在本申请应用实例中，虽然两个集群应用服务器上的环境变量和安装的应用程序存在差异(非灰程序与灰度程序)，但WEB服务器没有区别，仅通过配置确保访问各自集群的应用服务器。
(6)灰度规则服务器：该服务器上部署的功能组件包含三部分，分别是灰度规则库、规则配置组件、规则获取组件，参见图13，主要功能包含有非灰/灰度应用程序对灰度规则库进行规则获取，以及运维人员对灰度规则库进行规则维护，灰度规则库用来存放灰度规则，即进入灰度集群需要满足的条件(具体参见“2、灰度规则库存储设计”)；规则配置组件对外面向运维人员提供前端规则维护页面，运维人员可根据具体灰度发布需要，维护灰度规则，并保存进入灰度规则库。
规则获取组件是一个后台服务化接口，供应用服务器上的非灰程序或灰度程序调用，程序调用该接口后，该接口会从灰度规则库中匹配对应规则并返回(匹配逻辑参见“3、灰度筛选组件设计及部署”中“灰度规则获取单元”)，如没有获取到规则，则返回空。
2、灰度规则库存储设计
灰度规则库用来存储已配置的灰度规则，具体为一个XML格式的文件(定义为rule.xml)，运维人员可事先通过前台规则维护功能或直接操作XML文件，在XML文件中定义和维护灰度规则信息。
XML文件根节点定义为grayRules，根节点下有可扩展的XML元素grayRule，每个客户端可请求的路径对应一个元素grayRule，其属性名称为ruleName，运维人员可根据具体需要，对XML中的grayRule元素数量进行新增或删除。
同时，每个grayRule下有可扩展的XML子元素grayParam，该请求路径可附带的每个参数均可对应一个子元素grayParam(即一个请求路径可以附带多个参数信息)，子元素属性名称为grayName；子元素grayParam中的文本节点即灰度规则值，支持常量及正则表达式两种形式。
3、灰度筛选组件设计及部署
该部分是本申请应用实例的核心。本应用实例设计了独立的灰度筛选组件，并将该组件的程序代码与应用程序共同打包，部署在应用服务器，其中，非灰度集群应用服务器与灰度集群应用服务器均部署，非灰度集群中应用服务器部署结构参见图14，包含有灰度筛选组件程序代码和非灰应用程序代码；灰度集群中应用服务器部署结构参见图15，包含有灰度筛选组件程序代码和灰应用程序代码。该组件内部包括服务器判断单元、参数解析单元、灰度规则获取单元、灰度匹配单元、请求转发单元，现分别介绍如下：
(1)服务器判断单元：客户端请求在DNS服务器解析后，经过负载均衡服务器-WEB服务器，转发至应用服务器处理，首先即进入灰度筛选组件的服务器判断单元。服务器判断单元会读取本服务器上的环境变量grayTag，如grayTag值为0，说明当前程序运行在非灰度集群的应用服务器上，该单元会将客户端请求透传给“参数解析单元”；如grayTag值为1，说明当前程序运行在灰度集群的应用服务器上，该单元会控制程序跳出该组件的后续单元，直接进入灰度业务程序中执行。
(2)参数解析单元：根据“服务器判断单元”的处理逻辑，该单元及后续单元的程序代码，仅会在非灰度集群的应用服务器中生效；参数解析单元获取到“服务器判断单元”透传的请求数据后，对请求数据进行解析，从而提取得到请求数据中的关键要素(请求路径及请求参数/参数值)，并将关键要素构造成为一个HashMap类型的变量，记为HashMap1，其中，请求路径为HashMap1的key，请求参数/参数值作为HashMap1的value(HashMap1的value也为HashMap类型，记为HashMap2，其中每个请求参数作为HashMap2的一个key，参数值作为key所对应的value)。构造完成后，该单元将请求路径、HashMap1传给灰度规则获取单元。
(3)灰度规则获取单元：该单元将接收得到的HashMap1作为输入参数，调用“灰度规则服务器”上的规则获取服务化接口。服务化接口读取本地rule.xml文件，以HashMap1对象的key(请求路径)为条件，获取根节点grayRules下属性名称和key匹配的子元素grayRule；然后获取grayRule下每个grayParam元素的grayName属性值以及元素的文本节点信息，构造成一个新HashMap，定义为HashMap3(其中grayName属性值作为HashMap3的key，元素的文本节点信息作为key对应的value)，并将HashMap3返回给灰度规则获取单元；灰度规则单元将HashMap3，连同之前接收的请求路径、HashMap1，一起传给灰度匹配单元。
(4)灰度匹配单元：灰度匹配单元首先利用请求路径获取HashMap1中的value(即HashMap2)，并定义一个布尔型变量，变量值默认为True，然后分两层分别轮询HashMap3、HashMap2：
第一层：轮询HashMap3，每次轮询均获取HashMap3中的一条key，记为key_A，其对应的value值，记为value_A；
第二层：以key_A为匹配条件，与HashMap2中的key进行匹配，如匹配成功则返回key对应的value，记为value_B；若value_B与value_A匹配成功，则跳出至第一层继续轮询，如value_B与value_A匹配失败，则将布尔型变量值置为False，同时跳出整个两层轮询；
轮询结束后，将布尔型变量、请求路径、HashMap2传给请求转发单元。
(5)请求转发单元：如布尔型变量为True，则说明灰度规则匹配成功，“灰度请求单元”会将将灰度域名(提前预置)、请求路径、HashMap2(原始请求参数及参数值)，重新构造成一个新URL请求并进行访问；如布尔型变量为False，则说明灰度规则匹配失败，则继续由当前灰度筛选组件所在应用服务器中的应用程序代码进行后续业务处理。
综上所述，本申请提供了一种灰度发布方法及系统，能够解决现有灰度发布方法带来的功能代码修改、发布工作量大且耗费时间、以及服务器系统开销大和系统稳定性不足等技术问题；通过自定义环境变量、灰度筛选组件与应用程序代码合并打包、共享灰度规则库等设计，在应用服务器层实现了灰度规则的判断与筛选；尤其是灰度程序向非灰度集群同步时，只需在删除灰度规则后进行正常灰度程序安装即可，无需其他操作，可操作性强，极大提高了灰度程序的同步效率和便捷性。
从硬件层面来说，为了解决现有的灰度发布方法存在的无法同时解决效率低下、占用系统开销大及系统稳定性较差等问题，本申请提供一种用于实现所述灰度发布方法中的全部或部分内容的电子设备的实施例，所述电子设备具体包含有如下内容：
图16为本申请实施例的电子设备9600的系统构成的示意框图。如图16所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图16是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。
在一实施例中，灰度发布功能可以被集成到中央处理器中。其中，中央处理器可以被配置为进行如下控制：
步骤100：接收服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数。
在步骤100的一种情形中，若所述服务请求为客户端设备发出的，则由于客户端设备默认发出非灰度域名地址，那么当前的服务请求中的所述目标服务端标识可以为非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址；其中，第一IP地址可以由DNS服务器根据非灰度域名地址发送至客户端设备，且在DNS服务器中，不但存储有非灰度域名地址和第一IP地址之间的对应关系，还存有所述灰度服务端标识唯一对应有预先获取的灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址。
举例来说：DNS服务器中除了已有的服务端的非灰度域名地址与IP的对应关系，需要增加一个灰度域名地址与IP地址的对应关系，可以定义为“非灰域名地址：IP地址1”、“灰度域名地址：IP地址2”，其中，IP地址1即为第一IP地址的举例，IP地址2即为第二IP地址的举例，第一IP地址与第二IP地址是不同的地址。
基于此，接收到服务请求的当前应用服务器可以直接根据读取服务请求中的域名地址为非灰度域名地址还是灰度域名地址来判断自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，即，若接收到服务请求的当前应用服务器读取服务请求中的域名地址为非灰度域名地址，则判定自身属于非灰度集群内的应用服务器。但是，应用该方式的应用服务器若无法区分非灰度域名地址和灰度域名地址，则无法准确判断自身所述集群。基于此，在一种更为优选的实现方式中，应用服务器可以通过判断自身所处环境来确定自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器。
在步骤100的另一种情形中，若所述服务请求为非灰度集群中的应用服务器经由负载均衡服务器发出的，即在执行步骤400及步骤500后生成并发送的新的服务请求，例如可以为生成并发送一个新URL请求，则基于步骤400可知该服务请求中的目标服务端标识为：与用户自客户端设备发出的非灰度服务端标识相对应的灰度服务端标识，则此时，接收到该服务请求的应用服务器可以直接根据读取服务请求中的域名地址为非灰度域名地址还是灰度域名地址来判断自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，即，若接收到服务请求的当前应用服务器读取服务请求中的域名地址为灰度域名地址，则判定自身属于灰度集群内的应用服务器。但与非灰度集群内的应用服务器相类似的是：应用该方式的应用服务器若无法区分非灰度域名地址和灰度域名地址，则无法准确判断自身所述集群。基于此，在一种更为优选的实现方式中，应用服务器可以通过判断自身所处环境来确定自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器。
步骤200：若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息。
可以理解的是，所述灰度关键信息至少可以包含有存储在灰度规则中的灰度名称属性值和灰度参数元素的文本节点信息。
步骤300：基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则执行步骤400：获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求。
步骤500：将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。
从上述描述可知，本申请实施例提供的电子设备，由应用服务器自行确定自身是灰度服务器还是非灰度服务器，并由应用服务器根据自身角色自行判断当前的服务请求是否符合灰度规则，若非灰度服务器接收到的服务请求符合灰度规则，则由非灰度服务器将服务请求转发至灰度服务器进行处理，能够有效实现自动灰度发布，且能够有效提高灰度发布过程的处理效率，能够有效降低工作量及时间成本，同时能够适用于各类型的灰度规则，尤其针对复杂的灰度规则，不会占用过大的系统开销，能够有效降低灰度发布过程中系统开销及负担，并能够有效提高网络分流及WEB接入转发效率；还由于整个灰度发布方法由应用服务器自行执行，因此没有产生新的服务器节点或代理服务器，进而能够有效缩短系统处理流程，并能够有效提高整体系统处理链路的稳定性，尤其适用于分布式系统，能够有效保证分布式系统的处理性能。
在另一个实施方式中，应用服务器可以与中央处理器9100分开配置，例如可以将应用服务器配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现灰度发布功能。
如图16所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图16中所示的所有部件；此外，电子设备9600还可以包括图16中没有示出的部件，可以参考现有技术。
如图16所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。
其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。
输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。
该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。
存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。
通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。
基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。
本申请的实施例还提供能够实现上述实施例中的灰度发布方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的执行主体为服务器或客户端的灰度发布方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：
步骤100：接收服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数。
在步骤100的一种情形中，若所述服务请求为客户端设备发出的，则由于客户端设备默认发出非灰度域名地址，那么当前的服务请求中的所述目标服务端标识可以为非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址；其中，第一IP地址可以由DNS服务器根据非灰度域名地址发送至客户端设备，且在DNS服务器中，不但存储有非灰度域名地址和第一IP地址之间的对应关系，还存有所述灰度服务端标识唯一对应有预先获取的灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址。
举例来说：DNS服务器中除了已有的服务端的非灰度域名地址与IP的对应关系，需要增加一个灰度域名地址与IP地址的对应关系，可以定义为“非灰域名地址：IP地址1”、“灰度域名地址：IP地址2”，其中，IP地址1即为第一IP地址的举例，IP地址2即为第二IP地址的举例，第一IP地址与第二IP地址是不同的地址。
基于此，接收到服务请求的当前应用服务器可以直接根据读取服务请求中的域名地址为非灰度域名地址还是灰度域名地址来判断自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，即，若接收到服务请求的当前应用服务器读取服务请求中的域名地址为非灰度域名地址，则判定自身属于非灰度集群内的应用服务器。但是，应用该方式的应用服务器若无法区分非灰度域名地址和灰度域名地址，则无法准确判断自身所述集群。基于此，在一种更为优选的实现方式中，应用服务器可以通过判断自身所处环境来确定自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器。
在步骤100的另一种情形中，若所述服务请求为非灰度集群中的应用服务器经由负载均衡服务器发出的，即在执行步骤400及步骤500后生成并发送的新的服务请求，例如可以为生成并发送一个新URL请求，则基于步骤400可知该服务请求中的目标服务端标识为：与用户自客户端设备发出的非灰度服务端标识相对应的灰度服务端标识，则此时，接收到该服务请求的应用服务器可以直接根据读取服务请求中的域名地址为非灰度域名地址还是灰度域名地址来判断自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器，即，若接收到服务请求的当前应用服务器读取服务请求中的域名地址为灰度域名地址，则判定自身属于灰度集群内的应用服务器。但与非灰度集群内的应用服务器相类似的是：应用该方式的应用服务器若无法区分非灰度域名地址和灰度域名地址，则无法准确判断自身所述集群。基于此，在一种更为优选的实现方式中，应用服务器可以通过判断自身所处环境来确定自身属于非灰度集群中的应用服务器还是灰度集群中的应用服务器。
步骤200：若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息。
可以理解的是，所述灰度关键信息至少可以包含有存储在灰度规则中的灰度名称属性值和灰度参数元素的文本节点信息。
步骤300：基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则执行步骤400：获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求。
步骤500：将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。
从上述描述可知，本申请实施例提供的计算机可读存储介质，由应用服务器自行确定自身是灰度服务器还是非灰度服务器，并由应用服务器根据自身角色自行判断当前的服务请求是否符合灰度规则，若非灰度服务器接收到的服务请求符合灰度规则，则由非灰度服务器将服务请求转发至灰度服务器进行处理，能够有效实现自动灰度发布，且能够有效提高灰度发布过程的处理效率，能够有效降低工作量及时间成本，同时能够适用于各类型的灰度规则，尤其针对复杂的灰度规则，不会占用过大的系统开销，能够有效降低灰度发布过程中系统开销及负担，并能够有效提高网络分流及WEB接入转发效率；还由于整个灰度发布方法由应用服务器自行执行，因此没有产生新的服务器节点或代理服务器，进而能够有效缩短系统处理流程，并能够有效提高整体系统处理链路的稳定性，尤其适用于分布式系统，能够有效保证分布式系统的处理性能。
本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
Claims (11)
1.一种灰度发布方法，其特征在于，包括：
接收服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数；
若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息；
基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求；
将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。
2.根据权利要求1所述的灰度发布方法，其特征在于，还包括：
若确定所述服务请求与所述灰度规则匹配失败，则自行执行所述服务请求对应的请求业务；
其中，当前的所述目标服务端标识为非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址；
所述非灰度服务端标识唯一对应有预先存储的灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址。
3.根据权利要求1所述的灰度发布方法，其特征在于，在所述接收服务请求之后，还包括：
读取本地环境变量的值，并根据该环境变量的值判断自身所属集群为非灰度集群或灰度集群；
若确定自身为灰度集群内的应用服务器，则执行自身接收到的服务请求对应的请求业务；
其中，当前的所述目标服务端标识为灰度服务端标识，该灰度服务端标识包括：灰度域名地址对应的第二IP地址；
所述灰度服务端标识唯一对应有预先获取的非灰度服务端标识，该非灰度服务端标识包括：非灰度域名地址对应的第一IP地址。
4.根据权利要求1所述的灰度发布方法，其特征在于，所述根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息，包括：
将所述请求路径作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息。
5.根据权利要求4所述的灰度发布方法，其特征在于，所述将所述请求路径作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息，包括：
根据所述请求路径及请求参数生成第一哈希变量；
其中，该第一哈希变量的键值对的关键字包括所述请求路径，该第一哈希变量的键值对的值包括第二哈希变量；所述第二哈希变量的键值对的关键字包括所述请求参数的类型，该第二哈希变量的键值对的值包括所述请求参数的值；
将所述第一哈希变量作为输入参数，调用存储有所述灰度规则的灰度规则服务器的接口，以生成作为所述灰度关键信息的第三哈希变量；
其中，所述第三哈希变量的键值对的关键字包括灰度名称属性值，该第三哈希变量的键值对的值包括灰度参数元素的文本节点信息。
6.根据权利要求5所述的灰度发布方法，其特征在于，所述基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，包括：
根据所述第二哈希变量定义一布尔型变量，且该布尔型变量的初始状态为执行成功；
分别轮询所述第三哈希变量和所述第二哈希变量，以确认所述第三哈希变量和所述第二哈希变量各自对应的键值对的值是否匹配成功，若匹配失败，则将布尔型变量的状态修改为执行失败；
根据当前所述布尔型变量的状态确定所述服务请求是否与所述灰度规则匹配成功。
7.根据权利要求6所述的灰度发布方法，其特征在于，所述分别轮询所述第三哈希变量和所述第二哈希变量，以确认所述第三哈希变量和所述第二哈希变量各自对应的键值对的值是否匹配成功，包括：
执行第一层轮询：轮询所述第三哈希变量，且将当前轮询均获取所述第三哈希变量中的一条关键字，并将当前轮询到的所述第三哈希变量中的关键字对应的值记录为第一比较值；
执行第二层轮询：以所述第三哈希变量中的关键字为匹配条件，与所述第二哈希变量中的关键字进行匹配，若匹配成功，则将匹配到的所述第二哈希变量中的关键字对应的值记录为第二比较值；确定所述第一比较值与所述第二比较值是否匹配成功，若所述第一比较值与所述第二比较值匹配成功，则返回执行所述第一层轮询；若第一比较值与所述第二比较值匹配失败，则结束第一层轮询和第二层轮询，并将所述布尔型变量的状态修改为执行失败。
8.一种应用服务器，其特征在于，包括：
请求接收模块，用于接收服务请求，其中，所述服务请求中包含有目标服务端标识、请求路径及请求参数；
规则获取模块，用于若确定自身为非灰度集群内的应用服务器，则根据所述请求路径自预设的灰度规则中获取对应的灰度关键信息；
规则匹配模块，用于基于所述灰度关键信息和请求参数确定所述服务请求是否与所述灰度规则匹配成功，若是，则获取预存储的与所述目标服务端标识对应的灰度服务端标识，并根据该灰度服务端标识、请求路径及请求参数生成新的服务请求；
转发执行模块，用于将新的服务请求转发至灰度集群内的应用服务器，以使所述灰度集群内的应用服务器执行自身接收到的服务请求对应的请求业务。
9.一种灰度发布系统，其特征在于，包括：负载均衡服务器、非灰度集群、灰度集群和灰度规则服务器；
所述非灰度集群和所述灰度集群中均包含有WEB服务器和与所述WEB服务器通信连接的应用服务器，所述应用服务器用于实现权利要求1至7任一项所述的灰度发布方法；
所述负载均衡服务器用于接收客户端设备发送的服务请求，若所述服务请求中的目标服务端标识为非灰度服务端标识，则将该服务请求发送至所述非灰度集群内的WEB服务器；若所述服务请求中的目标服务端标识为灰度服务端标识，则将该服务请求发送至所述灰度集群内的WEB服务器；
各个所述WEB服务器分别与所述负载均衡服务器之间通信连接，所述WEB服务器用于将接收自所述负载均衡服务器的所述服务请求转发至所属集群中的一所述应用服务器；
各个所述应用服务器分别与所述灰度规则服务器之间通信连接，所述灰度规则服务器用于存储所述灰度规则。
10.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的灰度发布方法。
11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至7任一项所述的灰度发布方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110233005.9A CN113014651B (zh) | 2021-03-03 | 2021-03-03 | 灰度发布方法、应用服务器及灰度发布系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110233005.9A CN113014651B (zh) | 2021-03-03 | 2021-03-03 | 灰度发布方法、应用服务器及灰度发布系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113014651A true CN113014651A (zh) | 2021-06-22 |
| CN113014651B CN113014651B (zh) | 2022-09-27 |
Family
ID=76403144
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110233005.9A Active CN113014651B (zh) | 2021-03-03 | 2021-03-03 | 灰度发布方法、应用服务器及灰度发布系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113014651B (zh) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113381938A (zh) * | 2021-06-30 | 2021-09-10 | 北京字节跳动网络技术有限公司 | 数据包发送方法、装置、存储介质及电子设备 |
| CN113452776A (zh) * | 2021-06-25 | 2021-09-28 | 中国工商银行股份有限公司 | PaaS平台服务调度方法、装置及PaaS平台 |
| CN113542387A (zh) * | 2021-07-09 | 2021-10-22 | 平安银行股份有限公司 | 系统发布方法、装置、电子设备及存储介质 |
| CN113873054A (zh) * | 2021-09-13 | 2021-12-31 | 支付宝(杭州)信息技术有限公司 | 基于DNS的IPv6引流方法、装置以及设备 |
| CN113923081A (zh) * | 2021-10-15 | 2022-01-11 | 北京同城必应科技有限公司 | 分布式环境下灰度发布的业务网关解决方案 |
| CN114598553A (zh) * | 2022-03-29 | 2022-06-07 | 中国工商银行股份有限公司 | 一种灰度发布方法及灰度发布装置 |
| CN114648411A (zh) * | 2022-03-25 | 2022-06-21 | 四川新网银行股份有限公司 | 一种网关服务一键发布方法、系统及存储介质 |
| CN114840249A (zh) * | 2022-05-18 | 2022-08-02 | 吉林银行股份有限公司 | 集中式业务系统的灰度发布方法、装置及设备 |
| CN114884915A (zh) * | 2022-04-19 | 2022-08-09 | 阿里巴巴（中国）有限公司 | 基于灰度发布的消息处理方法、装置以及设备 |
| CN116132284A (zh) * | 2022-12-19 | 2023-05-16 | 江苏红网技术股份有限公司 | 一种服务接口在服务网格中实现灰度发布的方法及其系统 |
| CN117032991A (zh) * | 2023-10-08 | 2023-11-10 | 宁波银行股份有限公司 | 一种灰度发布方法、装置及系统 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111736872A (zh) * | 2020-06-22 | 2020-10-02 | 平安健康保险股份有限公司 | 灰度发布升级方法、装置、计算机系统及可读存储介质 |
| CN111756841A (zh) * | 2020-06-23 | 2020-10-09 | 中国平安财产保险股份有限公司 | 基于微服务集群的业务实现方法、装置、设备及存储介质 |
| CN111782260A (zh) * | 2020-06-29 | 2020-10-16 | 中国工商银行股份有限公司 | 灰度发布方法及灰度发布装置 |
| US20200412644A1 (en) * | 2019-06-28 | 2020-12-31 | Beijing Baidu Netcom Science And Technology Co., Ltd. | Content based routing method and apparatus |
-
2021
- 2021-03-03 CN CN202110233005.9A patent/CN113014651B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200412644A1 (en) * | 2019-06-28 | 2020-12-31 | Beijing Baidu Netcom Science And Technology Co., Ltd. | Content based routing method and apparatus |
| CN111736872A (zh) * | 2020-06-22 | 2020-10-02 | 平安健康保险股份有限公司 | 灰度发布升级方法、装置、计算机系统及可读存储介质 |
| CN111756841A (zh) * | 2020-06-23 | 2020-10-09 | 中国平安财产保险股份有限公司 | 基于微服务集群的业务实现方法、装置、设备及存储介质 |
| CN111782260A (zh) * | 2020-06-29 | 2020-10-16 | 中国工商银行股份有限公司 | 灰度发布方法及灰度发布装置 |
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113452776A (zh) * | 2021-06-25 | 2021-09-28 | 中国工商银行股份有限公司 | PaaS平台服务调度方法、装置及PaaS平台 |
| CN113452776B (zh) * | 2021-06-25 | 2022-12-09 | 中国工商银行股份有限公司 | PaaS平台服务调度方法、装置及PaaS平台 |
| CN113381938B (zh) * | 2021-06-30 | 2022-12-06 | 北京字节跳动网络技术有限公司 | 数据包发送方法、装置、存储介质及电子设备 |
| CN113381938A (zh) * | 2021-06-30 | 2021-09-10 | 北京字节跳动网络技术有限公司 | 数据包发送方法、装置、存储介质及电子设备 |
| CN113542387A (zh) * | 2021-07-09 | 2021-10-22 | 平安银行股份有限公司 | 系统发布方法、装置、电子设备及存储介质 |
| CN113542387B (zh) * | 2021-07-09 | 2023-07-04 | 平安银行股份有限公司 | 系统发布方法、装置、电子设备及存储介质 |
| CN113873054A (zh) * | 2021-09-13 | 2021-12-31 | 支付宝(杭州)信息技术有限公司 | 基于DNS的IPv6引流方法、装置以及设备 |
| CN113923081A (zh) * | 2021-10-15 | 2022-01-11 | 北京同城必应科技有限公司 | 分布式环境下灰度发布的业务网关解决方案 |
| CN114648411A (zh) * | 2022-03-25 | 2022-06-21 | 四川新网银行股份有限公司 | 一种网关服务一键发布方法、系统及存储介质 |
| CN114648411B (zh) * | 2022-03-25 | 2024-06-25 | 四川新网银行股份有限公司 | 一种网关服务一键发布方法、系统及存储介质 |
| CN114598553A (zh) * | 2022-03-29 | 2022-06-07 | 中国工商银行股份有限公司 | 一种灰度发布方法及灰度发布装置 |
| CN114884915A (zh) * | 2022-04-19 | 2022-08-09 | 阿里巴巴（中国）有限公司 | 基于灰度发布的消息处理方法、装置以及设备 |
| CN114884915B (zh) * | 2022-04-19 | 2024-03-26 | 阿里巴巴（中国）有限公司 | 基于灰度发布的消息处理方法、装置以及设备 |
| CN114840249A (zh) * | 2022-05-18 | 2022-08-02 | 吉林银行股份有限公司 | 集中式业务系统的灰度发布方法、装置及设备 |
| CN114840249B (zh) * | 2022-05-18 | 2023-08-08 | 吉林银行股份有限公司 | 集中式业务系统的灰度发布方法、装置及设备 |
| CN116132284A (zh) * | 2022-12-19 | 2023-05-16 | 江苏红网技术股份有限公司 | 一种服务接口在服务网格中实现灰度发布的方法及其系统 |
| CN116132284B (zh) * | 2022-12-19 | 2023-09-08 | 江苏红网技术股份有限公司 | 一种服务接口在服务网格中实现灰度发布的方法及其系统 |
| CN117032991A (zh) * | 2023-10-08 | 2023-11-10 | 宁波银行股份有限公司 | 一种灰度发布方法、装置及系统 |
| CN117032991B (zh) * | 2023-10-08 | 2024-01-26 | 宁波银行股份有限公司 | 一种灰度发布方法、装置及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113014651B (zh) | 2022-09-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113014651B (zh) | 灰度发布方法、应用服务器及灰度发布系统 | |
| CN108510389A (zh) | 基于区块链的智能合约调用方法、设备及可读存储介质 | |
| CN111786885B (zh) | 分布式全链路灰度路由方法及装置 | |
| AU2019256257B2 (en) | Processor core scheduling method and apparatus, terminal, and storage medium | |
| CN113748685A (zh) | 基于网络的媒体处理控制 | |
| CN110297944B (zh) | 分布式xml数据处理方法及系统 | |
| CN104871133A (zh) | 基于服务器健康以及客户端信息的应用智能请求管理 | |
| CN110062022B (zh) | 一种服务端灰度部署应用系统api更新的方法 | |
| CN107291744A (zh) | 确定及运用应用程序之间的关系关联的方法及装置 | |
| CN110764881A (zh) | 分布式系统后台重试方法及装置 | |
| CN104320482A (zh) | 一种银行柜员前端系统 | |
| CN113391823A (zh) | 灰度发布方法、装置及系统 | |
| US11709696B2 (en) | Preloading of virtual devices in anticipation of a connection request from a physical device | |
| CN110750780B (zh) | 基于多业务系统的用户角色权限融合方法、装置以及设备 | |
| CN114064062B (zh) | 基于Kubernetes平台和负载均衡组件的缺省灰度发布方法和装置 | |
| CN112394932A (zh) | 浏览器网页自动换肤方法及装置 | |
| CN111858050A (zh) | 服务器集群混合部署方法、集群管理节点及相关系统 | |
| CN112995303A (zh) | 跨集群调度方法及装置 | |
| CN114257532A (zh) | 服务端状态探测方法及装置 | |
| CN105763545B (zh) | 一种byod方法及装置 | |
| CN111782260B (zh) | 灰度发布方法及灰度发布装置 | |
| CN113900939A (zh) | 测试环境访问方法、装置、可读存储介质和计算机设备 | |
| CN113452776B (zh) | PaaS平台服务调度方法、装置及PaaS平台 | |
| CN116633771A (zh) | 灰度发布的方法、装置、介质 | |
| CN116351070A (zh) | 一种数据处理方法、装置、计算机设备以及可读存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |