开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

ISTIO sidecar导致Java grpc客户端在高并发负载下抛出“不可用:上游连接错误或在标题前断开/重置”

ISTIO是一个开源的服务网格平台，用于管理和连接不同的微服务。它通过将一个名为sidecar的代理容器注入到每个微服务实例中，实现了对流量的控制、安全性、可观测性和策略的管理。

Java gRPC是一种高性能、开源的远程过程调用（RPC）框架，它允许不同的应用程序在分布式系统中进行通信。在高并发负载下，由于ISTIO sidecar的存在，可能会导致Java gRPC客户端抛出“不可用:上游连接错误或在标题前断开/重置”的错误。

这个错误通常是由于ISTIO sidecar的连接管理策略导致的。ISTIO sidecar会对传入和传出的流量进行拦截和管理，以实现服务网格的功能。在高并发负载下，ISTIO sidecar可能会因为连接池的限制或其他原因导致连接错误或断开/重置。

为了解决这个问题，可以考虑以下几个方案：

调整连接池配置：可以通过调整ISTIO sidecar的连接池配置来增加连接数或延长连接的超时时间，以适应高并发负载。
使用连接池管理器：可以使用连接池管理器，如HikariCP或Tomcat JDBC连接池，来管理Java gRPC客户端的连接池。这样可以更好地控制连接的创建和释放，避免连接错误或断开/重置。
使用ISTIO的连接池配置：ISTIO提供了一些连接池的配置选项，可以通过修改ISTIO的配置文件来调整连接池的行为。可以参考ISTIO的官方文档（https://istio.io/latest/docs/ops/configuration/traffic-management/egress/#connection-pool-options）了解更多信息。
使用ISTIO的负载均衡策略：ISTIO提供了多种负载均衡策略，可以通过修改ISTIO的配置文件来选择适合的负载均衡策略。可以参考ISTIO的官方文档（https://istio.io/latest/docs/ops/configuration/traffic-management/egress/#load-balancing-options）了解更多信息。

总结起来，当在高并发负载下使用ISTIO sidecar时，可能会遇到Java gRPC客户端抛出“不可用:上游连接错误或在标题前断开/重置”的错误。为了解决这个问题，可以通过调整连接池配置、使用连接池管理器、使用ISTIO的连接池配置或负载均衡策略来优化和调整系统。

页面内容是否对你有帮助？

有帮助

没帮助

相关·内容

太强了,Istio竟然有这么多功能!

你可能希望在较庞大的应用程序中限制这样的 sidecar 可达性，配置每个代理能访问网格中的任意服务可能会因为高内存使用量而影响网格的性能。...在熔断器中，设置一个对服务中的单个主机调用的限制，例如并发连接的数量或对该主机调用失败的次数。一旦限制被触发，熔断器就会“跳闸”并停止连接到该主机。...故障注入是一种将错误引入系统以确保系统能够承受并从错误条件中恢复的测试方法。使用故障注入特别有用，能确保故障恢复策略不至于不兼容或者太严格，这会导致关键服务不可用。...与其他错误注入机制（如延迟数据包或在网络层杀掉 Pod）不同，Istio 允许在应用层注入错误。这使您可以注入更多相关的故障，例如 HTTP 错误码，以获得更多相关的结果。...它们模拟增加的网络延迟或一个超载的上游服务。终止终止是崩溃失败。他们模仿上游服务的失败。终止通常以 HTTP 错误码或 TCP 连接失败的形式出现。

7502 0

还不知道你就out了,一文40分钟快速理解

可以实现负载均衡、基于不同版本流量百分比路由。为什么使用虚拟服务？虚拟服务在增强 Istio 流量管理方面，发挥着至关重要的作用，通过对客户端请求与真实响应请求的目标工作负载进行解耦来实现。...在较庞大的应用程序中限制 sidecar 可达性，配置每个代理能访问网格中的任意服务，可能会因为高内存使用量而影响网格的性能。...栗子：将 v1 子集的reviews服务工作负载的并发连接数限制为 100： apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule...为什么使用：故障注入是一种将错误引入系统以确保系统能够承受并从错误条件中恢复的测试方法。作用：使用故障注入特别有用，能确保故障恢复策略不至于不兼容或者太严格，这会导致关键服务不可用。...它们模拟增加的网络延迟或一个超载的上游服务。终止：终止是崩溃失败。他们模仿上游服务的失败。终止通常以 HTTP 错误码或 TCP 连接失败的形式出现。

3.9K3 0

