从Neutrino-Proxy(中微子代理)到Solon Native

原创
2023/11/02 12:12
阅读数 104

Neutrino-Proxy(中微子代理)是啥

项目简介

主要特点:

  • 1、流量监控:首页图表、报表管理多维度流量监控。全方位掌握实时、历史代理数据。
  • 2、用户/License:支持多用户、多客户端使用。后台禁用实时生效。
  • 3、端口池:对外端口统一管理,支持用户、License独占端口。
  • 4、端口映射:新增、编辑、删除、禁用实时生效。
  • 5、Docker:服务端/客户端支持Docker一键部署。
  • 6、SSL证书:隧道通信支持SSL加密,保护您的数据安全。
  • 7、域名映射:支持绑定子域名,方便本地调试三方回调
  • 8、多种协议:支持代理TCP、HTTP、HTTPS、UDP协议
  • 9、原生部署:支持编译为原生可执行文件,更低部署门槛、更少内存占用
  • 10、采用最为宽松的MIT协议,免去你的后顾之忧

为什么开发Neutrino-Proxy(中微子代理)

2022年4月份左右,因工作原因需要用到内网穿透。此前一段时间使用的coplar,由于公司担心带来安全隐患, 因此决定自己研究一下这一块。

对于常年写业务代码的一介码农来说,内网穿透就是一个黑盒。为了打开这个黑盒,我开始到处找相关的开源项目,其中包括lanproxy、ngrok、nps、frp等。

经过一翻努力,2022年6月份,实现了中微子代理1.0.0。此版本纯粹为了练手, 所以是基于自己手写的一套底层框架(包含Ioc、Aop、SqlMaper(简易版本的mybatis)、xxljob等), 实现了客户端/服务端+纯配置文件版本的TCP代理。

千里之行,始于足下。1.0.0版本发布后,经过不断的迭代,如今2.0.0版本终于和大家见面了。

为什么选择Solon

中微子1.0.0版本发布之后,大约7~8个月的时间,进行了大量的更新,主要围绕在底层基础框架、 管理后台这一块。

此时中微子陆陆续续开始有了一些用户,开始迫切的需要加快代理相关功能的迭代进度。而此时自己手写 的底层框架成为了最大的掣肘,单单底层框架各种细节优化、测试、参考借鉴其他框架源码这些就足以耗光 我为数不多的业余时间,更别提在这个尚不成熟的框架上开发代理功能了。任何一次底层的优化调整,可能带来的 是上层代理功能的大量重构。

于是,我开始搜寻其它替代框架。因日常工作一直都在用Spring体系,我始终相信多种技术两相印证之后学到的东西更为深刻,所以自己的开源项目始终将Spring体系作为优先级最低 的选项。最终一个或偶然、或必然的机会,我了解到了Solon。

经过对Solon项目源码、官网文档、项目更新频率、生态完善度的深入了解,最终决定选择Solon作为中微子代理的底层框架。

2023年3月12日,中微子代理1.7.0版本发布,开始正式基于Solon框架。 2023年10月30日,中微子代理2.0.0版本发布,基于Solon Native实现原生部署。

Solon简介

项目简介

主要特性

启动快 5 ~ 10 倍;qps 高 2~ 3 倍;运行时内存节省 1/3 ~ 1/2;打包可以缩到 1/2 ~ 1/10

  • 克制、简洁、高效、开放、生态
  • 支持 JDK8、JDK11、JDK17、JDK21
  • Http、WebSocket、Socket 三种信号统一的开发体验(俗称:三源合一)
  • 支持“注解”与“手动”两种模式,按需自由操控
  • Not Servlet,可以适配任何基础通讯框架(最小 0.3m 运行rpc架构)
  • 独特的 IOC/AOP 容器设计。不会因为插件变多而启动变很慢
  • 支持 Web、Data、Job、Remoting、Cloud 等任何开发场景
  • 兼顾 Handler + Context 和 Listener + Message 两种架构模式
  • 强调插件式扩展,可扩展可切换;适应不同的应用场景
  • 支持 GraalVm Native Image 打包
  • 允许业务插件“热插”、“热拔”、“热管理”

最后说点什么

开源实属不易,开源国产生态型基础框架更是举步维艰。不仅需要长时间、持续、稳定的投入迭代、测试、文档撰写、bug修复、发版、推广, 还经常需要面对来自四面八方汹涌如潮的质疑。

时光无言,它磨灭了一切、也证明着一切。

一千八百多个日日夜夜、五年的风雨兼程,Solon生态已经初具规模,社区汇聚了一大批开源爱好者。

大鹏一日通风起,扶摇直上九万里。我相信国产开源在大家的努力下,一定会越来越好!

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部