🙈 By 单雷 2024-09-27
欢迎大家试用！
附录
1.https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/http3
2.https://www.haproxy.com/blog/how-to-enable-quic-load-balancing-on-haproxy
NJet3.1在9.26号正式发布了，不同于前期的版本，这个版本中很多关键特性来源于中金金融、京东、巨硬科技的贡献，是真正的社区协作结果。
在该版本中，NJet继续在新协议支持上发力，一是继续加强HTTP3, 来自于京东的贡献实现了HTTP3代理，HTTP2代理以及HTTP3和HTTP1、HTTP2的互操作性，客户端可以发送HTTP1、2、3,经NJet转换后，可以访问后端的HTTP1、2、3服务。这意味着，服务端不需要改变，就可以适应
client发起的HTTP3请求，从而更好的支持移动互联网业务。据通名智云的调研，目前仅仅在一些特定版本的商业版（envoy提供了验证性支持，见附1，haproxy在商业版本中才有提供，见附2）提供了纯粹的HTTP3 proxy能力，互操作性基本没有。
对HTTP3的增强还来自于中金金融对HTTP3国密双证书的支持。按照国密规范，server和client交互会采用签名加密双证书。这个规范在基于TLS1.1、1.2标准的HTTP1.x，或TLS stream上都得到了落地。但当来到HTTP1.3时，由于采用了QUIC传输+TLS1.3, 国家还没有一个标准出台。我们在前面版本中，尝试遵循RFC9898,采用单证书模式，尝试了HTTP3国密的一种模式;但我们认为双证书才是HTTP3国密应该采用的标准。感谢中金金融贡献的代码，完整实现了HTTP3上的双证书模型。当然，由于标准尚未出台，目前缺乏浏览器或其他客户端，这也是OpenNJet在后续的发力点。
此外，巨硬科技贡献了MQTT proxy能力。该代理不是简单的4层转发，除了可以根据MQTT的属性做路由选择外。还实现了broker切换client无感知，即即使后端broker故障，NJet重新选择了broker，但client到NJet的长连接依然得到保持。
根据规划，NJet会在release3及以后的版本上，逐渐落地云服务领域的应用服务器。在3.1这个release中，巨硬科技依托NJet前期发布的JIT框架，贡献了通用server框架及通用proxy框架，并用websocket协议做了验证，推出了基于TCC脚本编写的websocket服务器，既实现了和c语言编写的模块的一致高性能，又实现了按需定制的灵活性。这套框架，搭配上对grpc/dubbo协议解析的支持，就可以实现利用脚本语言编写微服务的能力。最关键的是，由于复用了NJet的底层网络、事件处理能力，应用开发者可以规避线程、异步编程、网络处理等挑战，仅仅编写业务函数就可以实现集群ready，按需扩展的超高性能应用服务器。
除基于JIT的TCC脚本支持外，NJet在这次发布中，还包括了标准的python WSGI应用服务器。之所以选择python语言，因为根据调查，python技术栈中，web应用服务器性能都不高（NJet对比了常见的开源web服务器，如gunicorn， uWSGI， NJet是其5倍以上）。相比其他的实现，NJet实现的WSGI服务器，依然依托于底层的事件处理模型，单进程支持并发请求。并且最关键的是，业务代码无需变更，可以直接利用上单进程多业务并行。
此外本版本中，还极大满足了企业部署的要求：实现了微服务注册中心的集成，从而使NJet可以成为外部访问微服务的标准网关；增强了集群配额对websocket/webrtc等长链接协议的支持；提供集群规模的token服务来保持集群配置的一致性。
欢迎大家试用！
京公网安备11011502037641号
京ICP备2022014815号