摘要：為安裝過濾器的偵聽器上的每個新請求調用服務，路由表指定應調用服務。使用了令牌桶算法來限流。

本博客是深入研究Envoy Proxy和Istio.io 以及它如何實現更優雅的方式來連接和管理微服務系列文章的一部分。

這是接下來幾個部分的想法（將在發布時更新鏈接):

斷路器（第一部分）

重試/超時（第二部分）

分布式跟蹤（第三部分）

Prometheus的指標收集（第四部分）

rate limiter（第五部分）

Envoy通過兩個過濾器與Ratelimit服務集成：

Network Level Filter： envoy為安裝過濾器的偵聽器上的每個新連接調用Ratelimit服務。這樣，您可以對通過偵聽器的每秒連接進行速率限制。

HTTP Level Filter：Envoy為安裝過濾器的偵聽器上的每個新請求調用Ratelimit服務，路由表指定應調用Ratelimit服務。許多工作都在擴展HTTP過濾器的功能。

http rate limiter 當請求的路由或虛擬主機具有與過濾器階段設置匹配的一個或多個速率限制配置時，HTTP速率限制過濾器將調用速率限制服務。該路由可以選擇包括虛擬主機速率限制配置。多個配置可以應用于請求。每個配置都會導致將描述符發送到速率限制服務。

如果調用速率限制服務，并且任何描述符的響應超出限制，則返回429響應。速率限制過濾器還設置x-envoy-ratelimited標頭。

果在呼叫速率限制服務中出現錯誤或速率限制服務返回錯誤并且failure_mode_deny設置為true，則返回500響應。

全部的配置如下：

  envoy.yaml: |-
    static_resources:
      listeners:
      - address:
          socket_address:
            address: 0.0.0.0
            port_value: 8000
        filter_chains:
        - filters:
          - name: envoy.http_connection_manager
            config:
              codec_type: auto
              stat_prefix: ingress_http
              access_log:
              - name: envoy.file_access_log
                config:
                  path: "/dev/stdout"
                  format: "[ACCESS_LOG][%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
"              
              route_config:
                name: local_route
                virtual_hosts:
                - name: gateway
                  domains:
                  - "*"
                  routes:
                  - match:
                      prefix: "/cost"
                    route:
                      cluster: cost
                  rate_limits: # enable rate limit checks for the greeter service
                    actions:
                    - destination_cluster: {}
              http_filters:
              - name: envoy.rate_limit # enable the Rate Limit filter
                config:
                  domain: envoy            
              - name: envoy.router
                config: {}
      clusters:
      - name: cost
        connect_timeout: 0.25s
        type: strict_dns
        lb_policy: round_robin
        hosts:
        - socket_address:
            address: cost.sgt
            port_value: 80
      - name: rate_limit_cluster
        type: strict_dns
        connect_timeout: 0.25s
        lb_policy: round_robin
        http2_protocol_options: {}
        hosts:
        - socket_address:
            address: limiter.sgt
            port_value: 80
    rate_limit_service:
        grpc_service:
            envoy_grpc:
                cluster_name: rate_limit_cluster
            timeout: 0.25s
    admin:
      access_log_path: "/dev/null"
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 9000
          

通過配置文件可以看出，本demo設置的是一個全局的http filter rate limiter。

盡管分布式熔斷通常在控制分布式系統中的吞吐量方面非常有效，但有時它不是非常有效并且需要全局速率限制。最常見的情況是當大量主機轉發到少量主機并且平均請求延遲較低時（例如，對數據庫服務器的連接/請求）。如果目標主機已備份，則下游主機將淹沒上游群集。在這種情況下，在每個下游主機上配置足夠嚴格的斷路限制是非常困難的，這樣系統在典型的請求模式期間將正常運行，但在系統開始出現故障時仍能防止級聯故障。全局速率限制是這種情況的一個很好的解決方案。

Envoy直接通過gRPC與速率限制服務集成。Envoy要求速率限制服務支持rls.proto中指定的gRPC IDL。有關API如何工作的更多信息，請參閱IDL文檔。

本身envoy 只是提供了限流的接口，沒有具體的實現，所以必須自己實現一個限流器。下面只是簡單實現一下，給大家一個思路。

具體的代碼如下：

package main

import (
    "log"
    "net"
    "time"

    rls "github.com/envoyproxy/go-control-plane/envoy/service/ratelimit/v2"
    "github.com/juju/ratelimit"
    "golang.org/x/net/context"
    "google.golang.org/grpc"
    "google.golang.org/grpc/reflection"
)

// server is used to implement rls.RateLimitService
type server struct {
    bucket *ratelimit.Bucket
}

func (s *server) ShouldRateLimit(ctx context.Context,
    request *rls.RateLimitRequest) (*rls.RateLimitResponse, error) {
    // logic to rate limit every second request
    var overallCode rls.RateLimitResponse_Code
    if s.bucket.TakeAvailable(1) == 0 {
        overallCode = rls.RateLimitResponse_OVER_LIMIT
    } else {
        overallCode = rls.RateLimitResponse_OK
    }

    response := &rls.RateLimitResponse{OverallCode: overallCode}
    return response, nil
}

func main() {
    // create a TCP listener on port 8089
    lis, err := net.Listen("tcp", ":8089")
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
    log.Printf("listening on %s", lis.Addr())

    // create a gRPC server and register the RateLimitService server
    s := grpc.NewServer()

    rls.RegisterRateLimitServiceServer(s, &server{
        bucket: ratelimit.NewBucket(100*time.Microsecond, 100),
    })
    reflection.Register(s)
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

具體項目，查閱github。

PS:

使用了令牌桶算法來限流。令牌桶算法(Token Bucket)和 Leaky Bucket 效果一樣但方向相反的算法,更加容易理解.隨著時間流逝,系統會按恒定1/QPS時間間隔(如果QPS=100,則間隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有個水龍頭在不斷的加水),如果桶已經滿了就不再加了.新請求來臨時,會各自拿走一個Token,如果沒有Token可拿了就阻塞或者拒絕服務.

該實現存在單點風險。

Dockerfile均在代碼倉庫中，大家可以構建鏡像自己測試。

本文簡單講了envoy的 rate limit功能，提供了全局限流的配置文件，并簡單實現了一個基于令牌桶的限流器。希望能幫助你理解Envoy的限速過濾器如何跟gRPC協議協同工作。