用例 1：边缘（南/北）路由
这个是平时最常见的使用场景，网关位于整个集群的入口处，统一去做一些流控、鉴权等方面的工作：
该场景的关注点在于：
- 控制/路由入口流量的能力
- 卸载请求
- 认证（比如要求所有入口流量都必须要进过认证）
- 加密（TLS 终端及传输加密）
- 重试及超时
saas service 中的真实用例：
用例 2：内部（南/北）路由
通常来说，企业内部的系统架构会比较复杂，会有多集群或者多租户，比如一个 kubernetes 的集群和一个 vm 的集群（可能是 openstack），那么在集群之间的流量就是内部的南/北流量，集群之间的流量交互可以通过 ambassador 完成。
此场景的关注点在于：
- 控制/路由多租户流量的能力
- 卸载请求
- 匹配（基于 headers）
- 重试及超时
saas service 中的真实用例：
用例 3：内部（东/西）路由
这个场景中 Ambassador 已经作为集群内部东西向流量的代理了，配合它自己的控制平面，有点 service mesh 的意思了。区别在于，Ambassador 在这个集群里是处于一个中心节点的位置（一个或一组 ambassador 实例），属于 server proxy 的范畴，而不是 service mesh 里面的 client proxy（sidecar）。这种架构其实和传统的 esb 更加的接近。
此场景关注点：
- 控制/路由任意流量的能力（南北向+东西向）
- 卸载请求
- 服务发现
- 负载均衡
- 访问控制
大家可以看到，已经非常接近于 service mesh 的能力了（也许 ambassador 以后也会出一个 service mesh 产品？）
saas service 的真实用例：
服务网格的真实用例（与 istio 集成）：
用例 4：流量镜像
此场景中可以把流量复制一份到其他服务中（影子流量），通常用于监控、测试等场景
- 测试代码、发布包的能力
- 利用真实的流量/负载
- 最小化重复资源
注意：上面所描述的几个典型场景其实不光可以使用 Ambassador，而是适用于各类使用 api gateway 或者 proxy 的场景。
评论区