热门Q&A

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

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

CoPilot架构如下图所显示：

事件配置框架则基于 CoPilots 框架，实现为下图：

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

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

另外的场景就是应用在灰度测试中，在生产环境中，正常的请求访问 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）