Istio 运维实战系列（2）：让人头大的『无头服务』-上

例如，如果后端的这一组 Pod 是有状态的，需要由客户端根据某种应用相关的算法来选择哪一个 Pod 提供服务；或者客户端需要连接所有的后端 Pod，这时我们就不能在这一组 Pod 前放一个负载均衡器了。...这就导致了客户端 Envoy Sidecar 在向 Redis 服务器创建链接时失败了。...Redis 客户端以为是这样的：但实际上是这样的：在服务器端没有安装 Envoy Sidecar，不支持 mTLS 的情况下，按理客户端的 Envoy 不应该采用 mTLS 向服务器端发起连接。...Redis 是一个 Headless Service，通过在社区查找相关资料，发现 Istio 1.6 版本前对 Headless Service 的处理有问题，导致了该故障。...这次我们遇到的问题是由于 Istio 1.6 版本前对 Headless Service 处理的一个 Bug 导致无法连接到 Headless Service。

7802 0

Istio 运维实战系列（2）：让人头大的『无头服务』-上

例如，如果后端的这一组 Pod 是有状态的，需要由客户端根据某种应用相关的算法来选择哪一个 Pod 提供服务；或者客户端需要连接所有的后端 Pod，这时我们就不能在这一组 Pod 前放一个负载均衡器了。...这就导致了客户端 Envoy Sidecar 在向 Redis 服务器创建链接时失败了。 Redis 客户端以为是这样的： ? 但实际上是这样的： ?...在服务器端没有安装 Envoy Sidecar，不支持 mTLS 的情况下，按理客户端的 Envoy 不应该采用 mTLS 向服务器端发起连接。这是怎么回事呢？...的同时被加上了该标签，客户端 Enovy Sidecar 在向该 Pod 发起连接时，根据 endpoint 中的标签匹配到 tlsMode-istio 中的配置，就会采用 mTLS；而如果一个 Pod...Redis 是一个 Headless Service，通过在社区查找相关资料，发现 Istio 1.6 版本前对 Headless Service 的处理有问题，导致了该故障。

3.5K27 10

使用 KubeSphere 轻松实现微服务灰度发布与熔断

连接池管理：将最大连接数和最大等待请求数(等待列队的长度) 都设置为 1，表示如果超过了一个连接同时发起请求，Istio 就会熔断，阻止后续的请求或连接；熔断器：参考如下设置，表示每 1 秒钟扫描一次上游主机...Step 7：设置客户端 由于我们已经在 reviews-v2 中 reviews 容器中注入了负载测试客户端 (fortio)，它可以控制连接数量、并发数以及发送 HTTP 请求的延迟，能够触发在上一步中设置的熔断策略...在 ratings 中设置了连接池管理的熔断规则，最大连接数和最大等待请求数(等待列队的长度) 都设置为 1，接下来设置两个并发连接（-c 2），发送 20 请求（-n 20）： $ kubectl...在「工作负载」→ 「部署」列表中找到 reviews-v2，点击右侧 ··· 选择「编辑配置文件」，添加一条 sidecar.istio.io/statsInclusionPrefixes 的 annotation...··· annotations: sidecar.istio.io/inject: 'true' sidecar.istio.io/statsInclusionPrefixes: '

2K2 0

干货 | 携程 SOA 的 Service Mesh 架构落地

由于这里的核心目标就是让刚启动的服务实例逐步接入流量，最小连接数的负载均衡算法就可以达到这个目标，并且负载均衡方式通过 Istio 的 DestinationRule 直接就可以进行配置，这个算法可以使客户端每次都去访问当前活跃请求数最小那个服务端...于是我们考虑在服务发布期间，将服务的负载均衡方式设置为最小连接数。对于利用最小连接数的负载均衡的实际效果我们也做了相关的测试，可以看到引入后服务端在启动过程中，客户端的平均响应时间大幅度下降。...而在服务接入 Service Mesh 后，在发布期间我们通过最小连接数的负载均衡算法，自适应地调整不同实例的负载。...如果我们不处理，这个异常在 gRPC 中就是UNKNOWN。因此需要在底层把RpcException和GrpcException的转换。将一般错误变为 gRPC 的异常抛出。...只可惜在一年多前这块还是有不少问题的，包括 Sidecar 占用内存大增、内存泄露、WebAssembly SDK 扩展性不够等。

1K2 0

后Kubernetes时代的微服务

