CN115334006B - 基于客户端实现的灰度验证方法及系统 - Google Patents

Abstract

本申请提供了一种基于客户端实现的灰度验证方法，包括：当客户端接收到用户的业务请求时，由客户端根据预设的灰度策略确定出用户的业务请求是否需要打灰度标签；当确定出需要打灰度标签时，由客户端根据预设的灰度策略对用户的业务请求打上对应的灰度标签得到包含有灰度标签的灰度流量；由客户端发送灰度流量到处理用户的业务请求至第一节点；由第一节点根据预设的灰度策略识别灰度流量中的灰度标签；以及当用户的业务请求所涉及的节点只包含第一节点，第一节点根据灰度标签和预设的灰度策略将灰度流量路由至相关联的灰度资源服务端以获得目标资源并由第一节点返回给所述客户端。本申请技术方案能够更加智能的对客户端发送业务请求进行验证。

Description

基于客户端实现的灰度验证方法及系统

技术领域

本申请涉及金融科技领域，尤其涉及一种基于客户端实现的灰度验证方法及基于客户端实现的灰度验证系统。

背景技术

现有技术中在设计灰度方案时，对于一个涉及移动端、服务端的大型系统，往往会遇到如下挑战：

1、同一个业务场景的灰度环境，同时涉及移动端和后端，如何保证他们同时处于灰度环境之中

2、组件化的前端应用，不同组件升级迭代节凑不一样，如何保证不同组件能够各自进行灰度验证而互不冲突

3、请求链路上如何有统一的灰度分流算法，防止灰度环境与正式环境场景混乱

