Envoy已在服务网格和代理世界中得到了不少欢迎。这是一项了不得的技术,但有时有些难以理解。我一直在玩的一件事是使用Envoy来执行速率限制。幸运的是,限速是Envoy的头等公民。然而,阅读率限制的文档有不少概念,这就可能致使咱们很难运行一个demo。通过探索,我对Envoy的限速理念和概念作一些总结。 Envoy容许咱们同时配置TCP和HTTP速率限制过滤器,但在本文中咱们将重点介绍HTTP。git
在查看这一切在Envoy中的工做方式时,咱们注意到的第一件事是Envoy但愿您定义速率限制服务。这是由于Envoy自己没有机制来肯定是否应让请求经过或限制请求。这是有道理的,由于有时这须要代理可能不该该是全部者的信息。很酷的事情是,Envoy但愿从限速服务中得到的接口已被详细记录。因为这是一个gRPC API(与Envoy的其余控制平面和数据平面API同样),所以能够很容易地从响应该模式的服务开始。为了使事情变得更好,Lyft最近发布了响应该接口的服务版本:https://github.com/lyft/ratel...github
要使用Envoy的配置文件配置此服务,咱们须要执行如下操做:算法
rate_limit_service: grpc_service: envoy_grpc: cluster_name: my_rate_limit_service timeout: 0.25s
可是要使咱们的限速服务正常工做,咱们须要一些信息。该信息与gRPC请求一块儿发送,咱们能够在这里查看:https://github.com/envoyproxy...json
率限制请求有三个字段:api
domain
让envoy告诉咱们的限速请求,咱们系统中的哪些设备正在要求这些限速。这对于避免可能因domain而异的键冲突颇有用。hits_addend
是envoy为该请求指定额外费用的一种方式,例如,更昂贵的路线。我很好奇为何要在请求中,而不是让服务来决定,但这仍然颇有趣。descriptors
是速率限制请求的关键。它是一组描述此请求上下文的键值对。它们能够帮助咱们的限速服务计算密钥,识别参与者等。当我第一次阅读gRPC接口时,这一切对我来讲颇有意义。但立刻产生一个疑问,我不清楚如何配置descriptors。个人目标是可以根据用户的HTTP_AUTHORIZATION
标头对限制用户进行评分,很难看到如何发送带有标头值的描述符值。这是一个运行时值,可能会随每一个请求而变化,所以将其做为静态配置没有任何意义。 这是速率限制操做起做用的地方。服务器
到目前为止,咱们涉及的内容是咱们的限速服务的一部分,以便让咱们作出正确的决定。可是,咱们仍然不知道Envoy如何填充这些数据,甚至不知道咱们如何发送感兴趣的数据。在envoy中配置的路由能够选择定义RateLimit配置,定义动做。动做是构建descriptor的一种方法:经过配置动做,咱们使Envoy知道咱们但愿它如何使用几个不一样的选项来构建要发送到速率限制服务的descriptor列表。dom
例如,若是咱们想对请求的Authorization标头实现速率限制,则能够指示envoy经过如下操做构建此类descriptor:设计
rate_limit: actions: - request_headers: header_name: HTTP_AUTHORIZATION descriptor_key: auth_token
如今,在进行此配置的状况下,速率限制服务将收到如下descriptor列表:代理
[ "key": "auth_token", "value": "1ae59f456ff7ec1185c03b781f955a4e" ]
这是咱们的限速服务将作出决定的地方。基于该descriptor集(此示例中只有1个),咱们能够查找密钥,使用某种速率限制算法(令牌桶,滑动窗口等)对密钥进行速率限制,而后将决策发送回envoy。注意,能够定义多个动做,在此进行解释。code
这里更复杂的是发送多个descriptor时。descriptor条目是分层的,这意味着条目能够创建在其余条目之上。
速率限制请求的主要消息。速率限制服务被设计为彻底通用的,由于它能够在任意层次的键/值对上运行。加载的配置将解析请求并找到最具体的限制。此外,RateLimitRequest能够包含多个“descriptor”以进行限制。当提供多个descriptor时,服务器将限制它们的所有,若是其中任何一个超出限制,则返回OVER_LIMIT响应。若是须要,这将启用更复杂的应用程序级别速率限制方案。
如您所见,Envoy中的速率限制很是通用且强大。