gRPC流式订阅：每个xDS API可以单独配置ApiConfigSource，指向对应的上游管理服务器的集群地址。...这是遵循电子工程中的先合后断（Make-Before-Break）原则的，即在断开原来的连接之前先建立好新的连接，应用在路由里就是为了防止在设置了新的路由规则时无法发现上游集群而导致流量被丢弃的情况，类似于电路里的断路...Listener（监听器）：监听器是命名网地址（例如，端口、UNIX Domain Socket等)，下游客户端可以连接这些监听器。Envoy暴露一个或多个监听器给下游主机连接。...这些策略中可以定义负载均衡配置、连接池尺寸及外部检测（用于在负载均衡池中对不健康主机进行识别和驱逐）配置。...ServiceEntry：在默认情况下，Istio服务网格中的服务是无法发现Mesh以外的服务的。

7863 0

Istio 运维实战系列（3）：让人头大的『无头服务』-下

在日志中还可以看到，在连接失败后，Envoy 向客户端应用返回了一个 “503” HTTP 错误码。...Istio 中 Envoy Sidecar 的该处理方式和 K8s 对 Headless Service 的处理是类似的，即由客户端根据 DNS 直接选择一个后端的 Pod IP，不会采用负载均衡算法对客户端的请求进行重定向分发...那么一个最直接的想法就是让 Envoy 采用正确的 IP 地址去连接 Upstream Host。在不修改客户端代码，不重建客户端链接的情况下，如何才能实现呢？...对于有状态的服务，需要由客户端根据应用特定的算法来自行决定访问哪一个后端 Pod，因此不应该在这些 Pod 前加一个负载均衡器。...对于该问题，更合理的处理方法是 Envoy Sidecar 在尝试连接 Upstream Host 失败一定次数后主动断开和客户端侧的链接，由客户端重新查询 DNS，获取正确的 Pod IP 来创建新的链接

5543 0

Istio 运维实战系列（3）：让人头大的『无头服务』-下

在日志中还可以看到，在连接失败后，Envoy 向客户端应用返回了一个 "503" HTTP 错误码。...那么一个最直接的想法就是让 Envoy 采用正确的 IP 地址去连接 Upstream Host。在不修改客户端代码，不重建客户端链接的情况下，如何才能实现呢？...对于有状态的服务，需要由客户端根据应用特定的算法来自行决定访问哪一个后端 Pod，因此不应该在这些 Pod 前加一个负载均衡器。...因此设置 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 环境变量，在客户端的 Envoy Sidecar 中对客户端发往 Eureka Server 的请求进行负载均衡是没有问题的...对于该问题，更合理的处理方法是 Envoy Sidecar 在尝试连接 Upstream Host 失败一定次数后主动断开和客户端侧的链接，由客户端重新查询 DNS，获取正确的 Pod IP 来创建新的链接

1.4K11 8

熔断与异常检测在 Istio 中的应用

最大连接数现在我们已经为 httpbin 服务设置了熔断策略，接下来创建一个 Java 客户端，用来向后端服务发送请求，观察是否会触发熔断策略。...这个客户端可以控制连接数量、并发数、待处理请求队列，使用这一客户端，能够有效的触发前面在目标规则中设置的熔断策略。该客户端的 deployment yaml 内容如下： ?...这里我们会把给客户端也进行 Sidecar 的注入，以此保证 Istio 对网络交互的控制： $ kubectl apply -f <(istioctl kube-inject -f httpbin-client-deploy.yaml...) 下面来观察一下当客户端试图使用太多线程与上游集群建立并发连接时，Envoy 会如何应对。...该配置表示每秒钟扫描一次上游主机，连续失败 1 次返回 5xx 错误码的所有主机会被移出连接池 3 分钟。

1.9K3 0

gRPC 长连接在微服务业务系统中的实践

负载均衡机制现代后端服务端架构中，为了实现高可用和可伸缩，一般都会引入单独的模块来提供负载均衡的功能，称为负载均衡器。根据工作在 OSI 不同的层级，不同的负载均衡器会提供不同的转发功能。...在长连接模式下，由于连接一旦建立便不会断开，就会导致流量会被分发到同一个 server。...在 client 与 server 数量差距不大甚至 client 少于 server 的情况下，就会导致流量分发不均。如下图中，第三个 server 会一直处于空闲的状态。...实践中一定要结合实际情况，避免因错误的使用导致性能下降或者负载均衡失效的情况发生。...当使用自定义的 dialOptions 时，切换到短连接模式性能测试我们在 Istio 平台下，对同一个接口在长连接和短连接两种模式下的响应时间和吞吐量进行了压力测试。

