CN116980480B - 基于微服务网络模型的熔断信息的处理方法及*** - Google Patents

Abstract

本申请涉及网络架构领域，公开了一种基于微服务网络模型的熔断信息的处理方法及***，解决了网络熔断后处理无法定制化的问题，使运维人员缩短问题定位的时间，提高效率。该方法包括：下游主机发出调用服务的请求；信息包过滤表将调用服务的请求转发至服务代理程序组件，服务代理程序组件内判断服务是否发生熔断；若服务未发生熔断，则将访问服务的流量分发至上游主机；若服务发生熔断，则将访问熔断服务的流量统一路由到指定的自定义服务，自定义服务被配置为通过获取请求的原始请求信息以返回熔断信息及错误信息。

Description

基于微服务网络模型的熔断信息的处理方法及***

技术领域

本申请涉及网络架构领域，具体涉及一种基于微服务网络模型的熔断信息的处理方法及***。

背景技术

本部分旨在为权利要求书中陈述的本申请的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是已被公开的现有技术。

K8s（kubernetes）+istio的组合已成为目前云原生以及微服务构建的事实上的标准。K8s是一款用于管理容器化工作负载和服务的可移植、可扩展的开源平台,它面向基础设施，将计算、网络、存储等资源进行紧密整合，为容器提供最佳运行环境，并面向应用提供封装好的、易用的工作负载与服务编排接口，以及运维所需的资源规格、弹性、运行参数、调度等配置管理接口，是新一代的云原生基础设施平台。K8s的服务基于每个节点的Kube-proxy（K8s的核心组件之一）从Kube-apiserver（K8s的核心组件之一）上获取服务（Service）和端点（Endpoint）的信息，并将对服务的请求经过负载均衡转发到对应的端点上。但K8s只提供了4层负载均衡能力。从外部接入的网关来讲，K8s使用了集群内服务对外暴露的访问接入点（ingress）来接收外部流量，但是同样地，也只提供4层转发能力，并不具备7层路由能力，这使得ingress的使用受到很大限制。

目前基于istio的微服务熔断机制并不完善：首先，无法统一设置熔断器，只能按照微服务一个一个设置，这样如果微服务很多，设置起来会相当麻烦。其次，服务熔断只能使用istio默认的返回错误，无法自定义，这会使用户在熔断时无法准确获知熔断的位置和具体的错误信息。

在现有技术中，如果发生熔断，只会返回50x错误，并不会提示服务链中哪个环节出现的熔断，返回错误不可定制，因此运维人员处理网络熔断时的效率也较低。

发明内容

本申请的目的在于提供一种基于微服务网络模型的熔断信息的处理方法及***，可以在网络服务出现熔断后进行定制化，运维人员可以缩短问题定位的时间，提高效率。

本申请公开了一种基于微服务网络模型的熔断信息的处理方法，包括：

下游主机发出调用服务的请求；

信息包过滤表将所述调用服务的请求转发至服务代理程序组件，所述服务代理程序组件内判断服务是否发生熔断；

若服务未发生熔断，则将访问服务的流量分发至上游主机；

若服务发生熔断，则将访问熔断服务的流量统一路由到指定的自定义服务，所述自定义服务被配置为通过获取所述请求的原始请求信息以返回熔断信息及错误信息。

在一个优选例中，在判断网络是否发生熔断之前还包括：

在服务所在的命名空间里创建公共熔断器，所述公共熔断器被配置为使在同一命名空间内的所有服务熔断。

在一个优选例中，所述公共熔断器的命名名称满足正则表达式的匹配。

在一个优选例中，所述信息包过滤表将所述调用服务的请求转发至服务代理程序组件进一步包括：

所述信息包过滤表将所述调用服务的请求转发至所述服务代理程序组件中的虚拟侦听器；

所述虚拟侦听器将所述调用服务的请求根据原目标地址和端口转发到对应的侦听器；

