共计 3446 个字符，预计需要花费 9 分钟才能阅读完成。
简介：下文将为你讲解云原生网关如何助你解决一系列痛点，优雅玩转云上微服务架构降级。
作者：百丈
随着云原生技术的倒退，微服务的架构选型也是突飞猛进。在 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 实现，完满兼容服务网格，技术大势所趋。
性能更丰盛
除了体系化的可观测能力，还有残缺的平安防护能力、丰盛的服务 / 流量治理能力、生产大规模实际的高可用教训以及精细化的 API 治理和扩大反对。
性能更强劲
压测后果：
- 云原生网关的 TPS 根本是 SpringCloud Gateway 的 2 倍，是 Zuul 1 的 5 倍。
- 云原生网关的 TPS 相比 Nginx Ingress 高出约 90%。
稳固更牢靠
自外部 2020.5 上线，云原生网关已在支付宝、钉钉、淘宝、天猫、优酷、飞猪、口碑等阿里各业务零碎中应用，两年以来可用率 100%，无任何故障。
历经 2020、2021 双 11 海量申请的考验，大促日可轻松承载每秒承载数 10 万笔申请，日申请量达到百亿级别。
重磅性能层出不穷
原文链接
本文为阿里云原创内容，未经容许不得转载。
