为什么选择 HTNN 这款网络产品？

我们（蚂蚁网络基础设施团队）推出了一款新的网络产品，基于 Istio 和 Envoy 开发：https://github.com/mosn/htnn。

基于 Envoy 的网关多如繁星，HTNN 这个新轮子优势在哪？

推广一个开源项目其实就是推广一种理念。几年前 APISIX 在推广时，主打的是更好的性能。HTNN 主打的也是“快”，但不仅仅是数据面执行性能之快，更主要的是研发效率之快。无论是什么时候，又快又好地推出新功能都是研发人员的刚需。HTNN 的各项功能，都围绕着提升开发效率来设计。

拥抱 Go

Envoy 支持多种拓展机制：Lua、ExtProc、Wasm，还有由我们蚂蚁网络基础设施团队贡献的 Go。HTNN 允许用户使用 CRD 配置以上全部四种拓展方式。不过其中最核心的，还是 Go 拓展。HTNN 的 Envoy 数据面大体上是围绕着 Envoy Go 拓展变化的。这不仅仅是因为我们对 Go 最为熟悉，而是在现行拓展方式中，拜广阔的生态和庞大的开发者基数所赐，使用 Go 能达到最好的研发效率。

HTNN 并没有停留在直接使用 Envoy Go 的能力上。在 Envoy 自己的 Golang filter 之上，HTNN 构造了一套更类似 Kong/APISIX 插件机制的 filter manager，把 Envoy 底层机制封装起来，让插件开发者只需要操心自己的插件业务逻辑。HTNN 还开发了一套测试框架，既向单元测试提供了一组 mock 接口，又为集成测试准备了运行所需的 Envoy。可以这么说，在现阶段基于 Envoy 的网关中，HTNN 的插件开发门槛是最低的。有时开发者直到完成了插件的开发任务之后，都还没有真正在本地部署过 HTNN。

插件化

让开发者心无旁骛地开发插件的同时，HTNN 也需要有机制能够感知开发者的插件能力。借鉴了 Kong/APISIX，HTNN 定义了一套插件注册机制。在 HTNN 看来插件就是实现了若干方法的黑盒，只要在某些节点调用插件定义的方法即可。开发者通过 protobuf 等方式来描述自己的插件配置字段，HTNN 就能在应用 k8s custom resource 时通过 webhook 检查用户配置是否合法，并将相关的字段通过 xDS 发送给 Envoy。期间 HTNN 不关心开发者到底配置了哪些字段。这带来了生产关系的变化：

• HTNN 的维护者专注于提供各种机制
• 插件开发者专注于开发体现业务逻辑的具体插件实现

分工带来更低的研发成本，因为现在我们可以把插件的开发交给更多的人来完成。

网络就是为了连接而存在的，尤其是应用层网络。要想让网络更强大，就要让它连接更多节点。而要想连接更多节点，降低连接的成本是一个办法。编写插件是连接的方式，所以 HTNN 要做的是不断降低插件编写的成本。通过把插件开发的门槛降低再降低，把插件开发者需要感知的知识减少再减少，HTNN 正在推动连接成本持续下降，连接建立效率不断提升，创建一个更加复杂的网络。

混合部署

应用层网络通常有许多相似的网络产品，比如接入层网关、API 网关、接出网关、mesh、基于 SNI 的 SLB 等等。HTNN 通过拥抱 Istio + Envoy，实现应用层网络的大一统。同一套 Istio 和 Envoy 的架构，可以同时用作接入层网关、API 网关、mesh 等等，只需做一些配置和打包上的区分。

每一个网络产品通常由三部分组成：管控面（如 console），控制面（如 istio），数据面（如 envoy）。HTNN 通过全栈使用 Go 语言，实现了三部分的知识复用。开发者不需要给自己设限，可以一路从数据面干到管控面，反正它们都是用 Go 写的。

总而言之，HTNN 允许对开发者进行横向和纵向上的混合部署。原本用于开发接入层网关的代码，也可以跑在 API 网关上。原本给网关开发的功能，也可以后置到 mesh 上。原本开发控制面的开发，也可以来编写数据面的代码。通过混部，我们既可以更高效地利用研发资源，又能消除不同产品之间的隔阂，在开发投入不变的同时增加产出，实现更多的业务价值。