所述对应的侦听器根据端口规则将流量进行分发。

在一个优选例中，所述将所述访问熔断服务的流量统一路由到指定的自定义服务进一步包括：

所述访问熔断服务的流量进入负载均衡，经过服务网关转发到默认服务对应的服务提供集群；

所述服务提供集群将所述访问熔断服务的流量引导至所述自定义服务。

在一个优选例中，在所述服务提供集群将所述访问熔断服务的流量引导至所述自定义服务之后还包括：

所述自定义服务根据配置找到目标服务并匹配相应的目标服务规则；

所述目标服务通过边车容器对所述访问熔断服务的流量进行流量劫持并转发至相应的容器。

在一个优选例中，所述熔断信息包括熔断的服务名、接口名称以及参数集合。

本申请还公开了一种基于微服务网络模型的熔断信息的处理***，包括：

信息包过滤表，被配置为转发下游主机的调用服务的请求；

服务代理程序组件，被配置为接受所述请求并判断服务是否发生熔断，若所述服务发生熔断则将所述服务的流量分发至上游主机；以及，

自定义服务容器，被配置为当所述服务熔断时接收所述服务的流量，以及通过获取所述请求的原始请求信息以返回熔断信息及错误信息。

在一个优选例中，还包括公共熔断器，所述公共熔断器被配置为使在同一命名空间内的所有服务熔断。

本申请还公开了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现如前文描述的方法中的步骤。

在本申请中，通过在服务熔断直接返回错误的环节中添加了转发至服务对应的集群这一步骤，该集群将流量引导至一个可定制的容器组中并返回错误的具体信息，从而可以实现错误信息的定制化，运维人员可以更迅速的定位和解决问题，从而提升***可用性；

进一步地，取代了以往每一个服务对应一个熔断器的设置，采用在同一命名空间下设置公共熔断器的方式，相同配置的熔断器可以使用一个配置，而无需每个都配置，可以减轻配置和运维负担，也利于统一修改配置。

上述发明内容中公开的各个技术特征、在下文各个实施方式和例子中公开的各技术特征、以及附图中公开的各个技术特征，都可以自由地互相组合，从而构成各种新的技术方案（这些技术方案均应该视为在本说明书中已经记载），除非这种技术特征的组合在技术上是不可行的。例如，在一个例子中公开了特征A+B+C，在另一个例子中公开了特征A+B+D+E，而特征C和D是起到相同作用的等同技术手段，技术上只要择一使用即可，不可能同时采用，特征E技术上可以与特征C相组合，则，A+B+C+D的方案因技术不可行而应当不被视为已经记载，而A+B+C+E的方案应当视为已经被记载。

附图说明

图1是根据本申请的一个实施方式的流程示意图；

图2是根据本申请的一个实施方式的熔断器配置示意图；

图3是根据本申请的一个实施方式的流程示意图；

图4是根据本申请的一个实施方式的流程示意图；

图5是根据本申请的一个实施方式的架构示意图。

具体实施方式

在以下的叙述中，为了使读者更好地理解本申请而提出了许多技术细节。但是，本领域的普通技术人员可以理解，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

部分概念的说明：

熔断：服务熔断也称服务隔离或过载保护。在微服务应用中，服务存在一定的依赖关系，形成一定的依赖链，如果某个目标服务调用慢或者有大量超时，造成服务不可用，间接导致其他的依赖服务不可用，最严重的可能会阻塞整条依赖链，最终导致业务***崩溃（又称雪崩效应）。此时，对该服务的调用执行熔断，对于后续请求，不再继续调用该目标服务，而是直接返回，从而可以快速释放资源。等到目标服务情况好转后，则可恢复其调用。

熔断器：本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式***中的蔓延，乃至雪崩。

Pod：pod是K8s的最小单元，容器（container）包含在pod中，pod是一组容器的集合。pod相当于逻辑主机，每个pod都有自己的ip地址。pod内的容器共享相同的ip和端口默认情况下，每个容器的文件***与其他容器完全隔离。

