CN113055492A - 服务灰度链路的控制方法、装置、计算机设备和存储介质 - Google Patents

服务灰度链路的控制方法、装置、计算机设备和存储介质 Download PDF

Info

Publication number
CN113055492A
CN113055492A CN202110321038.9A CN202110321038A CN113055492A CN 113055492 A CN113055492 A CN 113055492A CN 202110321038 A CN202110321038 A CN 202110321038A CN 113055492 A CN113055492 A CN 113055492A
Authority
CN
China
Prior art keywords
service
service request
gray
node
request
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.)
Pending
Application number
CN202110321038.9A
Other languages
English (en)
Inventor
王振宇
李一飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Yunzhijia Network Co ltd
Original Assignee
Shenzhen Yunzhijia Network Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Shenzhen Yunzhijia Network Co ltd filed Critical Shenzhen Yunzhijia Network Co ltd
Priority to CN202110321038.9A priority Critical patent/CN113055492A/zh
Publication of CN113055492A publication Critical patent/CN113055492A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0813Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/133Protocols for remote procedure calls [RPC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/146Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请涉及一种服务灰度链路的控制方法、装置、计算机设备和存储介质。所述方法包括:接收客户端通过网关发送的业务请求;所述业务请求中携带已协商的识别串;根据所述识别串,判断是否进行灰度请求分发;若是,则在所述业务请求中添加灰度标识,得到携带灰度标识的业务请求;将所述携带灰度标识的业务请求转发至对应的目标服务节点;利用所述目标服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端。采用本方法能够有效提高服务灰度链路的控制效率。

Description

服务灰度链路的控制方法、装置、计算机设备和存储介质
技术领域
本申请涉及计算机技术领域,特别是涉及一种服务灰度链路的控制方法、装置、计算机设备和存储介质。
背景技术
随着计算机技术的发展,在微服务云容器化的趋势下,云服务治理成为运维管理的难点。目前服务系统的微服务架构中,当需要发布新版本的微服务实例时,灰度发布能够为快速迭代的微服务提供有效的保证,降低产品升级所影响的用户范围。
然而,目前的服务灰度链路的控制方式中,通常采用蓝绿方式实现所有调用链中节点服务的分割部署,当需要对微服务集群下的某个服务节点发布新版本时,需要重新部署整个服务链路的所有服务实例,并且需要在代理服务器和服务网关中手动更新相应配置,通过重启加载相应的配置来实现更新,一旦发现新版本存在问题时,必须将整条业务的链路服务下线,这种服务灰度链路的弊端在于服务系统存在很大风险,无法保证系统更新迭代时的稳定性,尤其是涉及多种业务场景下的服务灰度链路测试时,容易导致服务灰度链路的控制效率较低。
发明内容
基于此,有必要针对上述技术问题,提供一种能够提高服务灰度链路的控制效率的服务灰度链路的控制方法、装置、计算机设备和存储介质。
一种服务灰度链路的控制方法,所述方法包括:
接收客户端通过网关发送的业务请求;所述业务请求中携带已协商的识别串;
根据所述识别串,判断是否进行灰度请求分发;
若是,则在所述业务请求中添加灰度标识,得到携带灰度标识的业务请求;
将所述携带灰度标识的业务请求转发至对应的目标服务节点;
利用所述目标服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端。
在其中一个实施例中,所述利用所述目标服务节点对所述业务请求进行处理包括:
根据所述业务请求中的参数,获取预设的端口号;
根据所述端口号,通过灰度软负载程序从注册中心获取对应灰度节点;
利用所述灰度节点对所述业务请求进行处理。
在其中一个实施例中,所述根据所述端口号,通过灰度软负载程序从注册中心获取对应灰度节点包括:
根据所述业务请求中携带的灰度标识,调用灰度函数,从注册中心查找匹配的灰度节点。
在其中一个实施例中,所述利用所述灰度节点对所述业务请求进行处理,包括:
若所述灰度节点调用返回错误,则跳转至非灰度节点对所述业务请求进行处理。
在其中一个实施例中,所述在所述业务请求中添加灰度标识包括:
若所述客户端为Motan客户端时,则将所述灰度标识添加至Motan请求头中;
若所述客户端为HTTP客户端时,则将所述灰度标识添加至HTTP请求头中。
在其中一个实施例中,所述利用所述目标服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端包括:
在所述目标服务节点启动时,对拦截到的所述业务请求添加灰度标识,并将所述灰度标识添加至追踪容器中;所述追踪容器与所述业务请求的线程具有绑定关系;
当所述目标服务节点需要调用其他服务节点对所述业务请求进行处理时,拦截调用下游服务节点的调用请求,并将所述追踪容器中的灰度标识添加至所述调用请求中,以使得调用与所述灰度标识对应的服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端。
在其中一个实施例中,所述预设的端口号包括第一预设端口号和第二预设端口号;
所述根据所述业务请求中的参数,获取预设的端口号包括:
当所述业务请求中的参数为RPC协议参数时,则获取第一预设端口号;所述第一预设端口号是灰度RPC服务节点的注册端口;
当所述业务请求中的参数为HTTP协议参数时,则获取第二预设端口号;所述第二预设端口号是灰度HTTP服务节点的注册端口。
一种服务灰度链路的控制装置,所述装置包括:
接收模块,用于接收客户端通过网关发送的业务请求;所述业务请求中携带已协商的识别串;
判断模块,用于根据所述识别串,判断是否进行灰度请求分发;
添加模块,用于若是,则在所述业务请求中添加灰度标识,得到携带灰度标识的业务请求;
发送模块,用于将所述携带灰度标识的业务请求转发至对应的目标服务节点;
处理模块,用于利用所述目标服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端。
一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,所述处理器执行所述计算机程序时实现以下步骤:
接收客户端通过网关发送的业务请求;所述业务请求中携带已协商的识别串;
根据所述识别串,判断是否进行灰度请求分发;
若是,则在所述业务请求中添加灰度标识,得到携带灰度标识的业务请求;
将所述携带灰度标识的业务请求转发至对应的目标服务节点;
利用所述目标服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端。
一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现以下步骤:
接收客户端通过网关发送的业务请求;所述业务请求中携带已协商的识别串;
根据所述识别串,判断是否进行灰度请求分发;
若是,则在所述业务请求中添加灰度标识,得到携带灰度标识的业务请求;
将所述携带灰度标识的业务请求转发至对应的目标服务节点;
利用所述目标服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端。
上述服务灰度链路的控制方法、装置、计算机设备和存储介质,通过接收客户端通过网关发送的业务请求,业务请求中携带已协商的识别串。根据识别串,判断是否进行灰度请求分发。若是,则在业务请求中添加灰度标识,得到携带灰度标识的业务请求,并将携带灰度标识的业务请求转发至对应的目标服务节点。利用目标服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端。由此使得,能够按需选取节点进行灰度,其它服务节点正常作业,灵活变更灰度调用链路,即实现了自动选取对应的服务灰度节点,无需改动业务代码及配置,能够保证系统更新迭代时的稳定性,同时有效的提高了服务灰度链路的控制效率。
附图说明
图1为一个实施例中服务灰度链路的控制方法的应用环境图;
图2为一个实施例中服务灰度链路的控制方法的流程示意图;
图3A为一个实施例中利用目标服务节点对业务请求进行处理步骤的流程示意图;
图3B为一个实施例中服务灰度链路执行流程的示意图;
图3C为一个实施例中根据预设端口号从注册中心获取对应灰度节点的示意图;
图4A为一个实施例中利用目标服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端步骤的流程示意图;
图4B为一个实施例中Trace标识对象传递的示意图;
图5为一个实施例中根据业务请求中的参数,获取预设的端口号步骤的流程示意图;
图6为一个实施例中服务灰度链路的控制装置的结构框图;
图7为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
本申请提供的服务灰度链路的控制方法,可以应用于如图1所示的应用环境中。其中,客户端102通过网络与服务器104通过网络进行通信。服务器104接收客户端102通过网关发送的业务请求,业务请求中携带已协商的识别串。服务器104根据识别串,判断是否进行灰度请求分发。若是,则服务器104在业务请求中添加灰度标识,得到携带灰度标识的业务请求,服务器104将携带灰度标识的业务请求转发至对应的目标服务节点。服务器104利用目标服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端102。其中,终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备,服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
在一个实施例中,如图2所示,提供了一种服务灰度链路的控制方法,以该方法应用于图1中的服务器为例进行说明,包括以下步骤:
步骤202,接收客户端通过网关发送的业务请求,业务请求中携带已协商的识别串。
在目前的应用软件开发过程中,开发人员可以采用微服务架构,围绕着业务领域组件来创建不同业务功能的应用,这些应用可独立地进行开发、管理和更新,在分散的组件中使用微服务云架构和平台,能够使部署、管理和服务功能交付变得更加简单。微服务是一个新兴的软件架构,能够把一个大型的单个应用程序和服务拆分为数十个的支持微服务。微服务的策略可以让工作变得更为简便,它可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等级协议。使用不同操作系统设备的用户均可以通过终端中的应用市场界面下载多种类型的应用程序,可以包括系统应用程序、桌面应用程序、驱动应用程序、网络应用程序以及物联网应用程序等。从用户使用应用程序不同的业务功能划分,应用程序还可以包括即时通讯应用程序、在线购物应用程序、影音娱乐应用程序等。
现有系统中服务发布上线或需要升级服务器端应用时,可以采用灰度发布服务的方式。灰度发布(又名金丝雀发布)是指在黑与白之间,能够平滑过渡的一种发布方式。在服务版本快速迭代过程中,灰度版本与正式版本可以并存,灰度版本逐步放量到升级正式版,这样服务更新版本发布过程中就不需要停用服务一段时间,而且不同版本之间过渡过程可监控,一旦发现灰度版本有问题,也可以快速回退为原有的正式版的状态。即灰度统指程序发布上线后由于无法预估风险而采取的客户影响最小化运行策略。服务器上可以预先部署服务注册中心以及服务配置中心,所有服务都注册到服务注册中心,同时也可以从服务注册中心获取当前可用的服务清单。其中,服务标识是用于标识唯一的服务,版本标识可以包括灰度版本标识和非灰度版本标识,即版本标识是指在服务系统中采用灰度发布的同一服务对应的不同的版本信息,版本信息可以包括非灰度版本和灰度版本。比如,某个购物应用程序中的已创建的微服务为订单服务即“Order Service”,开发人员可以不断优化更新订单服务的功能,可以在服务系统中发布更新的灰度版本的订单服务1.1版本以及订单服务1.2版本等。
具体的,用户可以通过在手机应用程序中或浏览器网页中输入用户名和密码的方式,登录特定场景的业务系统中,用户可以通过app(Application,应用程序)客户端或web客户端即web浏览器发起特定的业务请求,服务器可以接收到客户端通过网关发送的业务请求,业务请求中携带已协商的识别串。其中,识别串是指根据预设协议或者加密方式生成的字符串,识别串中可以包括用户标识、企业标识等标识信息。客户端或称为用户端,是指与服务器相对应,为客户提供本地服务的程序。除了一些只在本地运行的应用程序之外,一般安装在普通的客户机上,需要与服务端互相配合运行。客户端可以包括DNS客户端、web客户端、游戏客户端以及移动客户端等。例如,移动客户端以手机为例,手机客户端就是可以在手机终端运行的软件。业务请求是指用户根据不同需求在不同业务场景系统中发起的与业务功能对应的业务请求。网关是指服务网关,用于提供统一的服务入口。例如,在网上购物应用中,用户可以通过触发操作发起创建订单请求,并通过服务网关发送至服务器。当服务器接收到该客户端通过服务网关发送的创建订单请求时,则服务器可以根据创建订单请求中的识别串,从服务注册中心获取与识别串解密出的标识信息对应的可用的服务清单,调用对应的服务节点。
步骤204,根据识别串,判断是否进行灰度请求分发。
服务器接收到客户端通过网关发送的业务请求之后,服务器可以根据业务请求中携带已协商的识别串,判断是否进行灰度请求分发。其中,灰度请求是指该业务请求需要调用灰度版本的服务节点处理。具体的,服务器可以根据业务请求中识别串携带的标识信息,判断是否进行灰度请求分发。例如,服务器可以根据业务请求中识别串携带的用户标识信息或者企业标识信息,判断是否进行灰度请求分发。原始的业务请求可以是来自于移动端、PC端、WEB端发起的http调用请求,考虑安全性发起时统一在请求头(即header)中放置加密后的统一上下文,加密后的统一上下文即协商好的识别串,当业务请求到达网关或反向代理服务器时,网关或者代理服务器通过解密程序对业务请求携带的识别串进行解密,解析出对应的的上下文(即识别串携带的标识信息)。进一步的,服务器可以按照预先配置的规则,根据解析出的上下文(即识别串携带的标识信息)判断是否继续在下游服务调用时将灰度标识放置被请求业务接口的header中。
步骤206,若是,则在业务请求中添加灰度标识,得到携带灰度标识的业务请求。
服务器根据业务请求中携带已协商的识别串,判断是否进行灰度请求分发。若服务器根据业务请求中携带已协商的识别串,判断需要进行灰度请求分发,则服务器在业务请求中添加灰度标识,得到携带灰度标识的业务请求。其中,灰度标识用于标识唯一的灰度节点。例如,服务器可以通过Pinpoint程序对业务请求进行拦截,并在拦截到的业务请求中添加灰度标识,即可得到携带灰度标识的业务请求。
Pinpoint是一款开源链路追踪工具,基于APM技术,通过Trace传递,应用服务信息采集上报来实现分布式环境中服务与服务间调用链路追踪信息存储与图形化展示的一体化套件,该套件包括:采集代理Agent、预置Class类拦截点Plugins、信息收集Collector、信息持久化存储Hbase、链路图形化展示Dashboard组成。其中,APM(ApplicationPerformance Management)是指基于JavaAgent技术通过无侵入Java代码方式采集并上报服务的应用指标与传递服务间调用的链路Trace信息,通常适用于系统运维监控领域。Pinpoint基于无侵入式java字节码加强技术,无需改变原业务代码逻辑和重新编译,通过Java虚拟机启动加载字节码class文件时,将用于链路跟踪、Trace收集及透传的功能程序植入原业务服务运行时的字节码中。由于APM工具基于JavaAgent,JavaAgent是jdk1.5后推出的运行方法拦截技术,Pinpoint就是基于此技术开发而来。JavaAgent又名Java探针,通过JVM预留的扩展能力实现一种能够在不影响编译情况下,随程序启动前通过修改字节码class来植入代码逻辑加强程序功能,与直接更改Java代码然后编译运行的方式相比,具有开发无感知,原业务无显式侵入的特点。
步骤208,将携带灰度标识的业务请求转发至对应的目标服务节点。
服务器在业务请求中添加灰度标识,得到携带灰度标识的业务请求之后,服务器可以将携带灰度标识的业务请求转发至对应的目标服务节点。其中,目标服务节点是指从多个服务节点中,按照路由规则或路由配置信息(即根据标识信息)选取的其中一个服务节点作为目标服务节点,比如服务B对应的服务实例可以包括一个正式版的服务B1.0和灰度版的服务B1.1。此外,当一个Web服务系统从日访问量10万逐步增长到1000万时,则可以通过部署具有负载均衡功能或模块等软件将客户端发送的业务请求,转发至对应的目标服务节点地址。负载均衡是对系统的高可用、网络压力的缓解和处理能力扩容的重要手段之一。负载均衡是指服务端负载均衡,分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间按照专门用于负载均衡的设备,而软件负载均衡则是通过在服务器上安装一些用于负载均衡功能或模块等软件来完成请求分发工作,此外,还可以通过匹配HTTP Header,指定个别用户的流量到对应的灰度版本上。例如,客户端可以通过http请求方式调用服务,网关或反向代理web服务器接收到客户端发送的业务请求后,按照预设配置规则或算法(比如线性轮询、按权重负载、按灰度标识等)从维护的可用服务端清单中获取可用的服务对应的一个服务节点地址,将该客户端发送的业务请求转发至该服务节点地址。
步骤210,利用目标服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端。
服务器将携带灰度标识的业务请求转发至对应的目标服务节点之后,服务器可以利用目标服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端。其中,目标服务节点对客户端发送的业务请求进行处理时,可能会同时调用其他服务节点。例如,用户在购物界面中选好商品之后,用户通过点击按钮进行付款“Checkout”,生成对应的订单“Order”,“Checkout”和“Order”都是已构建的微服务。服务之间的调用可以通过RPC方式和事件通知方式完成。当“Order”服务对客户端发送的业务请求进行处理时,“Order”服务还需要调用其他几个服务来协助完成整个功能。当“Checkout”服务完成之后发送“OrderPlaced”消息,“Payment”服务收到该消息后,接收用户付款,发送“Payment received”消息,即“Order”服务通过调用其他服务节点对该客户端业务请求进行处理,完成收款订货的业务请求,并将该业务请求对应的处理结果返回至对应的客户端。
传统的服务灰度链路的控制方式中,采用蓝绿方式实现所有调用链中节点服务的全套分割部署,比如蓝绿两部分服务节点进行1:1运行,除数据库、缓存、消息中间件共享外,蓝绿两部分服务节点完全隔离运行。当系统中涉及灰度服务的链路调整时,无论上下游服务节点是否灰度,都必须将整条调用服务链路重新设置发布新服务实例,无法实现服务间的版本路由。如果灰度链路中任意节点服务意外退出将导致整条链路不可用,常规链路与灰度链路完全隔离,如果灰度流量较大会导致某个中间性能较差的节点成为瓶颈,阻碍其它灰度测试业务。
而本实施例中,通过接收客户端通过网关发送的业务请求,业务请求中携带已协商的识别串。根据识别串,判断是否进行灰度请求分发。若是,则在业务请求中添加灰度标识,得到携带灰度标识的业务请求,并将携带灰度标识的业务请求转发至对应的目标服务节点。利用目标服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端。由此使得,通过扩展Pinpoint链路追踪工具对业务请求的调用进行拦截,并在业务请求中添加灰度标识,使得能够按需选取节点进行灰度,其它服务节点正常作业,能够灵活变更灰度调用链路,即可实现基于不同业务场景特色动态定制微服务灰度发布的调用链路,达到访问微服务节点的路径改变,无须改动业务代码及配置等繁琐操作,也不需要1:1搭建整体灰度链路,能够保证系统更新迭代时的稳定性,同时有效的提高了服务灰度链路的控制效率。
在一个实施例中,如图3A所示,利用目标服务节点对业务请求进行处理的步骤,包括:
步骤302,根据业务请求中的参数,获取预设的端口号。
步骤304,根据端口号,通过灰度软负载程序从注册中心获取对应灰度节点。
步骤306,利用灰度节点对业务请求进行处理。
服务器将携带灰度标识的业务请求转发至对应的目标服务节点之后,服务器可以利用目标服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端。具体的,服务器可以根据业务请求中的参数,获取预设的端口号。进一步的,服务器可以根据端口号,通过灰度软负载程序从注册中心获取对应灰度节点,并利用灰度节点对业务请求进行处理。例如,可以预先设置灰度RPC服务节点的注册端口为37771,灰度HTTP服务节点的注册端口为37772,即部署服务时,通过指定对应的端口号参数将服务启动,并将服务接口注册到注册中心,例如RPC服务地址可以设置为192.168.1.2:37771,RPC服务地址为192.168.1.2:37772,服务调用者节点启动时,通过启动参数指定的对应类型服务的端口号,便可通过灰度软负载程序从注册中心获取对应节点。比如,服务器根据业务请求中的参数(即RPC协议或者HTTP协议),假设业务请求中的参数为RPC协议,则服务器可以获取预设的灰度RPC服务节点的注册端口号为37771。进一步的,服务器可以根据端口号,通过灰度软负载程序从注册中心获取对应灰度节点,即服务器可以通过RPC服务节点端口号37771,通过灰度软负载程序从注册中心获取对应灰度节点服务地址为192.168.1.2:37772,并利用灰度节点对业务请求进行处理。由此使得,通过约定好的固定端口号注册到注册中心,与常规节点的服务地址和端口进行区别,客户端根据服务启动时脚本中指定的灰度端口号进行启发式寻址即可。相较于传统的固定代码写死链路路由规则的方式,更具有灵活性,无需1:1搭建整体灰度链路,从而避免了增加额外资源成本。同时,可按需选取节点进行灰度,其它服务节点正常作业,使得服务器资源利用率高,整体链路不用调整,可快速回收释放灰度节点资源。
在一个实施例中,如图3B所示,为服务灰度链路执行流程的示意图。服务器接收到客户端发送的业务请求,服务器可以根据外部请求(即业务请求)通过携带与网关或反向代理协商好的识别串,来判断是否进行灰度请求分发。服务器通过解密程序对业务请求携带的识别串进行解密,若解析出isGray=true则走灰度节点,若解析出isGray=false则走常规节点。isGray即为灰度标识。如图3B中实线为非灰度链路,虚线为灰度链路。
具体的,外部请求识别串被网关或反向代理解析出为灰度作业时,则服务器将请求转发到灰度A服务节点,由于A服务节点在本次灰度发布中没有进行灰度部署,则直接由A服务节点接受请求进行业务处理。由于本次作业还将继续向后请求B服务节点,所以A服务中的服务发现客户端将通过连接的注册中心,搜寻B服务的灰度节点地址及端口,此时寻找到对应的灰度B_Gray节点,B_Gray节点将接受请求进行业务处理,B_Gray节点处理完成后还将通过注册中心搜寻下游节点继续向后请求,此时由于C节点服务没有灰度部署C_Gray节点,只存在常规节点则由常规节点即C节点服务接受请求进行相应业务处理,执行完对应环节业务后将继续向下执行请求,此时C环节服务发现客户端根据注册中心搜寻到了D_Gray节点,当发起请求时发现D_Gray节点其实不可用,则服务器根据高可用原则,跳回D常规节点完成请求作业。由此使得,即使当某个灰度节点意外退出时,也不会导致整条链路不可用。通过扩展Pinpoint链路追踪工具和调用方追加jar包,即可实现自动选取对应的服务灰度节点,无需改动业务代码及配置,能够保证系统更新迭代时的稳定性,同时有效的提高了服务灰度链路的控制效率。
在其中一个实施例中,根据端口号,通过灰度软负载程序从注册中心获取对应灰度节点的步骤,包括:
根据业务请求中携带的灰度标识,调用灰度函数,从注册中心查找匹配的灰度节点。
服务器利用目标服务节点对业务请求进行处理时,服务器可以根据业务请求中的参数,获取预设的端口号。进一步的,服务器可以根据端口号,通过灰度软负载程序从注册中心获取对应灰度节点,并利用灰度节点对业务请求进行处理。具体的,服务器获取预设的端口号之后,服务器可以根据业务请求中携带的灰度标识,调用灰度函数,从注册中心查找匹配的灰度节点,并利用匹配到的灰度节点对业务请求进行处理。例如,如图3B所示,A服务属于从外部通过网关或反向代理服务器后的第一层服务,则服务器可以通过对Pinpoint程序的加强,在拦截到的业务请求中添加灰度标识(即isGray)并置入Pinpoint全局Trace容器中,此Trace容器与当前请求的线程是绑定的,同时A服务继续向下请求B服务,由于属于同一个线程环境Pinpoint程序可再次拦截下游调用动作,将Trace容器中的灰度标识isGray置入http调用客户端header中,或者将Trace容器中的灰度标识isGray置入RPC调用客户端attachement中,服务调用客户端通过请求URI(统一资源标识符)在注册中心获取所有节点服务器IP(服务地址)+Port(端口号)列表,经过预置的灰度软负载程序过滤出专属标识为灰度节点Port的服务。其中,统一资源标识符(Uniform Resource Identifier,URI)是一个用于标识某一互联网资源名称的字符串。本实施例中,基于开源Pinpoint APM工具进行代码层扩展实现灰度标识的传递,即服务器根据改造Pinpoint实现业务代码无侵入情况下的灰度标识携带技术,同时,根据约定固定端口号标记常规服务节点和灰度节点,通过软负载实现灰度节点的选取,即可实现自动选取对应的服务灰度节点,无需改动业务代码及配置,能够保证系统更新迭代时的稳定性,同时有效的提高了服务灰度链路的控制效率。
在其中一个实施例中,利用灰度节点对业务请求进行处理的步骤,包括:
若灰度节点调用返回错误,则跳转至非灰度节点对业务请求进行处理。
如图3B所示,当C节点服务接受请求进行相应业务处理,执行完对应环节业务后将继续向下执行请求,此时C环节服务发现客户端根据注册中心搜寻到了D_Gray节点,当发起请求时发现D_Gray节点其实不可用,则服务器根据高可用原则,跳回D常规节点完成请求作业。其中,高可用原则是指一次完整的调用请求链中包括各种节点服务,每个节点不是单独存在的都是集群模式多节点,当某个节点出问题,会重试到正常节点上保证本次请求作业的完整可用性。例如,如果D_Gray节点调用返回connection refused或者响应状态码为404或5xx等错误,均代表服务不可用,客户端重试后仍无法返回响应状态码200,服务器将放弃D_Gray灰度节点,根据高可用原则,选取非灰度节点对业务请求进行处理。由此使得,即使当某个灰度节点意外退出或者不可用时,也不会导致整条链路不可用,通过扩展Pinpoint链路追踪工具和调用方追加jar包,即可实现自动跳转至对应的服务节点进行处理,无需改动业务代码及配置,保证本次请求作业的完整可用性。
在一个实施例中,在业务请求中添加灰度标识的步骤,包括:
若客户端为Motan客户端时,则将灰度标识添加至Motan请求头中。
若客户端为HTTP客户端时,则将灰度标识添加至HTTP请求头中。
若服务器根据业务请求中携带已协商的识别串,判断需要进行灰度请求分发,则服务器在业务请求中添加灰度标识,得到携带灰度标识的业务请求。由于目前分布式微服务环境下服务节点众多且技术框架不一,通过各业务领域开发改写代码进行灰度标识的传递很难推进,所以通过业务无入侵开发不参与的方式进行灰度标识传递非常合适,通过分析Pinpoint源码,将isGray字段加入Trace数据模型中,这样Trace的传递将作为载体把isGray灰度标识一同进行传递,不用特意增加额外的传递代码逻辑,由于APM工具基于JavaAgent,在服务节点启动时通过字节码加强的方式将相关拦截代码自动植入到调用方法的执行前与后,如果调用客户端为Motan拦截代码,则编写插入Motan请求头中。如果调用客户端为yzj-httpclient拦截代码,则编写插入到HTTP请求头中。其中,Trace是指Pinpoint链路跟踪传递的标识对象,包含TransactionId(TxId)、SpandId、ParentSpandId。Span是最基本的调用追踪单元,当远程调用到达的时候,Span指代处理该调用的作业,并且携带追踪数据。为了实现代码级别的可见性,Span下面还包含一层SpanEvent的数据结构。每个Span都包含一个SpanId,Trace是一组相互关联的Span集合,同一个Trace下的Span共享一个TransactionId,而且会按照SpanId和ParentSpanId排列成一棵有层级关系的树形结构,ParentSpandId是指当前作业Span的调用方SpanId。上文中提到的Trace模型结构中包含如下图示例的字段:
Figure BDA0002992984290000141
具体的,如图3C所示,为根据预设端口号从注册中心获取对应灰度节点的流程示意图。假设某企业的业务系统(云之家)中的核心微服务调用框架主要分为两种,一种是yzj-httpclient用于HTTP服务地址+端口发现。一种是Motan client用于RPC服务地址+端口发现,HTTP和RPC两种服务通过约定好的固定端口号注册到注册中心中,与常规节点的服务地址和端口进行区别,客户端根据服务启动时脚本中指定的灰度端口号进行启发式寻址即可。这样灰度请求作业时可根据灰度端口号作为过滤出灰度节点服务的依据,常规调用时则过滤掉灰度端口号对应的服务节点,这样的好处是不用大型改造现有yzj-httpclient与Motan的服务注册与发现逻辑,通过扩展客户端软负载程序即可实现,如图3C所示。其中,yzj-httpclient是在开源Apache Httpclient基础上开发而来的一种http协议服务调用工具,是一种socket短连接服务,即yzj-httpclient是服务与服务间HTTP调用的节点地址+端口发现客户端程序,基于Apache开源HttpClient开发而来,在之基础上集成了注册中心、客户端软负载、服务发现功能。即yzj-httpclient集成了服务发现能力和灰度软负载节点寻址能力。Motan为一种开源RPC框架,基于RPC协议和socket长连接,即Motan是一款开源的RPC服务注册、发现框架,集成了注册中心、客户端软负载、高可用等功能。由此使得,通过预先设置固定端口号标记常规服务节点和灰度节点,并通过yzj-httpclient和Motan client软负载实现灰度节点的自动选取,无须改动业务代码及配置等繁琐操作,也不需要1:1搭建整体灰度链路,能够保证系统更新迭代时的稳定性,同时有效的提高了服务灰度链路的控制效率。
在一个实施例中,如图4A所示,利用目标服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端的步骤,包括:
步骤402,在目标服务节点启动时,对拦截到的业务请求添加灰度标识,并将灰度标识添加至追踪容器中,追踪容器与业务请求的线程具有绑定关系。
步骤404,当目标服务节点需要调用其他服务节点对业务请求进行处理时,拦截调用下游服务节点的调用请求,并将追踪容器中的灰度标识添加至调用请求中,以使得调用与灰度标识对应的服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端。
如图4B所示,为Trace标识对象传递的示意图。Node1代表请求链路中的第一个Java服务节点,由于其是请求链路的第一个节点所以其父SpanId为-1代表不存在父节点。Node2、Node3以及Node4代表请求链路中下游的Java服务节点,isGray为灰度标识。
具体的,外部请求识别串被网关或反向代理解析出为灰度作业时,则服务器将请求转发到灰度Node1服务节点,由Node1服务节点接受请求进行业务处理。即Node1服务节点为目标服务节点,在Node1服务节点启动时,通过Pinpoint对拦截到的业务请求添加灰度标识(isGray=1),并将灰度标识添加至追踪容器中,追踪容器与业务请求的线程具有绑定关系。当目标服务节点即Node1服务节点需要调用其他服务节点对业务请求进行处理时,即Node1服务节点进行相应业务处理,执行完对应环节业务后将继续向下执行请求,Node1服务节点将继续向后请求Node2服务节点,Node1服务中的服务发现客户端将通过连接的注册中心,搜寻Node2服务的灰度节点地址及端口,此时寻找到对应的灰度Node2节点,通过Pinpoint拦截调用下游服务节点Node2的调用请求,并将追踪容器中的灰度标识(isGray=1)添加至调用请求中,以使得调用与灰度标识对应的服务节点Node2对业务请求进行处理,Node2节点处理完成后还将通过注册中心搜寻下游节点继续向后请求,搜寻到Node3和Node4服务的灰度节点地址及端口,则由Node3节点服务和Node4节点服务同时接受请求进行相应业务处理,执行完对应环节业务后将得到与业务请求对应的结果并返回至客户端。由此使得,扩充了Pinpoint原有Trace模型的内容增加了灰度标识isGray信息的传递,即通过扩展Pinpoint链路追踪工具和调用方追加jar包,即可实现自动选取对应的服务灰度节点,无需改动业务代码及配置,能够保证系统更新迭代时的稳定性,同时有效的提高了服务灰度链路的控制效率。
在一个实施例中,如图5所示,预设的端口号包括第一预设端口号和第二预设端口号,根据业务请求中的参数,获取预设的端口号的步骤,包括:
步骤502,当业务请求中的参数为RPC协议参数时,则获取第一预设端口号,第一预设端口号是灰度RPC服务节点的注册端口。
步骤504,当业务请求中的参数为HTTP协议参数时,则获取第二预设端口号,第二预设端口号是灰度HTTP服务节点的注册端口。
预设的端口号包括第一预设端口号和第二预设端口号,服务器可以根据业务请求中的参数,获取预设的端口号。具体的,可以预先设置灰度RPC服务节点的注册端口为第一预设端口号37771,,灰度HTTP服务节点的注册端口为第二预设端口号37772,即部署服务时,通过指定对应的端口号参数将服务启动,并将服务接口注册到注册中心,例如RPC服务地址可以设置为192.168.1.2:37771,RPC服务地址为192.168.1.2:37772,服务调用者节点启动时,通过启动参数指定的对应类型服务的端口号,便可通过灰度软负载程序从注册中心获取对应节点。比如,服务器根据业务请求中的参数(即RPC协议或者HTTP协议),假设业务请求中的参数为RPC协议参数,则服务器可以获取预设的灰度RPC服务节点的注册端口号为第一预设端口号。进一步的,服务器可以根据端口号,通过灰度软负载程序从注册中心获取对应灰度节点,即服务器可以通过RPC服务节点端口号37771,通过灰度软负载程序从注册中心获取对应灰度节点服务地址为192.168.1.2:37772,并利用灰度节点对业务请求进行处理。
由于原软负载为单纯的负责均衡策略程序,不具备根据灰度标识和启发启动参数传入的端口号来灵活选择对应灰度节点,本实施中,通过软负载扩展程序能自动置入到业务服务中,能够实现根据灰度标识和启发启动参数传入的端口号来灵活选择对应灰度节点。以Motan RPC类型的实现原理进行说明。Motan作为一款开源RPC微服务框架,内置有SPI(Service Provider Interface,根据抽象接口进行模块的扩展实现机制),Motan的软负载代码模块通过注册到该SPI上实现了原Motan的客户端负载均衡能力,借机于此,利用该机制编写相同逻辑负载均衡程序并加入从注册中心中获取所有节点时根据预先设置的固定端口方式清洗出灰度节点的地址+端口的代码逻辑,由于带灰度选取的软负载程序是基于SPI的,将程序打包后放入服务的类路径中就可自动加载。目前任何框架的Java服务只要使用Motan技术都能在服务启动时自动扫描并实现SPI模块的加载,这样运维在构建程序部署包时将该包一起构建便实现了灰度识别功能的自动加强。
例如,首先拷贝相同负载均衡策略Java代码改变其文件名,并追加如下图示例的代码:
Figure BDA0002992984290000171
本实施例中,与目前的开源Motan客户端相比,通过SPI方式扩展原Motan服务发现能力,使其具备灰度节点寻址能力,即根据Motan SPI机制重写Motan软负载逻辑,将灰度节点选取功能在不改变原有业务程序代码及配置情况下被业务服务自动加载并初始化,从而实现灰度识别功能的自动加强,能够保证系统更新迭代时的稳定性,同时有效的提高了自动识别服务灰度的准确性。
应该理解的是,虽然图1-5的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,图1-5中的至少一部分步骤可以包括多个步骤或者多个阶段,这些步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
在一个实施例中,如图6所示,提供了一种服务灰度链路的控制装置,包括:接收模块602、判断模块604、添加模块606、发送模块608和处理模块610,其中:
接收模块602,用于接收客户端通过网关发送的业务请求,业务请求中携带已协商的识别串。
判断模块604,用于根据识别串,判断是否进行灰度请求分发。
添加模块606,用于若是,则在业务请求中添加灰度标识,得到携带灰度标识的业务请求。
发送模块608,用于将携带灰度标识的业务请求转发至对应的目标服务节点。
处理模块610,用于利用目标服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端。
在一个实施例中,该装置还包括:获取模块。
获取模块用于根据业务请求中的参数,获取预设的端口号;根据端口号,通过灰度软负载程序从注册中心获取对应灰度节点。处理模块还用于利用灰度节点对业务请求进行处理。
在一个实施例中,该装置还包括:查找模块。
查找模块用于根据业务请求中携带的灰度标识,调用灰度函数,从注册中心查找匹配的灰度节点。
在一个实施例中,该装置还包括:跳转模块。
跳转模块用于若灰度节点调用返回错误,则跳转至非灰度节点对业务请求进行处理。
在一个实施例中,添加模块还用于若客户端为Motan客户端时,则将灰度标识添加至Motan请求头中;若客户端为HTTP客户端时,则将灰度标识添加至HTTP请求头中。
在一个实施例中,添加模块还用于在目标服务节点启动时,对拦截到的业务请求添加灰度标识,并将灰度标识添加至追踪容器中,追踪容器与业务请求的线程具有绑定关系。处理模块还用于当目标服务节点需要调用其他服务节点对业务请求进行处理时,拦截调用下游服务节点的调用请求,并将追踪容器中的灰度标识添加至调用请求中,以使得调用与灰度标识对应的服务节点对业务请求进行处理,得到与业务请求对应的结果并返回至客户端。
在一个实施例中,获取模块还用于当业务请求中的参数为RPC协议参数时,则获取第一预设端口号,第一预设端口号是灰度RPC服务节点的注册端口;当业务请求中的参数为HTTP协议参数时,则获取第二预设端口号,第二预设端口号是灰度HTTP服务节点的注册端口。
关于服务灰度链路的控制装置的具体限定可以参见上文中对于服务灰度链路的控制方法的限定,在此不再赘述。上述服务灰度链路的控制装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中,提供了一种计算机设备,该计算机设备可以是服务器,其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储服务灰度链路的控制数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种服务灰度链路的控制方法。
本领域技术人员可以理解,图7中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
在一个实施例中,提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时实现上述各个方法实施例的步骤。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory,ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory,RAM)或外部高速缓冲存储器。作为说明而非局限,RAM可以是多种形式,比如静态随机存取存储器(Static Random Access Memory,SRAM)或动态随机存取存储器(Dynamic Random Access Memory,DRAM)等。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种服务灰度链路的控制方法,所述方法包括:
接收客户端通过网关发送的业务请求;所述业务请求中携带已协商的识别串;
根据所述识别串,判断是否进行灰度请求分发;
若是,则在所述业务请求中添加灰度标识,得到携带灰度标识的业务请求;
将所述携带灰度标识的业务请求转发至对应的目标服务节点;
利用所述目标服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端。
2.根据权利要求1所述的方法,其特征在于,所述利用所述目标服务节点对所述业务请求进行处理包括:
根据所述业务请求中的参数,获取预设的端口号;
根据所述端口号,通过灰度软负载程序从注册中心获取对应灰度节点;
利用所述灰度节点对所述业务请求进行处理。
3.根据权利要求2所述的方法,其特征在于,所述根据所述端口号,通过灰度软负载程序从注册中心获取对应灰度节点包括:
根据所述业务请求中携带的灰度标识,调用灰度函数,从注册中心查找匹配的灰度节点。
4.根据权利要求2所述的方法,其特征在于,所述利用所述灰度节点对所述业务请求进行处理,包括:
若所述灰度节点调用返回错误,则跳转至非灰度节点对所述业务请求进行处理。
5.根据权利要求1所述的方法,其特征在于,所述在所述业务请求中添加灰度标识包括:
若所述客户端为Motan客户端时,则将所述灰度标识添加至Motan请求头中;
若所述客户端为HTTP客户端时,则将所述灰度标识添加至HTTP请求头中。
6.根据权利要求1所述的方法,其特征在于,所述利用所述目标服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端包括:
在所述目标服务节点启动时,对拦截到的所述业务请求添加灰度标识,并将所述灰度标识添加至追踪容器中;所述追踪容器与所述业务请求的线程具有绑定关系;
当所述目标服务节点需要调用其他服务节点对所述业务请求进行处理时,拦截调用下游服务节点的调用请求,并将所述追踪容器中的灰度标识添加至所述调用请求中,以使得调用与所述灰度标识对应的服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端。
7.根据权利要求2所述的方法,其特征在于,所述预设的端口号包括第一预设端口号和第二预设端口号;
所述根据所述业务请求中的参数,获取预设的端口号包括:
当所述业务请求中的参数为RPC协议参数时,则获取第一预设端口号;所述第一预设端口号是灰度RPC服务节点的注册端口;
当所述业务请求中的参数为HTTP协议参数时,则获取第二预设端口号;所述第二预设端口号是灰度HTTP服务节点的注册端口。
8.一种服务灰度链路的控制装置,其特征在于,所述装置包括:
接收模块,用于接收客户端通过网关发送的业务请求;所述业务请求中携带已协商的识别串;
判断模块,用于根据所述识别串,判断是否进行灰度请求分发;
添加模块,用于若是,则在所述业务请求中添加灰度标识,得到携带灰度标识的业务请求;
发送模块,用于将所述携带灰度标识的业务请求转发至对应的目标服务节点;
处理模块,用于利用所述目标服务节点对所述业务请求进行处理,得到与所述业务请求对应的结果并返回至所述客户端。
9.一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。
CN202110321038.9A 2021-03-25 2021-03-25 服务灰度链路的控制方法、装置、计算机设备和存储介质 Pending CN113055492A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110321038.9A CN113055492A (zh) 2021-03-25 2021-03-25 服务灰度链路的控制方法、装置、计算机设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110321038.9A CN113055492A (zh) 2021-03-25 2021-03-25 服务灰度链路的控制方法、装置、计算机设备和存储介质

