OpenNJet Q&A

By 李佳惠 2023-12-27

热门Q&A

Q:您好,OpenNJet 在帮助解决 NGINX 动态配置问题上表现如何?能否分享一些具体的应用案例,以及在这些案例中 OpenNJet 如何提高业务效率和稳定性的?

A:为了解决 NGINX 的动态配置问题,OpenNJet 首先实现了一个有多个 CoPilots:CoPilot:Ctrl、 CoPilot:broker、CoPilot:沙箱构建的动态配置框架,再基于这个框架,逐个对现存的模块进行动态化改造。

CoPilot架构如下图所显示:

img

事件配置框架则基于 CoPilots 框架,实现为下图:

img

目前实现的动态配置能力,典型的应用比如:

在高流量的环境下更新到期的服务端证书,这样就可以让业务完全不受影响,当前请求访问的还是老证书,下一个请求建立链接时,获得的就是新证书了。

另外的场景就是应用在灰度测试中,在生产环境中,正常的请求访问 A 集群,B 集群部署了升级包,那么就需要引流部分请求到 B 集群进行验证和测试。这块就可以利用 OpenNJet 的动态 location 能力,无需重起 /reload ,就可以实现,具体可以参考官网 blog :http://njet.org.cn/cases/case-gray/

Q:老师,您好!在您看来,NGINX 和 OpenNJet 在云原生方面有哪些共性和区别呢?在选择应用引擎时,我们应该考虑哪些关键因素?

A:共性实际上在官网及别的回复中有过描述,因为 OpenNJet 最初的代码树来源于 NGINX ,可以使用相同的配置模式进行维护。区别在于 OpenNJet 实现了 CoPilots ,动态配置框架,并对模块做了动态化改造,这种改造是扩展、新增,而不会变更原有实现的逻辑及含义。所以 NGINX 是可以自然、无需改造迁移到OpenNJet 上的。选择 OpenNJet ,最关键的点是在某些特殊的客户场景下,需要 7×24 业务无间断。

虽然 OpenNJet 把 7*24 作为切入点。但我们在选择引擎,或其他基础设施时,需要的更多是业务分析。比如我们的业务,可以容忍临时的中断,在线率只需99% 或 99.9% 那就可以不为性能作为切入点,而是重点考虑运维的友好度、扩展性等等。泛泛而谈,我认为有三点是需要考虑的:

首先是避免成为单点,至少需要支持主备的架构,能够尽量快的实现故障的 failover ;额外的则需要实现水平扩展能力,因为一个节点的硬件资源总是有限的。

另外,则是尽量内聚,对于较基础的组件,如果依赖太多的外部组件实现特定功能,一是不利于运维,需要这些额外组件的知识体系学习;在云环境中,还有可能导致特定基础设施的绑定。比如我们也看到,很多有效的业务组件,离开了 amazon s3/google bigtable 就无法运行,实际限制了在目前越来越流行的私有云中的应用。

最后一点,则是扩展性。尤其在私有云环境中,我们面临的协议千差万别,甚至还有些古老的协议要支持,像 tuxedo 等。那么实际我们需要大量的实施、交付人员,在现场针对这些特定的协议或需求进行开发。这块业界基本上也有成型的做法,采用嵌入式语言来做。从最早的 TCL ,到 LUA/JS / python ,支持哪种语言,还是要看面临的常见,所以游戏类 LUA 比较频繁,而进行算法处理的,python 比较多。

Q:请问在信创场景下, OpenNJet 对国密证书, 国密算法等有啥具体支持吗?

A:对国密有完备的支持,

1 可以支持国密 /rsa 自适应。

2 可以通过接口,动态更新国密证书。

3 主动健康检查可以适配国密server。

4 可以 proxy 到后端国密 server 。 在官网有一blog:http://njet.org.cn/cases/guomi_support/

Q:老师可以介绍下 OpenNJet 和 APISIX 区别优缺点吗

A:APISIX 也是我们接触较多的一款产品,其核心是利用 lua 实现动态能力,包括关键的路由选择。给我印象很深的还有其利用外部现有 go / Java 等第三方代码实现特定业务需求的能力。但总体上来说,APISIX 是和在其它咨询中谈到的 kong 是类似的。OpenNJet 基本上是通过 C 代码实现了这两者利用 Lua 实现的功能,所以也期望能够作为 APISIX 的底层引擎

Q:OpenNJet K8s Ingress Controller 1.0 有没有用于过生产环境,支持节点数是多少?现在生产环境基本都是 K8s ,可能由原来的 Ingress 能否平移或切换到 OpenNJet ?有没有对 k8s 有版本要求?

