Web Middleware

envoy内建了一个管理接口，它支持查询和修改操作，甚至有可能暴露私有数据（例如统计数据、集群名称和证书信息等）因此非常有必要精心编排期访问控制机制，以避免非授权访问。 administration interface 属于 bootstrap 配置文件中的==顶级配置字段==使用。 administration interface offical document yaml 1 2 3 4 5 6 7 8 admin: access_log_path: .. # 管理接口的访问日志文件路径，无须记录访问日志使用/dev/null profile_path: ... # cpu_profile的输出路径，默认为/var/log/envoy/envoy.prof; address: socket_address: # 监听的套接字 protocol: .. address: ... prot_value: ... 下面是一个简单的配置示例 yaml 1 2 3 4 admin: access_log_path: /tmp/admin_access.log address: socket_address: { address: 127.0.0.1, port_value: 9901 } admin接口内置了多个 /path ，不同的path可能会分别接受不同的GET或POST请求 GET /help ：打印所有可用选项； / : Admin home page /certs : GET 列出在的所有TLS相关的信息； /clusters : upstream cluster status GET，格外支持使用 /clusters?...

服务网格的基本功能 控制服务间通信：熔断、重试、超时、故障注入、负载均衡和故障转移等。 服务发现：通过专用的服务总监发现服务端点。 可观测：指标数据采集、监控、分布式日志记录和分布式追踪。 安全性：TLS/SSL通信和秘钥管理。 身份认证和授权检查：身份认证，以及基于黑白名单或RBAC的访问控制功能。 部署：对容器技术的原生支持，例如Docker和Kubernetes等。 服务间的通信协议：HTTP1.1 HTTP2.0和gRPC等。 健康状态监测：监测上游服务的健康状态。 …. 服务网格的部署模式有两种：主机共享代理和Sidecar容器 主机共享代理 适用于同一主机存在许多容器的场景，并且还可以利用连接池来提高吞吐量。 带一个代理进程故障将终止其所在主机上的整个容器队列，受影响的不仅仅是单个服务。 实现方式中，常见的是允许为Kubernetes之上的 DaemonSet。 Sidecar容器 代理进程注入每个Pod定义以与住容器一同运行。 Sidecar进程应该尽可能轻量且功能完善。 实现方案：Linkerd、Envoy和Conduit。 What IS Enovy Enovy是工作与OSI模型的7层代理 在实现上，数据平面的主流解决方案有Linkerd、Nginx、Envoy、HAProxy和Traefik等，而控制平面的实现主要有Istio、Nelson和SmartStack等几种口Linkerd ●由Buoyant公司于2016年率先创建的开源高性能网络代理程序（数据平面），是业界第一款Service Mesh产品，引领并促进了相关技术的快速发展 ·Linkerd使用Namerd提供控制平面，实现中心化管理和存储路由规则、服务发现配置、支持运行时动态路由等功能 Envoy 核心功能在于数据平面，于2016年由Lyft公司创建并开源，目标是成为通用的数据平面 云原生应用，既可用作前端代理，亦可实现Service Mesh中的服务间通信 Envoy常被用于实现APIGateway（如Ambassador）以及Kubernetes的Ingress Controller（例如gloo等），不过，基于Envoy实现的Service Mesh产品Istio有着更广泛的用户基础 Istio ·相比前两者来说，lstio发布时间稍晚，它于2017年5月方才面世，但却是目前最火热的Service Mesh解决方案，得到了Google、IBM、Lyt及Redhat等公司的大力推广及支持 ·目前仅支持部署在Kubernetes之上，其数据平而由Envoy实现 envoy适用于现代大型面向服务架构的动态组织应用程序的7层代理应用程序，其典型特性： 运行在架构进程之外 支持3/4层过滤器 支持HTTP协议7层过滤器 支持HTTP协议7层高级路由功能 envoy在现代服务体系架构当中的适用位置既可以为一组服务提供代理，作为整个服务统一的api网关来进行接入，同时也可以对每一个微服务单独实现作为代理，此时需要以sidecar的形式运行在应用程序前端。进而与最前端的apigateway组织成所谓的服务网格（Sevice Mesh）。而在每一个Envoy实例内部都要接受请求。这个请求可能是来自互联网或服务网格之外的客户端，称之为南北流量；也可能是来自网格当中的其他服务的请求，称之为东西流量。 在Envoy当中类似于Nginx或者haproxy的功能术语： listeners ：面向客户端一侧提供监听并接受客户端请求的组件。类似于nginx的server或haproxy的frontend 。 cluster：面向后端测，将多个被代理的实例分成组，统一进行负载均衡调度的组。 cluster definltions：cluster的归类。 filter chains：过滤器链，可以将多个链以流水线方式依次进行处理。 面向客户端提供服务/监听的套接字，lintener内部包含一到多个filter组成filter chains，称之为过滤器链。过滤器是lintener内部的子组件。envoy支持4层过滤器和7层过滤器。 envoy 术语 主机（Host）：能够进行网络通信的实体（如手机，服务器等上的应用程序）。在这个文档中，主机是一个逻辑网络应用程序。一个物理硬件可能有多个主机上运行，只要他们可以独立寻址。 下游（Downstream）：下游主机连接到Envoy，发送请求并接收响应。 上游（Upstream）：上游主机接收来自Envoy的连接和请求并返回响应。 监听器（Listener）：侦听器是可以被下游客户端连接的命名网络位置（例如，端口，unix域套接字等）。Envoy公开一个或多个下游主机连接的侦听器。 filters chains，过滤器链L4/L7 route：完成对客户请求进行分类 群集（Cluster）：群集是指Envoy连接到的一组逻辑上相似的上游主机。Envoy通过服务发现发现一个集群的成员。它可以通过主动健康检查来确定集群成员的健康度，从而Envoy通过负载均衡策略将请求路由到相应的集群成员。 网格（Mesh）：协调一致以提供一致的网络拓扑的一组主机。在本文档中，“Envoy mesh”是一组Envoy代理，它们构成了由多种不同服务和应用程序平台组成的分布式系统的消息传递基础。...

