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

简介：下文将为你解说云原生网关如何助你解决一系列痛点，优雅玩转云上微服务架构升级。

作者：百丈

随着云原生技术的发展，微服务的架构选型也是日新月异。在 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 的时候采用微服务架构我们碰到哪些问题？

拆分了微服务后相应的构建部署工作量开始翻倍，运维压力急剧提升；
随着业务迭代，微服务之间调用链路变的复杂，强弱依赖不清晰，故障/瓶颈排查困难；
不同业务团队使用异构的服务框架或技术栈，相互依赖集成成本增加。

通过合理的拆分服务可以降低协作成本及控制变更风险，这是微服务思想带来的价值，然而随之而来的也有巨大的治理难度和运维压力。

不过 Kubernetes 以其完整的网络、服务、负载均衡的标准定义似乎解决了我们不少问题。

统一的服务定义及服务发现机制

得益于 Kubernetes 的网络模型和 Pod 标准，Kubernetes Service 可以将运行在一组 Pods [2]上的应用程序抽象为网络服务（Kubernetes 微服务），你无需修改应用程序即可使用不熟悉的服务发现机制。Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名，并且可以在它们之间进行负载均衡。

userspace 代理模式：

iptables 代理模式：

IPVS 代理模式：

负载均衡 Ingress 标准

Ingress 公开了从集群外部到集群内服务的 HTTP 和 HTTPS 路由。流量路由由 Ingress 资源上定义的规则控制。

有了容器及 Kubernetes 的运维调度能力及标准服务、负载均衡基础，微服务架构可以往更高的层次发展，满足更多技术场景。

技术趋势及痛点

云原生时代的高要求和可选择

Kubernetes 是好，同时其庞大的体系和众多的概念标准也给技术从业者带来了学习成本，DevOps 似乎比之前多了不少的工作量，好在云原生时代，商业化产品满足高要求的同时给了我们更多的选择。

上图展示了在代码中通常包括三部分:业务代码、三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码;“三方软件”是业务代码中依赖的所有三方库，包括业务库和基础库;“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。

从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

精细化运营的需求

微服务架构的一路发展过来，从简单的拆分服务到服务发现机制，再到支持 Sidecar 代理治理流量，最终的形态是什么样的？或者我们技术需求是怎么样？

简单的拆分

服务发现机制

Sidecar代理流量

云原生架构成熟度模型 & API 安全质量报告

在云原生时代，云原生微服务体系将充分利用云资源的高可用和安全体系，让应用获得更有保障的弹性、可用性与安全性。应用构建在云所提供的基础设施与基础服务之上，充分利用云服务所带来的便捷性、稳定性，降低应用架构的复杂度。云原生的微服务体系也将帮助应用架构全面升级，让应用天然具有更好的可观测性、可控制性、可容错性等特性。

我们可能需要类似上述一个模型描述架构在服务化能力、弹性能力、可观测性及自动化能力等维度的成熟度，虽然这样比较全面，似乎不太适合总结沟通。如果用简单概念来描述，笔者总结几个阶段层次：

极致弹性：应对突发流量，弹性能力是重要的手段，是否极致对应着故障的恢复速度，弹性能力有时候还依赖于服务化程度。
可观测体验：能够应对突发流量后开始关注性能优化及故障处理，体系化的可观测体验及指标数据对我们的治理工作至关重要。
故障无感自愈：能够 360 度发现问题就能总结规律制定常用的预案及检查机制，常规故障即可自动化恢复。

最重要的结果衡量还有我们用户的体验，比较好代表用户的应该就是 API 安全质量报告，如果 API 的可用率提升了，如果 API 的响应 RT 减少了，这显然说明架构升级/治理给我们带来了巨大的价值，满足精细化运营的需求。

架构升级的痛点

架构升级（治理）能带来的价值有目共睹，甚至我们也有了相关架构持续演进的闭环方法论。

网关作为技术架构的门面，在架构整体成熟度的度量及可持续演进集成兼容等方面至关重要，以网关作为架构治理升级的切入口是个不错选择，但是，有些痛点还是实实在在的摆在我们面前：

怎么发现当前微服务架构的问题？
Kubernetes Ingress 后面再部署微服务网关影响性能吗？
用户登录鉴权逻辑能否集中处理/升级？
多个 Kubernetes 集群是否可以共用一个网关？
同时使用 SpringCloud 和 Kubernetes svc 怎么灰度？

此处只是稍作举例，实际的痛点大家深有体会，开源产品往往和我们的业务需求不是那么匹配，接下来看云原生网关是如何解决这些问题的。

云原生网关的优势

云原生网关=流量网关+微服务网关+？

云原生网关从开始就一直在强调，将流量网关（Kubernetes Ingress、Nginx）和微服务网关（Spring Cloud Gateway、Zuul 网关等）二合一，降低 50%资源成本，同时缩短了请求时间，降低运维复杂度。

仅仅只是二合一显然不够满足我们的期望，看看它还有什么：

开箱即用， 默认支持全局看板、实例监控、日志检索、业务 TOP 榜、日志投递、链路追踪及报警管理等体系化可观测能力，让你轻松了解微服务及 API 质量情况。
卓越的性能，详见下文性能更强劲。
支持 Ingress 标准，Kubernetes 体系首选网关产品。
多种服务发现，支持 ACK 容器服务、Nacos 等多种服务发现方式，可以同时接入多个 Kubernetes 集群。
基于 envoy+istio 实现，完美兼容服务网格，技术大势所趋。