抛弃了 Nginx, 选择了 Envoy

其实之前扇贝是大量使用 Nginx 的，无论是对于其部署，配置还是调优都更为有经验。如果可以，我们还是倾向于选用 Nginx作为 Service Mesh 的核心方案的。

但是碰到几个绕不开的问题：

Nginx的反向代理不支持 http2/grpc (好像今年3月份刚支持)
不像 Envoy 几乎所有的网络配置都可以利用 xDS API 来实现动态变更，Nginx缺乏有效的配置热变更机制(除非深入开发或者不断地reload)。
Nginx的很多微服务功能都是要买 Nginx Plus 才有的

Envoy 作为一个主打 Service Mesh 方案的 proxy，其设计处处考虑 Service Mesh，在经过一定地了解后，我们果断入了 Envoy 的坑。

Envoy 是什么

我们援引一段官网的描述：

Envoy is an L7 proxy and communication bus designed for large modern service oriented architectures. The project was born out of the belief that: "The network should be transparent to applications. When network and application problems do occur it should be easy to determine the source of the problem."

Envoy 的核心功能/卖点

非侵入的架构：Envoy 是和应用服务并行运行的，透明地代理应用服务发出/接收的流量。应用服务只需要和 Envoy 通信，无需知道其他微服务应用在哪里。
基于 Modern C++11实现，性能优异。
L3/L4 过滤器架构：Envoy 的核心是一个 L3/L4 代理，然后通过插件式的过滤器(network filters)链条来执行 TCP/UDP 的相关任务，例如 TCP 转发，TLS 认证等工作。
HTTP L7 过滤器架构：HTTP在现代应用体系里是地位非常特殊的应用层协议，所以 Envoy 内置了一个非常核心的过滤器: http_connection_manager。http_connection_manager 本身是如此特殊和复杂，支持丰富的配置，以及本身也是过滤器架构，可以通过一系列 http 过滤器(http filters)来实现 http协议层面的任务，例如：http路由，重定向，CORS支持等等。
HTTP/2 作为第一公民：Envoy 支持 HTTP/1.1 和 HTTP/2，推荐使用 HTTP/2。
gRPC 支持：因为对 HTTP/2 的良好支持，Envoy 可以方便的支持 gRPC，特别是在负载和代理上。
服务发现：支持包括 DNS, EDS 在内的多种服务发现方案。
健康检查：内置健康检查子系统。
高级的负载均衡方案：除了一般的负载均衡，Envoy 还支持基于 rate limit 服务的多种高级负载均衡方案，包括： automatic retries, circuit breaking, global rate limiting
Tracing：方便集成 Open Tracing 系统，追踪请求
统计与监控：内置 stats 模块，方便集成诸如 prometheus/statsd 等监控方案
动态配置：通过“动态配置API”实现配置的动态调整，而无需重启 Envoy 服务的。

核心术语解释

Host

这里的 Host，可以理解为由 IP, Port 唯一确定的服务实例

Downstream

发送请求给 Envoy 的 Host 是 Downstream(下游)，例如gRPC的 client

Upstream

接收 Enovy 发出的请求的 Host 是Upstream(上游)，例如 gRPC的 server

Listener

Envoy 监听的一个地址，例如 ip:port, unix socket 等等

Cluster

一组功能一致的上游 Host，称为一个cluster。类似 k8s 的 Service, nginx 的 upstream

Http Route Table

HTTP 的路由规则，例如请求的域名，Path符合什么规则，转发给哪个 Cluster。

配置(v2)

Envoy 的配置接口以 proto3(Protocol Buffers v3)的格式定义，完整的定义见 data plane API repository

具体的配置文件编写支持：yaml, json, pb, pb_text 四种格式。出于可读性的考虑，我们下面都以 yaml 格式为例。

先看一个简单的例子：

完全静态的配置

admin:
  access_log_path: /tmp/admin_access.log
  address:
    socket_address: { address: 127.0.0.1, port_value: 9901 }

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 127.0.0.1, port_value: 10000 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["example.com"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: some_service }
          http_filters:
          - name: envoy.router
  clusters:
  - name: some_service
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    hosts: [{ socket_address: { address: 127.0.0.2, port_value: 1234 }}]

在上面的例子中，我们配置了一个 envoy实例，监听 127.0.0.1:10000，支持 http 协议访问，http 访问域名为：example.com。接收到的所有http流量，转发给 127.0.0.2:1234 的服务。

很快大家发现一个问题，就是 some_service 这个cluster中 hosts 是固定的(127.0.0.2:1234)，但是很有可能对应的 host是会变的。例如：增加了新的 host(水平扩展), k8s环境中，发了新代码(pod变了)，等等。这时候，总不至于我们需要不停的该 cluster 中的 hosts吧？放心，如果是这样，我们就不会用 Envoy 了。

