微服务用户为什么要选择云原生网关?_微服务_技术课程_开发者学堂

阿里云
为了无法计算的价值
打开APP
阿里云APP内打开
开发者社区> 开发者学堂> 全部课程> 微服务用户为什么要选择云原生网关?

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

1课时 |
131人已学 |
免费
课程介绍
课程大纲:
1、微服务(网关)的发展
2、技术趋势及痛点
3、云原生网关的优势

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

 

内容介绍:

随着云原生技术的发展,微服务的框架日新月异。在K8s运维的时代,云上安全降本、提效、精细化运营等方面要求更高、供选择的产品也越多。

但部分网关缺少服务发现和容器服务能力,性能上也差强人意,在可观测性和安全方面都需要开源方案,需要极强的二次开发和计算能力。而且往往提供的集成的开发缺乏自定义业务意义,缺乏标准化。在后续的架构升级上成为短板,阻碍整体的技术发展。简单看一下微服务网关是怎么解决这些痛点的。

 

一、 微服务(网关)的发展

二、技术趋势及痛点

三、云原生网关的优势

 

一、微服务(网关)的发展

  1. 微服务发展大事记

2014年Martin Fowler系统性的整理了微服务的概念,比较严谨的定义微服务。但在它之前也出现微服务架构的说法,但它是第比较系统性的,之后使用手机的微服务,各类的开源和商业的支持就如雨后春笋般涌现。

 

需要特别关注的有两点:

  • 从历年来看,起初微服务不太成熟逐渐走向成熟之后,微服务从单体的支持走向了平台、解决方案的发展方向。比如 SpringCloud解决方案、Kubernetes体系 。

SpringCloud 有不同的组件:vr、服务框架、服务配置中心,以及熔断降级的能力。K8s从整个运维体系包括了docker容器或者部署,重新定义架构标准体系,它是更完整的体系。

 

  • 从2018、2019年开始,用户随着云的发展,开源的商品和商业化的知识融合的更加紧密。

 

国外的利、亚马逊大多也是如此发展。云原生技术的发展让技术从业者有了更多的选择:选择开源,云上的商业化支持。它们可能是同标准,实践起来却截然不同。

 

 

 

  1. 微服务网关的变化

 

2013年开源的Zuul 出现,内部使用可能更早,微服务概念相对较早出现。Zuul ,是早期的网关,开源负载均衡组件容易操作。

早期的Zuul性能上基于java,同步性稍弱,但它也相当流行。随后2015年出现Kong,2016年出现SpringCloud Gateway。最近就是 Ambassador,是开源的支持ingress 标准,与 Istio 无缝集成的网关。

所以发现,随着微服务逐步向平台发展的同时,网关出现了高集成的需求,例如Kong 早期是单个的组件,SpringCloud Gateway可能是整个微服务解决方案的门面,之后更关注于部署平台以及服务网关的计算,这是微服务网关变化的总体方式。

 

所以对应趋势,云原生网关应运而生。而且云原生网关从兼容性或者性能方面,不仅集齐它们的优点,而且功能更丰富,性能更强劲,安全稳定性更好。

  1. K8s 容器服务

 

 

将K8s容器服务单独提出来,因为微服务最早的本质是通过合理的拆分服务降低协作成本,以及控制代码变更或者迭代的变更风险。没有容器服务、K8s调度之前的部署相对困难。

 

由于服务拆分,运维难度较大。而且微服务之间调用链路比较复杂或者链路较长时,带来了很大的治理难度。甚至在全链路或者做压测活动时,无法区分强依赖、弱依赖以及瓶颈,带来了巨大的治理难度和业务压力。

但是K8s在运维层面上有相对完整的网络定义。因为它在 Pode中有内网的定义,拥有Pode标准,之后也有服务和负载均衡的标准。Service和Evory的标准定义,极大的降低微服务使用的门槛,可以更好的去使用微服务,但是也带来了服务成本。

二、技术趋势及痛点

  1. 云原生时代——高要求和可选择

现在是使用云上的产品(公有云或者专有云)的时代。云原生可能相比十年前的微服务,技术要求公告和产品选择更多,需要在技术发展上更精细化。

(1)弹性收缩

在云原生的时代,既然已经是云原生,可能想到云的弹性收缩,弹性是必要的条件。

 

(2)免运维

免运维针对一些托管产品。

业务代码上传统架构和云原生架构的差别:用户只针对业务代码编写业务运维。其它像非功能性的能力或者第三方软件或者中间件,都可以找到IaaS和PaaS的支撑码,是实现免运维的要求。

如果是亲自托管的产品,稳定的发展需要长期的经验和团队的保障。

 

(3)成本可控

因为云上有账单栏或者计费要清晰、一目了然,因为云上用户高要求和追求更多选择。

在这些基础条件上,更多精细化运营的需求才能得到满足。

 

  1. 精细化运营需求

(1)极致弹性

云上追求极致的体验,需要极致的弹性应对突发流量。健康码如果没有极致的弹性,会导致使用者过多需求得不到满足,疫情期间亮码时很多健康码崩坏,不能使用健康码。

