随着云原生技术的发展,微服务的架构选型也是日新月异。在 Kubernetes 重塑运维体系的云时代,我们在安全、降本提效、精细化运营等方面都有了更高的要求和更多的选择。曾经关炙手可热的 Zuul/SpringCloud Gateway/Kong 等在其网关位置上开始显得力不从心。它们欠缺发现容器服务的能力,性能可能不如 Nginx Ingress,可观测、安全等方面都需要二次开发再集成,这些关键短板都阻碍着技术发展。今天来看云原生网关如何助你解决这些痛点,优雅玩转云上微服务架构升级。
微服务(网关)的发展
微服务发展大事记
随着 Martin Fowler 在 2014 年的文章总结梳理 [1]“微服务”概念开始逐渐深入人心。之后各类开源或商业支持如雨后春笋般涌现,到如今笔者按年份简单整理了每年的大事记,其中两个变化值得大家需要关注:
- 微服务从单点支持向平台解决方案发展,例如 SpringCloud 解决方案、 Kubernetes 体系。
- 开源和商业产品融合得更加紧密,云原生的发展让技术从业者有了更多的选择。
微服务网关的变化
笔者按时间整理了几个简单对比:
- 2013 ZUUL:Netflix 开源的负载均衡组件,简单易上手,不过早期的 ZUUL 1 性能上限稍低。
- 2015 KONG:基于 Nginx 的 API 网关,性能强劲,Lua 国内开发者相对较少。
- 2016 SpringCloud Gateway:网关开始作为整个微服务解决方案的门面出现。
- 2019 Ambasssador(现在更名 Emissaey-ingress):支持 Kubernetes ingress 标准,且与 Istio 无缝集成。
微服务逐步向平台解决方案发展的同时,对网关的集成能力也有了更高的需求。这也是我们看到了这个趋势,云原生网关应运而生,而且云原生网关不仅集齐了他们的优点,而且功能更丰富、性能更强劲、稳定更可靠。
Kubernetes 微服务
这里为什么单独提 Kubernetes 微服务?这需要回到没有 Kubernetes 的时候采用微服务架构我们碰到哪些问题?
- 拆分了微服务后相应的构建部署工作量开始翻倍,运维压力急剧提升;
- 随着业务迭代,微服务之间调用链路变的复杂,强弱依赖不清晰,故障/瓶颈排查困难;</