开发者学堂课程【云原生网关开源、自研、商业化三位一体：下一代网关——云原生网关商业化发布】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/959/detail/14880
下一代网关——云原生网关商业化发布
内容介绍
一、MSE 云原生网关产品介绍
二、优势
三、适用场景
四、Demo 演示
MSE 云原生网关是兼容 K8s 标准的下一代网关产品，将传统的流量网关和微服务网关合并，降低了50%的资源成本，同时也支持 ACK 容器服务和 Nacos 等多种服务发现方式，同时支持多种认证登陆方式，快速构建安全防线。目前，云原生网关已经经过阿里巴巴内部多个事业部以及2020年双11大促海量请求的考验，低成本、高集成、高可用，安全可靠，经过几个月的公测，目前很多用户已经完成体验产品,已经在9月28号的零点正式商业化。云原生网关旨在为用户提供低成本、高效率的符合 K8S Ingress 标准的企业级网关产品。
一、MSE 云原生网关产品介绍：
1.网关分类的简介：
网关作为外部流量进入内部业务域的统一入口，基本可以分成两大类。
第一类为流量网关，它的职责主要是提供全局性并与后端业务无关的策略配置，例如可以使用 Nginx 部署面向外网的提供南北向流量调度的网关。
第二类为业务网关，业务网关是提供独立业务遇急的与后端业务紧耦合的策略配置，。目前的应用模式已经从单体架构演进到分布式微服务。在分布式微服务大背景下，业务网关又被称为微服务网关。例如，在 Java 体系中备受欢迎的spring Cloud Geteway。
目前通常在业务侧部署时，一个流量网关加微服务网关的两层网关，是经典的部署模式。由图所示，外部流量进入内部的第一道防线即流量网关，会提供南北向的流量调度以及安全防护。流量网关接收到外部请求，例如 HTPS 的请求卸载，请求进来后，转发至内部的微服务网关。微服务网关负责东西向流量的调度，以及服务治理。目前，是容器技术以及 K8S 主导的云原生时代，在云原生的大背景下面，需要思考：下一代的网关模式仍然是经典的两层架构吗？
2.下一代网关产品画像：
第一，完全拥抱云原生
云原生目前是被熟知的主流的软件架构演进的方向。云原生应该具有以下特性。首先应该支持标准的 K8s Ingress 、K8s Gateway API 以及 K8s 的 service 。
K8S Ingress：
K8S 的 Ingress 诞生的背景是为了标准化外部流量进入集群内部的规范，提供了一个标准的定义规范外部流量如何做路由配置进入集群内部。K8s 下集群内部的网络跟外部是隔离的，但 K8s Ingress 自身定义或者本身提供的路由能力较弱。基于 K8s Ingress 的规范，有许多 K8s Ingress 控制器的实现者，例如 NGS 、traffic 等， 控制器会针对标准的K8s Ingress 做一些扩展，甚至有控制器完全定义了一套自身的路由规范、流量规范。因为 K8s Ingress 标准的定义能力比较弱导致各个 Ingress 控制器的实现者，基于 Ingress 进行多种扩展，导致用户不知如何选择合适的 K8s Ingress 控制器。因此 K8s 社区提出了 在 Ingress 的基础之上，提供了更强大的一个路由策略配置的能力，重新命名为Getaway 的 API 。Getaway 的 API 目前在 α 阶段，但之后会成为 K8s 外部流量进入内部的标准的路由规范。
第二，拥抱开源
拥抱开源比较重要，拥抱开源的原因是软件发展需要开源，尤其基于云原生环境，每个用户不希望被某一个云厂商锁定，希望尽量使用开源的技术，因此下一代的网关产品应该基于开源的生态去构建，为解除用户担心厂商锁定的问题。
第三，策略配置
借鉴于例如传统的 NGS，策略配置生效时，依赖于自身的 reload 的机制。下一代网关产品，策略配置应该为热更新、不需要做 reload，并且此类策略配置应该是声明式、动态的、可编排。
第四，高集成
云原生网关，应该是高集成产品。因为网关作为外流量进入内部的入口，可以比作一个哨兵，应该具备丰富的能力。因此需要具备高集成的能力，因为网关自身不可能把所有的功能、能力都完成处理。
第五，高扩展。
作为网关产品，用户有一些跟自身业务相关的逻辑，希望放入网关中。因此下一代的网关产品应该支持插件化的扩展方式，方便的用户满足自定义的需求。
第六点，高安全。
作为网关产品，例如 Wat 、DDos 、HTTPS 证书的卸载、GWT。
第七，服务治理
基于分布式微服务的大背景，网关应该具备这个服务发现以及常规的限流，熔断降级的能力。
第八，丰富的可观测性：
可观测性重要的原因为随着分布式微服务的大背景，从之前单体应用到现在的微服务，微服务拆分的粒度越细越多会带来更多的优势。可以增加协同、提升开发效率，但会有出现问题的时，排查的难度会增大，运维的难度会加大。微服务中快速的去排查问题依赖于丰富的可观测性。因此可观测性是下一代网关产品应该具备的一个核心的能力。
3.云原生网关的产品：
云原生网关产品要解决的核心问题为下一个网关产品中用户不再需要两层的网站架构。换言之，本质上是不需要流量网关加微服务网关的两层架构。
两层架构主主要存在两个问题。第一资源消耗较高，第二运维部署复杂。因为此网关是从阿里巴巴内部的实践，通过使用测试得出的结论。阿里巴巴内部也具有一个流量网关，所有进入阿里的外部流量都会经过这个网关，因此流量很别大。为了保证流量的稳定性，流量网关不会做和业务域级别贴合的配置。很多业务不得不在流量网关后又自建，网关形成两层网关的模式。在阿里内部也是一直存在此问题。因此下一代网关除企业规模庞大外，其他是不需要再具备这种两层架构。例如阿里考虑高可用稳定性时可能会仍然需要两层架构，但是对于95%的企业用户，一层网络架构就完全能够满足用户的需求。一层网关就可以同时提供东西南北向的流量调度，以及安全防护、服务治理的能力。此为下一代的网关可能具备形态。
二、优势
1.云原生网关的优势主要有两点。
第一个优势是更经济。云原生网关实际上是把原来的流量网关跟微服务网关进行二合一的结合。例如传统流量网关个把 k8s 称为 K8s Ingress Gataway，用更多的会部署 Spring club gataway 形成两层架构。用云原生网关，这两层架构可以合二为一，由云原生网关同时提供东西南北向的流量调度，以及安全防护跟服务治理。因此对于用户侧由原来的两层网关架构变成一层，资源成本可以直接下降50%。
第二，两层网关变成一层，使运维部署更加简单。
2.更经济
基于分布式微服务大背景，丰富的可观测数据是对于业务是必要的核心诉求。云原生网关产品默认已经集成了阿里云的应用实时监控服务—— ARMS ，提供了丰富的日志，Tracing 以及监控的可观测数据。如图所示，有默认的全局看板、网关的实例级别的监控、业务的 TOP 榜以及网关的访问日治，并且云原生网关里面集成的能力对用户来说是完全免费的，即购买了云原网关之后，不需要再去额外购买其它的日志产品，就可以在网关查看可观测数据。
3.更安全
云原生网关支持 HTTPS , JWT , OIDC 的这些常规的认证。并且集成了这个 IDaas 的认证，IDaas 是阿里云的应用身份服务，简称 IDaas 。作用是可以帮助用户快速的构建认证中心，然后可以帮助客户实现例如支付宝、淘宝以及天猫等三方认证的登录。，因此云原生网关既提供传统的 HTTPS 的证书认证，包括 JWT 、OIDC 的认证，同时也支持灵活的自定义的 IDaas 的认证。总而言之，云原生就是可以提供丰富的认证健全能力，降低客户的安全接入成本。
4.更统一
由图所示，背景为利用云原生网关帮助钉钉了云上云下的互通。因为在上云的过程当中，不可能一蹴而就的把所有的服务全部搬到云上，而且混合云的场景应该是一种长期存在的场景，即有一部分核心的业务会私有云或者是内部，但是另外一些可售卖的服务会部署到云上的售卖区。在云上云下或者混合云的场景都使用云原生网关，即使用一套统一的架构，可以完全覆盖混合云的场景。
例图中是钉的服务是部署在云上的一个 APP，云原生网关部署在 MSE 的 VPC，因为云原生网关是 MSE 下的子产品，此为阿里巴巴内部的云原生网关。实现内部的服务，透明的调用云上的服务需要以下的操作。例如阿里巴巴内部的服务 A 要调用云上钉钉的服务C，那么云原生网关会 Mock 服务 C，把服务 C 注册到内部的注册中心中，因此服务 A 订阅服务 C时，得到云原生网关的IP 列表。此操作对调用方是透明的，而对于业务方，只知道调用方调用一个服务C，但实际服务器的请求会透明的发送到云原生网关，云原生网关转发到云上的原生网关，从云上的这个注册中心即Nacos 中订阅服务 C 的信息，得到IP 列表做选址路由并把它转给服务 C 。
为了保证云上云下互通时，通过 Dubbo3.0 里面的 tripple 协议，进行 MTLS 的双向认证。云上云下 RPC 服务互通时，其实对于调用方是透明的，所有的差异信息全部由云原生网关统一屏蔽掉了，而且云原生网关本质上是依托云社区的 Envoy 加 Istio 进行构建，并且紧贴开源，在开源的基础之上，做了很多公共增强，而且全程是通过开源的Dubbo 3.0的 IP 协议，由原生网关支持 Dubbo 3.0 Nacos，并且打通了阿里云容器服务的 ACK ，可以自动同步服务信息，因此云原生网关，在混合云的场景下实现了网关直连后端服务。
直连后端服务：K8s 中如果通过 k8s service 的调用方式，实际不是直联调 k8s service 首先 Class IP 通过域名的方式再调用后端。云原生网关是直接拿 service 的真实的IP直接将请求转给 Pod ，并且云原生网关打通了 Nacos，Eureka、K8s 等多种服务来源。如果在云上使用的是 Nacos 的注册中心，在阿里巴巴内部有自建的注册中心 ConfigServer 。ConfigServer是Nacos 的前身，两者略有差异。但差异全部由云原生网关屏蔽掉。并且在原生网关中率先支持了 Apache 的 Dubbo 3.0 的协议。
下一代网关产品应该是拥抱开源的，基于开源生态构建。云原生网关基于开源的 Istio 加 Envoy 这条生态构建，同时率先支持 Dubbo 3.0 的协议，在集团内部，钉钉的业务中全链路特都是通过 Dubbo 3.0的协议。
5.更稳定
云原生网关产品是从集团内部一步一步孵化出来，并不是全新的产品立刻在云上进行售卖。产品产生的大背景是为了和蚂蚁进行业务上协同互通，基于这个大背景，最初构建了云原生网关。云原生网关目前在阿里巴巴内部，在一些主要的业务场景，例如云上云下互通即跟钉钉互通的场景，以及跨域互通的即跟蚂蚁之间场景，以及优酷做南北向流量的场景。换言之在阿里巴巴内部，云原生网关如今已经覆盖了东西向、南北向全流量的调度。并且阿里巴巴内部已经在支付宝，钉钉，淘宝，天猫，优酷，飞猪，口碑等阿里各业务系统中使用。云原生网关已经经过了双11海量请求的考验，大促的时候，峰值可以轻松地承载每秒数十万米的请求，日请求量可以达到百亿级别。
三、云原生网关适用的场景
适用场景如图所示。首先南北向的流量是接受外部流量进入内部流量的。适用的典型场景第一是微服务注册到传统注册中心，并且直接对外提供服务。传统注册中心例如 Nacos、 Eureka 。
第二个场景，可以支持通过 K8s Service 来暴露服务的场景。第三个场景，可以支持传统的 ECS 应用的场景。云原生网关可以同时支持外部的注册中心也可以支持 K8s 标准的 service，即它的这 ETCD 的模式，同时也可以支持非 K8s 生态的 ECS 应用的方式。东西向可以支持混合云、多数据中心、多业务域的互通，例如钉钉的就是云上云下互通，是一个非常典型的混合云的应用场景。包括跟蚂蚁互通，其实是一个跨业务域之间的互通。云原生始网关产品，目前在这些实际的应用场景当中去大规模部署、应用。
四、Demo 演示
Demo 演示云原生网关一些核心的一个功能。
前期要准备后端服务所在的网络环境，比如说专用网络交换机，因为需要依赖于这样购买云原生网关实例。然后准备一些后端的 Demo 服务，配合一起测试观察使用的情况。
涉及到网关购买的网络信息，一是专有网络，一般后端服务都会部署在一个 VPC 内，只有对外暴露可能通过网关向南北向的关网暴露，自己网络端内会有一些不同的可能性，涉及到用交换机进行网络通讯的交互。网关是分布式的一个部署结构需要一个负载均衡，支持公网的负载均衡和私网负载均衡。
1.网关传统的应用场景
第一个是统一接入，对外公网对不同的端的形式，如浏览器、移动端、 IOT 或者一些开放平台其它的系统进行接入。统一接入对安全能力和应用的能力得到了集中的管控，进行保障，是高集成的一个能力。降低运维成本。
第二是中台的枢纽
随着公司发展提供不同业务，甚至请求多个域名，域名下有不同的路由规则管控。此情况下会有许多的业务形态对不同的这后端服务的中台，进行依赖，把中台抽离，让中台可以独立面对多个业务类型，例如有 C 端用户，B端用户是完全不同的行为，但是可能是共享同一套交易和营销的数据，此时需要统一管控，进行权限的交易和监控。
2.云原生网关能力视图
传统的流量网关和微服网关二合一，上面是接入层侧重于安全和证书健全的能力，下面是服务治理，以及可观测，高可用的这种实践经验，以及后期正在规划排期中的扩展的支持和 API 管理，满足后期用户对 API 管理和一些细节的能力支持吧。
Demo 的场景本身相对简单一点，支持多个服务来源。服务来源可以支持 Nacos ，也可以支持 K8s 的 SVC 的标准去暴露配置的路由关系。主要例举几个特点的功能点，按照常用的流程演示。
3.实际演示
通过事先购买好的一个网关可以看到基本概览里面有很多网关的信息，例如网络的购买条件。
结合场景，即将双11，业务也许会安排大促活动，因此会估算流量的高峰，以及压测的一些摸底，或者预备一些大促资源、制定一些预案或者降级的方案反复演练。网关接入了之后，可以通过提供的全局看板观察常看的全局的监控。可以通过时间筛选，看日常的流量情况和历史的活动的峰值，有参考，就可进行活动历史的评估。比如说的今年业务老板评估了是活动是十倍的流量峰值，可以根据数值做有效评估。
结合目前的负载，因为现在目前的负载不一定都用到，就像申请预算，也会要数据。当前内存、 CPU 使用啊，都是根据具体单个节点来看，而网关会多个节点。结合进行一些压测啊，计划这种水位的情况。开始会有一些压测的活动碰到某些比如说接口异常或请求比较多的情况，可能就需要看一些正常的日志。是自带集成也支持用户把这个日志投递到用户自己的 SSI 中。不做二次加工，可以不用投递。
发现接口比较异常的日志，如果有采样率高，会有一个 Trace ID 。
如果延迟比较高，看它整条链路可以分析到底是哪个环节的延迟比较高，或异常。随着那个监控的流量增加，可能会碰到就入口的带宽。带宽不足或者资源不足啊，都是算力不足。
带宽提供支持的是一个网关入口，网关入口所以说例如单个带宽有上限，可能要升级，这个升级过程中要平缓，前期可能要用一个新的 SLB 添加删除、关联、切换 SLB。可以选择其它有可用的 SLB 作为这个切换的操作。此操作只是做了它的大部分的基本的资源，当如果真正的的大促可能会超出预估，可能不支持十倍的流量，真正它可能十倍以上或者多少不可控的。有流量出现的话，可能就要做限流、预案或降级，这里提供了的一些限流的能力，就是网关自带的一些限流的能力。例如时间窗口的选择，它可以配置这样去做开启，执行限流的操作，这个是基本的一个限流能力。但后续会分装有更多的熔断和降级的整体的预案能力。
系统本身是保障这种压制和能力，还优化了一些性能，就是说五倍的资源可能扛住了十倍的流量。但最终还有一点可能会发现有安全风险，支持绑定不同的域名，选择协议，去强制 VIP 去做申请关联证书。这个因为可能业务产品会就是作为统一介入层，有很多业务的产品，比如不同的事业部、不同的部门，它可能不同的域名诉求。
涉及到可能对一些刷的流量，最常用的是 IP 或者黑名单的分析，在这里填一个 IP 或者 IP 段 ，那填一个就可以开启一个 IP 文件文件，也有这个能力。
当然更强一点，是有集成阿里云 Wolf 的能力，就是防火墙的规则是更复杂，更适合做一些流量的日统、管理会比较丰富，这个也是可以的。
这些安全和资源都配置完成之后，到时候可能会有一些日常迭代，比如说临近大促可能对这个紧急问题修复。这时候就在日常的路由，可能在原来的路由基础上，比如 com demo，但日常是这样，可能是需要一个 Header 头，需要一个是版本增加一个测试。新的这个路由会选择到新的这个服务里面去，就跟老的服务不会关联就起到一个灰度的作用。因此帮助在日常阶段减少变更的风险去观察。一些常规的大促的圆满完成。
还有更多的安全的其它的能力。为了用户的体验或什么的，用户的登录，在常规的有一些业务上，有自己的用户体系，也有他人的用户体系，就像第三方登录，就比较常见的这种微信登录，支付宝登录。这个可以，也集成阿里云上第三方认证的身份认证，可以快速的集成这个 IDaas ，就可以实现所有支付宝或者扫码钉钉这类的的认证机制，是一个比较便捷的一个能力。这个集成之后，整个生态效果会比较完整，可观性、可观测、监控以及高可用这些都会实现。