极致弹性有时候与微服务架构相关。云原生时代,微服务如果没有较好的服务,本身能力水平太差,导致无法计算部署架构。但现在微服务不过关,在不同的维度有不同的前提条件(如下图),可能在满足极致弹性前,服务技术要达标。

 

 

(2)可观测体验

极致弹性中,日常碰到故障或者故障定位或者性能瓶颈的排查,需要可观测体验。

可观测体验,经常出现的问题是观测的指标项缺失或者中间环节不够全面。而且有可能服务化或者治理的手段依赖于部分可观测的指标,极致弹性依赖于服务化的状态或者治理的诉求依赖可观测的指标。可观测拥有治理后,可以对问题故障摸索出规律,形成预案:针对突发流量要扩容,预防攻击流量使用安全策略去蔽。对于突发变化,可以及时切掉流量去止损,回滚,可观测和自己的能力两个业务就可以做到故障自动的恢复和治愈。

 

(3)API安全质量报告

拥有这些就能达到云上的应用和业务达到比较高阶的程度,会有很多的切流能力或者自动化能力,但最终的效果需要用户体验。用户感受API的质感,例如API的错误率降低,或者整体延迟降低。延时降低可能对整条链路的强弱依赖或者非必要的依赖、治理后重复调用优化请求,演示就降低了,故障的自愈能力提升了它的可用性,API质量就提升了。可能后续还有投入产出的成本。总体来看它有API质量或者说衡量整个精细化运营的效果,是在云上比较理想化的诉求。

阿里云官网上有更成熟、更详细的定义,个人总结的就是以下几点:极致的弹性有时在应对突发流量也是稳定手段,也能做到自愈;所有衡量架构或者升级的能力可能都需要API 安全质量报告。所以说网关作为整个架构的门面,度量的能力和功能至关重要。

 

  1. 架构升级的痛点

 

 

痛点是产生需求后想要达到理想化的状态或者上云下云、微服务申请时会碰到哪些问题。

第一点是怎么判断、发现当前微服务架构存在的问题。定性层面上,可能一方面对照前面的成熟度或者能力判断服务或者谈可观测性的指标制度是否全面。所以如果网关作为技术架构门面在整体架构的成熟度对API 报告进行梳理,就能发现真正需求。

比如说API服务涉及核心链路或者非核心链路。还有在升级的过程中,作为加工设计师可能会很难去做选题。主要是因为中间件或者开源支持的东西并不是完美契合的场景。像网关作为整体架构比较核心的产品,它向后兼容各种微服务的整个体系、中间件。但向前对应端上,对安全要做保障统一的防护。它的兼容和集成度也要求较高。

 

痛点主要列举了下面几个:

第一,怎样定义当前服务有哪些问题。如果发现问题,通过网关层面API安全质量报告,是否可以着手去改善。

第二,发现用户升级,用户规模变大,而健全体系比较落后、安全漏洞较多,怎样升级用户的登录系统,一般在网关集中处理登录认证权限能力,比单个散落在服务里处理更有效。

第三,介入ACK之后,出现Ingress ,即 ACK定义的标准。如果说刚开始使用gateway 或者其它不是K8s的标准,那必然会迁移K8s Ingress,后面再带Wlf网关,变成两层网关。它不仅带来了资源的浪费,还带来了网络消耗,增加了运维的难度。

第四,在部署多个K8s或者集群部署时,想共用网关去报入或者如果在迁移的过程中为了不同的部门,同时使用SpringCloud 或者K8s svc。

因为进入了 K8s 领域,SpringCloud 和K8s svc 如何互通,在迁移过程中怎样相互灰度,都是涉及到涉及到理想状态可能面临的问题。所以在整个架构持续演进闭环过程中,需要解决一系列的痛点。

 

 

 

三、云原生网关的优势

  1. 开箱即用,痛点不复存在

(1)2合1介绍

 

首先看一下微服务网关在之前的产品宣传上介绍2合1的原因。比较直观的理解是传统的接入层的网关,或者说K8s Ingress层可能记录证书和安全统一,不太具备较多的治理能力。更多的治理能力放在微服务网关层,必然形成了两层网络架构。最极端的检验是把两层合为一层,既符合K8s Ingress的标准,能够接入才能绑定证书、安全认证。另外,它有丰富的服务治理、流量治理的能力。总体来说,在2合1的过程中体会增加的优势。

(2)开箱即用可观测性

开箱即用云产品,最主要是有很大的高集成的能力。开箱即用可观测性默认支持全局看板、视频监控、日志检索、业务排行等套板,还有日志投递、链路追踪和报警管理。从网关链路开始直至一整串体系化的可观测角度都被考虑到,可以快速了解到微服务以及API质量的情况,网关的任何环节链路出现问题,都能在网络层面上体现,这是开箱即用可观测性。

其它的安全认证扩展也是开箱即用的范围。

(3)卓越的性能

