Q: Proxy Pattern Pro & Con

服务网格的代理模式(proxy pattern)有哪几种,差异和优缺点如何?

首先我们需要澄清两个概念:

网关

在service mesh里,通常包含3种类型的网关:

  • Ingress。如果我们把service mesh比喻成一个交通网络,那么ingress就是高速公路或者干线的入口。在k8s里边,就是ingress;在google的byeond corp模型里,就是ap(access proxy);在实际工作中这个部分经常部署在传统网络模型的DMZ区里边,所以有时候也叫“DMZ网关”;在大型互联网公司里,有时候叫做* Front Engine,比如GFE(Google Front Engine),BFE(BaiDu Front Engine)
  • Egress。对应Ingress,当流量离开service mesh的时候,通常会经过Egress网关出去,通常是正向代理和SSL加密等功能。用高速公路或者干线的例子,egress就是高速公路或者干线出口
  • Service Gateway。如果把service mesh约束到微服务领域,这个部分就叫做“微服务网关”;但是多数service mesh的需求者,都希望service mesh可以同时处理非微服务的流量。用交通网络的例子,这些service gateway就像立交桥,或者是有红绿灯的十字路口

Proxy/代理

代理通常是指逻辑功能上的,所以当我们说“代理”的时候,通常是有上下文的,在不同的上下文里边,会具体指代上边说的三种网关中的某一种。

目前看来,行业里的service mesh的实现,有4种proxy pattern:

Proxy per instance

典型的是istio的sidecar模式。就是每个服务的实例,都配置一个代理。模型如下:

service_a --> proxy_a --> proxy_b --> service_b

这个模型的优点是容易理解;缺点主要是:

  1. 经过两次Proxy,有两次性能开销
  2. proxy_a和proxy_b的配置要严格一致,比如SSL证书,否则会出现请求失败
  3. 目前的proxy的实现,比如envoy,在我们看来,还是没有达到这个模型所需要的“轻量化”,因此带来了资源的开销;这个模式下,Proxy软件的实现,需要非常非常的轻。从Envoy文档看,本来他设计也是希望“非常非常轻”,但是做着做着功能越来越多,就重了起来

Proxy per namespace

这个是Flomesh目前推荐的模式。这里说的namespace,如果是k8s环境,就对应到一个ns就可以;如果是openshift环境,就对应到一个project就可以;如果是非容器环境,可以理解成"一组强关联可以统一管理的服务"。这时候模型是这样的,如果是name space内部直接访问,可以过网关,也可以不过网关:

service_a --> proxy --> servie_b

我们推荐经过网关的模式;不过多数时候,组内访问不经过网关也不是大的问题。

当跨namespace的时候,流量模型是这样的:

service_a --> proxy_ns1 --> proxy_ns2 --> service_b

这样做的好处:

  1. 多数服务互访,经过一次网关
  2. 配置模型更容易理解,也更容易trouble shooting
  3. 相对集中的配置,更容易保持一致

这样做的缺点主要是理解拓扑的时候不直观,因为在网关内部实际是一种“多租户”的形式,好的一面是Flomesh解决了这个问题。

Proxy per node

这个是Linkerd V1的模式。在k8s里边,就是每个linux节点,部署一个网关,给这个节点上的实例做代理。这个模型最简单的。在实际中,如果应用场景比较简单,我们也推荐部署Flomesh采用这种模式

Central Proxy

这个模式下,需要管理的流量都走统一的中央化的代理服务器,典型的场景是传统网关管理(相对应的,我们认为service mesh是一种SDN,软件定义网络)。在传统网关管理里,这个部分或者是堆叠的Nginx,或者是堆叠硬件,比如F5。这个模式下,网络管理通常是网关管理部门的工作,相对而言,配置的变更不频繁。因为配置变更和管理,以及容量规划、扩缩容灵活性的问题,这个模式在微服务高速增长的背景下,有些跟不上应用架构需求的变化。 但是这个模型并非毫无优点。在实际工作中,我们通常结合这个模式使用Flomesh,如果用上边交通网络的例子来解释这个,这个就像大型的交通枢纽,比如机场、比如地铁换乘站等;这些设施结合公交、出租车、快速通道等,才能成本有效的实现高性能交通体系

在设计上,Flomesh被设计成可以支持如上4种模式;在实际使用中,Flomesh可以根据需要,通过配置方式实现这几种模式,并实现搭配使用。实践中,大型商用service mesh的设计和实施是一个复杂的工作。