服务网格-Envoy学习笔记:Envoy架构总览(1)

#术语
在我们深入了解架构文档之前,我们需要了解一些术语。有些定义在行业内部可能有争议,不过在Envoy的文档和代码中就是这么定义的,所以c’est la vie(这就是生活)。

**主机(Host)**:能够进行网络通信的实体 (手机、服务器等上的应用程序)。在本文档中,主机是一个逻辑网络应用程序。一个物理硬件可能有多个主机在上面运行,只要每个主机都可以独立寻址。

**下游(Downstream)**:一个下游主机连接Envoy,向Envoy发送请求,并收到响应。

**上游(Upstream)**:一个上游主机收到来自Envoy的连接和请求,并给出响应给Envoy。

**监听器(Listener)**:一个监听器是可由下游客户端连接的命名网络位置 (例如,端口、unix 域套接字等)。Envoy可以同时开放一个或多个供下游主机连接的监听器。

**集群(Cluster)**:群集是Envoy连接的逻辑上相似的上游主机组。Envoy通过服务发现发现集群的成员。它可以选择通过健康检查来确定群集成员的运行状况。Envoy根据负载平衡策略将请求路由到确定的群集成员。

**网格(Mesh)**:一组互相协调以提供一致的网络拓扑的主机。在本文档中, “Envoy 网格” 是一组Envoy 代理, 它为由许多不同服务和应用程序平台组成的分布式系统提供消息传递网络。

**运行时配置(Runtime configuration):与 Envoy 一起部署的额外的实时配置系统。可以更改配置设置影响操作,而无需重新启动 Envoy 或更改主配置。

#线程模型
Envoy 使用具有多个线程体系结构的单个进程。单个主线程控制各种零星的协调任务,而一些工作线程执行监听、筛选和转发。一旦监听器接受了连接,连接就会将其生存期的剩余时间绑定到单个工作线程。这使得 Envoy 拥有大量的工作线程(令人尴尬的并行),在工作线程之间进行少量更复杂的代码协调处理。通常 Envoy 是100% 非阻塞的,对于大多数工作负载,我们建议将工作线程的数量配置为计算机上的硬件线程数。

服务网格-Envoy学习笔记:什么是Envoy