通过EDS动态配置cluster hosts

接下来我们会碰到第一个动态配置的例子，就是动态配置 cluster 的 hosts。

我们先假设有这么一个服务A，地址是：127.0.0.3:5678，会返回 proto3 编码的下属响应

version_info: "0"
resources:
- "@type": type.googleapis.com/envoy.api.v2.ClusterLoadAssignment
  cluster_name: some_service
  endpoints:
  - lb_endpoints:
    - endpoint:
        address:
          socket_address:
            address: 127.0.0.2
            port_value: 1234

那么我们把 envoy 的配置调整为：

admin:
  access_log_path: /tmp/admin_access.log
  address:
    socket_address: { address: 127.0.0.1, port_value: 9901 }

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 127.0.0.1, port_value: 10000 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["example.com"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: some_service }
          http_filters:
          - name: envoy.router
  clusters:
  - name: some_service
    connect_timeout: 0.25s
    lb_policy: ROUND_ROBIN
    type: EDS
    eds_cluster_config:
      eds_config:
        api_config_source:
          api_type: GRPC
          cluster_names: [xds_cluster]
  - name: xds_cluster
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    http2_protocol_options: {}
    hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]

就可以实现 some_service 这个 cluster 的 hosts 的动态配置了。新的配置中，some_service 这个 cluster 的 hosts 是 EDS(Endpoint Discovery Service) 的返回值决定的，就是说 EDS 会返回 some_service 这个 cluster 的 hosts 的列表。新配置中，EDS 服务的地址定义在 xds_cluster 这个 cluster中，地址正是我们开头假设的服务A的地址。

其实 Envoy 的 listener, cluster, http route 等都是可以动态配置的，方法和 EDS一样，通过 LDS, CDS, RDS 来实现配置，而它们统称为 xDS。一个完整的动态配置的例子如下：

基于xDS的动态配置

admin:
  access_log_path: /tmp/admin_access.log
  address:
    socket_address: { address: 127.0.0.1, port_value: 9901 }

dynamic_resources:
  lds_config:
    api_config_source:
      api_type: GRPC
      cluster_names: [xds_cluster]
  cds_config:
    api_config_source:
      api_type: GRPC
      cluster_names: [xds_cluster]

static_resources:
  clusters:
  - name: xds_cluster
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    http2_protocol_options: {}
    hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]

这里我们假设 127.0.0.3:5678 提供完整的 xDS

LDS:

version_info: "0"
resources:
- "@type": type.googleapis.com/envoy.api.v2.Listener
  name: listener_0
  address:
    socket_address:
      address: 127.0.0.1
      port_value: 10000
  filter_chains:
  - filters:
    - name: envoy.http_connection_manager
      config:
        stat_prefix: ingress_http
        codec_type: AUTO
        rds:
          route_config_name: local_route
          config_source:
            api_config_source:
              api_type: GRPC
              cluster_names: [xds_cluster]
        http_filters:
        - name: envoy.router

RDS:

version_info: "0"
resources:
- "@type": type.googleapis.com/envoy.api.v2.RouteConfiguration
  name: local_route
  virtual_hosts:
  - name: local_service
    domains: ["*"]
    routes:
    - match: { prefix: "/" }
      route: { cluster: some_service }

CDS:

version_info: "0"
resources:
- "@type": type.googleapis.com/envoy.api.v2.Cluster
  name: some_service
  connect_timeout: 0.25s
  lb_policy: ROUND_ROBIN
  type: EDS
  eds_cluster_config:
    eds_config:
      api_config_source:
        api_type: GRPC
        cluster_names: [xds_cluster]

EDS:

version_info: "0"
resources:
- "@type": type.googleapis.com/envoy.api.v2.ClusterLoadAssignment
  cluster_name: some_service
  endpoints:
  - lb_endpoints:
    - endpoint:
        address:
          socket_address:
            address: 127.0.0.2
            port_value: 1234

结束语

作为一篇 Envoy 的快速入门文，我们大概地了解了 Envoy的核心功能，术语，以及配置。关于更加深入的定制配置，可以进一步翻阅 Envoy 的官方文档。

在扇贝，Envoy 作为 Service Mesh 的核心组件，承载了微服务间的所有直接调用流量。

我们的不同的微服务对应一个个 Cluster，通过 authority 来设置 Route Table。

利用 Envoy 的 stats 数据做服务调用的性能监控，Envoy 的 access log 做流量日志收集，rate limit 做服务保护。