Cluster：集群，是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益，其任务调度则是集群***中的核心技术。集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一***的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。集群配置是用于提高可用性和可缩放性。

iptables：是与最新的3.5版本Linux内核集成的IP信息包过滤表。如果Linux***连接到因特网或LAN、服务器或连接LAN和因特网的代理服务器，则该***有利于在Linux***上更好地控制IP信息包过滤和防火墙配置。

Istio：是一种微服务管理、保护和监控框架。使用Istio可以很简单的创建具有负载均衡、服务间认证、监控等功能的服务网络，而不需要对服务的代码进行任何修改。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请的实施方式作进一步地详细描述。

本申请的第一实施方式涉及一种基于微服务网络模型的熔断信息的处理方法，其流程如图1所示，该方法包括以下步骤：

在步骤101中，下游主机发出调用服务的请求。

在步骤102中，信息包过滤表将调用服务的请求转发至服务代理程序组件，服务代理程序组件内判断服务是否发生熔断。

在步骤103中，若服务未发生熔断，则将访问服务的流量分发至上游主机。

在步骤104中，若服务发生熔断，则将访问熔断服务的流量统一路由到指定的自定义服务，自定义服务被配置为通过获取请求的原始请求信息以返回熔断信息及错误信息。

可选地，在判断网络是否发生熔断之前还可以包括：在服务所在的命名空间里创建公共熔断器，公共熔断器被配置为使在同一命名空间内的服务熔断。可选地，如图2所示，优化后的熔断器，可以在服务所在的命名空间配置，该熔断器可以像pod和service一样按照命名空间进行隔离，在一个命名空间下的熔断器不会影响或适用到其他命名空间的服务。从而可以在一个命名空间里建立一个公共的熔断器。

可选地，公共熔断器的命名名称可以满足正则表达式的匹配。例如，abc.*可以表示以abc开头的服务，*可以表示该命名空间下的所有服务。所以相同配置的熔断器可以使用一个配置，而无需每个都配置，这样就减轻了配置和运维负担，也利于统一修改配置。

可选地，如图3所示，在步骤102中还可以进一步地包括以下步骤：

在步骤1021中，信息包过滤表将调用服务的请求转发至服务代理程序组件中的虚拟侦听器。

在步骤1022中，虚拟侦听器将调用服务的请求根据原目标地址和端口转发到对应的侦听器；

在步骤1023中，对应的侦听器根据端口规则将流量进行分发。

可选地，将访问熔断服务的流量统一路由到指定的自定义服务可以进一步包括：访问熔断服务的流量进入负载均衡，经过服务网关转发到默认服务对应的服务提供集群，服务提供集群将访问熔断服务的流量引导至自定义服务。

可选地，在服务提供集群将访问熔断服务的流量引导至自定义服务之后还可以包括：自定义服务根据配置找到目标服务并匹配相应的目标服务规则，目标服务通过边车容器对访问熔断服务的流量进行流量劫持并转发至相应的容器。

可选地，熔断信息可以包括熔断的服务名、接口名称以及参数集合。

为了能够更好地理解本申请的技术方案，下面结合一个具体的例子来进行说明，该例子中罗列的细节主要是为了便于理解，不作为对本申请的保护范围的限制。

如图4所示，服务srvA发起对服务srvB的调用。请求被服务srvA的容器组（pod）的信息包过滤表（iptables）截取，转发到端口15001，该容器组的地址可以为192.168.200.3。服务代理程序组件（边车容器envoy）的虚拟侦听器（Virtual Listener）在15001端口上监听，收到了该请求。请求被虚拟侦听器根据原目标IP（通配）和端口（9080）转发到0.0.0.0_9080这个侦听器（listener）。