3.8K3 1

云原生社区最新力作《深入理解 Istio》出版

gRPC 流式订阅：每个 xDS API 可以单独配置 ApiConfigSource，指向对应的上游管理服务器的集群地址。...Istio 使用 gRPC 流式订阅的方式配置所有的数据平面的 Sidecar Proxy。下面总结关于 xDS 协议的要点。...这是遵循电子工程中的先合后断（Make-Before-Break）原则的，即在断开原来的连接之前先建立好新的连接，应用在路由里就是为了防止在设置了新的路由规则时无法发现上游集群而导致流量被丢弃的情况，类似于电路里的断路...Upstream（上游）：上游主机接收来自 Envoy 的连接和请求，并返回响应，即接收请求的主机。...这些策略中可以定义负载均衡配置、连接池尺寸及外部检测（用于在负载均衡池中对不健康主机进行识别和驱逐）配置。

5242 0

Istio的流量管理(概念)(istio 系列二)

istio的流量管理依赖Envoy代理，该代理作为sidecar与服务容器部署在同一个pod内，服务发送或接收的流量都会经过Envoy，这样就可以在不改变服务的情况下实现网格中的流量管理。...在断路器中，可以设置对服务中单个主机的呼叫限制，如限制到一台主机的并发连接数，或限制到一台主机的调用失败的次数，一旦达到限制值，断路器或发出告警并停止连接这台主机。...下面例子限制了reviews服务负载的v1服务子集的最大并发连接数为100。...故障注入是一个测试机制，将错误引入到一个系统来保证系统能够承受该错误支持错误恢复。使用故障注入可以特别有助于确保不会因为故障恢复策略的兼容性和限制性而导致关键服务不可用。...用于模拟增加的网络延迟或超载的上游服务中断：崩溃故障。用于模拟上游服务故障，通常以HTTP错误代码或TCP连接失败的形式出现。

1.8K4 0

《云原生服务网格Istio》第3章非侵入的流量治理

第3章非侵入的流量治理通过对本章的学习，可基于Istio的这些配置在不修改代码的情况下实现各种流量治理 ---- 3.1 Istio流量治理的原理流量治理是一个非常宽泛的话题动态修改服务间访问的负载均衡策略...3.1.2 服务熔断 “熔断器”这个概念延伸到计算机世界中指的是故障检测和处理逻辑，防止临时故障或意外导致系统整体不可用，最典型的应用场景是防止网络和服务调用故障级联发生，限制故障的影响范围，防止故障蔓延导致系统整体性能下降或雪崩...即使其他服务都是运行良好的，只要其中一个服务有这样0.001%的故障几率，对整个系统就都会产生严重的影响熔断主要应用于微服务场景下的分布式调用中在远程调用时，请求在超时前一直挂起，会导致请求链路上的级联故障和资源耗尽...连接池管理（ConnectionPoolSettings）和异常点检查（OutlierDetection）这两种配置在 Istio 中通过限制某个客户端对目标服务的连接数、访问请求数等，避免对一个服务的过量访问...可以通过如下参数配置来控制检查驱逐的逻辑 consecutiveErrors：实例被驱逐前的连续错误次数，默认是 5。

1.8K3 0

istio之流量治理篇

负载均衡概念：在微服务场景下，负载均衡一般和服务发现配合使用，每个服务都有多个对等的服务实例，需要有一种机制将请求的服务名解析到服务实例地址上。...1.在远程调用时，请求在超时前一直挂起，会导致请求链路上的级联故障和资源耗尽。...Istio中的具体实现： ? 备注：在触发了熔断之后，应用程序需要处理错误并有一定的fall back行为。例如当负载平衡池中的所有服务实例都出现异常时，Envoy将返回HTTP 503。...istio提供了两种配置，分别是连接池管理（ConnectionPoolSettings）和异常点检查（OutlierDetection） 1.在 Istio 中通过限制某个客户端对目标服务的连接数、...还会限制重试次数，避免重试次数过多导致系统压力变大并加剧故障的传播。 ? 连接池的设置： connectionpool可以对上游服务的并发连接数和请求数进行限制，适用于TCP和HTTP。 ?

1.4K2 0

Istio实战——流量管理

