[NJet-user] NJet3.0发布了

[单雷]

经历半年时间，NJet3.0终于要发布了。
3.0继续在引擎动态化的规划路线中演进，本阶段完成了动态代理转发，动态共享内存，动态证书吊销列表，动态header控制4项能力：
- 动态共享内存，解决了关键的资源分配无法应对业务弹性变化的关键痛点
- 动态代理转发，可以通过API直接切换后端的集群，为蓝绿发布提供了另外的技术途径。至此， 结合"动态表达式location"实现灰度引流测试，在测试完成后，通过动态代理转发实现蓝绿切换，NJet为企业急需的关键业务无中断的滚动升级提供了完备的解决方案
- 动态证书吊销列表则是动态SSL证书，动态国密的后续，补齐了动态SSL安全缺失的一环。结合本次发布对SSL基础库的更新（升级到铜锁8.4,使用openssl3.x)，NJet3.0不仅实现了SSL的完全动态化，也为后续的新的算法（比如抗量子）支持打下了基础
- 动态header能力则使NJet可以动态设置对客户端的返回，在CORS控制、作为应用服务器方面等方面使用广泛

3.0的另外一项关键优化是支持大配置量的动态配置。在合作伙伴的交流中，都提到了实际生产环境中的配置项，都是10M级别的，证书的吊销列表等业务数据，甚至可以达到GB的规模。NJet在3.0的研发中，基于自研的底层同步协议，使得不仅单一节点可以快速处理大配置量数据、而且使得集群内的不同节点也能够得到及时的更新

动态协议识别是3.0最重要的安全特性之一。在2.0推出后，其可动态配置的通用TCP/UDP代理，以及对PROXY_PROCOCOL2的支持，吸引到了一些非HTTP协议的用户，也因此提出了使用中的一些问题，最关键的需要是避免互联网环境对暴露出的公网可访问的端口的冲击。为应对这类威胁，NJet3.0实现了协议识别+端口快速关闭技术，可以过滤掉非法的客户端访问。鉴于私有的TCP/UDP协议千差万别，3.0引入了即时编译技术（JIT）,可以在现场配置类似C语言的脚本，实现对特定协议类型的解析，即保留了对协议分析的高性能，又极大的增强了配置的灵活性。此外，安全方面的加强还包括数据隐藏，和防刷。 前者可以在记录访问日志时过滤掉敏感信息，后者则可以根据规则自动完成机器人校验，防止脚本工具对资源的冲击

集群多主支持是3.0的关键能力。在NJet1.x,2.x阶段，NJet虽然提供了集群能力，但集群的构建还需要部分的手工配置，尤其是在节点变更的情况下。3.0则完全实现了集群的自动构建;并且，无论通过动态配置接口访问哪个节点，集群内部的所有节点都会得到更新

此外，根据规划， API管理能力是3.0重要的功能点。目前实现的API管理，从OpenAPI文档导入起，到用户、角色管理，实现了细粒度的认证授权，把权限认证汇聚到网关层面，大大简化了应用开发的复杂度。
对消息类协议的支持也是3.0发力的重点。在消息类应用的使用模型中，client需要同所有的broker建立连接，这种模式比较适合企业内网，出于安全考虑，不太适合客户端位于互联网的情况，如果互联网需要访问内部网络的消息broker，一种方案是通过代理，一种方案是进行协议转换。NJet的目标是都支持，前者由NJet的合作伙伴在进行开发中，后者由3.0提供。目前实现了http2MQTT， http2Kafka， 使得无需特定的客户端，就可以把消息发送到相应的broker中

最后， 《应用引擎白皮书》描绘了应用引擎在云原生环境出入口网关、边车、应用服务器的规划。NJet的研发过程也是逐步对应用引擎落地的过程。伴随NJet1.0, 边车的到了落地; NJet KIC 则随着2.0的发布推出。在3.0阶段，应用服务器也即将推出。由于应用服务器需要考虑不同的语言实现，所以也会有两种技术路线，一种是为不同的语言实现特定的服务器，另一种是把不同语言的实现，转换为wasm，应用服务器仅仅实现对wasm的支持。后者，也是由NJet的合作伙伴在开发中，NJet则在实现对特定语言的支持。 首先选择的是Python支持，目前已经实现了对Python WSGI的规范支持，基于NJet的底层异步IO，NJet实现的Python WSGI服务器，相比目前市面的python 应用服务器，有近10倍的性能提升。

欢迎转发及试用

谢谢


欢迎大家试用！