Envoy 是什么，和 Nginx 对比

最新推荐文章于 2025-03-19 23:04:43 发布
最新推荐文章于 2025-03-19 23:04:43 发布
阅读量6.5k 收藏 1
点赞数
分类专栏： 互联网技术架构 服务器 文章标签： Envoy Nginx Istio
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_39384184/article/details/121406834
版权

什么是 Nginx，Nginx 实践以及与 Tomcat，Apache 的比较

什么是 Envoy

Envoy 是一款 CNCF 旗下的开源项目，由 Lyft 开源。Envoy 采用 C++ 实现，是面向 Service Mesh 的高性能网络代理服务。它与应用程序并行运行，通过以平台无关的方式提供通用功能来抽象网络。当基础架构中的所有服务流量都通过 Envoy 网格时，通过一致的可观测性，很容易地查看问题区域，调整整体性能。

Envoy 也是 Istio Service Mesh 中默认的 Data Plane，本文我们将讲解 Envoy 的一些基本概念，并采用一些实例来介绍如何在本地环境中快速使用 Envoy 作为 Service Mesh 的数据平面，以帮助读者理解 Istio 的 Data Panel 层实现。

Envoy 和 Nginx 对比

Nginx的关键词是Web服务器和反向代理，Envoy是透明接管流量，更加体现对流量的控制和掌控力。另外，从使用方式上看，微服务对Nginx是显式调用，通过Nginx完成负载均衡等相关功能，对Envoy是隐式调用，业务微服务不需要感知Envoy的存在，和使用Envoy使用相同的方式进行通信，只不过不再需要关注通信和链路治理的细节。
详细对比