A:1、版本问题,OpenNJet KIC考虑到了目前企业异构的 k8s 部署情况,有适配不同 k8s 的版本。目前实现支持 >1.21 (我们选择了 1.24 环境进行的验证)和1.19. 如果有特定版本的适配,请在 Gitee 上提 Issue:https://gitee.com/njet-rd/njet

2、OpenNJet 的 KIC 实现基于社区版 NGINX KIC 做了扩展,在 Gitee 仓库中,有使用手册和 Release 的功能清单,(或参考:https://my.oschina.net/u/6606114/blog/10150202),如果使用到这些功能,是完全可以平滑迁移的。其他不支持的能力,有些是我们的设计架构变了,比如 Ingress 资源中我们去掉了主动健康检查,或是还没有实现动态化。 有特定的需求,还是请提 Issue 。

3、OpenNJet KIC 的设计目标是支持 200 个应用,5000 个后端实例。测试指标会在即将举行的开放原子开发者大会放出。

当前版本某银行目前在内部测试中

Q:您好,OpenNJet 是云原生应用引擎,那么他与 kong(基于 nginx 的 The Cloud-Native API Gateway )有什么联系?

A:我们原先在做项目时也对接过kong,其基于nginx+lua架构,利用lua编写了大量的业务需求插件. 我们理解kong的特点更体现在API管理上。OpenNJet是相当于kong底层使用的nginx,或者说可以平滑替换kong使用的底层nginx,因为OpenNJet也使用到了openresty开放出来的lua模块。另外,因为OpenNJet利用了原生的C模块实现了kong利用lua实现的功能,如果kong底层切换到OpenNJet,会有更好的性能

Q: 您好,我们刚好有需求,正在调研类似的产品。主要考虑几个点:

1、能不能有企业内部的账号权限体系快速的整合。

2、能不能实现一键回切,走直连接模式。

3、在跨城多中心的场景效果怎么样,底层的数据存储和同步架构如何。

不知道 OpenNJet 在这些方面如何支持的?

A:1: OpenNJet 目前提供 API 对外接口,并且可以配置在访问授权时,利用后端的 radius/ldap/openid 等其他的标准 auth 方式。所以是可以和现有企业快速整合。针对这个需求,我们月底前将在官网放出一个 blog ,描述如何使用

2: 这个需求是否是要实现一键回切到其他的 proxy/ 直连应用? 如果是这样,我们建议: 在两台代理机器上部署分别部署 OpenNJet 和其他代理,如nginx/haproxy 等。两台机器配置一个浮动 IP(如利用keepalived),那么通过控制浮动 IP 的漂移,就可以实现一键回切

3: OpenNJet 支持集群模式,配置数据的存储也是基于消息的,同步模式是基于 mqtt 消息协议的,所以多中心支持是没问题的。

Q:但“控制浮动 IP 的漂移”还是有点粗放,是否考虑在控制面做开关,通过数据面实现 IP 漂移。

A:可以参考https://my.oschina.net/u/6606114/blog/10143305,可以看出 OpenNJet 本身是实现了控制面控制的。但您提到的这个一键切换,我们理解是在 OpenNJet 和其他系统间一键切换,所以这个开关,是需要配置在管理多个 proxy 系统的管理面中的

Q:OpenNJet 目前是否成熟,是否可用于生产环境? OpenNJet 在内核重构、安全加固和功能增强方面进行了哪些工作?** **OpenNJet 如何与 NGINX 进行版本迭代?** **OpenNJet 的未来发展规划和路线图是什么?**

A: OpenNJet 目前已经经历了1.0、1.1、1.2、1.2.1、1.2.2、1.2.3 等多个版本迭代,OpenNJet 官网、2个运营商客户都在使用,所以是可以利用生产环境。

我们都知道 NGINX 最大的问题是无法动态加载。我们对 NGINX 做的最大改动就是这个,增加了动态配置框架,并利用该框架对企业界反馈强烈的需求,逐个对功能模块进行动态化改造,目前实现有:动态配置限流限速策略 动态配置 HTTPS 证书 动态配置 IP 黑白名单、动态清除缓存、动态开启指标项、动态配置分流策略、动态map、动态virtual server。

动态配置上游服务实例 KV 存储 Location 健康检查策略 动态开启链路监控 动态配置访问日志 动态指标获取 动态流量劫持 动态资源调整 ,我们也会在njet.org.cn 定期更新动态能力清单,供大家选用。

此外, 我们还剥离出 nginx 原先由业务处理进程(worker)做的配置等控制面功能,实现了 CoPilots(副驾驶)架构,比如主动健康检查,指标输出等功能,避免这些功能对正常的业务请求处理的影响。

在安全加固方面,OpenNJet 集成了 modsecurity ,目前对其做了动态化改造,可以按需开关。在 2024 年度,会对其的规则加载实现动态化,并利用线程池的模式优化执行性能。此外,也实现了 4/7 层面的限流,一定程度上防止 DOS 攻击。最后,支持国密标准,可以利用国标算法。

在功能增强方面, OpenNJet 主要实现了先有模块的动态化,这个在对其他提问的回复中有涉及。另外,是对特定协议的支持,比如 ftp 协议,虽然古老,但在企业内部还有大量应用。还有,OpenNJet 很大的一块功能增强是对 KIC/Sidecar 等云原生环境的部署形态进行支持,像实现 proxy_protocol_v2 以支持 Sidecar 功能中的流量劫持中的路由等等。这块的内容太多,可以访问官网的 blog 进行了解。

OpenNJet 的上游包括 Openresty 和 nginx ,会定期从其同步。之所以定期,是因为 OpenNJet 的内部结构已经和 nginx 有了较大差异,只能人工分析代码差异,手工 merge 。但 OpenNJet 一直在做,保证 CVE 及严重 bug 得到及时修复。

如官网首页展示,OpenNJet 是期望在云原生环境中,做数据面的内核,可以部署为 Sidecar/KIC ,以及应用容器。前两者已经有版本 release 出来,所以基于 WASM 实现通用的应用容器,是 OpenNJet 2024 年的一个重点规划。 另外,针对现有的 modsecurity 模块进行优化,实现高性能 waf 是另一个重点。 最后,是要实现 HTTP3 proxy ,完善 http 协议间的互操作。

Q:Nginx 老了吗?哈哈哈. 关于 OpenNJet 应用引擎如何通过增强 NGINX 的云原生功能和安全性以及提供多种产品形态和新功能特性,来支持云原生架构中的高效和可靠的服务交付?

A:请参考官网,概述来说,就是 OpenNJet 在保留 NGINX 原生高性能的基础上,实现动态配置,从而适应云原生环境频繁变化的环境。在这个基础上,为KIC/Sidecar 的特定需求实现了功能扩展,比如实现了协议识别及自适应来适应 Sidecar 的需要。

Q:当在 OpenNJet 中配置动态路由时,如何确保负载均衡在增加/移除后端服务时能够平稳地进行,避免对现有流量造成中断或延迟?

A:如果您仅仅关注的是后端服务的变化,那在 OpenNJet 中是一个较容易的实现。我们都知道,为了支持后端服务的动态调整,OpenNJet(实际上也是原先NGINX 的机制)把后端服务的列表保存在一个共享内存中,不同进程(worker)可以实时的访问该内存,获取列表,根据特定的算法来选定一个后端服务,这是对业务毫无影响的(都对该共享内存区加读锁)。当需要通过 API 变更这个清单时,另外一个独立的进程(这块请参考官网的描述,这个进程被称做 CoPilot:ctrl )会通过加读写锁的方式去写修改这个区域。由于每次更新是单条,并且是直接的内存操作,所以锁住的时间只有纳秒级别,不会对业务处理造成影响。

Q:什么是云原生应用引擎?OpenNJet 的有哪些优势

我们如何解决数据面控制面隔离、国密、动态配置等问题?

是否有监控界面?

A:1、可以关注 https://njet.org.cn/ 官网哈。 云原生应用引擎从传统互联网架构发展到云原生架构,其支撑的软硬件类型由操作系统、数据库、应用中间件和 Web 服务器逐步发展为基于云原生内核、分区解耦的数据库及相关衍生产品。主流有 NGINX、envoy、kong、OpenNJet 等。 主要优势:性能无损动态更新、灵活的 CoPilot 框架、支持 HTTP/3、支持国密、企业级应用、高效安全;

2、为了解决NGINX的动态配置问题,OpenNJet 首先实现了一个有多个 CoPilots:CoPilot:Ctrl, CoPilot:broker,CoPilot:沙箱构建的动态配置框架,再基于这个框架,逐个的对现存的模块进行动态化改造;对国密有完备的支持,(1)可以支持国密 /rsa 自适应。 (2) 可以通过接口,动态更新国密证书。 (3) 主动健康检查可以适配国密 server。(4) 可以 proxy 到后端国密server;

3、目前有vts指标输出界面,可通过配置展示出来,请求的统计数据等。

Q:njet运行过程中,如果删除log后,不会生成新log?

A:可以执行:kill -USR1 `cat /usr/local/njet/logs/njet.pid` 手动产生。 (pid 为njet master 的进程号。 也可以ps -ef |grep njet 查询,然后 kill -USR1 pid)