开发者学堂课程【玩转容器服务进阶课程：如何在 ACK 中使用 MSE Ingress】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1079/detail/15852
如何在 ACK 中使用 MSE Ingress
内容介绍：
一、 Ingress 趋势
二、 MSE Ingress 优势
三、 MSE Ingress 实践
四、 MSE 产品定位和竞争力
五、总结
六、一图了解 MSE 竞争力
七、集中回答问题
今天分享的题目是如何在 ACK 中使用 MSE Ingress。作为 Nacos 的创始人，现在负责整个 MSE ，今天分享Ingress 的发展趋势，然后是 MSE Ingress 的优势跟实践。
一、 Ingress 趋势
首先介绍一下 Ingress 的一个趋势。因为 Ingress 是一个社区的标准，然后在这个标准上有 Ingress 的一个实现。因此今天按照标准实现分别讨论一下 Ingress 的现状和趋势，最后介绍一下 Ingress 的云产品的一些趋势。
1. Ingress 标准现状
首先给看一下左边这张图，左边这张图是按照入口网关和内部网关，two C的和 two B 的，然后把网关分成了四个象限，大家对 ACK 最熟知的可能是 Ingress 流量网关；然后跟他最近的流量下边的也就在网关内部很多的叫微服务网关或者叫业务网关，以 spring out gateway 和空速这种；然后跟他平行的在入口网关里做一些 two C 的一些领域包括 API 的一些计量计费，这种可能就是 API 网关的一个场景；最后就是最下角的内部和产品之间集成的网关是 CSB 也就是做集成网关，做新老系统的集成协议互通互换。
因此把网关先分成了四个象限，今天从整个网关的领域上来看， Ingress 目前只是定义了流量网关，简单的ATP 请求的一些从入口往内部转发的一些基本的能力，但实际上在整个实践的过程中会发现跟他交集最大的 API 网关跟微服务网关的领域他并不能很好的去支撑，这就是目前发现的一些问题，包括从 Ingress 社区，从标准上也发现这个问题了。因此他会往 Getway-API 的这个方向去演进，补齐整个微服务和 API 管理的能力，包括支持协议的一个能力。这是在标准层面他引进的一个方向，但是当前来看， Ingress 的能力是比较弱的，这些用户是怎么去扩展的——他有实现的时候，比如对 Nginx的实现他是通过 location 的方式去拓展，涉及很多方式，大多数同学是通过这种模式去做的。当然还有一个就是 Envoy 实现 Ingress 的时候，是通过 CRD 去实现的，但这也带来了一个问题，就是 Ingress 作为一个标准，他的实现扩展的方式分化了，这样就会导致今天 Ingress 整个标准价值会不断的弱化，这个也是一个非常不好的现象。
因此为了更好的去引进这个标准，社区推出了 Getway-API ，目前已经到了 Beta 版，然后 Envoy 社区也推出了 Envoy Getway 的一个产品实现了 Getway-API，加速了 Getway-API 的一个转换，包括 Nginx 最早的实验其实做流量网关是非常合适的，但是当他往 API 管理和微服务管理的时候， Nginx 就会显得力不从心。后面给会通过实现的一些趋势再去做具体的一个介绍。从目前来看的，Ingress 目前因为实现再分化，所以一些标准的价值有弱化的一个趋势。
2. Ingress 标准趋势
那面对未来 Ingress 的一个趋势是什么。这里展示了三个内容，这个是从 Getway-API 的整个文档里翻出来的。第一个可以看到 Ingress 会长期往 Getway-API 上去演进，但是中期这两个是会并存的而不是一个替代关系，短期还是以Ingress 为主，中期是长期并存，长期是往 Getway-API 去演进。左边这个可以关注一下，然后从整个Getway-API 的整个发布历程上来看，这个月已经从整个 Alpha 版本变成Beta 版本，说明整个 Getway-API 基本已经成型，这个东西如果关注的话可以详细去了解一下。在这个协议里边，可以看到他在各种协议的支持上，在整个 API 管理上，跟微服务领域的一些流量治理的能力上，包括网关的整个生命周期管理上做了非常多的一个定义和扩展。基于 API 管理，他会基于决策把 API 的一个管理人员、开发人员、运维人员做了一个区分。当然随着公司变大的话，其实这些人员的区分是非常有必要的，因为网关作为一个入口，是一个安全入口的防线，因此做一些权限的区分是有利的，可以从长期关注一下这个趋势。
3. Ingress 实现现状： Nginx vs Envoy
Ingress 在这个标准的趋势之下整个 Ingress 实现的一个现状跟趋势是什么。从目前来看， Ingress 的实现主要是一个以 Nginx 为内核的，一个以 Envoy 为内核的，基于 Nginx 为内核的市面上可以看到 Nginx Kong 这样的一些网关，包括 open resty 都是基于Nginx 内核的。以 Envoy 为内核的，有 Envoy Getway 包括 Gloo 、 Ambassador 都是基于 Envoy 内核去实现的。为什么在 Ingress 实现上会有一个分支和一个发展。
目前梳理了一下，在两个实践的各自优劣。可以看到右边这个从社区的角度去看，目前 Nginx 社区已经确定最近六个月不更新新功能，他会核心的解决目前安全性和稳定性的一些问题，他为什么要去解决。因为Nginx 本身的稳定性的性能还是很好的，但是他扩展支持 Ingress 场景的时候，对 controller 的一些设计会带来一些性能和稳定性，包括一些安全的问题。这就是为什么现在来看很多的一些新 API 网关，包括原生网关都基于 Envoy 内核去构建，因为他的整个架构相对来说是更有优势一点的。这就是从社区活跃度和对应的安全和稳定性的问题上，简单介绍一下这块的对比。
为什么现在基于 Envoy 为内核稳定性和安全会稍微好一点。原因就是因为 Envoy 采用了数据面控制面分离的一个机制，这样控制面的一些安全问题和爆炸环境也不会影响到数据面，然后控制面的稳定性也不会影响到数据面，这样数据面的整个稳定性跟安全就会得到更好的保障。最后讲一下扩展性，在扩展性上，其实 Nginx 的主要是采用 Lua 的一个扩展机制，主要是采用 Lua 的一个语言； Envoy 为内核的网关，很多都是采用了 WASM 的一个多语言的扩展机制，这样方便写更复杂的逻辑，而且 WASM 相比Lua 扩展机制，他是一个沙箱机制，这样出现一些稳定性或者安全问题的话，他的整个爆炸半径是非常可控的，而且在语言上和规则的更新上也是一个热更新的一个机制，这也就是 Nginx 和 Envoy 的一个非常大的区别。为什么 Envoy 能做到热更新。因为 Envoy 从 Sidecar 这个角度和服务网格的体系去设计，他基于长链接在这个体系里对于规则和路由的一些热更新能力也就是他核心的一个能力。
在网关的场景下，热更新带来的好处也是明显的，比如现在的一些 LT 的场景、一些长链接的场景，他是不能断的，断了的话就会重启，包括更新规则如果去 reload 和 restyle Nginx ，对长连接会有损的，因此 Envoy 作为网关的情况下，他的热更新的优势就会非常的明显。其次就是高性能，可能很多人会觉得为什么 Envoy 内核的性能可能比 Nginx 高，下面这个就是一个基本的原因，后面章节会详细介绍一下。最后选择以Envoy 为内核的一个网关还有一个好处就是会与服务网格和微服务体系全部打通，标准的控制东西南北流量，也就是说微服务非常友好的一个选择，这就是在 Ingress 整个实现里，目前 Nginx 和 Envoy 的一个基本的对比，但是为什么现在这么多的公司依然选择 Nginx 。因为Nginx 相对来说架构会更简单一点，对于简单的流量控制的场景更容易接受，而且 Nginx 目前在社区的时间也比较久，所以认可度和存量客户比较多。
4. Ingress 实现趋势
下面就分享一下未来的整个发展趋势。这两张图分别是 CNCF 2019年和2020年的一个 Ingress 实现的统计报告，就是对于 Ingress 这个标准，有很多的一些产品去实现了他这个标准，但是在这些标准的整个调研报告里可以看到两个非常核心的信息。第一个信息是对于 Ingress 的实现的榜首第一名，不管是2019年还是2020年， Nginx 都是最大的一个用户，但是可以看到第二名 Envoy 在19年是第四名而在2020年快速地越级第二名，以最快的一个增长速度成为了第二选择，包括很多的创业公司，很多的云企业，全部基于 Envoy 内核去构建下一代网关的技术，包括 F5他有对应的一个实现。可以通过前面的现状，包括 Envoy 和 Nginx 的一个对比就可以理解为什么现在新的选择，新增的用户里边儿，为什么以 Envoy 为内核的 Ingress 实现越来越多。相信这两年 CF 没有更新报告，如果更新的话，从目前得到的社区的反馈上来看的话，这个比例在持续地去扩大也就是 Nginx 和 Envoy 的差距在缩小。
5. Ingress 产品趋势（高集成）
面对这些实现跟对应的 Ingress 标准的现状，也就是说 Ingress 的云产品的一些趋势就简单介绍一下。左边是用户自建 Ingress ，右边是阿里云的MSE 的一个对比。从整个产品的趋势上做一个基本的判断高集成是一个方向，为什么这么讲。因为从刚才的四个象限的角度划分了网关，这样就会导致用户的网关会非常多，运维成本包括整个RT 非常大，因此在符合 Ingress 或者 Getway-API 的标准之上，在未来相信流量网关、微服网关以及安全网关都会往高集成的角度去集成到一个网关上，提高整个网关的性价比，降低整个运维成本，答疑和支持的一个成本，降低整个链路的一个RT 。
这是第一个看到的一个高集成的趋势，在今天有这个高级层的趋势之下 K8S 通过 Ingress 把流量网关标准化了；在短期也就是说 Ingress Nginx Annotation的模式又为主流，因此 NSE 今天在整个 Ingress 跟对应的 Nginx Annotation 的注解上支持了80%以上的核心场景，就意味着可以平滑地去从 Nginx 自驾迁移到 MSE 云原生网关，目前迁移非常多的客户没有问题的。
第二个就是基于今天在流量网关 Ingress 符合标准的流量网关上整合了微服务网关的能力，意味着在微服务管理的角度支持了录有各种的限流降低的能力、全链路灰度的能力；在服务发现的角度，支持除了 K8S 的以外的 Nacos 、DNS 、传统的 ECS 以及 FaaS 的各种服务发现机制，那就可以做到统一接入，也可以帮助用户从非 K8S 到 K8S 的整个体系平滑的去演进，这个东西对用户的吸引力是非常大的；其次在整个安全可观测体系也做了非常多的事情，比如会基于整个 Metrics 和 Open Tracing 的一个标准给用户提供从网关到全链路的一个追踪的能力，并且在登录认证上支持多种登录认证的机制；如果说这些东西不能满足要求的时候也支持自定义认证鉴权；最后在整个安全和扩展性上也提供了非常多的机制。
这就是今天可能从原生整个 Ingress 的角度，发展角度、产品角度去看他今天呈现一个高集成的一个趋势。