官方文档 healthy_check Envoy的服务发现并未采用完全一致的机制，而是假设主机以最终一致的方式加入或离开网格，它结合主动健康状态检查机制来判定集群的健康状态； 健康与否的决策机制以完全分布式的方式进行，因此可以很好地应对网络分区； 为集群启用主机健康状态检查机制后，Envoy基于如下方式判定是否路由请求到一个主机； 发现失败，单健康检查正常，此时，无法添加新主机，但现有主机将继续正常运行。 Discovery Status Health Check OK Health Check Failed Discovered Route Dont’t Route Absent Route Don’t Route / Delete 故障处理机制 Envoy提供了一系列开箱即用的故障处理机制： 超时（timeout） 有限次数的重试，并支持可变的重试延迟 主动健康检查与异常探测 连接池 断路器 所有这些特性，都可以在运行时动态配置；结合流量管理机制，用户可为每个服务/版本定制所需的故障恢复机制； 健康状态监测 健康状态检测用于确保代理服务器不会将下游客户端的请求代理至工作异常的上游主机； Envoy支持两种类型的健康状态检测，二者均基于集群进行定义： 主动检测（Active Health Checking）：Envoy周期性地发送探测报文至上游主机，并根据其响应判断其健康状态；Envoy目前支持三种类型的主动检测： HTTP：向上游主机发送HTTP请求报文 L3/L4：向上游主机发送L3/L4请求报文，基于响应的结果判定其健康状态，或仅通过连接状态进行判定； Redis：向上游的redis服务器发送Redis PING； 被动检测（Passive Health Checking）：Envoy通过异常检测（Outlier Detection）机制进行被动模式的健康状态检测； 目前，仅htp router、tcp proxy和redis proxy三个过滤器支持异常值检测； Envoy支持以下类型的异常检测： 连续5XX：意指所有类型的错误，非htp router过滤器生成的错误也会在内部映射为5xx错误代码； 连续网关故障：连续5XX的子集，单纯用于http的502、503或504错误，即网关故障； 连续的本地原因故障：Envoy无法连接到上游主机或与上游主机的通信被反复中断； 成功率：主机的聚合成功率数据阀值； 主动健康状态监测 集群的主机健康状态检测机制需要显式定义，否则，发现的所有上游主机即被视为可用； 定义语法 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 clusters: - name: ....

