本文是为那些刚开始使用 Istio 速率限制功能，希望了解基于请求路径的速率限制如何工作的人而写的。它源于我的实践，并澄清了关于rate_limit操作中 AND/OR 操作的困惑。我花了比预期更多的时间来弄清楚我将在这里为你总结的内容，以便你在几分钟内学习。 基础知识 Istio 在 Envoy 之上运行，而我们将讨论的主要技术是 Envoy。Envoy 有在代理本身上实现的本地速率限制和在 L

Envoy 是一个用 C++ 开发的高性能代理，Envoy 是一种 L7 代理和通信总线，专为大型的现代面向服务的架构而设计。 核心能力 Envoy 的诞生源于以下理念： 网络对于应用程序来说应该是透明的，当网络和应用程序出现问题时，应该很容易确定问题的源头。 当然要实现上述目标是非常困难的。Envoy 试图通过提供以下高级功能来实现这一目标： 非侵入架构: Envoy 是一个独立的进程，设计为伴

前面我们和大家学习了 Envoy 的基础知识，使用静态配置来认识了 Envoy，但实际上 Envoy 的闪光点在于其动态配置，动态配置主要有基于文件和 API 两种方式。 基于文件的动态配置 Envoy 除了支持静态配置之外，还支持动态配置，而且动态配置也是 Envoy 重点关注的功能，本节我们将学习如何将 Envoy 静态配置转换为动态配置，从而允许 Envoy 自动更新。 Envoy 动态配置

Envoy作为容器sidecar被注入应用Pod内的主要流程如下：主要的组件就是Listener和Cluster，Listener负责监控Downstream发送的请求，最终由Cluster来选择Upstream中的某个节点来处理该请求。 Envoy会从控制面或者静态配置中获取路由的集群信息，保存在内存中，当请求从Downstream流向Upstream时，会通过Filter，根据路由和集群的配置

本篇文章主要介绍 XDS 如何在 Envoy 中使用. XDS 是一组用于配置管理的协议，特别是在云原生环境中，XDS 中的 "X" 代表不同的配置类型，例如 LDS（监听器配置）、RDS（路由配置）、CDS（集群配置）、EDS（端点配置）等。这些协议被广泛用于管理服务间的通信、负载均衡、流量控制等配置。 这些协议的设计是为了解决在现代微服务架构中的一些挑战，比如动态配置的需求、服务发现、负载均衡

Envoy 是一个开源边缘和服务代理，专为云原生应用程序而设计。基于对Nginx、HAProxy、硬件负载均衡器和云负载均衡器等解决方案的学习，Envoy 与每个应用程序一起运行，并通过以与平台无关的方式提供通用功能来抽象网络。 在 Ubuntu 20.04 LTS Focal Fossa 上安装 Envoy 代理 apt步骤 1. 首先，通过在终端中运行以下命令，确保所有系统包都是最新的。 su

5.请求首部条件路由 正常情况下从客户端请求的流量会发送到sidecar-proxy(eneoy)，请求发送到上游的pod，而后响应到envoy，并从envoy响应给客户端。 在这个过程中，客户端到envoy是不能够被修改的，只有从envoy到上游serrvice中才是可以被操作的，因为这段报文是由envoy发起的。而从serrvice响应到envoy的也是不能够被修改的。并且从envoy响应到客

Istio 为网格中的微服务提供了较为完善的安全加固功能，在不影响代码的前提下，可以从多个角度提供安全支撑，官方文档做了较为详细的介绍，但是也比较破碎，这里尝试做个简介兼索引，实现过程还是要根据官方文档进行。 Istio 的安全功能主要分为三个部分的实现： 双向 TLS 支持。 基于黑白名单的访问控制。 基于角色的访问控制。 JWT 认证支持。 首先回顾一下 Istio 网格中的服务通信过程： 利

正如我之前所说的，在如此短的时间内，Envoy 带来的兴奋既神奇又震撼人心。我经常问自己：envoy 的哪些方面导致了我们所看到的异常的社区增长？虽然 Envoy 具有很多引人注目的特征，但最终我认为有三个主要特征在共同推动： 性能：在具备大量特性的同时，Envoy 提供极高的吞吐量和低尾部延迟差异，而 CPU 和 RAM 消耗却相对较少。 可扩展性：Envoy 在 L4 和 L7 都提供了丰富的

Envoy Lyft 本文为翻译文章，点击查看原文。 关键要点 在过去的四年中，Lyft 已从单体架构转变为数百个微服务。随着微服务数量的增加，由于级联故障或意外内部拒绝服务导致的中断次数也在增加。 今天，这些故障情况在 Lyft 基础设施中已经基本解决。Lyft 部署的每项服务都通过使用 Envoy 代理自动获得吞吐量和并发保护。 Envoy 可以作为中间件部署或仅在请求入口处部署，但最大的好处

