好吧，这两天朋友圈被两篇文章卷飞了
一是 Envoy 的 Matt 大佬的 采访文章 ，预测 Nginx 在市场上的寿命只剩 10 到 15 年了（大佬可真敢说…）
二是阿里云基于 Envoy 开源 Higress 的文章 ，又拿 Tengine/Nginx 来对比。
仿佛一夜间，Envoy 就要逆袭 Nginx 了，朋友圈里好不热闹，搞 Envoy 的招呼赶紧上车，不搞 Envoy 的直呼太卷了，甚至还有 “去 Nginx” 的论调 …
以上，是朋友圈中摘选的一些情绪化的东西。
外行看热闹，内行看门道，咱作为网关领域的一线开发，怎么看呢？
正好，前几天在组内有一个这方面的小分享，拿出来说道说道
个人背景
我以前一直是搞 OpenResty/Nginx 的，去年底加入了蚂蚁开始搞 MOSN，MOE 这个方向，也差不多一年了。
这一年中，有小半时间在搞 Envoy 相关的，对 Envoy 也开始有了一些了解。
后面的分享，就是一个已经上车 Envoy 的 Nginx 老炮，谈谈从 Nginx 到 Envoy 有哪些变化，仅供参考。
大环境
- 时代变了，云原生时代来了，对很多基础软件都带来了冲击。谁能顺应潮流，与时俱进，就能赢得未来。
- Nginx 基本盘还在，在 Web server 市场，Nginx 依然独占鳌头。只是对于开发者而言，已经不再那么诱人。
- Envoy 已经在开始蚕食 Nginx 的强项市场，Ingress，API gateway。这一波中，云厂商在打头阵，冲在一线。一线大厂，由于历史包袱，也在积极储备，逐步汰换。
- 东西南北，统一架构的趋势，愈演愈烈。
控制面
从 Nginx 到 Envoy 最大的一个变化，就是抽象了独立的控制面。
Nginx 诞生于云原生之前的时代，是面向系统运维的架构。那个时代，应用发布是很低频的操作，由系统运维来把关操作，是很合理的。
而 Envoy 诞生的云原生时代里，动态变更配置，已经是常态化的基础需求，独立的控制面，是更合理的选择。
并且，有了独立控制面之后，网关就可以脱离数据面，进行更上层的产品演进。比如，Istio，Envoy Gateway 这种就有了独立的发展空间。
扩展机制
回到 Envoy 数据面，另外一个很大的变化是，扩展机制。
Nginx 的底座是 Http/TCP server，可以在预定的 hook 点注册 handler。
Envoy 的底座则更加底层，只是 Filter 扩展的管理器。底座与协议无关，只负责管理运行一个个的 Filter，由 Filter 来完成所有的事情，包括协议解析。
同时四层 TCP 和七层 HTTP 使用的是同一套架构，HTTP 的 filter manager，本身也只是一个 TCP 层的一个复杂的 Filter。
这种灵活的可扩展性，使得 Envoy 可以适用于更多不同的场景。
Matt 大佬采访中确实也提到了这一点，Envoy 的核心技术理念就是围绕可扩展性展开的，希望提供的是一个可扩展的底层工具。
上手门槛
Envoy 确实上手门槛有点高。
以我个人的体验来看，有这么几个方面：
- 由于上述的一些架构变化，软件的整体复杂性本身，确实是要更高了一些
- Envoy 有非常深的 Google/硅谷 C++ 全家桶的痕迹，构建工程就很复杂，初次 bazel 编译，按小时算的
- 从 C 到 C++ 的学习成本
这些门槛，对于一个专门从事网关的开发人员来说，也并不是太大的难事，硬着头皮，有一两个月，也可以啃下来。
有解么？
但是，对于简单的网关用户来说，这个门槛，其实是非常高的。并且，跨过这个门槛之后，C++ 的研发效率，也确实比较低。
所以，这也就是，我们正在搞的 MOE 架构的发展空间，通过把 Go 语言嵌入到 Envoy，为用户提供了，使用 Go 语言来开发 Envoy Filter 的机制。
这么下来，上手门槛就非常低了，同时上手之后，Go 语言的研发效率，也是公认的高。
不信？MOE 的底层，envoy-go-extension 已经开源了 ，欢迎来体验用 Go 来开发 Envoy Filter 。
后续，我们还会提供更上层的 MOSN 侧的封装，到时候，整个 MOSN 都可以跑在 Envoy 上，大家直接开发 MOSN filter 就可以了。
最后
随着云原生的发展，对于网络提出更高的要求，多租，多云，身份认证，这些都是网关软件的发展机会。
未来谁会发展得更好？尚未可知。每个开发者，会用脚投出最真实的一票。