Lyft 的 Service Mesh 工具 Envoy

原文

Envoy 的链接

Lyft 的 SoA 架构

3-5年前,Lyft 的架构是, AWS ELB + Php monolith app + Mongo DB。出现的问题是,apache 服务器的连接数也是有限的。整个架构的 scalability 很差。

大概2年前,Lyft 采用了 SoA 架构。

envoy-1

业内 SOA 在网络层的现状

  • 使用各种语言,各种框架
  • 对于一个工具 ,每个语言需要一个对应的 library
  • 使用各种协议: http1, http2, gRPC, db 协议,缓存机制
  • 使用各种基础设施: IaaS, Caas 等
  • 使用各种 Load balancer: AWS ELB, F5
  • 各种其他工具,从 server 读取信息:stats, logging, tracing
  • 各公司需要自己实现 retry, circuit breaker, rate limiting, timeout 等等基础功能
  • authentication, authorization
  • 很难 debug 这些问题
  • 很多基础设施,比如 LB、cache、网络拓扑,对工程师并不可见
  • 很多基础设施对于

所有这些变化,使得业内没有一个相对统一的维护方式,难以管理。

Envoy

envoy-2

Envoy 认为,网络层应该对 app 透明。当网络的问题出现的时候, app 应该知道这是什么网路问题。

  • 它是一个软件,像 Nginx 一样,而不是一个 library
  • 它在网络中处于 L3/L4 层。所以它可以被用在很多网络协议中,比如 db, cache, gRPC
  • Envoy 应该和每一个 app 放在一起,作为 app 处理网络问题的 proxy
  • 它也做 service discovery
  • 提供 observibility
  • 实现了大部分 nginx 的功能,对于很多人来说,它可以作为 nginx 的替代

如今的 Lyft 架构

envoy-3

请求,由 front Envoy 发送给其他 sub Envoy。各个 service 再用 microservices 架构,使用后端各种工具,MongoDB, DynamoDB 等

关于 service discovery

作者认为,service discovery 是一个 eventually consistent 问题,其实不需要实现 fully consistent。而且如果做成 fully consistent,会遇到太多次的系统中断的情况,所以也很难 scale。他的分布式系统设计哲学是,如果一个 fully consistent 问题,可以通过变成 eventually consistent 来解决,那就用 eventually consistent。

Envoy 是将 service discovery 按照 eventually consistent 设计和实现的。

Envoy 其他功能

  • 各种类型的 service discovery: API, DNS

  • load balancing

  • 将请求发送到最近的 service

  • 记录 stats

  • circuit breaking:设置最大请求数,连接数等

  • rate limiting

  • Request shadowing:复制请求,并发送给测试服务器

  • 实现 Retry

  • deploy control: 可以使用 blue/green deploy,或者 canary deploy

  • 既然所有请求都通过 Envoy,那么Envoy 可以提供一个完整的 log。下图是一个Envoy记录的全局 stats。这些都是为 Observisibility 服务。

envoy-4

  • 完整跟踪一个请求。能看到一个请求是怎么在各个 service 之间流动的。

envoy-5

  • 使用 Kibana 作为 logging system

最后看一眼使用 Envoy 的公司:

envoy-6