以往有很多文章讲解 Istio 是如何做 Sidecar 注入的，但是没有讲解注入之后 Sidecar 工作的细节。本文将带大家详细了解 Istio 是如何将 Envoy 作为 Sidecar 的方式注入到应用程序 Pod 中，及 Sidecar 是如何做劫持流量的。 在讲解 Istio 如何将 Envoy 代理注入到应用程序 Pod 中之前，我们需要先了解以下几个概念： Sidecar 模式：容

本文为翻译文章，点击查看原文。 Envoy 通过查询文件或管理服务器来动态发现资源。概括地讲，对应的发现服务及其相应的 API 被称作 xDS 。Envoy 通过订阅（ subscription ）方式来获取资源，如监控指定路径下的文件、启动 gRPC 流或轮询 REST-JSON URL。后两种方式会发送 DiscoveryRequest 请求消息，发现的对应资源则包含在响应消息 Discove

Cilium Kubernetes 本文为翻译文章，点击查看原文。 我们很高兴地宣布Cilium 1.3发布了。这个版本加入了几个新特性。主要的亮点是实现了Cassandra和带有策略执行能力的Memcached协议解析器，作为Envoy的Go语言扩展包。 和往常一样，整个Cilium社区的开发者贡献巨大，他们在1.2到1.3版本的这段时间贡献了785个提交。 什么是Envoy的Go语言扩展？ 从

本文为翻译文章，点击查看原文。 Envoy是专为Cloud Native应用设计的轻量级服务代理，也是为数不多的支持gRPC的代理之一。gRPC是一个基于HTTP/2的高性能RPC（远程过程调用）框架，支持多种语言。 Envoy 在这篇文章中，我们将使用gRPC和Protocol Buffers构建C++语言版本的Greeter应用，使用Go语言构建另一个gRPC应用，实现Envoy的RateLi

本文为翻译文章，点击查看原文。 如果你刚接触“Service Mesh“和“Envoy”，我这里有一篇文章可以帮你入门。 这是Envoy service mesh下的可观测性系列的第二篇文章，你可以在这里阅读第一篇关于分布式追踪的文章。 在微服务中谈及监控时，你可不能被蒙在鼓里，至少要知道问题出在哪儿了。 让我们看看Envoy是怎样帮助我们了解我们的服务运行状况的。在service mesh下，所

这是我在Envoy架构系列中的第3篇文章。这篇文章基于以前关于Envoy的线程模型和热重启功能的帖子。如果您还没有阅读这些帖子，请先阅读。 需要指出的是，随着预演的结束，我们现在可以进入更有趣的话题！ 统计概述 到目前为止，Envoy所做的最重要的事情是为分布式系统的可观测性提供了一个健壮的平台。这包括统计数据、日志记录和分布式跟踪。这篇文章将集中在统计数据和Envoy是如何实现允许高容量的同时保

如果你是初次接触服务网格和Envoy，我这里有一篇文章可以帮助你入门。 在微服务架构中，可观测性变得越加重要。我认为这是选择微服务这条路的必要条件之一。我的一位前同事列出了一份非常棒的需求清单，如果你想做微服务，那么你需要满足提到的这些要求。 可观测性有许多事要做： 监控 报警 日志集中化 分布式追踪 本文只讨论Envoy下的分布式追踪，我尽量给出一个全貌来描述分布式追踪、OpenTracing、

本文以 Istio 官方的 bookinfo 示例来讲解在进入 Pod 的流量被 iptables 转交给 Envoy sidecar 后，Envoy 是如何做路由转发的，详述了 Inbound 和 Outbound 处理过程。关于流量拦截的详细分析请参考理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持。 下面是 Istio 官方提供的 bookin

Envoy 是 Istio Service Mesh 中默认的 Sidecar，Istio 在 Enovy 的基础上按照 Envoy 的 xDS 协议扩展了其控制平面，在讲到 Envoy xDS 协议之前还需要我们先熟悉下 Envoy 的基本术语。下面列举了 Envoy 里的基本术语及其数据结构解析，关于 Envoy 的详细介绍请参考 Envoy 官方文档，至于 Envoy 在 Service M

本文为翻译文章，点击查看原文。 编者注：原文于 2017 年 7 月 30 日发布于 Envoy 博客上。 关于 Envoy 代码库的底层技术文档目前相当稀少。 为了纠正这个问题，我打算做一系列关于各种子系统的博客文章。 由于这是第一篇文章，请让我知道您的想法以及您希望了解的其他主题。 我经常看到的关于 Envoy 的最常见技术问题之一就是要求从底层描述 Envoy 使用的线程模型。这篇文章将介绍