卓越的性能是在后面的性能对比下,后发优势再加上软硬件结合的能力、业界加个人能力,性能较高。

(4) Ingress 标准

在微服务发展的后端,K8s体系更降低了微服务的门槛,帮助用户精细化运营。它的负载均衡,Ingress 是标准和支持,也是往外发展一大特色。它在云端环境上是国内支持最早的。

(5)多种服务发现

现在针对用户传统的java技术或者其它技术上使用注册配置中心体系的,进入兼容的传统服务发现方式,同样支持现在K8s 、 Service 等多种方式,默认支持载固定的地址和静态地址、DNS,有多种服务发现。

(6)兼容服务网络

基于Evory + Istiod 的进程加速,金融服务网的在未来的趋势下金融和技术能力是非常强的。

 

  1. 功能更丰富

云原生网关3个特点:功能更丰富,性能更强劲还有稳定更可靠。

 

可以看到在首页上最顶端的设计安全的能力,WAF,是应用防火墙。往往在云上的用户可能购买了网关或者其它的产品,还需要额外购买WAF,因为是两个不同的产品。但云原生网关已经推出了有内嵌式的WAF模块,不必购买两个产品,而且在部署运维或者网络消耗会更低,它默认携带DDos 防御。

 

云原生网关支持多域名能力,绑定多个域名、多个证书满足分业务线的需求,有丰富的库支持和认证、健全的能力,也支持集成自定义或自建,不需要集成文件,即公司原来内部有旧例,可以通过衍生扩展模式来接受,兼容性较好。

访问控制不使用WAF,也可以直接处理简单的状况。这是对外的传统接入时才会有的安全能力。

体系化的可观测,之前列举很多体系化的例子,这里列的比较少,就像日志投递没有单独说明,用户可以去产品页上提示。

内部保障是可用性的保障是阿里云的实践经验,对异常节点都能取得容灾和过载保护,有内部充分的时间经验保障。

服务治理不仅是微服务网关和流量网关二合一,最主要有更强劲的服务治理能力,不仅支持多个服务来源: ACK容器服务还有其它的服务,同时也支持接入多个K8s取向,K8s Ingress标准的有集群,NGS,可以做多个K8s用于同一个云原生网关,不需要单独建Ingress。

额外治理的能力是限流降级、标签路由等,标签路由场景可能有金丝雀、揽月都可以支持。轮询、负载均衡的策略和超市从事流量治理能力,可以自定义。这是微服务能力比较强劲的情况。

如果有新用户针对业务自定义的扩展能力提出问题,那即将推出的Wasm插件,可以让其它插件扩展,支持用户自己去介入。后面跟踪细化了今年上半年会的API管理,针对API的整个生命周期文档,它的moke最终会产出自己业务的API推荐的SAR或者质量报告,可以看出整个架构治理或者升级时的数据。

 

  1. 性能更强劲

可能比较关注的是说对比前面列举的几个网关:Kong、Nginx Ingress、ZUUL1、SpringCloudGateway。

压测对比下可以看到,不同字符节下云原生网关相对资源的TBS是SpringCloudGateway的2倍,是ZUUL1的5倍。

ZUUL1属于早期的网关,性能相对差一点。但比SpringCloudGateway高2倍,比Nginx Ingress的性能高出90%,也将近是2倍。这种情况是没有针对域名,没有对证书开启硬件加速。

 

  1. 服务更可靠

 

 

这个是针对整个内部运营产品或者说整个高可用体系,在研发时、运行时、变更时的制作能力,可能大部分用户看不见的功能。

网关从内部2020年5月上线,2021年在支付宝、钉钉、淘宝、天猫等很多业务系统,两年来可用率百分百,没有任何故障。而且历经2020年、2021年两次双十一的海量请求的考验,大促日每秒能承载10万笔请求,每天的访问量达到百亿级别。所以云原生网关拥有大量的生产经验,产品的稳定性有保障。

 

  1. 重磅功能——层出不穷

(1)TLS硬件加速

TLS硬件加速是中间件产品为数不多的软硬件结合能力比较强的产品。针对证书卸载、TLS的握手时延、cpu层面的优化,从原来测试的报告可以看到,TLS的握手时延从313毫秒降到148毫秒,提升约86%。有些新购的用户可以在购买页去勾选选项,去测试能力。

(2)内置WAF

在前面提到的WAF,刚开始是独立在外部,云原生网关把它集成在流量和微服务网关二合一,未来可能是安全、流量、微服务网关三合一。传统对外的网关可能更需要这种模式。如果说内网没有进一步需要,可以不开启这样的模式,即可以按需开启。

(3)插件市场

插件市场近期会推出Wasm之类的插件类型,可以帮助自定义网上的业务逻辑,网关统一处理,集中上下文,可以降低成本。

 

  1. 优惠活动

云原生网关现在预付费7折优惠。

没有体验过云原生网关的用户可以在产品首页上,点击免费体验恢复能力的链接试用一下,也可以一步步操作,了解大致的基础功能,再结合业务的需求去购买。