据Gartner预测,到2025年,云原生架构将成为超过95%的新数字计划基础,高于2021年的不到40%,云原生架构市场占有率不断提高。而如今,全球半数以上(55%) 的网站都基于 NGINX 运行,差不多相同比例 (53.7%) 的中国网站在 NGINX 开源版上运行。而NGINX存在难于动态配置、管理功能影响业务等问题,为了解决这些问题,OpenNJet由此诞生。
OpenNJet基于 NGINX1.19 基础 fork 并独立演进,具有高性能、稳定、易扩展的特点,通过数据面与控制面的隔离,能够在不重启进程的情况下基于动态配置能力进行配置的实时更新。最近还推出了OpenNJet K8s Ingress Controller 1.0,基于OpenNJet的动态特性、高性能实现,弥补了NGINX在云原生场景中不足,而且提供了丰富的流量管理功能,如动态location、host/path路由、负载均衡、动态upstream、金丝雀发布、SNI等。
OSCHINA 本期高手问答(12 月 13 日 - 12 月 19 日)我们请来了嘉宾单雷老师和大家一起聊聊NGINX向云原生演进那点儿事。
可讨论的问题包括但不限于:
- OpenNJet和NGINX是什么关系?
- 什么是云原生应用引擎?OpenNJet的有哪些优势
- 我们如何解决数据面控制面隔离、国密、动态配置等问题?
- 读NGINX/OpenNJet源码的建议
- 如何上手开发一个开源项目?
其他关于NGINX、OpenNJet的更多内容,也欢迎积极提问。
嘉宾介绍
通明智云产品总监 单雷
20年的IT行业经验,精通云原生以及高性能应用引擎技术。曾在亚信科技历任研发主管、首席架构师等职务,并主导多个云原生、高性能应用网关项目的设计开发工作,现任公司应用引擎产品总监。
🎁 为了鼓励踊跃提问,下一代云原生应用引擎OpenNJet开源社区会在问答结束后从提问者中抽取 5 名幸运会员,赠予精美棉马甲一件。
OpenNJet 应用引擎是基于 NGINX 的面向互联网和云原生应用提供的运行时组态服务程序,作为底层引擎,OpenNJet 实现了NGINX 云原生功能增强、安全加固和代码重构,利用动态加载机制可以实现不同的产品形态,如Web服务器、流媒体服务器、负载均衡、代理(Proxy)、应用中间件、API网关、消息队列等产品形态等等。OpenNJet 在云原生架构中作为数据平面,除了提供南北向通信网关的功能以外,还提供了服务网格中东西向通信能力。在原有功能基础上增加了透明流量劫持、熔断、遥测与故障注入等新功能特性。
OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。
下面欢迎大家就 “NGINX 向云原生演进” 相关问题向 单雷老师 提问,直接回帖提问既可。
高手问答第 311 期 —— 聊聊 NGINX 向云原生演进那点儿事
@HeartArea @famince @osc_89645095 @os_bitmap @猪娃娃
恭喜以上5位网友分别获得 精美棉马甲一件。
请于12月28日23点前登陆账号, 私信 @小白兔爱吃大灰狼 告知快递信息(格式:姓名+电话+地址+尺码),过期视为自动放弃哦~
尺码参考:
@OpenNJet 大佬,你好,OpenNJet作为云原生应用引擎,有哪些优势以及有哪些类似的产品,各自的优缺点是什么呢?
@OpenNJet 您好,OpenNJet是云原生应用引擎,那么他与kong(基于nginx的The Cloud-Native API Gateway)有什么联系?
@OpenNJet 您好,我们刚好有需求,正在调研类似的产品。主要考虑几个点:
1、能不能有企业内部的账号权限体系快速的整合。
2、能不能实现一键回切,走直连接模式。
3、在跨城多中心的场景效果怎么样,底层的数据存储和同步架构如何。
不知道OpenNJet在这些方面如何支持的?
@OpenNJet 我也是刚刚了解到这个开源软件,希望了解以下问题:
OpenNJet目前是否成熟,是否可用于生产环境?
OpenNJet在内核重构、安全加固和功能增强方面进行了哪些工作?
OpenNJet如何与NGINX进行版本迭代?
OpenNJet的未来发展规划和路线图是什么?
@OpenNJet Nginx 老了吗?哈哈哈. 关于OpenNJet 应用引擎如何通过增强 NGINX 的云原生功能和安全性,以及提供多种产品形态和新功能特性,来支持云原生架构中的高效和可靠的服务交付?
@OpenNJet 当在 OpenNJet 中配置动态路由时,如何确保负载均衡在增加/移除后端服务时能够平稳地进行,避免对现有流量造成中断或延迟?
引用来自“iman123”的评论
@OpenNJet 大佬,你好,OpenNJet作为云原生应用引擎,有哪些优势以及有哪些类似的产品,各自的优缺点是什么呢?
云原生应用引擎有多种部署形态,如出入口网关,web/应用容器,边车等等。
目前我们看到在市场上,边车这种模型,基本上是istio+envoy一家独大。已经成为了事实上的标准,但由于这种模式相对资源损耗大(每个应用的实例都配一个边车),所以市场上有别的解决方案,像Cilium基于eBPF的实现,或per node的ambient 模式。 前者在国内的环境下大规模部署很不现实,因为需要面对大量的centos7.6(内核长期在3.x,ebpf的网络能力没有实现),后者社区发现有较多的性能问题,还需要较长时间的演进。NJet发布的边车,是遵循和istio对接的xDS接口,仅仅替换envoy,利用nginx良好的架构实现更高的性能。实测边车资源利用率,是envoy的1/3。
在proxy领域,比较流行的有百度BFE,阿里开源的MSON。 都是基于GO语言的实现,由于是基于GO的实现,基本上都具备开发便利,扩展灵活的特点。但是其性能上,尤其是SSL性能上比NJet上有较大差异,其https性能应该约为NJet的1/5。
NJet作为后来者,其功能的完善程度上会比市场上,尤其是经历了社区验证的这些产品有所缺失。性能是目前NJet的主要切入点
引用来自“famince”的评论
@OpenNJet 当在 OpenNJet 中配置动态路由时,如何确保负载均衡在增加/移除后端服务时能够平稳地进行,避免对现有流量造成中断或延迟?
如果您仅仅关注的是后端服务的变化,那在NJet中是一个较容易的实现。我们都知道,为了支持后端服务的动态调整,NJet(实际上也是原先NGINX的机制)把后端服务的列表保存在一个共享内存中,不同进程(worker)可以实时的访问该内存,获取列表,根据特定的算法来选定一个后端服务,这是对业务毫无影响的(都对该共享内存区加读锁)。当需要通过API变更这个清单时,另外一个独立的进程(这块请参考官网的描述,这个进程被称做CoPilot:ctrl)会通过加读写锁的方式去写修改这个区域。由于每次更新是单条,并且是直接的内存操作,所以锁住的时间只有纳秒级别,不会对业务处理造成影响
引用来自“小城渔翁”的评论
@OpenNJet 您好,OpenNJet在帮助解决NGINX动态配置问题上表现如何?能否分享一些具体的应用案例,以及在这些案例中OpenNJet如何提高业务效率和稳定性的?
为了解决NGINX的动态配置问题,NJet首先实现了一个有多个CoPilots:CoPilot:Ctrl, CoPilot:broker,CoPilot:沙箱构建的动态配置框架,再基于这个框架,逐个的对现存的模块进行动态化改造。
CoPilot架构如下图所显示:
事件配置框架则基于CoPilots框架,实现为下图:
目前实现的动态配置能力,典型的应用比如:
在高流量的环境下更新到期的服务端证书,这样就可以让业务完全不受影响,可以当前请求访问的还是老证书,下一个请求建立链接时,获得的就是新证书了。
另外的场景就是应用在灰度测试中,在生产环境中,正常的请求访问A集群,B集群部署了升级包,那么就需要引流部分请求到B集群进行验证和测试。这块就可以利用NJet的动态location能力,无需重起/reload,就可以实现,具体可以参考官网blog:http://njet.org.cn/cases/case-gray/