灰度发布 概述 新版本上线时，无论是出于产品稳定性还是用户接受程度等方面因素的考虑，直接以新代旧都充满风险；于是，通行做法是新老版本同时在线，且一开始仅分出较小比例的流量至新版本，待确认新版本没问题后再逐级加大流量切换。 灰度发布是迭代的软件产品在生产环境安全上线的一种重要手段，对于Envoy来说，灰度发布仅是流量治理的一种典型应用；以下是几种常见的场景口金丝雀发布 - 蓝绿发布 - A/B测试 - 流量镜像 灰度策略 需要在生产环境发布一个新的待上线版本时，需要事先添加一个灰度版本，而后将原有的生产环境的默认版本的流量引流一部分至此灰度版本，配置的引流机制即为灰度策略，经过评估稳定后，即可配置此灰度版本接管所有流量，并下线老版本。 常用的策略类型大体可分为 “基于请求内容发布”和“基于流量比例发布”两种类型 基于请求内容发布：配置相应的请求内容规则，满足相应规则服务流量会路由到灰度版本；例如对于http请求，通过匹配特定的Cookie标头值完成引流 Cookie内容： 完全匹配：当且仅当表达式完全符合此情况时，流量才会走到这个版本； 正则匹配：此处需要您使用正则表达式来匹配相应的规则； 自定义Header： 完全匹配：当且仅当表达式完全符合此情况时，流量才会走到这个版本； 正则匹配：此处需要您使用正则表达式来匹配相应的规则；可以自定义请求头的key和value，value支持完全匹配和正则匹配； 基于流量比例发布：对灰度版本配置期望的流量权重，将服务流量以指定权重比例引流到灰度版本；例如10%的流量分配为新版本，90%的流量保持在老版本。这种灰度策略也可以称为AB测试； 注：所有版本的权重之和为100； 灰度发布的实现方式 基于负载均衡器进行灰度发布 在服务入口的支持流量策略的负载均衡器上配置流量分布机制 仅支持对入口服务进行灰度，无法支撑后端服务需求 基于Kubernetes进行灰度发布 根据新旧版本应用所在的Pod数量比例进行流量分配，不断滚动更新旧版本Pod到新版本（先增后减、先减后增、又增又减）；服务入口通常是Service或Ingress。 基于服务网格进行灰度发布 对于Envoy或lstio来说，灰度发布仅是流量治理机制的一种典型应用。通过控制平面，将流量配置策略分发至对目标服务的请求发起方的envoy sidecar上即可。 支持基于请求内容的流量分配机制，例如浏览器类型、cookie等。 服务访问入口通常是一个单独部署的Envoy Gateway。 Envoy中流量转移 新版本上线时，为兼顾到产品的稳定性及用户的接受程度，让新老版本同时在线，将流量按需要分派至不同的版本； 蓝绿发布 A/B测试 金丝雀发布 流量镜像 …. HTTP路由器能够将流量按比例分成两个或多个上游集群中虚拟主机中的路由，从而产生两种常见用例： 版本升级：路由时将流量逐渐从一个集群迁移至另一个集群，实现灰度发布； 通过在路由中定义路由相关流量的百分比进行； A/B测试或多变量测试：同时测试多个相同的服务，路由的流量必须在相同服务的不同版本的集群之间分配；通过在路由中使用基于权重的集群路由完成；另外，匹配条件中，结合指定标头或也能够完成基于内容的流量管理； 流量迁移是指，通过在路由中配置运行时对象选择特定路由以及相应集群的概率的变动，从而实现将虚拟主机中特定路由的流量逐渐从一个集群迁移到另一个集群。 runtime_fraction yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 route: - match: prefix|path|regex: runtime_faction: # 额外匹配指定的运行时键值，每次评估匹配路径时，必须低于此字段指示的百分比，支持渐进式修改。 default_value: # 运行时键值不可用时，则使用此默认值。 numerator: # 指定分子，默认0 denominator: # 指定分母，小于分母时，最终百分比为1， 分母可使用 HUNDRED（默认） TEN_THOUSAND和MILLION， runtime_key: routing....

HTTP 链接管理 envoy处理用户请求逻辑 ① 用户请求报文到达七层过滤器链处理机制后，首先根据请求HTTP报文中的 Host 首部来完成虚拟主机的选择；② 由此虚拟机主机内部的 Route 表项进行处理。③ 后由 match 进行匹配; Match 是与请求URL的 PATH 组成部分或请求报文的标头部分 header 。④ 最后才可到达 Route 进行 direct_response 、redirect 等。 官方手册 Envoy通过内置的L4过滤器HTTP连接管理器将原始字节转换为HTTP应用层协议级别的消息和事件，例如接收到的标头和主体等，以及处理所有HTTP连接和请求共有的功能，包括访问日志、生成和跟踪请求ID，请求/响应头处理、路由表管理和统计信息等； 支持HTTP/1.1、WebSockets和HTTP/2，但不支持SPDY; 关联的路由表可静态配置，亦可经由 xDS API 中的 RDS 动态生成； 内建重试插件，可用于配置重试行为; Host Predicates Priority Predicates 内建支持302重定向，它可以捕获302重定向响应，合成新请求后将其发送到新的路由匹配（match）所指定的上游端点，并将收到的响应作为对原始请求的响应返回客户端 支持适用于HTTP连接及其组成流（constituent streams）的多种可配置超时机制 连接级别：空闲超时和排空超时（GOAWAY）； 流级别：空闲超时、每路由相关的上游端点超时和每路由相关的 gRPC 最大超时时长； 基于自定义集群的动态转发代理； HTTP协议相关的功能通过各HTTP过滤器实现，这些过滤器大体可分为编码器、解码器和编/解码器三类； router envoy.router 是最常的过滤器之一，它基于路由表完成请求的转发或重定向，以及处理重试操作和生成统计信息等； HTTP 路由 Envoy基于HTTP router过滤器基于路由表完成多种高级路由机制，例如: 将域名映射到虚拟主机； path的前级 prefix 匹配、精确匹配或正则表达式匹配； 虚拟主机级别的TLS重定向； path级别的 path/host 重定向； direct_response ，由Envoy直接生成响应报文 ； 显式 host rewrite； prefix rewrite； 基于HTTP标头或路由配置的请求重试与请求超时； 基于运行时参数的流量迁移； 基于权重或百分比的跨集群流量分割； 基于任意标头匹配路由规则； 基于优先级的路由； 基于hash策略的路由； 路由配置和虚拟主机 路由配置中的顶级元素是虚拟主机...