开发者学堂课程【K8s Ingress 选择 MSE 云原生网关解析：K8s Ingress 为什么选择 MSE 云原生网关？】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/965/detail/14886
K8s Ingress 为什么选择 MSE 云原生网关？
2. 功能更丰富
上图展示的功能一部分是已发布功能，一部分是待发布功能。
简单来讲可以分为下面几类：安全认证、服务治理、基础路由以及性能、可观测、可扩展、高可用。
（1）安全认证
例如在安全认证模块：支持HTTPS、 JWT认证、OIDC 认证、自定义鉴权认证、IP 黑名单、IDaaS 认证、Waf 防护。IDaaS 认证是阿里云提供通用的鉴权认证产品，可以对接许多三方的认证中心。以及会发布Waf 防护能力。
（2）服务治理
服务治理模块：微服务网关与流量网关二合一，流量网关主要负责安全认证以及全局的流量调度，微服务网关侧重于服务治理。因此服务治理主要分为四个小部分：服务发现、流量分发、服务探针、治理。服务发现下支持：K8s、Nacos、Eureka、DNS以及静态地址。流量分发下支持金丝雀、A/B 、自定义流量比例分发。服务探针下支持超时、重试、主动健康检测、服务 Mock 。治理下支持限流、熔断、降级。目前提供本地限流，之后会结合阿里云产品不断优化熔断、降级能力。
（3）基础路由
基础的路由能力模块，例如基础路由里支持Host / Path 、Header 、Parameter的参数去做路由以及跨域重写;负载均衡支持轮询、随机、最小请求以及一致性的Hash;协议目前主要集中在7层负载，例如支持HTTP、HTTPS 、 gRPC 、以及Dubbo3.0 。
（4）性能
性能重点为硬件加速，内核调优；
（5）可观测
可观测主要集成阿里云的Prometheus产品提供访问日志。Prometheus的监控以及报警；在可扩展方面，接下来会推出 Wasm 插件市场。
（6）高可用
高可用方面是源于集团内部网关已经运行两年以来积累的很多高可用经验。比如说提供了文件的Cache，推空保护以及过载保护等。
总之，第一，云原生网关可以提供丰富的安全认证能力，降低客户的安全接入成本。第二，网关可以做到直连后端的服务，打通了Nacos 、K8s等多种服务来源。并且率先支持 Dubbo 3.0的协议。第三，就是默认集成了阿里云应用实时监控服务 ARMS , 提供丰富的可观测数据。
3. 稳定更可靠
在高可用方面，主要分成三个部分：研发时、运行时、变更时。研此三个部分大概为阿里内部大概为十几年大促经验沉淀的主要部分。
（1）研发时
开发人员去提交code review 的时候，提到仓库之前，会去做一些自动的CI/CD的卡点检测。这些检测包括内存异常检测、多线程的竞争检测、静态代码分析检测单元与集成测试以及混沌测试。实际上现在的卡点多于举例。部分卡点没有被罗列说明实际功能多于列举功能。
（2）运行时
在运行时，第一，网关要提供过载保护。即根据网关的cpu 和memory 的负载情况调整，当负载过高的时候，拒绝接受新建的连接，保证自身持续运转，确保流量大时网关服务自身没有问题。第二，当网关服务发生异常时，例如网络异常，或其它原因异常重启，配置本地文件的cash，即在发生异常，可以迅速重启，并且从本地cash中把load配置 ，及时提供服务。
通过内部的故障与容灾演练压力测试以及大盘的监控与报警, 验证这些能力是否达标。
（3）变更时
任何一个软件，在运行的过程中，不可避免的要配置变更、配置发布。根据阿里内部积累的经验，大部分发生故障的场景为变更时的异常问题。避免出现上述问题的方法是首先要做配置的合法性的校验。其次做配置变更 Drain 机制。即配置真正做切换的时候，有一个变化的过程，不是立刻替代老的配置去，有一个平滑的迁移过程。
完善了优雅的升级以及监控报警。在变更时，通过就灰度与回滚机制以及大盘的监控报警验证这些能力是否达标。
网关先在内部上线，经过了两年验证的以及大数据验证后，推出商业化的云产品。目前看，网关从内部2020年的五月份上线，已在支付宝、钉钉、淘宝、天猫、优酷、飞猪、口碑等阿里各业务系统中使用。两年以来网关的可用率为百分之百，没有任何的故障。而且也经历了2020到2021年的双十一的海量请求的考验。大促的时候可以轻松承载每秒数10万笔的请求，日请求量达到百亿级别。
4. 即将上线的功能
（1） TLS 硬件加速
硬件加速目前对于Envoy英特尔公开有4种硬件加速方案。四个方案分成两个大类, Envoy标准的SSL使用的是 BoringSSL ，以及被熟知的 OpenSSL 。那么基于BoringSSL，有两种硬件加速的实现方案。基于OpenSSL也有两种的技术实现方案。硬件加速的最终选择的是方案二。方案二，利用CPU的SIMD机制通过AVX-512指令并行处理提升 RSA 以及 ECDSA 性能。内部使用1C2G机器测试，压测 HTTPS 。
由图可知，加速前，QPS是1004 / 秒；加速后， QPS达到了1873 / 秒。即在使用硬件加速之后，在1C2G的机器上使用HTTPS，QPS从1004/ 秒提升到1873/ 秒，提升率86%。更直观的指标是 TLS 的握手。 TLS 的硬件加速本质上是把 TLS 的握手of flow到CPU使用，利用CPU的SIMD机制去提升它的性能。加速前 TLS 握手， rt在313.84。加速后， TLS 握手已经降到了145.81毫秒。如果只依据 TLS 握手rt，使用硬件加速之后，提升率超过200%。
通过压测数据得知，开启TLS硬件加速之后，对于HTTPS 的性能有非常大的提升。目前的请求更推荐HTTPS的方式保证更好的安全性，是推出TLS硬件加速的非常重要的原因。
（2）内置 Waf
在真正的网络中使用网关时，最原始的流量先经过Waf的安全网关，到达之后会到流量网关，接着到微服务网关。
云原生网关，是流量网关跟微服务网关二合一。所以它的架构变成流量先过Waf 的安全网关，再过云原生网关。
未来预期部署模式能够进一步的简化，也就是如第三幅图所示，云原生网关内部直接内置一个Waf的模块，集成阿里云的Waf的云产品。由云原生网关直接提供Waf的防护能力，即用户的请求链路从原来要过三个网关节点——安全网关、流量网关、微服务网关，再到后端服务变为流量直接到云原生网关，云原生网关直接通往后端服务。
整个链路上此为最短方式，第一，网关的部署分层减少，因此用户运维会简单。第二，因为整个链路的节点减少所以rt 更好。第三，用户可以一站式的去使用安全网关、流量网关，、微服务网关，操作方便。
目前已在与阿里云的Waf团队对接，很快推出相关功能，内部集成Waf模块，用于对接阿里云的Web应用防火墙的产品,实现安全、流量、微服务网关的三合一，进一步的降低网关的使用成本。
（3）Wasm 插件市场
用户了解Wasm较多 ，此技术虽然诞生于浏览器上面，如今是被非常认可的向。第一，Wasm技术有可能是作为server list，成为docker 的下一代的基础。因为 Wasm runtime的启动时间要比docker 更短。同时提供一个沙箱的能力，能够做到很好的安全隔离。
Wasm初步支持在Evory和Istio上使用。但在开源社区目前更多是在探讨技术方向，或做简单的Demo 、Poc。目前在国内网关市场，没有任何一个网关产品推出Wasm 插件市场，能够去方便用户去扩展网关。在国外市场上，尝试去推出Wasm的插件市场。但目前没有过多的用户使用。
虽然目前应用Wasm 插件市场的很少，但是不可否认Wasm插件不管是网关，还是service match，都是一个已经被认可的技术方向。所以网关希望率先推出Wasm插件市场，满足用户对于网关的多样性扩展的诉求。因为网关从去年七月份公测到现在上线经历了一段时间,遇到很多用户咨询网关是否支持自己写一些扩展插件，扩展网关的能力，因此就推出Wasm的插件市场。
上图介绍Wasm的插件在云原生网关中，如何运作、安装配置的流程。
例如用户在云原生网关的控制台上安装配置一个插件，控制台会生成WasmPlugin资源。这个资源是由Istio定义的，Istio List & watch此资源后，会把资源通过xDS协议推送给Istio的agent。拿到这个配置之后，Istio的agent会把这个插件下载到本地。同时去把配置通过UDS的方式推送Evory，接着会挂载此插件。挂载之后，用户的请求进入，就可以使用 Wasm 插件。
目前Wasm插件更多停留在文章、demo或者是poc里。对Wasm插件做了很多的测试及验证。
目前有多个Wasm的runtime，例如v8、wavm以及wasmtime以及wamr 。具有四个runtime 的运行时。通过插件，全部使用C++语言去测试了一下4种runtime的rt以及cpu的耗时，例如v8，执行 C++的插件的rt耗时是63毫秒，消耗的cpu是8%。
如果只通过第一组数据，得知第二个Wasm runtime的数据是最好的。通过对比测试的数据，在Evory里，如果每增加一个work线程，或者每个线程当中增加一个Wasm的runtime进行对比， runtime消耗的内存增长。由此可知，v8消耗的内存增长只有两兆，远远低于其它三个runtime。
第三，对比多语言插件的运行情况。例如使用C++ 在v8运行时，它的rt消耗是63毫秒，cpu消耗是8%。Go消耗68毫秒，cpu消耗也是8%。使用Lua对比 ，Lua的消耗是164毫秒，cpu消耗20%。
因此基于测试验证，得出来初步结论， Wasm插件的性能实际优于lua的。并且通过Wasm runtime的综合对比，v8较好, v8在真正运行时rt不是最好，但结合内存消耗，综合得知v8的效果最好。
第一组数据当中，第二个runtime最好，但是在第二组测试数据中显示内存消耗反而是更大的。因此可能采用了类似于空间换时间的策略提升性能。因此综合上述数据可知V8的性能较好。