随着服务网格的概念爆火,Istio+Envoy的组合受到了热捧。于是开始着手研究Envoy,并在此记入笔记。
本文我在简书上也发表过(https://www.jianshu.com/u/6421d3fed5e4)。

#什么是Envoy
Envoy 是一个基于七层的代理和通讯总线,专为大型面向服务的体系结构而设计。该项目的诞生主要出于如下的想法:
>网络对应用程序应该是透明的。当网络和应用程序确实出现问题时,应该很容易确定问题的根源。

实际上,实现前面的想法是极其困难的。Envoy试图通过提供以下高级别特征来做到这一点:
**独立于进程的架构** :Envoy是一个独立的进程,旨在与每个应用程序服务器一起运行。所有Envoy组成了一个透明的通信网格,其中每个应用程序发送和接收来自本地主机的消息,并且不用知道网络拓扑。与传统的服务通信服务的库方法相比,进程外架构有两个实质性好处:
– Envoy支持任何编程语言写的服务。只用部署一个Envoy就可以在Java、C++、Go、PHP、Python等服务间形成网格。面向服务的体系结构使用多个应用程序框架和语言的情况越来越普遍。Envoy以透明的方式弥合了这些差距。
– 任何使用过大型面向服务的体系结构的人都知道,部署库升级可能会非常痛苦。Envoy可以在整个基础设施中迅速部署和升级。

**基于最新的C++11开发**:Envoy是基于C++11编写的。选择本机代码是因为我们认为像Envoy这样的体系结构组件应该尽可能给应用程序让路。现代应用程序开发人员习惯于在共享云环境中的部署,以及使用非常高效但性能不是特别好的语言 (如 PHP、Python、Ruby、Scala 等), 在这种环境下,找到尾延迟的原因变得非常的困难。本机代码通常提供出色的延迟属性,不会给已经令人困惑的情况增加额外的混乱。与用 C 编写的其他本机代码代理解决方案不同,C++11 提供了出色的开发人员工作效率和性能。

**基于 L3/L4 网络Filter的架构**:Envoy的核心使用的是基于 L3/L4 的网络代理。可插拔的Filter链机制允许编写Filter以执行不同的 tcp 代理任务并插入主服务器。当然Envoy也提供现成的Filter以支持各种任务,如原始 TCP代理、HTTP 代理、TLS客户端证书身份验证等。

**基于 L7 网络的HTTP Filter架构**:HTTP是现代应用程序体系结构的重要组成部分,Envoy支持额外的 HTTP L7 Filter层。HTTP Filter可以插入到 HTTP 连接管理子系统中,该子系统支持执行不同的任务,如缓冲、速率限制、路由、嗅探亚马逊的 Dynamodb 等。

**对HTTP/2 的极佳支持**:在 HTTP 模式下运行时,Envoy同时支持 HTTP/1.1 和 HTTP/2。Envoy可以做到让 HTTP/1.1 和 HTTP/2 之间的通讯保持透明。这意味着对于任意的 HTTP/1.1 和 HTTP/2 的客户端和目标服务器的组合,Envoy都可以将他们桥接起来。当然建议在配置Envoy服务时使用 HTTP/2 在所有组件之间创建一个长链的网格,这样请求和响应可以多路复用。Envoy 不支持 SPDY,因为这个协议正在逐渐被淘汰。
>SPDY(读作“SPeeDY”)是 Google 开发的基于 TCP 的应用层协议,用以最小化网络延迟,提升网络速度,优化用户的网络使用体验。互联网工程任务组(IETF)对谷歌提出的 SPDY 协议进行了标准化,于2015年5推出了类似于 SPDY 协议的 HTTP 2.0 协议标准(简称HTTP/2)。谷歌因此宣布放弃对SPDY协议的支持,转而支持HTTP/2。

**HTTP L7 路由**:在 HTTP 模式下运行时,Envoy 的路由子系统能够根据路径、权限、内容类型、运行时值等来路由和重定向请求。在使用 Envoy 作为前端代理时,此功能非常有用。同时在构建服务网格时也会利用此功能。

**对 gRPC 的支持**:gRPC 是一个来自谷歌的 RPC框架, 使用 HTTP/2 作为底层的多路复用传输。Envoy支持所有需要用作 gPRC请求和响应的路由和负载均衡基础的 HTTP/2 功能。这两个系统是非常互补的。

**对MongoDB的 L7 网络协议的支持**:对于当今的 Web 应用,MongoDB数据库非常流行。因为Envoy支持基于 L7 的网络协议,所以Envoy 支持 MongoDB 连接的嗅探、数据统计和日志记录。

**对DynamoDB的 L7 网络协议的支持**:DynamoDB是由Amazion提供的基于键值对的NoSQL数据库。因为Envoy支持基于 L7 的网络协议,所以Envoy 支持 DynamoDB 连接的嗅探和数据统计。

**服务的动态注册和发现**:Envoy 可以选择使用一组分层的动态配置 API 来进行集中管理。这些层为Envoy提供了以下方面的动态更新: 后端群集的主机、后端群集本身、HTTP 路由、侦听套接字和通信加密。为了实现更简单的部署, 后端主机发现可以通过 DNS 解析 (甚至完全跳过) 完成, 层也可以替换为静态配置文件。

**健康检查**:构建 Envoy 网格的建议方法是将服务发现视为最终一致的过程。 Envoy 包括一个运行状况检查子系统,该子系统可以选择对上游服务集群执行主动运行状况检查。然后,Envoy 使用服务发现和运行状况检查信息的联合来确定健康的负载均衡服务器。Envoy 还支持通过异常检测子系统进行被动运行状况检查。

**高级负载均衡**:分布式系统中不同组件之间的负载平衡是一个复杂的问题。由于 Envoy 是一个独立的代理而不是库,因此它能够在一个位置实现高级负载平衡技术,并使任何应用程序都可以访问。目前Envoy 包括支持自动重试、断路、通过外部速率限制服务限制全局速率、请求隐藏和异常值检测。未来计划为Request Racing提供支持。

**前端/边缘系统代理支持**: 虽然 Envoy 主要是为服务通信系统而设计的,但对前端/边缘系统也是很有用的(可观测性、管理、相同的服务发现和负载平衡算法等)。Envoy包含足够的功能,使其可用作大多数 Web 应用服务用例的边缘代理。这包括作为 TLS 的终点、HTTP/1.1 和 HTTP/2 支持, 以及 HTTP L7 路由。

**最好的观察统计能力**:如上所述,Envoy 的首要目标是使网络透明。但是在网络级别和应用程序级都无法避免的容易出现问题。Envoy 包含了对所有子系统的强有力的统计支持。 [statsd](https://github.com/etsy/statsd) (和其他兼容的数据提供程序) 是当前支持的统计接收器,插入不同的统计接收器也并不困难。Envoy 可以通过管理端口查看统计信息,还支持通过第三方供应商进行分布式追踪。