2选1：Istio vs Nginx，微服务流量管理哪家强？
java专栏
12-20 1034
首先，我们需要了解一下Istio和Nginx的基本概念。Istio：一个开源的服务网格平台，提供了丰富的流量管理、安全性和可观测性功能。它通过sidecar代理（如Envoy）来拦截和控制服务之间的通信。Nginx：著名的反向代理服务器和负载均衡器，广泛应用于Web应用的前端层。它可以作为独立的流量控制器，也可以与其他组件结合使用。
后端开发中Ribbon与Nginx的性能对比
最新发布
后端开发笔记博客记录
04-26 591
随着互联网业务的不断发展，后端系统面临着越来越高的并发请求压力。负载均衡技术作为解决这一问题的重要手段，能够将请求均匀地分配到多个服务器上，从而提高系统的整体性能和可用性。Ribbon和Nginx是目前后端开发中广泛使用的两种负载均衡工具，它们各自具有独特的特点和适用场景。本文的目的是对Ribbon和Nginx的性能进行详细对比，分析它们在不同场景下的优势和劣势，为开发者在选择负载均衡方案时提供决策依据。
K8s 网关选型初判：Nginx 还是 Envoy？
阿里云云栖号
06-09 1223
本文将从性能和成本、可靠性、安全性 3 方面，对两大开源实现进行比对，希望对正在做 K8s 网关选型的企业有所借鉴。
微服务架构的API网关实践：NGINX与Envoy比较
AI天才研究院
12-26 935
1.背景介绍 微服务架构的API网关是一种在微服务系统中提供统一访问点、安全控制、流量管理、负载均衡等功能的组件。在微服务系统中，服务数量众多，服务之间的交互频繁，API网关作为中心化的管理平台，可以为开发者提供统一的接口，降低服务之间的耦合度，提高系统的可扩展性和可维护性。 在微服务架构中，API网关的选型非常重要。NGINX和Envoy是两款流行的API网关实现，它们各自具有不同的优势和局...
envoy 源码分析
xiyanxiyan10的专栏
03-19 846
服务网格 生态中 envoy源码分析
使用Envoy代替Nginx作为反向代理服务
aurawing的专栏
08-18 1221
Envoy是一款开源的高性能、可扩展的服务代理，本文对Envoy和Nginx进行对比，并介绍了Envoy的部署和配置方式
envoy proxy nginx haproxy等比较
jklfjsdj79hiofo的专栏
06-29 4491
与类似系统的比较总体而言，我们相信Envoy为现代服务导向架构提供了独特且引人注目的功能集。下面我们将Envoy与其他相关系统进行比较。尽管在任何特定领域（边缘代理，软件负载平衡器，服务消息传递层），Envoy可能不像下面的某些解决方案那样具有丰富的功能，但总体而言，没有其他解决方案将相同的整体功能集提供给单个自包含的高性能套餐。注：以下大部分项目正在积极开发中。因此，某些信息可能会过时。如果是这...
浅谈Service Mesh体系中的Envoy
weixin_34122548的博客
07-05 2405
背景 最近因工作原因开始了解Service Mesh与Envoy，为系统性梳理所学内容，因此沉淀了此文档，但由于所知有限，如文档中有描述不当之处，希望不吝赐教。 提到Envoy就不得不提Service Mesh，说到Service Mesh就一定要谈及微服务了，那么我们就先放下Envoy，简单了解下微服务、Service Mesh以及Envoy在Serv...
Nginx、LVS、Keepalived的关系
weixin_45654405的博客
08-23 2588
LVS不也有负载均衡问题吗？无论设计多少层负载均衡，多少层网关，所有流量总还是会通过一个地方的，怎么扛得住呢？ 确实是这样的，但是服务器和服务器之间并不是完全相同点，从LVS到Nginx到Tomcat，他们的功能以此增加，吞吐量也依次减少。几台Tomcat扛不住的流量可能一台Nginx就能扛住，几台Nginx扛不住的流量可一台LVS就能扛住。那LVS扛不住呢？总不能让所有流量都往一个地方走吧，所以可以考虑类似CDN的手段，每个地区就近解决就好了。
Envoy VS Traefik
weixin_51735396的博客
11-06 1845
云原生场景，产生了很多的Edge Router，Load balance，API Gate Way，Proxy等组件。 最近研究了一下，分享几个喜欢的项目，它们大致分为两类： Gateway为主：Kong，Krakend Proxy为主：Envoy，Traefik 但两类没有实际功能的边界，Proxy为主，一般要支持在L4，Gateway为主，支持在L7即可。 Proxy主要位置是中间，可以做sidecar，Gateway在服务endpoint前面。 再比如传统的HAProxy就是Proxy，Nginx
envoy实现_网络通信与治理，谁更在行？Envoy 和 Nginx 对比 | 本月送书活动来啦
weixin_39600291的博客
12-08 791
Nginx 是 Envoy 出现之前网络通信中间件领域非常有代表性的开源系统，功能强大，性能出色，扩展性很强，已经形成了强大的生态，成为 HTTP 流量管理领域事实上的标杆。Envoy 作为后起之秀，虽然定位和目标上与 Nginx 有不少差异，但架构设计层面， Envoy 和 Nginx 都有很多的可取之处。下面会从功能定位、整体网络模型、连接处理、请求解析、插件机制等维度，对 Envo...
Envoy 【2】从 NGINX 迁移到 Envoy 代理
爱死亡机器人
11-15 2770
文章目录1. 简介2. NGINX 示例3. envy与nginx 配置对比3.1 Worker Connections3.2 HTTP Configuration3.3 Server Configuration3.4 Envoy Listeners3.5 Location Configuration3.6 Envoy Filters3.7 Proxy and Upstream Configuration3.8 Envoy Clusters3.9 Logging Access and Errors4. 启动
在Kubernetes上对Envoy代理，HAProxy和NGINX性能进行基准测试
NewTyun的博客
03-05 1617
在典型的Kubernetes部署中，所有到Kubernetes服务的流量都流经ingress代理——从Internet到后端服务的流量。这样，ingress就在您提高性能的关键路径上。有...
他们将生产环境从nginx迁移到envoy，原因竟然是……
weixin_45583158的博客
06-29 1619
导读：随着Service Mesh在最近一年进入人们的视野，Envoy 作为其中很关键的组件，也开始被广大技术人员熟悉。本文作者所在公司已经从 nginx 迁移到 Env...
Envoy为什么能战胜Ngnix——线程模型分析篇
weixin_45583158的博客
08-03 1134
导读：随着Service Mesh在最近一年的流行，Envoy 作为其中很关键的组件，也开始被广大技术人员熟悉。作者是Envoy的开发者之一，本文详细说明了Envoy的线...
Envoy
JosephThatwho的博客
03-18 686
Envoy用C++开发的网络7层代理，被设计用于在大型的、服务导向的架构中做通信总线。 既可以作为应用整体的API Gateway也可以作为每个为微服务的sidecar，组成服务网格。 南北流量：来自应用外部的流量 东西流量：服务内部的流量 listeners / 侦听器：类似与nginx中的server类似，面向客户端提供服务，用于接受客户端、前端的请求。 cluster：类似与nginx中的upstream servers，用于归类上游服务组。 filter：过滤器，listener内部的子组件，支持
istio通过envoyFilter实现nginx的error_page
ledrsnet的博客
11-04 1015
注意：匹配的pod必须得开启istio sidecar注入，不然不生效，之前一直没查出问题只能选择上面的配置在istio-system空间里面了。需求：实现nginx的error_page，istio本身不支持，只能通过envoyfilter来实现。当收到后端返回503时候，并且响应header中action为redirect时重定向跳转到首页。ps: virtualSerivce支持自定义添加header参数。
Envoy 代替nginx https://www.jianshu.com/p/0a1f67b42fdb
weixin_34253539的博客
03-11 770
官方文档:https://www.envoyproxy.io/docs1.6.0版官方文档:https://www.envoyproxy.io/docs/envoy/v1.6.0/ 一、 编译和安装 1、 编译 Envoy使用Bazel工具 构建系统。为了简化初次构建以及快速入门，我们提供了一个基于Ubuntu16的Docker容器镜像，其中包含了构建静态链接Envo...
比较好的网关工具有什么 java
03-26
<think>嗯，用户问的是比较好的Java网关工具有哪些。首先，我需要回顾一下之前对话中提到的相关组件，比如在分布式组件里提到了Zuul作为Spring Cloud的一部分，还有可能提到的其他网关工具。用户可能是在构建微服务架构，需要选择合适的网关来处理路由、负载均衡、安全等问题。 首先，我应该考虑用户的使用场景。网关工具通常用于微服务架构中，作为所有请求的入口，负责路由、过滤、认证、限流等。所以需要列举常见的Java网关工具，并说明它们的特点和适用场景。 接下来，用户可能对开源和商业工具有不同的需求，但根据问题中的“Java”限定，可能更倾向于基于Java开发的或者与Java生态兼容较好的工具。需要确认每个工具的技术栈和是否适合Java项目。 然后，需要回忆之前提到的组件，比如Spring Cloud Gateway是Spring Cloud生态的一部分，替代了Zuul，应该重点介绍。还有Apache的ShenYu，之前可能没有提到过，但也是常用的。此外，Kong和Nginx虽然不是Java写的，但常与Java系统集成，可能需要提到，但需要区分开是否属于Java网关工具。 还要考虑用户可能的深层需求，比如是否需要云原生支持，是否需要高性能，或者是否需要丰富的插件生态。例如，Spring Cloud Gateway适合Spring Cloud用户，ShenYu有强大的插件支持，而Kong和Nginx在性能和扩展性上表现优异，虽然它们不是Java实现，但常与Java后端一起使用。 需要确保回答的结构清晰，分点列出每个工具，说明核心特性、适用场景和架构组成。可能还需要给出选型建议，帮助用户根据具体需求选择合适的工具。同时，注意之前的回答中使用了数学公式，但这里可能不需要，除非有特别的技术指标需要用公式表达，比如QPS计算，但网关工具更多是功能性的，可能不太需要公式。 另外，要检查是否有遗漏的工具，比如是否有其他流行的Java网关，如Zuul 2，虽然它已经被Spring Cloud Gateway取代，但可能仍有人使用。或者是否还有其他新兴的工具需要补充。确保信息的准确性和时效性，比如Spring Cloud Gateway的版本特性，是否支持响应式编程等。 最后，整理回答的结构，先分点介绍每个工具，再给出选型建议，可能还需要比较它们的优缺点，帮助用户做出决策。同时，注意使用中文，保持口语化，但作为思考过程，不需要太正式。</think>以下是一些主流的Java网关工具及其核心特性，按技术栈和适用场景分类说明： --- ### 一、**Spring Cloud Gateway** (云原生网关) $$Gateway = Route + Filter + Predicate$$ - **核心特性** - 基于Spring 5 + WebFlux响应式编程 - 动态路由配置：支持Path、Header、Cookie等匹配规则 - 集成Hystrix熔断：$QPS_{max} = \frac{Threads \times TPS}{Latency}$ - 支持JWT/OAuth2安全认证 - **架构组成** ``` Client → Gateway → LoadBalancerClient → Microservices ↑ RouteLocator (动态更新) ``` - **适用场景**：Spring Cloud微服务体系的API网关 --- ### 二、**Apache ShenYu** (高性能网关) $$Throughput = Async \times Plugin \times Divide$$ - **核心优势** - 支持HTTP/WebSocket/gRPC协议代理 - 插件化架构：内置鉴权/限流/监控等50+插件 - 流量染色：通过`Header: X-Shenyu-Tag`实现灰度发布 - 性能指标：单机QPS可达5万+（基于Netty异步模型） - **数据分片**： ``` Request → ShenYu Admin (配置中心) ↓ ShenYu Gateway集群 → 后端服务集群 ``` - **典型用例**：高并发场景下的全协议网关 --- ### 三、**Zuul 2** (Netflix开源网关) $$FilterChain = Pre → Routing → Post$$ - **关键改进**： - 异步非阻塞架构（Zuul 1为同步阻塞） - 动态过滤器加载：Groovy脚本热更新 - 精细化监控：支持请求/响应字节级追踪 - **局限**： - 社区活跃度下降（Netflix已逐步转向Spring Cloud Gateway） - 配置复杂度较高 --- ### 四、**Kong** (Nginx-based API网关) - **Java生态适配方案**： - 通过**Kong Java PDK**开发自定义插件 - 支持与Spring Boot集成： ```yaml kong: routes: - name: user-service paths: [/api/users/**] service: http://user-service:8080 ``` - **核心能力**： - 流量控制：$RateLimit = \frac{Requests}{Second}$ - 身份验证：Key Auth/JWT/OAuth2.0 - 服务网格集成：支持Kubernetes Ingress --- ### 五、**Nginx + OpenResty** (高性能方案) - **Java扩展方式**： - 使用**LuaJIT**调用Java代码（需通过FFI接口） - 典型案例： ```lua local http = require("resty.http") local httpc = http.new() res, err = httpc:request_uri("http://java-service", { method = "POST", body = "Lua调用Java服务" }) ``` - **优势场景**： - 静态内容缓存：$HitRate = \frac{Cache_{hit}}{Total_{req}}$ - 四层负载均衡：TCP/UDP代理 --- ### 六、**Envoy** (云原生代理) - **Java集成模式**： - 通过**xDS API**动态配置路由规则 - 与Java服务网格（如Istio）协同工作： ``` Envoy Sidecar → Java服务容器 (通过Unix Domain Socket通信) ``` - **核心特性**： - 熔断机制：基于异常率 $ErrorRate \geq threshold$ - 分布式追踪：兼容Jaeger/Zipkin --- ### **选型对比矩阵** | 工具 | 吞吐量 | 延迟 | 学习曲线 | 微服务集成度 | |---------------------|-------------|--------|---------|-------------| | Spring Cloud Gateway| 3万 QPS | <50ms | 低 | ★★★★★ | | ShenYu | 5万+ QPS | <30ms | 中 | ★★★★ | | Kong | 7万 QPS | <20ms | 高 | ★★★ | | Envoy | 10万+ QPS | <10ms | 高 | ★★ | --- ### **选型建议** 1. **Spring技术栈优先** → 选Spring Cloud Gateway 2. **超高并发需求** → ShenYu/Kong 3. **服务网格架构** → Envoy + Istio 4. **传统运维体系** → Nginx集群 + Keepalived 实际选择需结合团队技术栈和 $SLA = Availability \times Performance$ 要求综合评估。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值