istio之流量治理篇

最新推荐文章于 2024-01-04 15:55:54 发布

灰子学技术

最新推荐文章于 2024-01-04 15:55:54 发布

阅读量1.4k

点赞数 1

文章标签：分布式 java python linux 数据库

本文链接：https://blog.csdn.net/zhghost/article/details/118447557

版权

对于service mesh来说，一个比较大的特点就是把路由转发和流量控制这一层下沉到这一层面来做，可以让业务不去操心这部分事情。

本篇文章就是来整理和讲解istio中的流量治理功能，更准确的说是介绍envoy的治理功能，流量治理的常见场景，如下图所示，本文主要对这些场景做一个详细的介绍：

1. 负载均衡

概念：

在微服务场景下，负载均衡一般和服务发现配合使用，每个服务都有多个对等的服务实例，需要有一种机制将请求的服务名解析到服务实例地址上。服务发现负责从服务名中解析一组服务实例的列表，负载均衡负责从中选择一个实例。

1.服务注册：服务实例会先向服务注册中心进行服务注册。
2.服务发现：在客户端发起服务访问的时候，
会以同步或者异步的方式从服务注册中心获取对应的服务实例列表。
3.负载均衡：根据配置的负载均衡算法从服务实例中选一个进行消息转发。

istio中负载均衡的实现：

1.pilot-discovery负责维护服务发现的数据，
并将服务发现的服务实例列表通过xds标准同步给envoy。
2.envoy在收到请求后会根据配置中的负载均衡策略选择一个服务实例进行请求的转发。
目前支持的负载均衡算法主要包括：轮询、随机和最小连接数这三种方式。

例子：

配置：

2. 服务熔断、限流和服务降级

概念：

熔断：服务提供方（upstream）因访问压力过大而响应变慢或失败，服务发起方（downstream）为了保护系统整体的可用性，可以临时暂停对服务提供方的调用，这种牺牲局部，保全整体的措施就叫做熔断。

限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。一般也会算在熔断中。

服务降级：也算是熔断的一种策略，往往是在熔断发生后的一种处理策略，要么直接返回错误给到调用的上游服务，让他们来决策处理，一般直接跳过出现问题的服务。

1.在远程调用时，请求在超时前一直挂起，会导致请求链路上的级联故障和资源耗尽。
2.熔断器封装了被保护的逻辑，监控调用是否失败，当连续调用失败的数量超过阈值时，
熔断器就会跳闸，在跳闸后的一定时间段内，所有调用远程服务的尝试都将立即返回失败。
3.熔断器设置了一个计时器，当计时到期时，允许有限数量的测试请求通过。
如果这些请求成功，则熔断器恢复正常操作；如果这些请求失败，则维持断路状态。
4.熔断关闭：熔断器处于关闭状态，服务可以访问。
熔断器维护了访问失败的计数器，若服务访问失败则+1。
5.熔断开启：熔断器处于开启状态，服务不可访问，若有服务访问则立即出错。
6.熔断半开启：熔断器处于半开启状态，允许对服务尝试请求，
若服务访问成功则说明故障已经得到解决，否则说明故障依然存在。

Istio中的具体实现：

备注：在触发了熔断之后，应用程序需要处理错误并有一定的fall back行为。例如当负载平衡池中的所有服务实例都出现异常时，Envoy将返回HTTP 503。当上游服务返回 HTTP 503 错误，则应用程序需要采取回退逻辑。

istio提供了两种配置，分别是连接池管理（ConnectionPoolSettings）和异常点检查（OutlierDetection）

1.在 Istio 中通过限制某个客户端对目标服务的连接数、访问请求数等，
避免对一个服务的过量访问，如果超过配置的阈值，则快速断路请求。
还会限制重试次数，避免重试次数过多导致系统压力变大并加剧故障的传播。

连接池的设置：

connectionpool可以对上游服务的并发连接数和请求数进行限制，适用于TCP和HTTP。

（官方定义的属性）

TCP配置示例：

HTTP配置参数：（备注：http连接池设置用于http1.1/HTTP2/GRPC连接）

1. http1MaxPendingRequests：
http请求pending状态的最大请求数，从应用容器发来的HTTP请求的最大等待转发数，默认是1024。
2. http2MaxRequests：后端请求的最大数量，默认是1024。
3. maxRequestsPerConnection：
在一定时间内限制对后端服务发起的最大请求数，如果超过了这个限制，就会开启限流。
如果将这一参数设置为 1 则会禁止 keepalive 特性。
4. idleTimeout：
上游连接池连接的空闲超时。空闲超时被定义为没有活动请求的时间段。
如果未设置，则没有空闲超时。当达到空闲超时时，连接将被关闭。
注意，基于请求的超时意味着HTTP/2ping将无法保持有效连接。
适用于HTTP1.1和HTTP2连接。
5. maxRetries：
在给定时间内，集群中所有主机都可以执行的最大重试次数，默认为3。

异常点检查（OutlierDetection）：

检测原理：
 检测到了某个主机异常。
2.如果到目前为止负载均衡池中还没有主机被隔离出去，将会立即隔离该异常主机；
如果已经有主机被隔离出去，就会检查当前隔离的主机数是否低于设定的阈值
（通过envoy中的 outlier_detection.max_ejection_percent 指定），
如果当前被隔离的主机数量不超过该阈值，就将该主机隔离出去，否则不隔离。
3.隔离不是永久的，会有一个时间限制。
当主机被隔离后，该主机就会被标记为不健康，并且不会被加入到负载均衡池中，
除非负载均衡处于恐慌模式。
隔离时间等于envoy中的outlier_detection.base_ejection_time_ms的值乘以主机被隔离的次数。
所以如果某个主机连续出现故障，会导致它被隔离的时间越来越长。
4.经过了规定的隔离时间之后，被隔离的主机将会自动恢复过来，重新接受调用方的远程调用。
通常异常检测会与主动健康检查一起用于全面的健康检查解决方案。

异常检测的类型：

1.连续5XX响应：上游主机连续返回一定数量的5XX响应，该主机就会被驱逐。
2.连续网管故障：上游主机连续返回一定数量的‘gatewayerrors’(一般是502，503，504这些状态码)，该主机会被驱逐。
3.调用成功率：基于调用成功率的异常检测类型会聚合集群中每个主机的调用成功率，然后根据统计的数据以给定的周期来隔离主机。

配置的例子：