如果不发生熔断，根据0.0.0.0_9080listener的http_conn_filter和circuitbreaker_filter配置,该请求通过路由：9080进行分发。如果发生熔断，该请求通过路由：8080进行转发。路由：8080转发到默认服务对应的集群（cluster），即向外发送集群Outbound Cluster:outbound||8080||message，从而将流量引导到DefaultSrv服务，地址可以为192.168.200.10。DefaultSrv服务是专为熔断处理运行的容器组pod，该容器组包括可定制的容器，并且可以定制返回信息。例如，服务通过获取原始请求信息返回熔断的服务名，接口名称和参数集合，可以将错误记入日志或者通过消息服务发送给运维人员。通过这种方式，运维人员可以更迅速的定位和解决问题，从而提升***可用性。

在不发生熔断情况下的“9080”route的配置中，主机（host）名称为info:9080的请求对应的集群为outbound||9080||info.default.svc.cluster.local。outbound||9080||info.default.svc.cluster.local cluster为动态资源，通过终端发现服务（EDS）查询得到其端点为192.168.200.4:9080。请求被转发到192.168.200.4，即info服务所在的容器。流量被信息包过滤表规则拦截，转发到15001端口。Envoy的虚拟侦听器在15001端口上监听，收到了该请求。请求被虚拟侦听器根据请求原目标地址IP（192.168.200.4）和端口9080转发到192.168.200.4_9080这个侦听器。根据192.168.200.4_9080侦听器的http_connection_manager_filter配置,该请求对应的集群为内部接收集群Inbound Cluster:inbound||9080||info.default.svc.cluster.local。请求被转发到127.0.0.1:9080。流量最终抵达服务srvB。

本申请的第二实施方式涉及一种基于微服务网络模型的熔断信息的处理***，该***包括：

信息包过滤表，被配置为转发下游主机的调用服务的请求；

服务代理程序组件，被配置为接受请求并判断服务是否发生熔断，若服务发生熔断则将服务的流量分发至上游主机；以及，

自定义服务容器，被配置为接收服务熔断时服务的流量，以及通过获取请求的原始请求信息以返回熔断信息及错误信息。

可选地，该***还可以包括一个或多个公共熔断器，公共熔断器被配置为使在同一命名空间内的服务熔断。

第一实施方式是与本实施方式相对应的方法实施方式，第一实施方式中的技术细节可以应用于本实施方式，本实施方式中的技术细节也可以应用于第一实施方式。

为了能够更好地理解本申请的技术方案，下面结合一个具体的例子来进行说明，该例子中罗列的细节主要是为了便于理解，不作为对本申请的保护范围的限制。

本申请整体遵循k8s+istio的容器网络架构，如图5所示，流量从负载均衡进来后，经过istio服务网关，路由到指定的虚拟服务virtual service，virtual service根据配置找到service（如果设置了目标服务（destination service），则要匹配相应destinationservice规则，而熔断器正是配置在destination service之中），service再通过pod内边车（sidecar）流量劫持，并转发到相应的容器。

相应地，本申请的实施方式还提供一种计算机可读存储介质，其中存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现本申请的各方法实施方式。计算机可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于，相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读存储介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

需要说明的是，在本申请中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。本申请中，如果提到根据某要素执行某行为，则是指至少根据该要素执行该行为的意思，其中包括了两种情况：仅根据该要素执行该行为、和根据该要素和其它要素执行该行为。多个、多次、多种等表达包括2个、2次、2种以及2个以上、2次以上、2种以上。

在描述方法的步骤时使用的序号本身并不对这些步骤的顺序构成任何的限定。例如，序号大的步骤并非一定要在序号小的步骤之后执行，也可以是先执行序号大的步骤再执行序号小的步骤，还可以是并行执行，只要这种执行顺序对于本领域技术人员来说是合理的即可。又如，拥有连续编号序号的多个步骤（例如步骤101，步骤102，步骤103等）并不限制其他步骤可以在其间执行，例如步骤101和步骤102之间可以有其他的步骤。

