作为一个开源项目,Envoy拥有大量的拥护者并且由于可以用来解决任意大型分布式系统中出现的网络问题,它的用户数量还在持续增长。但它究竟是什么呢?又如何开始使用呢?
欢迎来到Envoy 101,对于刚接触Envoy的新手的理想选择。本文将提供一个简单易懂的介绍,介绍如何将Envoy设置为网关、提供yaml示例并解释yaml在每个步骤中的做法和原因。最后会提供完整的envoy.yaml文件,读者可以根据它自己尝试设置网关并使用它将流量引流到两个服务上。
Envoy的用途
Envoy代理有两个常见用途。一是用作服务代理(sidecar),二是用作网关。
用作sidecar时,Envoy是一个位于服务旁边的四层或七层的应用代理,可以生成指标、应用策略和控制流量。
用作API网关时,Envoy作为一个“前置代理”接受inbound流量,核对请求中的信息并将其定向到目的地。本文的例子将演示如何使用Envoy作为前置代理。我们将编写一个静态配置,返回例如HTTP和IPv4等不会改变的静态数据。正如你将在本例中看到的那样,这一用途很简单,适合处理几乎不变化的信息。
这个配置能做什么?
该yaml配置是一个好起点,它展示了如何使用Envoy将流量路由到不同的端点并介绍了一些关键概念。
下图的箭头展示了请求在配置中的流程。五个关键元素分别是“listener”、“filter chain”、“route”、“cluster”和“endpoint”。其中route是filter chain的一部分,filter chain是listener的一部分。
简单来说,它们是静态API yaml中的重要部分,描述了Envoy网关应该如何处理流量。
listener的工作最为重要。它与端口“绑定”并监听到达网关的inbound请求。listener只接受来自它绑定的端口的请求。任何通过其他端口进来的请求都不会被Envoy看到或处理,发送该请求的用户只会获得错误响应。
一旦请求被listener接受,它就会经过一条filter chain,该filter chain描述请求一旦进入Envoy后应当被如何处理。filter chain由一些filter组成,filter决定请求能否被传递到下一个filter或发生短路并向用户发送404错误。
在本例中,如果一个请求通过了filter chain中的所有filter,route(作为filter chain的扩展)将会获取HTTP请求信息并将其定向到正确的服务。
现在,在了解Envoy的功能和基本的请求流程后,我们开始介绍yaml。
了解yaml
在运行完整的配置之前,最好先了解每部分都在做些什么。在每个部分,它将向你介绍一些核心概念(和术语)。随着你不断使用Envoy和阅读文档,你会越来越多的看到这些概念。
声明静态资源
static_resources
我们做的第一件事是声明这个一个对于静态资源的配置,这意味着其中的信息是不能改变的。以上配置描述了上图中listener的信息。
listener将预期地址设置为IPv4(0.0.0.0)并将“port_value”设为8080。IPv4是IP地址的基本标准,我们想让Envoy能够监听世界上几乎所有的流量。listener会自己绑定到8080端口并将不会接受通过其他任何接口传来的流量。
过滤链和路由
filter_chains
filter chain由一些形成chain的filter组成,yaml描述了请求进入Envoy后应该被如何过滤和路由。首先将该filter定义为http_connection_manager。接着写明经过该filter的请求将被发送给http_filters和http.router。
该filter的另一部分是告诉chain如何根据它匹配到的前缀向对应的集群路由流量。路由通常匹配HTTP相关的名词,包括请求头、路径名或主机名等。在本例中,请求是根据路径名而非请求头或主机名进行路由的(如match: prefix行所示)。
设置集群
clusters
类似的,在这儿设置两个集群也很平常且容易。为什么设置两个集群?因为它将流量路由到两个不同的端点集合。这些服务(集群)已经被命名好了。它们设置了0.25秒的连接超时和round-robin负载均衡策略。在生产环境中,round-robin可能不是最好的选择,但对于demo解释来说,它是有效的。如果想了解更多关于Envoy中可以配置什么类型的超时,建议查看Envoy文档。
特别值得注意的是HTTP/2的使用,与前代相比它改变了数据的格式和传输方式以减少延迟。如果想了解更多关于HTTP/2的知识,建议阅读Google关于Web基础知识的介绍性文章。
管理
admin
这里设置了对Envoy管理平面的管理权限。这意味着你可以在localhost中访问管理数据。
完整的yaml文件
static_resources
自己试一试吧!
首先,确保Docker Compose正在运行。如果没在运行,按这个说明操作:https://docs.docker.com/compose/gettingstarted/。
然后,你要运行的所有东西都在这儿:https://github.com/envoyproxy/envoy/tree/master/examples/front-proxy。
如果跟随Github repo中的说明进行操作,你将会看到输出结果!别担心service.py中的任何错误,它们既不重要也不影响脚本运行。
运行命令“docker-compose up”就行了。
一旦在bash终端确认service1和service2正在运行。在浏览器里打开http链接并在网址后面加上/service/1或者/service/2。如果没加上,你会看到404错误。
这就可以啦!你已经为自己设置好了一个Envoy网关并用它将流量定向到了两个服务。
要点重述
现在让我们来看看为什么配置以这样的方式运作。下图显示请求通过Envoy到达Service2端点的流程。
以上每一步中都会进行校验以确保消息的正确性并将其送到正确的地方。例如,如果试图向/service/3提出请求,请求会一直抵达路由器(http_router)处才会确定没有地方可以路由该请求。服务3不存在。
静态配置在可预测且简单的情况下很棒。然而在经常变化的动态环境中,它并不实用。如果你试图在动态环境中使用静态配置,将会进行大量的手动更改(这很费时)。
因此,这篇文章已经介绍了Envoy的关键概念,但我并不建议将其投入生产。
如果你想了解更多关于Envoy的信息,请查看我们的资源库以及我们的开源项目GetEnvoy。