对七层接入的一些思考
做了近两年的七层接入的事情,到月底做一个阶段性的结束.借用一句话, 既往不念,纵情向前.
需要做的事情:
- 在 openresty 上笔记上记了很多的内容,做一个整理.
- 把一些技术方面的思路,重新整理成完整的库.
如果拖的时间太久可能会对技术细节的遗忘,懒得在这方面投入经历.
tengine 和 openresty
tengine 是 nginx 的 fork
openresty 是 nginx 的 plugin
两者是不同的技术方向, tengine 的技术方向在 16 年之前非常优秀,但是能不用就不用吧.首先 tengine 在 19 年后就没有在更新维护,相比来说 openresty 的社区活跃得多.
不过今年 tengine 时隔 4 年,今年发布了 2.0.4 的版本,在对 nginx 1.21 openresty 1.21 tengine 2.0.4 的 ocsp 测试中, tengine 的 ocsp 不生效.
去年在查看相关插件时, tengine 对 nginx 的改动几乎没有办法平滑的更新 nginx 的版本. 社区的不活跃也导致 bug 的修复几乎没有.
如果是 nginx 做均衡负载产品,使用 c 技术栈来做由于变化不多,有一定可取性.但是目前大家开始做融合, 均衡负载、网关、mash 做融合,使用 openresty lua 方案要比 c 写组件的方式在开发维护成本要低的多.
apisix 和 kong
apisix 和 kong 两个都是建立在 openresty 上的开源产品, apisix 是在看到了 kong 的缺点后出现的解决方案.我理解的 apisix 优于 kong 的几点:
- apisix 使用 etcd watch 作为配置下发, kong 使用数据库轮询. ms 级和 s 级的区别.
- apisix 的路由使用 rds_tree 性能要比 kong 的高很多.
- apisix 的代码相比 kong 要简洁很多.
作为两个建立在 openresty 生态上的开源产品,相互直接也有很多的借鉴, 比如 apisix 的 dns 服务发现使用的库是 kong 开源的.
在做引擎的替换时,我几乎看完了 apisix 、kong 已经生态上开源库的代码, 为什么说几乎看完呢,首先这个生态和其他开发语言相比,要小众得多,而多数的开源库都是来自 openresty apisix kong 官方,剩下的一小部分来自其他的开发者,另外就是 openresty lua 确实是非常简单.
nginx 和 envoy
我没有用过 envoy ,只是看过相关的文档. 这里的描述可能是错的.
nginx 和 envoy 的架构不同,在性能上实际相差不大,nginx 成熟稳定,enovy 年轻激情.
envoy + wasm / openresty + lua 两种不同的技术栈.
相对来说 openresty 要简单一些. envoy 的配置动态下发方式是 openresty 一大优势,在很多时候我都知在想办法解决怎么才能让 nginx 少 reload 或者不 reload.
envoy 对云原生的支持要比 nginx 优秀. apisix 也在这方面做了很多工作.
日志监控
日志可以看 apisix 的实现,写本地或者使用 tcp 的方式,tcp 的方式可能更好一些,会少一个日志收集组件. 可能会出现丢日志的情况.
监控由于 promehtus 几乎成为了云原生监控的规范.apisix使用的 resty-lua-prometheus 的库使用了单独的进程来做 metrics 输出,原因是 metrics 拉指标存在排序和一些计算,导致内存和 cpu 的异常占用,我通过一些技巧,对此进行重写后,性能非常可观.
