开发者学堂课程【微服务用户为什么要选择云原生网关?：微服务用户为什么要选择云原生网关?】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/964/detail/14885
微服务用户为什么要选择云原生网关
内容介绍：
随着云原生技术的发展，微服务的框架日新月异。在K8s运维的时代，云上安全降本、提效、精细化运营等方面要求更高、供选择的产品也越多。
但部分网关缺少服务发现和容器服务能力，性能上也差强人意，在可观测性和安全方面都需要开源方案，需要极强的二次开发和计算能力。而且往往提供的集成的开发缺乏自定义业务意义，缺乏标准化。在后续的架构升级上成为短板，阻碍整体的技术发展。简单看一下微服务网关是怎么解决这些痛点的。
一、 微服务（网关）的发展
二、技术趋势及痛点
三、云原生网关的优势
一、微服务（网关）的发展
1. 微服务发展大事记
2014年Martin Fowler系统性的整理了微服务的概念，比较严谨的定义微服务。但在它之前也出现微服务架构的说法，但它是第比较系统性的，之后使用手机的微服务，各类的开源和商业的支持就如雨后春笋般涌现。
需要特别关注的有两点：
第一，从历年来看，起初微服务不太成熟逐渐走向成熟之后，微服务从单体的支持走向了平台、解决方案的发展方向。比如 SpringCloud解决方案、Kubernetes体系 。
SpringCloud 有不同的组件：vr、服务框架、服务配置中心，以及熔断降级的能力。K8s从整个运维体系包括了docker容器或者部署，重新定义架构标准体系，它是更完整的体系。
第二，从2018、2019年开始，用户随着云的发展，开源的商品和商业化的知识融合的更加紧密。
国外的利、亚马逊大多也是如此发展。云原生技术的发展让技术从业者有了更多的选择：选择开源，云上的商业化支持。它们可能是同标准，实践起来却截然不同。
2. 微服务网关的变化
2013年开源的Zuul 出现，内部使用可能更早，微服务概念相对较早出现。Zuul ，是早期的网关，开源负载均衡组件容易操作。
早期的Zuul性能上基于java，同步性稍弱，但它也相当流行。随后2015年出现Kong，2016年出现SpringCloud Gateway。最近就是 Ambassador，是开源的支持ingress 标准，与 Istio 无缝集成的网关。
所以发现，随着微服务逐步向平台发展的同时,网关出现了高集成的需求，例如Kong 早期是单个的组件，SpringCloud Gateway可能是整个微服务解决方案的门面，之后更关注于部署平台以及服务网关的计算，这是微服务网关变化的总体方式。
所以对应趋势，云原生网关应运而生。而且云原生网关从兼容性或者性能方面，不仅集齐它们的优点，而且功能更丰富，性能更强劲，安全稳定性更好。
3. K8s 容器服务
将K8s容器服务单独提出来，因为微服务最早的本质是通过合理的拆分服务降低协作成本，以及控制代码变更或者迭代的变更风险。没有容器服务、K8s调度之前的部署相对困难。
由于服务拆分，运维难度较大。而且微服务之间调用链路比较复杂或者链路较长时，带来了很大的治理难度。甚至在全链路或者做压测活动时，无法区分强依赖、弱依赖以及瓶颈，带来了巨大的治理难度和业务压力。
但是K8s在运维层面上有相对完整的网络定义。因为它在 Pode中有内网的定义，拥有Pode标准，之后也有服务和负载均衡的标准。Service和Evory的标准定义，极大的降低微服务使用的门槛，可以更好的去使用微服务，但是也带来了服务成本。
二、技术趋势及痛点
1. 云原生时代——高要求和可选择
现在是使用云上的产品（公有云或者专有云）的时代。云原生可能相比十年前的微服务，技术要求公告和产品选择更多，需要在技术发展上更精细化。
（1）弹性收缩
在云原生的时代，既然已经是云原生，可能想到云的弹性收缩，弹性是必要的条件。
（2）免运维
免运维针对一些托管产品。
业务代码上传统架构和云原生架构的差别：用户只针对业务代码编写业务运维。其它像非功能性的能力或者第三方软件或者中间件，都可以找到IaaS和PaaS的支撑码，是实现免运维的要求。
如果是亲自托管的产品，稳定的发展需要长期的经验和团队的保障。
（3）成本可控
因为云上有账单栏或者计费要清晰、一目了然，因为云上用户高要求和追求更多选择。
在这些基础条件上，更多精细化运营的需求才能得到满足。
2. 精细化运营需求
（1）极致弹性
云上追求极致的体验，需要极致的弹性应对突发流量。健康码如果没有极致的弹性，会导致使用者过多需求得不到满足，疫情期间亮码时很多健康码崩坏，不能使用健康码。
极致弹性有时候与微服务架构相关。云原生时代，微服务如果没有较好的服务，本身能力水平太差，导致无法计算部署架构。但现在微服务不过关，在不同的维度有不同的前提条件（如下图），可能在满足极致弹性前，服务技术要达标。
（2）可观测体验
极致弹性中，日常碰到故障或者故障定位或者性能瓶颈的排查，需要可观测体验。
可观测体验，经常出现的问题是观测的指标项缺失或者中间环节不够全面。而且有可能服务化或者治理的手段依赖于部分可观测的指标，极致弹性依赖于服务化的状态或者治理的诉求依赖可观测的指标。可观测拥有治理后，可以对问题故障摸索出规律，形成预案：针对突发流量要扩容，预防攻击流量使用安全策略去蔽。对于突发变化，可以及时切掉流量去止损，回滚，可观测和自己的能力两个业务就可以做到故障自动的恢复和治愈。
（3）API安全质量报告
拥有这些就能达到云上的应用和业务达到比较高阶的程度，会有很多的切流能力或者自动化能力，但最终的效果需要用户体验。用户感受API的质感，例如API的错误率降低，或者整体延迟降低。延时降低可能对整条链路的强弱依赖或者非必要的依赖、治理后重复调用优化请求，演示就降低了，故障的自愈能力提升了它的可用性，API质量就提升了。可能后续还有投入产出的成本。总体来看它有API质量或者说衡量整个精细化运营的效果，是在云上比较理想化的诉求。
阿里云官网上有更成熟、更详细的定义，个人总结的就是以下几点：极致的弹性有时在应对突发流量也是稳定手段，也能做到自愈；所有衡量架构或者升级的能力可能都需要API 安全质量报告。所以说网关作为整个架构的门面，度量的能力和功能至关重要。