本说明书包括本文所描述的各种实施例的组合。对实施例的单独提及（例如“一个实施例”或“一些实施例”或“优选实施例”）；然而，除非指示为是互斥的或者本领域技术人员很清楚是互斥的，否则这些实施例并不互斥。应当注意的是，除非上下文另外明确指示或者要求，否则在本说明书中以非排他性的意义使用“或者”一词。

在本说明书提及的所有文献都被认为是整体性地包括在本申请的公开内容中，以便在必要时可以作为修改的依据。此外应理解，以上所述仅为本说明书的较佳实施例而已，并非用于限定本说明书的保护范围。凡在本说明书一个或多个实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例的保护范围之内。

在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

Claims (10)

1.一种基于微服务网络模型的熔断信息的处理方法，其特征在于，包括：

下游主机发出调用服务的请求；

信息包过滤表将所述调用服务的请求转发至服务代理程序组件，所述服务代理程序组件内判断服务是否发生熔断；

若服务未发生熔断，则将访问服务的流量分发至上游主机；

若服务发生熔断，则将访问熔断服务的流量统一路由到指定的自定义服务，所述自定义服务被配置为通过获取所述请求的原始请求信息以返回熔断信息及错误信息。

2.如权利要求1所述的基于微服务网络模型的熔断信息的处理方法，其特征在于，在判断网络是否发生熔断之前还包括：

在服务所在的命名空间里创建公共熔断器，所述公共熔断器被配置为使在同一命名空间内的所有服务熔断。

3.如权利要求2所述的基于微服务网络模型的熔断信息的处理方法，其特征在于，所述公共熔断器的命名名称满足正则表达式的匹配。

4.如权利要求1所述的基于微服务网络模型的熔断信息的处理方法，其特征在于，所述信息包过滤表将所述调用服务的请求转发至服务代理程序组件进一步包括：

所述信息包过滤表将所述调用服务的请求转发至所述服务代理程序组件中的虚拟侦听器；

所述虚拟侦听器将所述调用服务的请求根据原目标地址和端口转发到对应的侦听器；

所述对应的侦听器根据端口规则将流量进行分发。

5.如权利要求1所述的基于微服务网络模型的熔断信息的处理方法，其特征在于，所述将所述访问熔断服务的流量统一路由到指定的自定义服务进一步包括：

所述访问熔断服务的流量进入负载均衡，经过服务网关转发到默认服务对应的服务提供集群；

所述服务提供集群将所述访问熔断服务的流量引导至所述自定义服务。

6.如权利要求5所述的基于微服务网络模型的熔断信息的处理方法，其特征在于，在所述服务提供集群将所述访问熔断服务的流量引导至所述自定义服务之后还包括：

所述自定义服务根据配置找到目标服务并匹配相应的目标服务规则；

所述目标服务通过边车容器对所述访问熔断服务的流量进行流量劫持并转发至相应的容器。

7.如权利要求1所述的基于微服务网络模型的熔断信息的处理方法，其特征在于，所述熔断信息包括熔断的服务名、接口名称以及参数集合。

8.一种基于微服务网络模型的熔断信息的处理***，其特征在于，包括：

信息包过滤表，被配置为转发下游主机的调用服务的请求；

服务代理程序组件，被配置为接受所述请求并判断服务是否发生熔断，若所述服务发生熔断则将所述服务的流量分发至上游主机；以及，

自定义服务容器，被配置为当所述服务熔断时接收所述服务的流量，以及通过获取所述请求的原始请求信息以返回熔断信息及错误信息。

9.如权利要求8所述的基于微服务网络模型的熔断信息的处理***，其特征在于，还包括公共熔断器，所述公共熔断器被配置为使在同一命名空间内的所有服务熔断。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现如权利要求1至7中任意一项所述的方法中的步骤。