在服务网络出来之前,就已经有很多各式各样的Api Gateway了。他们之间有什么不同呢?

1. Api Gateway架构

Api Gateway有很多,现阶段做的比较好的有ambassador和kong。还有一些其它的,目前看来这两个用的人比较多。
– Ambassador架构:

  • Kong架构:

从流量转发的角度来看,Api Gateway主要做的事是外部到内部的流量转发,也就是通常所说的南北流量。基于kubernetes的架构内来说,其主要是实现ingress的功能。

应用内部之间的流量(东西流量)并不是它关注的重点,虽然部分上也可以实现,但是相关功能并不多。

2. API Gateway解决了什么问题?

API Gateway主要是解决了API管理的问题。

根据Wikipedia的定义:API管理的过程包括创建和发布Web API、执行调用策略、访问控制、订阅管理、收集和分析调用统计以及报告性能。

根据以上定义,API Gateway主要的功能如下:
– api的创建和发布,比如说api的自动注册
– 访问控制和调用策略(流控等),谁能访问?API被调用时,怎么确保安全和稳定的访问?
– 订阅管理,哪些人可以访问我的API
– 调用性能分析及信息收集等

3. 服务网络(Service Mesh)架构

在微服务一统天下的时代,微服务数量成百上千,一个API通常要经过几个或几十个微服务,微服务之间的管理越来越复杂,这就是服务网络出现的原因。

可见服务网络的侧重点在解决微服务之间服务调用的问题。也就是所谓的东西流量的问题。

4. 服务网络(Service Mesh)解决了什么问题?

服务网络解决了什么问题呢?主要有如下:
– 弹性:超时、重试、熔断、故障处理、负载均衡。
– 流量限制:基于多个来源的基础设施流量限制。
– 通信路由:根据path、host、header、cookie base、源Service……
– 可观测性:指标、日志、分布式追踪。
– 安全:mTLS、RBAC……

5. 简单总结

经过上面的对比,从运维的角度来看的话。简单的类比就是:
– Api Gateway实际上相当于外网网关层。
– 服务网络相当于内网网关层(当然它把外网网关层也做了,只是侧重点在内网网关层)。