OpenNJet v2.0.0:动态能力迈入全新篇章
NGINX 向云原生演进,All in OpenNJet
OpenNJet 应用引擎是基于 NGINX 的面向互联网和云原生应用提供的运行时组态服务程序,作为底层引擎,OpenNJet 实现了NGINX 云原生功能增强、安全加固和代码重构,利用动态加载机制可以实现不同的产品形态,如Web服务器、流媒体服务器、负载均衡、代理(Proxy)、应用中间件、API网关、消息队列等产品形态等等。在云原生架构中作为数据平面,OpenNJet除了提供南北向通信网关的功能以外,还提供了服务网格中东西向通信能力。在原有功能基础上增加了透明流量劫持、熔断、遥测与故障注入等新功能特性。
在最新发布的v2.0.0版本中,对基础框架进行了大幅优化,增加对HTTP/3的支持,进一步丰富了OpenNJet的生态,动态能力逐渐成熟。此次更新主要包括以下五个方面:
- 基础框架大幅优化。框架的优化对于 CoPilots 进行了加固,实现了lua vm、高权限执行框架、配置沙箱等能力,从而进一步提高 OpenNJet 的稳定性以及执行效率。
- 成熟的动态能力。对模块继续进行动态化改造,优化了动态证书管理,覆盖企业灰度发布等关键场景,动态 location 能力在 v2.0.0 已经进入成熟阶段。
- 加入新协议 HTTP/3 。主要实现了 HTTP/3 的 Server 能力,以及 ftp 协议的代理能力。在安全的基础上实现灵活的负载均衡
- 继续强化高效安全。强化系统安全,加固自身;实现了业务安全,业务修复无损性能,更好的保护数据、提供可靠的服务,并简化运维任务。
- 两个企业特性。实现集群的基本构建,从而避免在故障转移、集群扩容新增加节点等人工操作,减少业务中断时间而无损性能;尝试引入智能化,合理分配资源。
基础框架优化
相比 OpenNJet v1.0.0,OpenNJet v2.0.0 对前期实现的基础框架做了大幅优化。CoPilot 框架方面:
- 首先,优化了 CoPilot 的监督机制,允许 OpenNJet Reload 时CoPilot 不重启,以保证 OpenNJet 事件总线的稳定性;
- 同时,可以根据职能为 CoPilot 配置不同的权限,使得 CoPilot 可以具备网络、内核等系统级别的能力;
- 最后,把 CoPilot 接入统一的事件总线,使得 CoPilot 的实现天然具备动态配置、同其他模块以及CoPilot交互的能力。
根据这个框架, v2.0.0 对 v1.0.0 实现的 CoPilots 包括ctrl、HA、broker 都进行了加固,并实现了lua vm、高权限执行框架、配置沙箱等能力,满足了上层功能,尤其是OpenNJet-Kubernetes Ingress Controller(以下简称:KIC)方面的需要。
配置沙箱是 OpenNJet v2.0.0 开发的主要特性之一。所有的动态配置,都需要经过配置沙箱的验证,然后应用到 OpenNJet 中,从而极大地提高 OpenNJet 本身的稳定性,确保不因新配置的缺陷影响到 OpenNJet 数据面的稳定性及执行效率。
OpenNJet 中的外部接口,采用了 OpenAPI 标准协议。为了减轻协议服务端实现的开发难度,避免人为的错误造成对系统稳定性的影响,OpenNJet v2.0.0 开发了对应的 JSON Schema 2c 的代码生成工具,利用 Schema 描述业务校验标准,并生成对应的 C 代码,对 v1.0.0 段实现的所有接口做改造,从而进一步提高 OpenNJet 的稳定性。
动态能力
在动态能力这块,OpenNJet v2.0.0 继续根据上层应用的需要或合作伙伴的反馈,对模块进行动态化改造,优化了动态证书管理,使其可以同时动态配置 RSA / ECC / 国密证书,并修复了v1.0.0 存在的证书管理的幂等性问题。
Map 指令也实现了动态化,以便应用到 KIC 中,实现 OpenNJet KIC 最重要的特性——应用间的配置隔离;此外,动态 TCP 流量劫持为 KIC 实现通用 TCP 协议代理的支持提供了保障。随着动态 location 可以配置复杂的表达式路由,可以覆盖企业需要的灰度场景,并在 Sidecar / KIC 等内部得到了广泛利用,现在可以说 OpenNJet 的动态 location 能力在 v2.0.0 已经进入成熟阶段。
加入新协议 HTTP/3
新协议是 OpenNJet v2.0.0 开发的重点内容。在本周期内,OpenNJet 主要实现了 HTTP/3 的 Server 能力,以及 ftp 协议的代理能力。依赖于底层的动态 TCP 流量劫持,OpenNJet 实现了 pasv ftp / sftp 支持,可以动态在 proxy 部署的机器上开关 ftp 数据传输的端口,保证安全的基础上实现灵活的负载均衡。
HTTP/3 在协议的解析上继承于 NGINX , OpenNJet HTT/P3的代码一直跟踪并及时合并,目前已合并到 v1.25.3 。OpenNJet 在 HTTP/3 的工作主要是做动态化改造,即在 HTTP/3 协议下,OpenNJet也可以动态维护证书,添加Virtual Server。另外则是适配国密、安全加固的改造,国密标准在 HTTP/3 上尚未出台的情况下,基于 rfc8998,HTTP/3、国密已经通过,当然,由于缺乏相关的客户端和浏览器支持,在本阶段,OpenNJet 也改造了相应的Client 及工具:xquic(支持rfc8998)、curl(HTTP/3)、HTTP/3 性能测试工具等等。
继续强化高效安全
安全,是 OpenNJet 一直秉持的重要任务。OpenNJet v2.0.0 主要包括以下两部分:
- 强化系统安全,避免 OpenNJet 自身成为短板。在 v2.0.0 代码开发周期中,继续强化安全开发,在对外的 API 接口中,实现了 ACL 的访问控制,并可以根据读写进行更细粒度的权限划分;在和外部系统集成时,统一使用 TLS / HTTPs,也避免明文存储认证信息;优化了事件总线,尽量暴露出本机 /unix socket 的通讯接口,而不是外界可以访问的 TCP 端口。
- 实现业务安全,通过引入并发连接限制、并发请求限制、RPS 限制,OpenNJet 可以减缓 DOS/DDOS 对 OpenNJet 以及所代理的后端业务的冲击,保证服务的可持续性;并且通过 HA+sharding 特性,平滑应对正常业务波动的需求。针对频发的 Web 类安全威胁,OpenNJet在 v2.0.0 阶段也引入了 ModSecurity,并对其做了动态化改造。从而在某威胁暴露时,可以临时动态打开进行安全加固,并在应用修复完成时及时关闭以避免影响性能。
优秀企业特性
除上述功能介绍外,OpenNJet 在 v2.0.0 中还实现了两个优秀的“企业”特性:
一、集群上的同步。在 v1.0.0 中,OpenNJet 实现了基本的集群构建能力,在 v2.0.0 中进一步实现了配置和状态的同步,无论是 HA 的主备间,还是 MA 的多节点间,对活跃节点上的配置操作,可以及时反馈到其他节点上,从而避免了在故障转移、集群扩容新增加节点等情况下的人工操作,减少了业务中断的时间。
二、尝试引入了智能化。因为一个系统的资源需求是随时间弹性变化的,按最高需求估算大多数情况下存在极大的浪费,而不按照最大估算配置则会存在故障,进而形成“雪崩”。OpenNJet 会尝试根据业务的负荷情况按需申请资源,并在不需要时及时释放。
逐步丰富生态
在丰富生态方面,OpenNJet继续稳步推进。
首先,OpenNJet适配了不同的操作系统,尤其是国产化的操作系统。
其次,扩展了系统集成,目前除Prometheus对外的指标输出外,可通过SNMP协议向外输出指标。值得一提的是,这里就利用了前面描述的CoPilot:lua vm。通过和前端ADC设备的集成,OpenNJet 解除了单点的性能限制,可以通过 Sharding 机制、水平扩展以应对企业更高的业务需要。在 v2.0.0 阶段,OpenNJet 实现了和云科通明湖负载均衡设备及 F5 负载均衡设备的适配,而 CoPilot 机制使得 OpenNJet 具备了在现场由运维工程师对接其他设备的能力。
再次,落实 OpenNJet 的应用部署形态。OpenNJet 的全景视图是成为云计算领域的基础,落实到目前的广泛应用的 k8s 集群及服务网格,也就是Sidecar / KIC / 应用容器。在 v1.0.0 阶段,Sidecar 已经发布,而伴随 v2.0.0的则是 OpenNJet KIC,其详细功能不在此赘述,大家可以参考后文提供的介绍文档。
除了 KIC 外,v2.0.0 新特性之一的应用加速,则是 OpenNJet 脱离 DC 应用到边缘计算节点的尝试。利用 cache 特性,并通过动态 location 按需构建需要缓存的内容,主动推送内容到 cache 实现“预热”,保证了边缘节点对应用内容的访问,维持一致的高速体验。
致谢
整个开发周期历时半年,共实现了 21 项新功能,增强功能 23 项,修复Bug 31 项,开发了配套工具 4 项,适配了 openEuler 及 OpenCloudOS 操作系统。在开发过程中,OpenNJet v2.0.0 采用快速迭代的方式,共推送 7 次小版本,积极响应社区及企业需求。在此,也感谢在开放原子基金会的大力支持与推广,感谢来自于浪潮、招商银行、工商银行的需求输入以及测试反馈,感谢众多贡献者们的倾情奉献!
参考链接:
OpenNJet KIC v1.0 发布!K8s Ingress Controller:https://njet.org.cn/cases/opennjet-kic-v1.0-%E5%8F%91%E5%B8%83k8s-ingress-controller/
【实战经验】如何动态配置 NGINX Map?:https://my.oschina.net/u/6606114/blog/10116956
一文带你从了解到搭建 HTTP/3 Web 服务:https://my.oschina.net/u/6606114/blog/10112475
【最佳实践】利用 OpenNJet 实现灰度发布:https://njet.org.cn/cases/case-gray/
OpenNJet 最早是基于 NGINX1.19 基础 fork 并独立演进,具有高性能、稳定、易扩展的特点,同时也解决了 NGINX 长期存在的难于动态配置、管理功能影响业务等问题。 邮件组 官网
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
有了向量数据库,我们还需要 SQL 数据库吗?
“除了向量数据库外,我是否还需要一个普通的 SQL 数据库?” 这是我们经常被问到的一个问题。如果除了向量数据以外,用户还有其他标量数据信息,那么其业务可能需要在进行语义相似性搜索前先根据某种条件过滤数据,例如: 在法律领域,可能只需要从某个特定数据库中搜索相关的法律条款; 在零售业,可能需要搜索某个尺码的男鞋; 在图像搜索时,可能希望搜索 2010-2016 年上映且 IMDB 电影评分高于 7.0 的电影的海报。 对此,我们的答案是——不需要。用向量数据库 Milvus 或全托管的 Milvus 服务——Zilliz Cloud,就无需额外再维护一个 SQL 数据库存储标量了。只要一个系统,用户便可起送实现“向量搜索+标量过滤”的混合查询,从而获取更精准的搜索结果。 其中,Milvus 允许用户在进行向量搜索时依据标量数据进行条件过滤,数据属性可以是除向量以外的任何字段。Milvus 会对向量字段创建向量索引并进行向量相似性搜索,与此同时,还可以通过表达式对搜索结果进行元数据过滤。只需在搜索时输入过滤表达式,Milvus 就会帮你自动进行这两种操作。 本教程使用 Zilliz Cl...
- 下一篇
Simple Admin Go 语言分布式后台管理系统 v1.3.0 发布
Simple Admin - Go 语言分布式后台管理系统 v1.3.0 更新 项目介绍 Simple Admin 是一个开箱即用的分布式微服务后端管理系统,基于go-zero开发,为开发中大型后台提供了丰富的功能,支持三端代码生成。 官方自带多种扩展,助力中小企业快速上云,快速迭代。适合用于微服务学习和商用,开源免费。 Simple Admin Core / Job / MCMS / FMS / Common v1.3.0 更新 介绍 核心模块 Core, 定时任务模块 Job, 消息中心模块 MCMS, 以及文件管理模块 FMS 均已升级至 v1.3.0 本次更新 新增(Common): NewRedis 和 NewRedisCluster 方法合并为 NewUniversalRedis, 使得 redis 同时支持单体和集群 优化(Common): Captcha store 使用 universal redis 重构(Core): errorhandler 包重构为 dberrorhandler 新增(Core): token 新增 username 字段,方便后台查看 优化:...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8安装Docker,最新的服务器搭配容器使用