现状
下图是我们系统的架构现状，大致介绍一下：
- 基础设施在华为云上
- 基本上是基于
istio on k8s架构。 istio版本为 1.3，所以组件较多（galley、pilot、citadel、telemetry......）- 微服务后端用
spring boot单体，前端有nodejs、vue等 - 应用的链路监控主要基于
skywalking,istio的通讯层面利用kiali可视化调用链 - 其他比较传统
历史架构
主要介绍下作为服务通讯基础设施的 istio 在这里的作用
- 服务间通讯，依赖
envoy sidecar - 注册中心，依赖
istio控制面 - 服务治理（熔断、超时、重试）这部分还没有完完全全切干净，还有些
spring boot应用依赖hystrix，后面会全部改成利用istio。 - 流量管理（
ingress gateway、egress gateway、负载均衡） - 测试（错误注入）
通过将传统微服务架构的这些控制面功能解耦到 istio,可以让微服务应用本身专注于业务开发，是一个比较简的单体 springboot 应用。再结合 k8s 的高扩展性，研发整体的迭代速度和运维效率还是比较高的，缺点是无论是 k8s 还是 istio ，学习成本偏高，需要团队至少 2 人具有专业知识，对于招聘成本、系统升级都有风险。
上了贼船
坦白讲，如果系统最初的设计是我来做，是不会用如此“激进”的方案的，会转而用 spring cloud 为基础的架构，当然，k8s 是非常可能会使用的。但可惜我是中间接手，也想过换架构，但迫于公司业务和迭代的压力，再加上人手有限，再换架构的风险会非常高，所以既然上了 istio 的贼船，就只能走下去了，等什么时候时机成熟再并行其他架构，或切换回合适的架构。这里我要强调的是，做架构选择或者选型不是为了技术而技术，一定是要非常适合当时公司的发展现状、业务场景、团队能力、招聘成本等等，综合多种条件而得出的结论。 巧合的是 istio 的 logo 也是一个帆船的样子，果真
是上了贼船
API Gateway
终于说到本文的重点 API Gateway 了，对于这个话题，之前写过一篇文章，读者可以先脱离现在的架构从功能层面来了解下 API Gateway。
回到我们现在的架构，你会发现，虽然我们有前置的 openResty,但应用层这边并没有一个担当 API Gateway 角色的服务。而无论是 openResty 或者是 nginx 对于云原生 API Gateway 的需求是不能完全满足的。
当然了解 istio 的读者可能会问：
istio ingress gateway不也具有网关的功能吗 ？- 为什么没有用
nginx ingress controller？
首先，我承认基于 k8s ingress 实现的各种 ingress controller 功能越来越完善，如果我们没有用 istio 可能会采用这种方案，但我们使用了，那么再结合 k8s ingress 就会有如如何为服务网格选择入口网关[1]中说的如下问题：
K8s Ingress是独立在Istio体系之外的，需要单独采用Ingress rule进行配置，导致系统入口和内部存在两套互相独立的路由规则配置，运维和管理较为复杂。K8s Ingress rule的功能较弱，不能在入口处实现和网格内部类似的路由规则，也不具备网格sidecar的其它能力，导致难以从整体上为应用系统实现灰度发布、分布式跟踪等服务管控功能。
其次，没错 istio ingress gateway 除了基础的通讯功能之外，还有一些其他的应用层功能。但我们综合来比较下 k8s ingress、istio ingress gateway 和我们理想中的 API Gateway，就会发现它还不够完善,主要是对于 API 管理的这部分功能欠缺。
未来
前文已经对各种 API Gateway的实现方案进行了讨论，结论是在目前难以找到一个同时具备API Gateway和Isito Ingress能力的网关。那么再回顾一下我们的需求：
- 我们使用 istio
- 我们需要 API Gateway
所以，经过思考，我们未来的方案设计如下图：
- 仍然利用
istio ingress gateway作为入口 - 将
istio ingress gateway接到LB - 将
API Gateway纳入到istio cluster管理的范畴当中，即拥有sidecar proxy，可被istio控制面控制。API Gateway的选型很有可能使用云原生应用网关，如API SIX - 应用层微服务不会利用如 spring cloud gateway 编码一个服务网关
总结：使用API Gateway和Sidecar Proxy一起为服务网格提供外部流量入口。
还有没有问题？
有的，根据 Service Mesh 和 API Gateway关系深度探讨[2]上述方案的优势在于API Gateway和Sidecar独立部署，职责明确，架构清晰。但是，和Service Mesh使用sidecar被质疑多一跳会造成性能开销影响效率一样，API Gateway使用Sidecar也被同样的质疑：多了一跳……
对了多了这一跳，从整个架构每一段的网络耗时及其作用来看，这一跳多出的时间，几乎可以忽略不计。
性能如何？
作为 sidecar 的 envoy的性能应该是毋庸置疑了。至于istio ingress gateway虽然官方给出的数据也不错，但还是要在实践中观察。而作为 Cloud Native API Gateway 比如 API SIX 我对它有足够的信心，至少在我司现阶段业务体量以及未来百倍增长规模下都不会担心性能问题。