对于移动端加载在线静态资源，考虑灰度方案时传统的做法一般为：首先，静态资源通过统一资源定位符（URL）区别出灰度环境与正式环境，例如，/a/ok/* 表示正式静态资源，/a/gray/* 表示灰度静态资源；接着在移动端加载静态资源的统一入口处加入分流逻辑，根据是否命中灰度决定访问哪个URL。

该方法的使用局限在于：如果业务方在静态资源页面内引用了其他静态资源时，URL也要求业务方按前述URL区分方式来使用，无疑于加大了业务方的代码侵入；但如果业务方在页面内引用静态资源URL时未在URL上作区分，则整个灰度的覆盖范围只能局限于入口页面，不能覆盖所有静态资源。

发明内容

有鉴于此，实有必要提供一种更加智能的基于客户端实现的灰度验证方法及基于客户端实现的灰度验证系统。

第一方面，本申请实施例提供一种基于客户端实现的灰度验证方法，所述基于客户端实现的灰度验证方法包括下面步骤:当客户端接收到用户的业务请求时，由所述客户端根据预设的灰度策略确定出所述用户的业务请求是否需要打灰度标签，所述预设的灰度策略由灰度验证控制服务器发送给客户端以及处理所述用户的业务请求所涉及的节点；当确定出所述用户的业务请求需要打灰度标签，由所述客户端根据预设的灰度策略对所述用户的业务请求打上对应的灰度标签得到包含有灰度标签的灰度流量，所述灰度标签与灰度资源服务端相关联，所述灰度资源服务端用于提供动态资源或者静态资源；由所述客户端发送所述灰度流量到处理所述用户的业务请求至第一节点，由所述第一节点为所述用户的业务请求所涉及的节点中的第一个节点；由所述第一节点根据所述预设的灰度策略识别所述灰度流量中的所述灰度标签；以及当所述用户的业务请求所涉及的节点只包含第一节点，所述第一节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源并由所述第一节点返回给所述客户端。

第二方面，本申请实施例提供一种基于客户端实现的灰度验证系统，所述基于客户端实现的灰度验证系统包括：灰度验证控制服务器，包括灰度配置模块和流量控制模块，所述灰度配置模块用于设置预设的灰度策略；所述流量控制模块用于控制所述预设的灰度策略下发；资源服务端，包括若干灰度资源服务端，若干灰度资源服务端用于提供相应的灰度资源服务；客户端，包括资源管理模块、灰度标识加载模块和标签添加模块，所述资源管理模块用于管理静态资源和动态资源；所述灰度标识加载模块用于当接收到用户的业务请求时，根据所述灰度验证控制服务器下发的预设的灰度策略确定所述用户的业务请求是否需要打灰度标签；所述标签添加模块用于当确定出所述用户的业务请求需要打灰度标签时，根据预设的灰度策略对所述用户的业务请求打上对应的灰度标签得到包含有灰度标签的灰度流量；若干节点，每个节点包括接收模块和识别模块，所述接收模块用于接收所述客户端发送所述灰度流量；所述识别模块用于根据所述预设的灰度策略识别所述灰度流量中的所述灰度标签，并根据所述灰度标签将所述灰度流量路由至相应的灰度资源服务端以使所述灰度资源服务端提供相应的灰度资源服务得到目标资源，所述目标资源经由相应的节点返回给所述客户端。

第三方面，本申请实施例提供一种基于客户端实现的灰度验证方法，所述基于客户端实现的灰度验证方法包括：灰度验证控制服务器发送预设的灰度策略给相应关联的节点；当客户端接收到用户的业务请求时，所述客户端根据预设的灰度策略确定出所述用户的业务请求是否需要打灰度标签；所述预设的灰度策略由灰度验证控制服务器在所述客户端接收到所述用户的业务请求时发送给所述客户端；当确定出所述用户的业务请求需要打灰度标签，所述客户端根据预设的灰度策略对所述用户的业务请求打上对应的灰度标签得到包含有灰度标签的灰度流量，所述灰度标签与灰度资源服务端相关联，所述灰度资源服务端用于提供动态资源或者静态资源；所述客户端发送所述灰度流量到处理所述用户的业务请求至第一节点，所述第一节点为所述用户的业务请求所涉及的节点中的第一个节点；所述第一节点根据所述预设的灰度策略识别所述灰度流量中的所述灰度标签；以及当所述用户的业务请求所涉及的节点只包含第一节点，所述第一节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源并由所述第一节点返回给所述客户端。

上述基于客户端实现的灰度验证方法及基于客户端实现的灰度验证系统，通过灰度验证控制服务器对客户端及处理客户端发出的业务请求的节点进行统一下发灰度策略，从而使得客户端和相应服务端同时处于灰度之中；通过对节点对流量中是否带有灰度标签的判断，从而可以防止灰度环境与正式环境的场景混乱；另外，通过从客户端对请求进行打标从而使得整个链路上可以获得一致的灰度分流行为，保证整个链路灰度的一致性。

附图说明

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

图1为本申请第一实施例提供的基于客户端实现的灰度验证方法的流程图。

图2为本申请第二实施例提供的基于客户端实现的灰度验证方法的部分流程图。

图3为本申请第三实施例提供的基于客户端实现的灰度验证方法的部分流程图。

图4为本申请第四实施例提供的基于客户端实现的灰度验证方法的流程图。

图5为本申请第五实施例提供的基于客户端实现的灰度验证方法的流程图。

图6为本申请实施例提供的基于客户端实现的灰度验证系统的功能模块示意图。

图7为本申请实施例提供的基于客户端实现的灰度验证方法的运行环境示示意图。

图8为本申请实施例提供的服务器的内部结构示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的规划对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，换句话说，描述的实施例根据除了这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，还可以包含其他内容，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于只清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者多个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

请结合参看图1、图6和图7，图1其为本申请实施例提供的基于客户端实现的灰度验证方法的流程图。图6其为本申请实施例提供的基于客户端实现的灰度验证方法的系统示意图。所述基于客户端实现的灰度验证系统1000具体包括灰度验证控制服务器1、客户端101、若干节点102、和资源服务端103。在本实施例中，若干节点102包括RPC组件800、网关500、以及静态资源服务器200等。资源服务端103用于根据用户的业务请求提供相应的服务以获得目标资源，并将目标资源返回给客户端101。资源服务端103包括静态资源服务器、各业务服务器/服务组件等，各业务服务器/服务组件通过所述RPC组件进行通信。其中，所述基于客户端101实现的灰度验证方法具体包括如下步骤S102-S110。

步骤S102，当客户端101接收到用户的业务请求时，由所述客户端101根据预设的灰度策略确定出所述用户的业务请求是否需要打灰度标签，所述预设的灰度策略由灰度验证控制服务器1发送给客户端101以及处理所述用户的业务请求所涉及的节点。[1]可以理解地，所述灰度验证控制服务器1包括流量控制服务器100、标识配置服务器400、RPC配置服务器300。其中，流量控制服务器100将所述预设的灰度策略下发给标识配置服务器400、RPC配置服务器500、静态资源服务器200、网关500，并由标识配置服务器400发送所述预设的灰度策给客户端101，以及通过RPC配置服务器500发送所述预设的灰度策给RPC组件800。用户在灰度验证控制服务器1中预先根据需要设置相应的灰度策略得到所述预设的灰度策略。当所述预设的灰度策略完成设置或者完成更新时，标识配置服务器400、RPC配置服务器500、静态资源服务器200、网关500。标识配置服务器400和RPC配置服务器500接收到所述预设的灰度策略后发送给客户端101以及相应的RPC组件800。当客户端接收到用户的业务请求时，使得客户端101先将用户的业务请求先行拦截后，再根据所述灰度策略对用户发起的业务请求进行判断，判断所述业务请求是否需要打灰度标签。[2]所述客户端101可以为手机、平板电脑等移动设备，也可以是笔记本电脑、台式机等计算机。在本实施例中，灰度验证控制服务器1包括多个提供不同服务的服务器，即流量控制服务器100、标识配置服务器400、RPC配置服务器300，从而缓解流量控制服务器100的运算量。可以理解地，在一些可行的实施例中，可以将识配置服务器400、RPC配置服务器300集成在流量控制服务器100中作为灰度验证控制服务器。

步骤S104，当确定出所述用户的业务请求需要打灰度标签，由所述客户端101根据预设的灰度策略对所述用户的业务请求打上对应的灰度标签得到包含有灰度标签的灰度流量，所述灰度标签与灰度资源服务端相关联，所述灰度资源服务端用于提供动态资源或者静态资源。可以理解地，根据步骤S102后，当所述客户端101判断出用户的业务请求在灰度策略中，则客户端101确定出所述用户的业务请求需要打灰度标签，则客户端101根据获取的灰度策略对用户的业务请求进行打标签，使得客户端101将拦截的业务请求释放后所述业务请求中携带有客户端101所打上的灰度标签得到带有灰度标签的灰度流量，并根据所述用户的业务请求的静态资源和动态资源，将所述释放后的带有灰度标签的灰度流量发送至相应的静态资源的灰度资源服务端或动态资源的灰度服务端。

步骤S106，由所述客户端101发送所述灰度流量到处理所述用户的业务请求至第一节点，由所述第一节点为所述用户的业务请求所涉及的节点中的第一个节点。可以理解地，根据步骤S104，当用户发送的业务请求是静态资源时，所述客户端101将带有灰度标签的灰度流量发送至可获取静态资源的第一节点中。举例来说，若用户发送的业务请求是静态资源时，且所述获取静态资源的第一节点是内容分发网络（CDN 100）时，所述客户端101将带有灰度标签的灰度流量直接发送至CDN 100中。

步骤S108，由所述第一节点根据所述预设的灰度策略识别所述灰度流量中的所述灰度标签。可以理解地，根据步骤S102得知，灰度验证控制服务器1对处理所述客户端101发送的业务请求的节点下发灰度策略，也就是说，第一节点与灰度流量接收了灰度验证控制服务器1下发的相同灰度策略。当带有灰度标签的灰度流量到达第一节点时，第一节点则先对到达的灰度流量中是否带有标签进行判断，当第一节点判断出灰度流量中带有灰度标签，则所述第一节点对灰度流量中的灰度标签进行识别。

步骤S110，当所述用户的业务请求所涉及的节点只包含第一节点，所述第一节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源并由所述第一节点返回给所述客户端101。可以理解地，当第一节点根据接收的灰度策略先对用户的业务请求进行拦截，判断所述用户的业务请求中是否带有灰度标签，且灰度标签是否与所述接收的灰度策略一致，当用户的业务请求中带有灰度标签且所述灰度标签命中所述接收的灰度策略时，则第一节点将根据所述用户的业务请求进行路由至相关联的灰度资源服务端，并根据所述请求获取相应目标资源，在经由第一节点将目标资源返回值所述客户端101；当用户的业务请求中未带有灰度标签时，则第一节点将所述用户的业务请求进行路由至相关联的正式资源服务器，所述正式资源服务器为正式环境的资源服务器。举例来说，若用户的业务请求为静态资源请求，且灰度资源服务端的第一节点为CDN 100，则当客户端101将带有灰度标签的用户的业务请求发送至CDN 100，所述CDN100将所述带有灰度标签的用户的业务请求先行拦截，判断所述请求中是否包含灰度标签，当所述CDN 100确认出所述请求中带有灰度标签时，则CDN 100将根据所述请求直接获取相应灰度的目标资源，并将获取后的目标资源通过CDN 100返回至所述客户端101；当所述CDN100未确认出所述请求中带有灰度标签时，则CDN 100将根据所述请求直接获取相应正式的目标资源，并将获取后的目标资源通过CDN 100返回至所述客户端101。其中所述灰度标签是否命中灰度策略的情况，将在下文详细描述。

上述实施例中，通过灰度验证控制服务器1对客户端101及处理客户端101发出的业务请求的节点进行统一下发灰度策略，从而使得客户端101和相应服务端同时处于灰度之中；通过对节点对流量中是否带有灰度标签的判断，从而可以防止灰度环境与正式环境的场景混乱，通过从客户端101对请求进行打标从而使得整个链路上可以获得一致的灰度分流行为，保证整个链路灰度的一致性。

请结合参看图2和图7，图2其为本申请实施例提供的基于客户端实现的灰度验证方法的第一子流程图。步骤S110，还具体包括如下步骤S202-S204。

步骤S202，当所述用户的业务请求所涉及的节点包含第一节点和第二节点且所述灰度流量经由所述第一节点传递至所述第二节点时，由所述第二节点根据预设的灰度策略识别所述接收到的灰度流量中的灰度标签，其中，所述第一节点为所述用户的业务请求所涉及的节点中的第一个节点，所述第二节点为所述用户的业务请求所涉及的节点中的最后一个节点。可以理解地，灰度验证控制服务器1会对客户端101发出的静态资源或动态资源的流量所要经过的所有节点进行统一同步下发，则使得所述流量到达每一节点时，则每一个节点都会对客户端101发出的流量进行灰度标签的识别以确认当前到达的流量是否是灰度。

步骤S204，由所述第二节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源并依次经由所述第二节点和所述第一节点返回所述目标资源给所述客户端101。可以理解地，在一些实施例中可以根据第一节点和第二节点对所述流量都进行识别，当所述第一节点和第二节点都识别出所述流量带有灰度标签时，则直接由第二节点将所述流量路由至相关联的灰度资源服务端以获得目标资源，并将所述目标资源经由第二节点和第一节点返回至所述客户端101；当所述第一节点和第二节点都没有识别出所述流量带有灰度标签时，则直接由第二节点将所述流量路由至相关联的正式资源服务端以获得目标资源，并将所述目标资源经由第二节点和第一节点返回至所述客户端101。在另一些实施例中还可以是，当用户对灰度验证控制服务器1中的灰度进行修改并统一同步下发，若用户想要请求的所述灰度资源服务端为静态资源服务端，所述静态资源服务端的关联节点包括第一节点CDN 100和第二节点静态资源服务端200，当客户端101根据新的灰度策略对用户发出的静态资源请求打上新的灰度标签后得到带有新灰度标签的灰度流量，当所述带有新灰度标签的灰度流量经过第一节点CDN 100时，因灰度验证控制服务器1重新下发了新的灰度策略，但是静态资源服务端200还没有将所述新的灰度策略同步于CDN 100，则导致第一节点CDN 100接收到带有新灰度标签的灰度流量时，对新灰度标签识别失败，则第一节点CDN 100无法判断要返回给客户端101的目标资源是正式环境的还是灰度环境的，则所述第一节点CDN 100会将标签识别失败的所述灰度流量传递至第二节点进行识别，也就是说，第一节点CDN 100会将所述识别失败的灰度流量传递至静态资源服务端200进行灰度标签的识别，当静态资源服务端200接收到第一节点传递过来的带有新灰度标签的灰度流量后，还是根据接收的新的灰度策略对接收的所述灰度流量进行灰度标签的识别，当所述静态资源服务端200识别出所述灰度流量带有命中所述接收的新的灰度策略的灰度标签时，则静态资源服务端200将根据所述灰度流量路由至相关联的灰度资源服务端以获得目标资源，并直接由第二节点返回至所述客户端101；当所述静态资源服务端200对所述灰度流量带有的未命中所述接收的新的灰度策略的灰度标签时，则静态资源服务端200将根据所述灰度流量路由至相关联的正式资源服务端以获得目标资源，并直接由第二节点返回至所述客户端101。

上述实施例中，通过对灰度验证控制服务器1对所述客户端101发送的静态资源请求或动态资源请求所要经过的节点都同步下发相同的灰度策略，从而保证各业务线可以各自进行灰度验证流程且互不干扰，且针对静态资源，通过在客户端101进行统一的打标以及在静态资源请求链路上对流量中灰度标签的识别和处理，保证用户在使用静态资源引用时无需自己关注灰度版本，仅需要使用统一的URL，剩下的打标和分流由相应的静态资源服务端的关联节点来完成，进而可以保证灰度的完整覆盖。

请结合参看图3和图7，图3其为本申请实施例提供的基于客户端实现的灰度验证方法的第二子流程图。步骤S110，还具体包括如下步骤S302-S306。

步骤S302，当所述用户的业务请求所涉及的节点包含第一节点、第二节点以及第三节点且所述灰度流量经由所述第一节点传递至所述第三节点时，由所述第三节点根据预设的灰度策略识别所述接收到的灰度流量中的灰度标签，其中，所述第一节点为所述用户的业务请求所涉及的节点中的第一个节点，所述第二节点为所述用户的业务请求所涉及的节点中的最后一个节点，所述第三节点为所述用户的业务请求所涉及的节点中的中间节点。可以理解地，灰度验证控制服务器1会对客户端101发出的静态资源或动态资源的流量所要经过的所有节点进行统一同步下发，则使得所述流量到达每一节点时，则每一个节点都会对客户端101发出的流量进行灰度标签的识别以确认当前到达的流量是否是灰度。

步骤S304，由所述第三节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量传递至所述第二节点。可以理解地，当所述第一节点没办法直接与第二节点，即最终节点，进行直接交互时，则需要一个中间节点使得所述第一节点与第二节点可以交互，且第一节点、第二节点和第三节点进行交互的过程中还需要对所述灰度流量的灰度标签进行传递，使得每一节点都可以进行所述灰度标签的识别，并根据所识别的结果进行相应的操作。举例来说，若用户想要请求的所述灰度资源服务端为动态资源服务端，所述动态资源服务端的关联节点包括第一节点网关500、第三节点相应的应用服务器600和第二节点RPC组件800，其中，RPC组件800是通过RPC配置服务器300对所述RPC组件800下发相应的灰度策略，也就是说，灰度验证控制服务器1将灰度策略先下发至RPC配置服务器300，所述RPC配置服务器300再根据接收的灰度策略，将所述灰度策略下发至RPC组件800中。当客户端101根据新的灰度策略对用户发出的静态资源请求打上新的灰度标签后得到带有新灰度标签的灰度流量，当客户端101对所述动态资源请求打上灰度标签后得到带有灰度标签的灰度流量，并让所述带有灰度标签的灰度流量在动态链路上进行传输，当网关500在动态链路上接收到所述带有灰度标签的灰度流量后，所述网关500先将所述带有灰度标签的灰度流量拦截下来，进行灰度标签的识别，若拦截的灰度流量带有的灰度标签命中接收的灰度策略后，所述网关500将所述灰度标签和所述带有灰度标签的灰度流量传递至第三节点相应的应用服务器600中，所述第三节点在通过第二节点RPC组件800对第三节点接收的所述灰度标签和所述带有灰度标签的灰度流量进行灰度标签的识别。

步骤S306，由所述第二节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源，并依次经由所述第二节点、第三节点以及所述第一节点返回所述目标资源给所述客户端101。可以理解地，根据步骤S304，当所述第二节点RPC组件800识别出所述灰度流量带有的灰度标签命中接收的灰度策略时，则第二节点RPC组件800将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源，若所述灰度流量访问的不止一个应用服务器600，即第三节点包括一个或者多个节点，也就是说第三节点为相应的其他的应用服务器700时，则所述第二节点RPC组件800还将负责将所述灰度标签传递至所述灰度流量需要访问的其他的应用服务器600中，并根据其他的应用服务器600中的RPC组件800进行相应的上述操作，也就是说每一应用服务器600中都包含有相对应的所述RPC组件800去处理上述操作。当所述RPC组件800获取完目标资源后，直接依次经由所述第二节点、第三节点以及所述第一节点返回所述目标资源给所述客户端101；当所述第二节点RPC组件800识别出所述灰度流量带有的灰度标签未命中接收的灰度策略时，则第二节点RPC组件800将所述灰度流量路由至相关联的正式资源服务端以获得目标资源，并在所述RPC组件800获取完目标资源后，直接依次经由所述第二节点、第三节点以及所述第一节点返回所述目标资源给所述客户端101。

上述实施例中，通过对灰度验证控制服务器1对所述客户端101发送的静态资源请求或动态资源请求所要经过的节点都同步下发相同的灰度策略，从而保证各业务线可以各自进行灰度验证流程且互不干扰。

请结合参看图4和图7，图4其为本申请实施例提供的基于客户端实现的灰度验证方法的第二子实施例流程图。所述基于客户端实现的灰度验证方法还具体包括如下步骤S402-S404。

步骤S402，对所述各个节点进行埋点获得埋点信息。可以理解地，在各个处理所述客户端101发送流量的节点处设置埋点，所述埋点仅对接收的流量中带有灰度标签的灰度流量的流量信息进行获取。

步骤S404，将所述埋点信息发送给所述灰度验证控制服务器以对所述预设的灰度策略进行验证。可以理解地，用户先再所述灰度验证控制服务器中添加应有多少流量会命中，当所述埋点在获取到带有灰度标签的灰度流量后，将获取的所述灰度流量信息发送至所述灰度验证控制服务器，以便根据在所述灰度验证控制服务器中根据预设的命中情况对埋点上报的命中的灰度流量进行命中率的验证，在另一些实施例中，还可以通过消息组件或数据库等根据预设的规则将获取的所述命中的灰度流量上报至流量控制中。

上述实施例中，通过设置埋点对灰度命中的情况进行验证，从而可以更加明晰的查看命中情况，并根据所述命中情况进行相应的问题排查，从而降低排查人员的工作量。

请结合参看图5和图7，图5其为本申请实施例提供的基于客户端实现的灰度验证方法的第三子实施例流程图。所述基于客户端实现的灰度验证方法还具体包括如下步骤S502-S512。

步骤S502，灰度验证控制服务器1发送预设的灰度策略给相应关联的节点。可以理解地，当客户端101接收到用户的业务请求时，所述灰度验证控制服务器1将同时下发相应的灰度策略于客户端101和相关联的节点中。

步骤S504，当客户端101接收到用户的业务请求时，所述客户端101根据预设的灰度策略确定出所述用户的业务请求是否需要打灰度标签；所述预设的灰度策略由灰度验证控制服务器1在所述客户端101接收到所述用户的业务请求时发送给所述客户端101。

步骤S506，当确定出所述用户的业务请求需要打灰度标签，所述客户端101根据预设的灰度策略对所述用户的业务请求打上对应的灰度标签得到包含有灰度标签的灰度流量，所述灰度标签与灰度资源服务端相关联，所述灰度资源服务端用于提供动态资源或者静态资源。

步骤S508，所述客户端101发送所述灰度流量到处理所述用户的业务请求至第一节点，所述第一节点为所述用户的业务请求所涉及的节点中的第一个节点；

步骤S510，所述第一节点根据所述预设的灰度策略识别所述灰度流量中的所述灰度标签。

步骤S512，当所述用户的业务请求所涉及的节点只包含第一节点，所述第一节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源并由所述第一节点返回给所述客户端101。

所述基于客户端实现的灰度验证系统1000包括灰度验证控制服务器1、客户端101、若干节点102和资源服务端103。其中，灰度验证控制服务器1包括灰度配置模块3和流量控制模块2。其中，灰度配置模块3用于设置预设的灰度策略；流量控制模块2用于控制所述预设的灰度策略下发。客户端101包括资源管理模块、灰度标识加载模块、标签添加模块。其中，所述资源管理模块用于管理静态资源和动态资源。所述灰度标识加载模块用于当接收到用户的业务请求时，根据所述灰度验证控制服务器下发的预设的灰度策略确定所述用户的业务请求是否需要打灰度标签。所述标签添加模块用于当确定出所述用户的业务请求需要打灰度标签时，根据预设的灰度策略对所述用户的业务请求打上对应的灰度标签得到包含有灰度标签的灰度流量。其中，所述若干节点102包括每个节点都包括接收模块和识别模块。其中，所述接收模块用于接收所述客户端101发送所述灰度流量。所述识别模块用于根据所述预设的灰度策略识别所述灰度流量中的所述灰度标签，并根据所述灰度标签将所述灰度流量路由至相应的灰度资源服务端以使所述灰度资源服务端提供相应的灰度资源服务得到目标资源，所述目标资源经由相应的节点返回给所述客户端。其中，所述资源服务端103，包括若干灰度资源服务端，若干灰度资源服务端用于提供相应的灰度资源服务。

请结合参看图8，其为本申请实施例提供的服务器的内部结构示意图。服务器10包括计算机可读存储介质11、处理器12以及总线13。其中，计算机可读存储介质11至少包括一种类型的可读存储介质，该可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器（例如，SD或DX存储器等）、磁性存储器、磁盘、光盘等。计算机可读存储介质11在一些实施例中可以是服务器10的内部存储单元，例如服务器10的硬盘。计算机可读存储介质11在另一些实施例中也可以是的外部服务器10存储设备，例如服务器10上配备的插接式硬盘、智能存储卡（Smart Media Card， SMC）、安全数字（Secure Digital， SD）卡、闪存卡（Flash Card）等。进一步地，计算机可读存储介质11还可以既包括服务器10的内部存储单元也包括外部存储设备。计算机可读存储介质11不仅可以用于存储安装于服务器10的应用软件及各类数据，还可以用于暂时地存储已经输出或者将要输出的数据。

总线13可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

进一步地，服务器10还可以包括显示组件14。显示组件14可以是发光二极管（Light Emitting Diode，LED）显示器、液晶显示器、触控式液晶显示器以及有机发光二极管（Organic Light-Emitting Diode，OLED）触摸器等。其中，显示组件14也可以适当的称为显示装置或显示单元，用于显示在服务器10中处理的信息以及用于显示可视化的用户界面。

进一步地，服务器10还可以包括通信组件15。通信组件15可选地可以包括有线通信组件和/或无线通信组件，如WI-FI通信组件、蓝牙通信组件等，通常用于在服务器10与其他智能控制设备之间建立通信连接。

处理器12在一些实施例中可以是一中央处理器（Central Processing Unit，CPU）、控制器、微控制器、微处理器或其他数据处理芯片，用于运行计算机可读存储介质11中存储的程序代码或处理数据。具体地，处理器12执行处理程序以控制服务器10实现基于客户端101实现的灰度验证方法。

可以理解地，图8仅示出了具有组件11-15以及基于客户端101实现的灰度验证方法的服务器10，本领域技术人员可以理解的是，图8示出的结构并不构成对服务器10的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘且本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

以上所列举的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属于本申请所涵盖的范围。

Claims (6)

1.一种基于客户端实现的灰度验证方法，其特征在于，所述基于客户端实现的灰度验证方法包括：

当客户端接收到用户的业务请求时，由所述客户端根据预设的灰度策略确定出所述用户的业务请求是否需要打灰度标签，所述预设的灰度策略由灰度验证控制服务器发送给客户端以及处理所述用户的业务请求所涉及的节点；

当确定出所述用户的业务请求需要打灰度标签，由所述客户端根据预设的灰度策略对所述用户的业务请求打上对应的灰度标签得到包含有灰度标签的灰度流量，所述灰度标签与灰度资源服务端相关联，所述灰度资源服务端用于提供动态资源或者静态资源；

由所述客户端发送所述灰度流量到处理所述用户的业务请求的第一节点，所述第一节点为所述用户的业务请求所涉及的节点中的第一个节点；

由所述第一节点根据所述预设的灰度策略识别所述灰度流量中的所述灰度标签；以及

当所述用户的业务请求所涉及的节点只包含第一节点，所述第一节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源并由所述第一节点返回给所述客户端，具体包括：

第一节点根据接收的灰度策略先对用户的业务请求进行拦截，判断所述用户的业务请求中是否带有灰度标签，且灰度标签是否与所述接收的灰度策略一致，当用户的业务请求中带有灰度标签且所述灰度标签命中所述接收的灰度策略时，则第一节点将所述用户的业务请求路由至相关联的灰度资源服务端，并根据所述用户的业务请求获取相应目标资源，再经由第一节点将目标资源返回值所述客户端；当用户的业务请求中未带有灰度标签时，则第一节点将所述用户的业务请求进行路由至相关联的正式资源服务器，所述正式资源服务器为正式环境的资源服务器；

当所述用户的业务请求所涉及的节点包含第一节点和第二节点且所述灰度流量经由所述第一节点传递至所述第二节点时，由所述第二节点根据预设的灰度策略识别所述接收到的灰度流量中的灰度标签，其中，所述第一节点为所述用户的业务请求所涉及的节点中的第一个节点，所述第二节点为所述用户的业务请求所涉及的节点中的最后一个节点；以及

由所述第二节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源并依次经由所述第二节点和所述第一节点返回所述目标资源给所述客户端；

当所述用户的业务请求所涉及的节点包含第一节点、第二节点以及第三节点且所述灰度流量经由所述第一节点传递至所述第三节点时，由所述第三节点根据预设的灰度策略识别所述接收到的灰度流量中的灰度标签，其中，所述第一节点为所述用户的业务请求所涉及的节点中的第一个节点，所述第二节点为所述用户的业务请求所涉及的节点中的最后一个节点，所述第三节点为所述用户的业务请求所涉及的节点中的中间节点；

由所述第三节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量传递至所述第二节点；以及

由所述第二节点根据所述灰度标签和所述预设的灰度策略将所述灰度流量路由至相关联的灰度资源服务端以获得目标资源，并依次经由所述第二节点、第三节点以及所述第一节点返回所述目标资源给所述客户端。

2.如权利要求1所述基于客户端实现的灰度验证方法，其特征在于，所述第三节点包括一个或者多个节点。

3.如权利要求1所述基于客户端实现的灰度验证方法，其特征在于，所述灰度验证控制服务器包括流量控制服务器和标识配置服务器，所述预设的灰度策略由所述控制服务器下发给所述标识配置服务器，所述标识配置服务器发送所述灰度策略给所述客户端。

4.如权利要求3所述的基于客户端实现的灰度验证方法，其特征在于，所述灰度资源服务端包括动态资源服务端，所述动态资源服务端的关联节点包括网关和RPC组件，所述灰度验证控制服务器还包括RPC配置服务器，所述预设的灰度策略还由所述灰度验证控制服务器下发给所述RPC组件和所述网关，所述灰度流量通过网关和所述RPC组件路由至所述相应的动态资源服务端。

5.如权利要求3所述的基于客户端实现的灰度验证方法，其特征在于，所述灰度资源服务端包括静态资源服务端，所述静态资源服务端的关联节点包括CDN和静态资源服务端，所述预设的灰度策略还由所述灰度验证控制服务器下发给所述CDN和静态资源服务端，所述灰度流量通过所述CDN路由至所述相应的静态资源服务端。

6.如权利要求1所述的基于客户端实现的灰度验证方法，其特征在于，所述基于客户端实现的灰度验证方法包括：

对所述各个节点进行埋点获得埋点信息；以及

将所述埋点信息发送给所述灰度验证控制服务器以对所述预设的灰度策略进行验证。

Images