SnailJobPro版本
前言
为什么要做PRO版本?
原计划采用插件化方式实现功能扩展,但考虑到插件模式需在源码中预留大量插槽,开发和维护成本较高。同时,许多用户反馈在实际使用中插件管理较为繁琐,通常需要安装和配置多个插件,影响使用体验。 综合考虑后,我们决定将核心插件功能直接集成到 PRO 版本源码中,以简化使用流程,提升系统的可维护性和用户体验。 此外,SnailJob 的架构本身具备支持海量任务调度的能力,但受限于数据库层面的性能瓶颈,难以完全发挥系统潜力。因此,我们在 PRO 版本中对底层性能进行了专项优化,以更好地满足高并发、大规模任务调度的业务场景。
PRO版本与开源版本的发展方向?
- 开源版本:定位为轻量、易用,聚焦技术驱动,适合个人学习与中小型项目使用
- PRO 版本:在开源版本基础上扩展,面向企业场景,提供更完善的功能与性能优化,例如:单点登录、更灵活的权限体系、日志独立存储、Redis 缓存加速等,满足中大型项目的业务与稳定性需求。
开源版本是否阉割功能和继续维护
目前的开源版本功能足以满足大部分的公司的业务述求了不存在阉割的说法。 开源版本依旧持续维护大家放心使用
PRO版本定价多少?
- 1788元
PRO版本与开源版本的对比
基础能力: 表示目前开源版本所有的功能
功能 | 开源版本 | PRO版本 | 描述 |
---|---|---|---|
基础能力 | ✅ | ✅ | |
AI执行器 | ❌ | ✅ | (🔨持续更新) 【基于SnailJob开发的Ai智能客服近期就会上线】 |
日志独立存储 | ❌ | ✅ | 目前PRO版本采用mongo存储 |
任务维度日志清理功能 | ❌ | ✅ | 支持按照任务维度设置 保留条数和保留天数 |
支持动态配置SSO配置 | ❌ | ✅ | 支持RuoYi-Vue-Plus、钉钉、百度、GitHub、Gitee、微信、GitLab、Topiam等23种类型 |
系统日志 | ❌ | ✅ | 系统操作日志 |
服务端缓存改造 | ❌ | ✅ | 1.废弃DB分布式锁,采用Redis实现 2.全流程缓存优化处理 |
注册中心Redis改造 | ❌ | ✅ | 利用Redis 替代现在的DB模式 |
工作流执行跨组执行 | ❌ | ✅ | 【待实现(后面开源版本也会支持) 】 |
节点监控 | ❌ | ✅ | 系统JVM/CPU/内存等监控大盘【待实现】 |
体验地址
- 地址: https://pro.snailjob.opensnail.com/
- 账号: admin
- 密码: admin@snail123
常见疑问:
- 是否提供文档?有,提供项目运行、打包、部署等步骤文档
- 是否提供技术支持?提供一年内技术支持,购买授权后可以提问项目相关问题,一对一解答。(基础技术问题答疑,而非帮忙定制开发,请知悉)
- 项目后续更新是否免费升级?提供三年时间内免费升级服务。
- 我发现有人违规使用源码,是否可以举报?可以,恶意传播源码造成我方利益损失的,将追究相关法律责任,对举报者我们将做出实质性感谢。
🔥授权说明
购买商业版授权说明,采购添加微信 wnysd123 备注 SnailJobPro 了解更多细节。
- 谁购买谁可以商业使用(授权只覆盖一级授权人主体[1])
- 允许授权单位[1]以可运行jar、镜像等(非源码)方式向客户交付。
- 若授权单位[1]个别项目需要向客户[2]交付源码,客户[2]将无权修改源码二开商用,如涉及修改后二次商用(客户[2]修改交付代码后继续商用)必须重新购买授权。
注明:
- [1]:购买爱组搭、飞龙工作流等企业版源码的用户
- [2]:购买使用爱组搭、飞龙工作流等源码进行商业化软件开发的客户群体
场景案例
❗️授权遵守的原则:不可传递授权,即 A 为授权主体,商用给了 B 其中 B 是可以自用的,但是❌️不享受商用能力【B为非授权主体】需获取官方授权后✅️可商用。
场景案例一:
在这个场景中,假设软件开发公司(授权单位[1])开发了一个用于数据处理的软件,并授权给客户公司(客户[2])使用。根据授权协议,客户公司可以使用可运行的jar文件或镜像来部署和运行该软件。然而,如果客户公司需要访问源代码,他们必须重新向软件开发公司购买授权。一旦他们获得源代码,他们可以用于内部目的,但不能进行二次开发或修改并将其用于商业目的。如果客户公司修改了源代码并打算将其用于商业用途,他们必须重新购买授权。
场景案例二:
在这个场景中,假设软件服务提供商(授权单位[1])提供一种用于云存储的软件服务,并将其授权给云服务提供商(客户[2])。根据授权协议,云服务提供商可以使用可运行的jar文件或镜像来在其云平台上提供该服务。然而,如果云服务提供商需要访问源代码以进行定制或优化,他们必须重新向软件服务提供商购买授权。在获得源代码后,云服务提供商可以进行必要的修改,但不能将修改后的代码用于商业目的,除非他们重新购买了授权。
场景案例三:
在这个场景中,假设一个开源软件项目的维护者(授权单位[1])授权给一家IT咨询公司(客户[2]),该公司希望在其客户项目中使用该软件。根据授权协议,IT咨询公司可以使用可运行的jar文件或镜像来集成该开源软件到他们的项目中。然而,如果该公司需要对软件进行定制以满足其客户的特定需求,他们必须重新向软件维护者购买授权以获取源代码。一旦获得源代码,IT咨询公司可以根据需要进行修改,但不能将修改后的代码用于商业目的,除非他们重新购买了授权。