如果没有它，默认使用Envoy的轮循模型在每个服务的负载平衡池中分配流量，即轮流向每个池成员发送请求。这种分发方式，缺少一定灵活性，比如无法实现AB测试的百分比流量分发。...它定义了在路由发生后应用于服务的流量的策略。这些规则指定了负载平衡的配置、 sidecar 的连接池大小和异常检测设置，以检测并驱逐负载平衡池中不健康的主机。...支持配置负载均衡，基于哈希的一致性负载平衡，连接池，断路器，连接设置，tls证书设置负载均衡策略包括：随机，加权，最少请求。...# 网关错误指：HTTP的502、503或504，tcp的连接超时和连接错误/失败 maxEjectionPercent: 20 # 负载平衡池中可以弹出的上游服务的最大主机百分比。...默认情况下，Istio 配置使者代理来传送请求到未知服务。

1.7K2 0

服务网格istio落地之旅

由于k8s service对grpc长链接负载均衡的局限性：grpc如果和service ip建立长链接，实际只会和一个pod ip建立链接，之后的请求也只会请求到同一个pod（详细原理见：https:...后来转而基于k8s api server的服务发现中心，即客户端从api server获取每个pod端建立连接（grpc kuberesolver ：https://github.com/sercand...通过服务降级来终止潜在的关联性错误。安全。在服务网格上实现安全机制（如 TLS），并且很容易在基础设施层完成安全机制更新。多语言支持。...服务发现在使用了istio后，客户端再也不需要关心目标服务的实际IP的，只需要访问目标服务的k8s service地址，出口流量在到达sidecar后，自然地就会被拦截，并按照规则达到正确的目的ip。...我们使用一个单独的grpc kong网关暴露集群中的grpc接口，方便本地开发时连接远程服务。

6622 0

互联网之总体架构设计篇

Go/C++ Goole,IBM,Lyft 由于Istio是集大成这于一身，所以这里介绍一下Istio，更多详细的内容可以参考 Istio官方文档 Istio 总体架构 Istio服务网格逻辑上分为数据面板...] 数据面板Envoy 动态服务发现，负载均衡，TLS连接终止，HTTP/2 & gRPC代理熔断器，健康检查基于百分比流量灰度，故障注入和丰富指标 Envoy被部署为sidecar，和对应服务在同一个...功能包括：超时带超时预算有限重试以及重试之间的可变抖动并发连接数和上游服务请求数限制对负载均衡池的每个成员进行主动（定期）运行健康检查细粒度熔断器（被动健康检查），适用于负载均衡池中的每个实例...流量控制/错误注入错误配合的故障恢复策略（例如：跨服务调用的不兼容/限制性超时）可能导致应用程序中关键服务持续不可用，从而导致用户体验不佳可以注入两种类型的故障：延迟和中止延迟是计时故障，模拟增加的网络延迟或过载的上游服务...中止通常以HTTP错误代或TCP连接失败的形式表现千亿真实案例设计与实践这个章节从真实案例入手讲解架构的演进之路，给予同学们更多的思考。

1.9K3 1

Istio 可观测性之指标

因此，为了监控 Envoy 指标，需要了解网格服务和 Envoy 资源之间的连接。 Istio 允许运维人员在每个工作负载实例上选择生成和收集哪些 Envoy 指标。...对于 TCP 流量，Istio 生成以下指标： TCP 发送字节大小 (istio_tcp_sent_bytes_total)：这是一个 COUNTER 类型的指标，用于测量在 TCP 连接情况下响应期间发送的总字节数...TCP 接收字节大小 (istio_tcp_received_bytes_total)：这是一个 COUNTER 类型的指标，用于测量在 TCP 连接情况下请求期间接收到的总字节数。...（客户端模式） TCP_OPENED_CONNECTIONS 工作负载生命周期中打开的 TCP 连接计数器。...（客户端模式） TCP_CLOSED_CONNECTIONS 工作负载生命周期中关闭的 TCP 连接计数器。

5351 0

五千字长文详解Istio实践之熔断和限流工作原理

这样的快速失败策略可以降低服务负载压力，很好地保护服务免受高负载的影响。熔断器对比 Hystrix vs Istio ?...Istio是无缝衔接服务，istio可以在不更改应用程序代码的情况下配置和使用。Hystrix的使用需要更改每个服务来引入Hystrix libraries。...HTTP设置 http连接池设置用于http1.1/HTTP2/GRPC连接。...当访问不透明的TCP连接时，连接超时和连接错误/失败也会都视为错误。即将实例从负载均衡池中剔除，需要连续的错误（HTTP5XX或者TCP断开/超时）次数。默认是5。...minHealthPercent：在健康模式下，外部检测可以和负载均衡池一样，有最小健康百分比的阈值。

3.6K3 0

点击加载更多

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