Publications (1)

Publication Number Publication Date
CN113055492A true CN113055492A (zh) 2021-06-29

Family

ID=76515490

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110321038.9A Pending CN113055492A (zh) 2021-03-25 2021-03-25 服务灰度链路的控制方法、装置、计算机设备和存储介质

Country Status (1)

Country Link
CN (1) CN113055492A (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113301168A (zh) * 2021-07-23 2021-08-24 浩鲸云计算科技股份有限公司 一种动态策略灰度发布引擎实现请求精准分流方法及系统
CN113794705A (zh) * 2021-09-02 2021-12-14 百融至信(北京)征信有限公司 基于TTL的多header链路灰度发布方法及系统
CN114205422A (zh) * 2021-12-13 2022-03-18 平安养老保险股份有限公司 一种无侵入式业务处理方法、装置、设备及存储介质
CN114615128A (zh) * 2022-03-08 2022-06-10 网易(杭州)网络有限公司 服务管理方法及系统、计算机存储介质和电子设备
CN114721710A (zh) * 2022-04-29 2022-07-08 北京达佳互联信息技术有限公司 版本控制方法、装置及存储介质
CN115048177A (zh) * 2022-08-15 2022-09-13 成都中科合迅科技有限公司 基于自定义容器完成业务场景的动态配置方法
CN115334006A (zh) * 2022-10-14 2022-11-11 平安银行股份有限公司 基于客户端实现的灰度验证方法及系统
CN115665230A (zh) * 2022-10-17 2023-01-31 上海浦东发展银行股份有限公司 一种无侵入应用灰度发布控制方法
CN116760650A (zh) * 2023-08-23 2023-09-15 深圳开源互联网安全技术有限公司 基于iast技术确认微服务调用中http参数污染传播链的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105791344A (zh) * 2014-12-22 2016-07-20 华为软件技术有限公司 灰度发布业务处理的方法、系统、负载均衡器及服务总线装置
CN109739552A (zh) * 2019-01-04 2019-05-10 深圳壹账通智能科技有限公司 微服务灰度发布方法、装置、计算机设备和存储介质
CN110311989A (zh) * 2019-08-02 2019-10-08 中国工商银行股份有限公司 一种灰度发布方法、装置、存储介质、设备及系统
CN111580846A (zh) * 2020-05-15 2020-08-25 厦门靠谱云股份有限公司 一种基于混合框架的微服务灰度发布方法
CN112118565A (zh) * 2020-08-14 2020-12-22 金蝶医疗软件科技有限公司 多租户服务灰度发布方法、装置、计算机设备和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105791344A (zh) * 2014-12-22 2016-07-20 华为软件技术有限公司 灰度发布业务处理的方法、系统、负载均衡器及服务总线装置
CN109739552A (zh) * 2019-01-04 2019-05-10 深圳壹账通智能科技有限公司 微服务灰度发布方法、装置、计算机设备和存储介质
CN110311989A (zh) * 2019-08-02 2019-10-08 中国工商银行股份有限公司 一种灰度发布方法、装置、存储介质、设备及系统
CN111580846A (zh) * 2020-05-15 2020-08-25 厦门靠谱云股份有限公司 一种基于混合框架的微服务灰度发布方法
CN112118565A (zh) * 2020-08-14 2020-12-22 金蝶医疗软件科技有限公司 多租户服务灰度发布方法、装置、计算机设备和存储介质

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113301168A (zh) * 2021-07-23 2021-08-24 浩鲸云计算科技股份有限公司 一种动态策略灰度发布引擎实现请求精准分流方法及系统
CN113794705A (zh) * 2021-09-02 2021-12-14 百融至信(北京)征信有限公司 基于TTL的多header链路灰度发布方法及系统
CN113794705B (zh) * 2021-09-02 2023-08-04 百融至信(北京)科技有限公司 基于TTL的多header链路灰度发布方法及系统
CN114205422B (zh) * 2021-12-13 2023-07-25 平安养老保险股份有限公司 一种无侵入式业务处理方法、装置、设备及存储介质
CN114205422A (zh) * 2021-12-13 2022-03-18 平安养老保险股份有限公司 一种无侵入式业务处理方法、装置、设备及存储介质
CN114615128A (zh) * 2022-03-08 2022-06-10 网易(杭州)网络有限公司 服务管理方法及系统、计算机存储介质和电子设备
CN114615128B (zh) * 2022-03-08 2024-02-23 网易(杭州)网络有限公司 服务管理方法及系统、计算机存储介质和电子设备
CN114721710A (zh) * 2022-04-29 2022-07-08 北京达佳互联信息技术有限公司 版本控制方法、装置及存储介质
CN115048177B (zh) * 2022-08-15 2022-11-04 成都中科合迅科技有限公司 基于自定义容器完成业务场景的动态配置方法
CN115048177A (zh) * 2022-08-15 2022-09-13 成都中科合迅科技有限公司 基于自定义容器完成业务场景的动态配置方法
CN115334006B (zh) * 2022-10-14 2023-04-14 平安银行股份有限公司 基于客户端实现的灰度验证方法及系统
CN115334006A (zh) * 2022-10-14 2022-11-11 平安银行股份有限公司 基于客户端实现的灰度验证方法及系统
CN115665230A (zh) * 2022-10-17 2023-01-31 上海浦东发展银行股份有限公司 一种无侵入应用灰度发布控制方法
CN116760650A (zh) * 2023-08-23 2023-09-15 深圳开源互联网安全技术有限公司 基于iast技术确认微服务调用中http参数污染传播链的方法
CN116760650B (zh) * 2023-08-23 2023-11-21 深圳开源互联网安全技术有限公司 基于iast技术确认微服务调用中http参数污染传播链的方法

Similar Documents

Publication Publication Date Title
CN113055492A (zh) 服务灰度链路的控制方法、装置、计算机设备和存储介质
US11726828B2 (en) Managing a virtualized application workspace on a managed computing device
US10776171B2 (en) Endpoint management system and virtual compute system
US9841882B2 (en) Providing application and device management using entitlements
CN112000348A (zh) 服务灰度发布的控制方法、装置、计算机设备
CN112118565A (zh) 多租户服务灰度发布方法、装置、计算机设备和存储介质
CN109067890B (zh) 一种基于docker容器的CDN节点边缘计算系统
US7174534B2 (en) Efficient system and method for running and analyzing multi-channel, multi-modal applications
US9143511B2 (en) Validation of conditional policy attachments
US7471947B1 (en) Method and system for accessing a universal message handler on a mobile device
US7079839B1 (en) Method and system for push launching applications with context on a mobile device
CN110187912B (zh) 一种节点选择方法和装置
JP2005509322A (ja) アプリケーションの通信に基づく請求方法およびシステム
WO2002044892A2 (en) Method and system for maintaining and distributing wireless applications
CN104298604A (zh) 云服务健壮性测试系统及测试方法
US7996840B2 (en) Method, system, and apparatus for scheduling pattern based web services
US11846972B2 (en) Method and apparatus for generating software test reports
CN113961463A (zh) 应用环境切换方法及系统、存储介质和电子设备
US20050108388A1 (en) Method, system, and apparatus for scheduling pattern based web services
CN114385382A (zh) 轻应用的访问方法、装置、计算机设备和存储介质
US11494184B1 (en) Creation of transportability container files for serverless applications
Passini et al. Developing self-adaptive service-oriented mobile applications: a framework based on dynamic deployment
WO2023049520A1 (en) Advanced agent instrumentation for opentelemetry implementations
US11513833B1 (en) Event listener interface for container-based execution of serverless functions
CN114428723A (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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20210629