Envoy vs Traefik

云原生场景，产生了很多的Edge Router，Load balance，API Gate Way，Proxy等组件。

最近研究了一下，分享几个喜欢的项目，它们大致分为两类：

但两类没有实际功能的边界，Proxy为主，一般要支持在L4，Gateway为主，支持在L7即可。

Proxy主要位置是中间，可以做sidecar，Gateway在服务endpoint前面。

再比如传统的HAProxy就是Proxy，Nginx就偏Gateway。

这个概念和数据通信网络的Core Router和Edge/Service Router是差不多的，Edge Router是感知服务的，理论上功能更多，Data Plane基本一样，Control Plane功能更丰富而已。

所以Gateway一般是一个Control Plane + Data Plane，比如Kong的Data Plane就是OpenResty。

使用Envoy作为Data Plane的Control Plane有Solo.io（Istio族下）。

从需求角度，我有几个偏好：

功能性能上，需要看场景。我关注在差异上，也就是高扩展与独立。

Envoy：C++原生性能没得说，线程模型比Nginx还先进，水平扩展，所有配置均支持动态接口。最吸引我的是WASM的插件机制，逻辑上WASM可以编译到原生水平，还有很好的容器属性。只要push/pull就能增加插件进行使用。
Traefik在今年上半年选型时，我很看好，独立，2.0开始支持L4，与Swarm，K8S结合都很好，性能也与Nginx不相上下，但配置动态还自带UI，可惜当时不支持插件，惜败。没想到从2.3开始支持golang的动态链接库和golang代码解析执行两种（Dev Mode），实验阶段。
Kong/OpenResty：Nginx性能没的说，Lua动态没得说，Kong增加了控制平面的动态能力，差就差在Kong是几个东西组合的，大而全，但不小也不美，配置部署都麻烦。
Krakend：这个是个欧洲公司，小众，golang，插件支持Lua与Golang，性能说是比Kong高，有很技术后发优势，小而美，自带UI。但生态上还是和几个大哥差太多了，怕半路夭折了，长期观望。

Envoy VS Traefik

Envoy WASM插件：

BodyRewrite的流程，弄了一遍，总体不算太痛苦，哭在写C++上比较烦，当前还支持Rust，所以不算缺点。

本身插件是WASM文件，如果支持容器，还需要一些繁琐的步骤。据说性能目前还不行。可以先用Lua。

这里是Hub的生态，还比较冷清

Traefik插件：

Golang的开发成本更低，写起来比较快，动态性上差点。

Plugins的生态更冷清。

虽然在插件概念上，大家都各用奇招。但插件需求还是比较高级的开发者需求，普通用户不一定用到。

我关注的其他功能

gRPC：都支持。
状态：虽说Proxy无状态的，但状态是我的特殊需求，比如RateLimit如何实现，分布式下如何存储状态，效率如何。两者实现默认都是无状态的，不能集群全局RateLimit。Envoy给了一种gRPC实现有状态的实现的例子。
数据收集：Traefik比较弱，主要是文本输出Access，Envoy更加灵活可以将日志通过gPRC protobuf输出。

总结

Envoy的门槛更高，定位更有想象力，聚焦Data Plane，CloudNative的网红。

Traefik自带Control，上手快速，功能不花哨，就和它的Sologan一样 “Just Works“。

各有优劣，不相上下，持续关注吧。