微服务用户为什么要用云原生网关

随着云原生技术的发展，微服务的架构选型也是日新月异。在 Kubernetes 重塑运维体系的云时代，我们在安全、降本提效、精细化运营等方面都有了更高的要求和更多的选择。曾经关炙手可热的 Zuul/SpringCloud Gateway/Kong 等在其网关位置上开始显得力不从心。它们欠缺发现容器服务的能力，性能可能不如 Nginx Ingress，可观测、安全等方面都需要二次开发再集成，这些关键短板都阻碍着技术发展。今天来看云原生网关如何助你解决这些痛点，优雅玩转云上微服务架构升级。

微服务（网关）的发展

微服务发展大事记

随着 Martin Fowler 在 2014 年的文章总结梳理 [1]“微服务”概念开始逐渐深入人心。之后各类开源或商业支持如雨后春笋般涌现，到如今笔者按年份简单整理了每年的大事记，其中两个变化值得大家需要关注：

1. 微服务从单点支持向平台解决方案发展，例如 SpringCloud 解决方案、 Kubernetes 体系。
2. 开源和商业产品融合得更加紧密，云原生的发展让技术从业者有了更多的选择。

微服务网关的变化

笔者按时间整理了几个简单对比：

1. 2013 ZUUL：Netflix 开源的负载均衡组件，简单易上手，不过早期的 ZUUL 1 性能上限稍低。
2. 2015 KONG：基于 Nginx 的 API 网关，性能强劲，Lua 国内开发者相对较少。
3. 2016 SpringCloud Gateway：网关开始作为整个微服务解决方案的门面出现。
4. 2019 Ambasssador（现在更名 Emissaey-ingress）：支持 Kubernetes ingress 标准，且与 Istio 无缝集成。

微服务逐步向平台解决方案发展的同时，对网关的集成能力也有了更高的需求。这也是我们看到了这个趋势，云原生网关应运而生，而且云原生网关不仅集齐了他们的优点，而且功能更丰富、性能更强劲、稳定更可靠。

Kubernetes 微服务

这里为什么单独提 Kubernetes 微服务？这需要回到没有 Kubernetes 的时候采用微服务架构我们碰到哪些问题？

1. 拆分了微服务后相应的构建部署工作量开始翻倍，运维压力急剧提升；
2. 随着业务迭代，微服务之间调用链路变的复杂，强弱依赖不清晰，故障/瓶颈排查困难；</