构建云原生微服务网关篇一：Ambassador

在微服务架构中，API网关是一个十分重要的存在。一方面它为外部的流量访问提供了统一的入口，使得可以方便的进行防火墙的策略实施；另一方面，可以在网关处进行流量控制、认证、授权、灰度发布、日志收集、性能分析等各种高级功能，使得业务功能与非业务功能有效解耦，给予了系统架构更大的灵活性。本系列文章尝试分析目前主流的云原生微服务网关，并比较它们各自的优劣。

网关选型标准

其实kubernetes本身有一个ingress controller，基于Nginx或HAProxy等7层代理进行流量的转发。不过ingress只能进行简单的反向代理，不支持流控、灰度、认证、授权等网关必备的功能。所以一般意义认为，ingress是一个7层http代理，而非api网关。本系列主要分析Ambassador、Traefik、Kong等具备微服务所需能力的网关产品。

什么是Ambassador？

这里引用官网的一段描述

Ambassador是一个基于Envoy proxy构建的，kubernetes原生的开源微服务网关。Ambassador在构建之初就致力于支持多个独立的团队，这些团队需要为最终用户快速发布、监控和更新服务。Ambassador还具有Kubernetes ingress和负载均衡的能力。

注意这里的几个关键词：Envoy，kubernetes原生，微服务。现在市面上网关产品不少，不过Kubernetes原生的产品倒真的不多。传统的网关产品一般是基于rest api或者yaml文件来进行配置（谁让这些老大哥出来的早呢，他们火的时候k8还没出来呢），而Ambassador完全基于k8s标准的annotation或者CRD来进行各类配置，没错，非常的native。

Ambassador架构

具体流程如下：

1. 服务所有者在kubernetes manifests中定义配置（通过annotation或者CRD）。

2. 当manifest应用到集群时，kubernetes api会将更改通知Ambassador。

3. Ambassador解析更改并将配置转换为一种中间语义。Envoy的配置由该IR生成。

4. 新的配置通过基于gRPC的聚合发现服务（ADS）api传递给Envoy。

5. 流量通过重新配置的Envoy，而不会断开任何连接。

扩展性和可用性

Ambassador依靠Kubernetes实现扩展性、高可用性和持久性。所有Ambassador配置都直接存储在Kubernetes中（etcd），没有数据库。Ambassador被打包成一个单独的容器，其中包含控制平面和一个Ambassador代理实例。默认情况下，Ambassador部署为kubernetes deployment，可以像其他kubernetes deployment一样进行扩展和管理。

与其他网关产品比较

目前主流的网关产品可以分为三类：

• 托管的API网关，比如 Amazon api gateway

• 传统的API网关，比如 Kong

• 7层代理，比如 Traefik, NGINX, HAProxy, or Envoy, 或者是基于这些代理的 Ingress controller

所有这些托管的和传统的API网关的问题是：

• 不是自服务的。传统API网关上的管理接口不是为开发人员自服务而设计的，为开发人员提供的安全性和可用性有限。

• 不是Kubernetes原生的。它们通常使用REST apis进行配置，这使得采用云原生模式（如GitOps和声明式配置）变得很困难。

• 为API管理而设计，而非微服务。

一般来说，7层代理可以用作API网关，但需要额外的定制开发来支持微服务用例。事实上，许多API网关都将API网关所需的附加功能打包在L7代理之上。Ambassador使用Envoy，而Kong使用Nginx。

Istio

Istio是一个基于Envoy的开源服务网格。服务网格用于管理东/西向流量，而API网关用于管理南/北向流量。一般