NJet在做动态化能力设计时，曾利用了基于mqtt消息的event框架，整体实现为利用CoPilot框架实现了一个消息的broker，同时CoPilot ctrl进程作为api server，接收http请求，转化为消息后，发送给沙箱进程做配置验证，验证后，广播给作为消费者的所有的worker进程应用配置变更

 目前市场上存在多种类型的分布式数据库，出于兼容性考虑，很多数据库都提供标准的mysql的访问接口; 其基本架构都是多节点分区存储数据，有的甚至采用存储和计算节点分离的模式，但无论怎样，出于高可用性以及支撑访问量水平扩展的需要，其前端都需要部署一个负载均衡设施。

Ingress NGINX 退役引发开发者们的强烈关注，OpenNJet 作为一款基于NGINX开发的云原生 流量管理平台，在保留NGINX稳定性的基础上，针对云原生场景进行了深度优化。根据 OpenNJet官方测试数据，其 K8s Ingress Controller (KIC)在高并发场景下的请求处理延迟比 Ingress NGINX降低15%，内存占用减少20%，这对于大规模集群来说意味着显著的资源节省和性能提升。

NJet的API网关（API Gateway）提供了OpenAPI3.0 格式文档的导入，提供了用户角色及API授权关系的维护API，以及基于角色的API访问控制。用户通过API 网关提供的Restful 接口，可以在NJet实例上注册后端服务，并开启授权校验功能。后端服务不需要提供额外的登录及授权功能，由API 网关提供统一安全管控。

NJet 集成了Lua 的运行环境，在不配置 lua_code_cache off; 的情况下，worker收到请求时，会从context中获取已经创建的Lua VM (第一次执行Lua相关代码时创建）。Lua VM中, package.loaded 是一个核心的 Lua 表，它扮演着 Lua 模块缓存的角色。当使用 require(“module_name”) 加载一个 Lua 模块时，Lua 解释器会首先检查 package.loaded 表中是否已经存在名为 module_name 的模块。如果存在，它会直接返回已缓存的模块值；如果不存在，它才会去文件系统（根据 package.path）查找、加载并执行该模块文件，然后将其返回值存储到 package.loaded 中，供后续调用。

目前NJet的配置文件与Nginx的配置文件格式相同。这种配置文件的格式对我们阅读比较友好。但是对一些自动化配置的需求来说，处理起来就很困难。为了以后能够对NJet的配置通过自动化工具来进行维护，NJet增加了对json格式配置文件的支持。目前这种支持是很基本的，只是支持主配置文件为json格式，里面include的文件的格式还是与之前相同。

由于ssl证书签发的有效期越来越短，运维人员花在证书管理的成本将成倍增加。结合NJet动态证书管理的能力，在初次配置后，NJet可以通过标准的ACME协议实现证书的自动签发、续签，并自动更新到服务器中，从而实现无需重启，就可以保持证书的有效性，保证业务的持续安全。

  作为 NGINX 可信开源替代项目，本次版本聚焦三大核心功能突破：监听配置热加载、四层代理配置动态化及创新式沙盒预加载三大功能特性，同时该版本还完成了全面的代码安全加固工作。这些特性不仅标志着 NJET 在技术成熟度上达到了新的里程碑，更为广大 NGINX 用户提供了一个更加灵活、安全、易迁移的开源选择。

动态监听是NJet核心需求，在NJet4.0中，在7层(http)与4层(stream)均实现了该能力。在新版本NJet中，无需重启NJet服务，即可实时调整监听配置。适配云原生环境动态特性。目前先支持SSL协议，可满足HTTPS服务动态调优需求（如大促流量应对、负载灵活调整）。团队计划后续支持完整的Listen选项，实现与静态配置的完全兼容。

作为开发人员，经常碰到的问题是代码开发、测试都是好的，但在客户现场/生产环境，总是出各种各样的问题。这种问题，有可能是实现的逻辑，但更多的情况是现场人员的配置问题导致。因此开发人员需要一个和现场完全一致的环境，进行现场的故障复现，配置验证。