3.x和4.x区别
注意
4.16.0 版本后，4.x的none模式正式开源。源码地址位于lamp-cloud项目的4.x_java17分支。
4.x 的数据源模式和字段模式需要赞助后，方可使用。
本节文档适合老用户观看，新接触此项目的用户，只需要理解3.x和4.x是使用相同的技术栈来实现的不同多租户场景和功能的2个完全独立的项目即可，3.x版本不能无缝升级到4.x。
下面列出详细变化：
点我体验： 4.x赞助版(数据源模式)
点我体验： 4.x赞助版(字段模式)
点我体验： 4.x赞助版(非租户模式)
菜单对比
| 3.x | 4.x | ||||
|---|---|---|---|---|---|
| 1级菜单 | 2级菜单 | 备注 | 1级菜单 | 2级菜单 | 备注 |
| 租户设置 | 数据源配置 | 管理数据源模式，租户的自定义数据源 | 开发运营系统 租户管理 | 数据源维护 | |
| 租户管理 | 创建租户 | 租户维护 | |||
| 超级用户 | 管理所有租户的登录账号 | 用户维护 | |||
| 工作台 | 通知公告 | 查看自己的站内通知 | 基础平台 消息中心 | 我的消息 | |
| 待我审批 | 未实现 | - | |||
| 我已审批 | 未实现 | - | |||
| 我发起的 | 未实现 | - | |||
| 组织管理 | 机构管理 | 管理当前租户的组织、机构、公司、部门等数据 | 基础平台 用户中心 | 组织机构 | |
| 岗位管理 | 管理当前租户的岗位 | 岗位维护 | |||
| 用户管理 | 管理当前租户的用户 | 员工维护 | |||
| 资源中心 | 消息中心 | 管理员方发送当前租户的站内信 | 基础平台 消息中心 | 消息管理 | |
| 短信模板 | 管理当前租户的短信模板 | 开发运营系统 运维平台 | 消息模板 | 管理整个系统的全局消息模板 | |
| 短信中心 | 管理测试发送当前租户的短信 | 消息模板 测试发送消息 | 测试整个系统的全局消息模板是否能被正常发送 | ||
| 附件管理 | 管理当前租户的附件 | 开发运营系统 系统管理 | 附件管理 | 管理默认库的附件 | |
| 流程管理 | 流程部署 | 管理当前租户的流程 | 基础平台 流程管理 | 流程部署 | |
| 模型管理 | 管理当前租户的模型 | 模型管理 | |||
| 请假流程 | 当前租户的一个简单请假流程示例 | - | |||
| 报销流程 | 当前租户的一个简单报销流程示例 | - | |||
| 系统设置 | 菜单管理 | 管理当前租户的菜单、按钮等 | 开发运营系统 应用管理 | 资源维护 | 管理全局的菜单、视图、按钮、字段、数据 |
| 角色管理 | 管理当前租户的角色和授权信息 | 基础平台 系统功能 | 角色权限维护 | ||
| 字典管理 | 管理当前租户的字典 | 开发运营系统 系统管理 | 字典维护、数据字典、字典管理 | 管理全局的字典 | |
| 地区管理 | 管理当前租户的地区 | 地区维护 | 管理全局的地区 | ||
| 参数管理 | 管理当前租户的参数 | 参数维护 | 管理全局的参数 | ||
| 操作日志 | 管理当前租户的操作日志 | 操作日志 | 管理全局的日志 | ||
| 登录日志 | 管理当前租户的登录日志 | 登录日志 | 管理全局的日志 | ||
| 应用管理 | 管理当前租户的应用 | 客户端维护 | 3.x的应用管理改名为客户端 | ||
| 在线用户 | 管理当前租户的在线用户 | - | |||
| 网关管理 | 限流规则 | 管理当前租户的URI限制访问规则 | - | ||
| 阻止访问 | 管理当前租户的黑名单规则 | - | |||
| 开发者管理 | 定时任务 | 开发运营系统 开发者管理 | 分布式定时任务 | ||
| 接口文档 | Swagger文档 | ||||
| nacos | nacos | ||||
| 服务监控 | 服务器监控 | ||||
| 数据库监控 | 数据库监控 | ||||
| 缓存监控 | - | ||||
| zipkin监控 | - | ||||
| SkyWalking监控 | SkyWalking | ||||
| 了解lamp | 开发运营系统 了解lamp | ||||
| 更多功能 | 开发运营系统 静态示例 | ||||
4.x 新增的功能
| 系统 | 1级菜单 | 2级菜单 | 说明 |
|---|---|---|---|
| 开发运营系统 | 应用管理 | 应用维护 | 管理全局的应用 |
| 应用资源授权 | 给租户授权应用 | ||
| 应用授权记录 | |||
| 开发者管理 | 代码生成 | 给开发人员使用的可视化代码生成器 | |
| 项目生成 | 给开发人员使用的可视化代码生成器 | ||
| 开发示例 | 使用代码生成器生成出来的代码 | ||
| MinIO | |||
| 文件预览 | |||
| Jenkins | |||
| 运维平台 | 接口管理 | 管理全局的接口信息 | |
| 接口日志 | 全局的接口执行日志 | ||
| 基础平台 | 我的应用 | 当前租户已经购买的应用(普通用户使用) | |
| 应用管理 | 已购应用 | 当前租户已经购买的应用(管理员使用) | |
| 消息中心 | 个性消息模板 | 当前租户的消息模板 | |
| 基础配置 | 个性字典 | 当前租户的字典 | |
| 个性参数 | 当前租户的参数 | ||
| 系统功能 | 附件管理 | 当前租户的附件 | |
| 操作日志 | 当前租户的日志 | ||
| 登录日志 | 当前租户的日志 |
一、项目拆分
提示
项目名含有pro表示 4.x 赞助版，项目名含有plus表示 3.x 赞助版和个人学习版，不含 pro 或 plus 的表示对应的开源版。
3.x 版本，通过配置即可任意切换租户模式，3.x 的全部项目包括：
- lamp-util（lamp-util-plus）：工具类
- lamp-cloud（lamp-cloud-plus）： spring cloud 版 后台
- lamp-boot（lamp-boot-plus）：spring boot 版 后台
- lamp-web：前端
- lamp-web-plus： vue3 + ant design vue 版 前台 (仅赞助版拥有)
- lamp-job（lamp-job-plus）： 定时任务
- lamp-generator（lamp-generator-plus)： 代码生成
4.x 之后，除了 lamp-util-pro、lamp-web-pro、lamp-job-pro 等工具类项目会共用， 还将lamp-cloud按照租户的模式拆分成了3个项目，将lamp-boot按照租户的模式拆分成了3个项目：
同时废弃独立的 lamp-generator 项目，在lamp-cloud和lamp-boot内部集成可视化在线代码生成器服务lamp-generator-server。
工具集
| 项目 | Gitlab | 备注 |
|---|---|---|
| lamp-util | lamp-util-max | 核心工具集 |
| lamp-job | lamp-job-max | 分布式定时调度器 |
后端
| 项目 | datasource模式（gitlab） | column模式（gitlab） | 备注 |
|---|---|---|---|
| 后端工程 | lamp-datasource-max | lamp-column-max | 微服务&单体融合版 |
| 项目 | none模式（gitee） | none模式（github） | 备注 |
|---|---|---|---|
| 后端工程 | lamp-cloud | lamp-cloud | 微服务&单体融合版 |
前端
| 项目 | gitee | 备注 | 演示地址 |
|---|---|---|---|
| lamp-web-pro | lamp-web-pro | 基于 vue-vben-admin （vue 3 + ant design vue 3） | https://datasource.tangyh.top |
| lamp-web-pro-soybean | lamp-web-pro-soybean | 基于 soybean-admin （soybean-admin、fast-crud、vxe-table） | https://soy-datasource.tangyh.top |
| 项目 | gitee | github | 备注 | 演示地址 |
|---|---|---|---|---|
| lamp-web | lamp-web | lamp-web | 基于 vue-vben-admin （vue 3 + ant design vue 3） | https://none.tangyh.top |
二、 服务合并
为了方便新手入门、降低系统部署成本、降低系统复杂度，隧对服务做了合并。
| 3.x 拥有服务 | 4.x 拥有服务 |
|---|---|
| lamp-authority-server | lamp-base-server |
| lamp-file-server | lamp-base-server |
| lamp-msg-server | lamp-base-server |
| lamp-oauth-server | lamp-oauth-server |
| lamp-tenant-server | lamp-system-server |
| lamp-gateway-server | lamp-gateway-server |
| lamp-generator(独立项目) | lamp-generator-server(仅一个微服务) |
- lamp-system-server： 对应开发运营系统的功能接口
- lamp-base-server: 对应基础平台的功能接口
- lamp-oauth-server：对应登录、菜单获取、权限获取、个人信息获取等
- lamp-gateway-server：路由、token鉴权、URI鉴权等
- lamp-generator-server: 在线代码生成器服务。3.x中lamp-generator是一个独立的项目，只能根据在单元测试中写代码的方式来生成前端和后端代码，4.x的则升级为在线配置的方式，在页面上填写必要的参数即可生成、下载、预览前端、后端代码
合并原因？file 和 msg 服务的业务比较单一，而且也是比较基础的功能
三、 datasource模式数据库变化
为了方便新手入门、降低系统部署成本、降低系统复杂度，隧对租户数据库做了合并。
| 3.x 拥有数据库 | 4.x 拥有数据库 | 备注 |
|---|---|---|
| lamp_defaults | lamp_ds_c_defaults | 所有租户都相同的数据放在默认库 |
| lamp_base_{租户编码} | lamp_base_{租户ID} | 租户自己的数据，放在base库 |
| lamp_extend_{租户编码} | lamp_base_{租户ID} |
- datasource_column 模式库名为：lamp_ds_c_defaults、lamp_base_{租户ID}
- datasource 模式库名为：lamp_defaults、lamp_base_{租户ID}
- column 模式库名为：lamp_column
- none 模式库名为：lamp_none
合并后，也支持1个租户配置多个租户库，但需要自行修改配置文件来实现调整数据库。
四、 租户数据的使用发生变化
3.x 除了租户的创建相关的表和数据是全局库(lamp_defaults库)，所有的租户数据都在租户库(lamp_base_xxx或lamp_extend_xxx) 。 这样做的好处是方便租户拥有自己个性数据，但弊端也很明显，对于一些全局数据，每个租户都需要自己维护一份，后面全局数据发生改变，需要去每个租户库分别修改全局数据。 比如： 菜单、字典等数据。
注意
对于菜单的配置，应该是全局仅有一份，而且只有让系统开发方进行增删改操作。租户应该只有菜单的授权操作，即给不同的角色分配不同的菜单。
对于字典数据，应该是全局有一份系统内置的字典，租户拥有一些自定义字典项（字典是字典的分类，字典项是字典的明细），租户可以新增、修改或删除字典项，但不会对全局字典造成影响。租户读取字典数据时，应先查询自己是否有自己的字典，若自己没有配置个性的字典，在读取系统全局的字典。
上述的功能在3.x是不支持的，但在4.x得到了很好的解决。
五、 功能变化
菜单管理：更名为：资源维护
3.x 的菜单管理，需要每个租户都维护1份
菜单(c_menu) 和资源(c_resource)，即c_menu和c_resource存放在租户库（lamp_base_xxx），当菜单变动时，需要调整所有租户的菜单数据。4.x 的资源维护 将应用、菜单、按钮、字段、数据、接口 统称为资源，其中接口存放在 def_resource_api 表、应用存放在def_application表、其余资源存放在
def_resource表通过type字段区分，且存放在全局的lamp_defaults库。资源应该是全局的，新增、修改或删除
菜单、按钮、字段、数据时，只需要调整全局的资源数据，就可以影响到所有的租户。 而资源数据是不允许租户自己修改的，所以资源相关的表移动到了lamp_defaults库。提示
下文中提到的资源是这几种类型的一个统称，根据上下文可以是任意一种类型的资源， 甚至应用都可以理解为一种资源，因为应用是需要分配权限的。应用是给企业授权，资源是给企业下的员工授权。
- 菜单：页面上可以看见的菜单或隐藏的菜单，可以是1级、2级、n级 （有些系统会区分为目录和菜单，本系统都统称为菜单）
- 按钮：页面上的新增、删除、修改、导入、下载等按钮。
- 字段：控制页面上不同人，能看到不一样的字段。 可以控制显示、隐藏、脱敏、是否可以编辑等。
- 接口：又称URI、API，菜单或视图调用的所有接口，员工拥有菜单或视图后，就应该拥有此菜单或视图下的所有接口权限。
角色管理：更名为 角色权限维护
4.x和3.x功能上没有太大的调整，但在3.x基础上增强了角色管理的逻辑：
- 3.x版本每次新增一个资源，都需要给每个租户的超管绑定这个新增的资源, 4.x 的每个租户都内置一个租户管理员，租户管理员默认拥有管理租户的所有权限，且他的权限是无需分配和删除的，后期系统新增资源，也无需分配权限给这个租户管理员角色。
- 给角色绑定资源时做了限制：①勾选了子资源，必定要勾选所有的父资源； ②取消了父资源，必定取消所有的子；③页面操作上新增了资源全选功能；
- 支持给角色绑定员工，为了优化员工过多的问题，调整为实时绑定、实时取消绑定。
字典管理：更名为字典维护，同时支持租户新增自己的 个性字典
3.x 的字典管理，需要每个租户都维护1份字典数据， 即c_dictionary存放在租户库（lamp_base_xxx），所有租户都需要维护整个系统所需要的全部字典， 当字典变动时，需要调整所有租户的字典数据。
4.x 分为字典维护和个性字典，字典维护功能管理全局的字典，个性字典管理每个租户自己的字典项，租户可以新增、修改或删除自己的字典项，且不会对全局字典造成污染。租户读取字典数据时，会先查询自己是否配置了个性化字典，若没有配置个性化字典，在读取系统全局的字典。
参数管理：参数维护 + 个性参数
同 字典维护 + 个性字典
地区管理：地区维护
增加了导出地区json文件的功能，地址数据调整后，重新生成json文件，供前端使用。前端选择级联地区数据时，直接读取json文件内容，加快响应速度。
应用管理：客户端维护
维护你们系统的客户端，比如：小程序端、安卓端、IOS端、WEB端等，然后将client_id和client_secret分配给对应的客户端，接口请求时后台接口时，携带client_id和client_secret， 方便日后做统计或其他限制。
登录日志：登录日志 + 登录日志
在基础平台的登录日志是租户自己的登录日志，在开发运营系统查看的登录日志是所有租户的登录日志。
六、 新增的功能
租户体系
在3.x的基础上，4.x 优化了以下功能：
- 租户在线创建
- 在线初始化各个微服务数据源
- 在线初始化各个租户的数据库建表脚本和初始数据
- 每个租户的数据源失败重连
- 数据源链接情况查看
- 租户拥有的应用授权、续期、查看
- 租户拥有的租户管理员绑定、解绑、查看
应用-资源体系
平台级的SAAS系统，往往拥有多个自建应用或第三方应用，在 应用管理 ->应用维护 中创建好自建应用，配置好应用的资源，然后给企业授予相应的应用权限后， 用户即可切换到对应的应用，并使用应用下的功能。 对于第三方应用 经过简单的单点登录对接，即可实现单点登录。
同时，给企业授权应用时，还支持给不同的企业授权不同的资源，即对于同一个应用，不同的租户可以拥有不同的功能（菜单）。 资源包括应用、菜单、视图(可以理解为隐藏菜单)、按钮、字段、接口 （URI）等，应用是一种特殊的资源。
用户体系
3.x 系统中，一个用户，若同时属于多个租户，必须创建多个账号。
4.x 用户体系，使用身份证(或其他唯一标识)作为用户的唯一标识，当你属于多个租户时，用户在登录系统后，可以切换自己的身份，即可操作不同租户的数据。而每个租户通过员工表和全局用户表做好映射。
员工体系
- 每个员工可以有多个部门，并设置主部门
- 可以给部门分配一个部门的角色，部门下的员工拥有部门角色的权限
- 可以给员工分配角色
- 也可以在角色界面绑定员工
七、 分层
3.x 应用分层采用 Controller -> Service -> Mapper ，领域模型采用DTO、Entity。
4.x 应用分层采用 Controller -> Biz -> Service -> Manager -> Mapper ，领域模式采用VO、DTO、Query、Entity等。
提示
3.x 的分层是最简单，最易于理解的分层，但随着不断的出现复杂的业务，所有逻辑都放在Service层已经不在合适，故而对其改造。但3.x和4.x的分层，并没有绝对的谁好谁坏，对于业务极其简单，只为快速交付的项目，3.x的分层更加便捷；而4.x的分层更适合于长期迭代、业务复杂、对接第三方的系统。
应用分层 （借鉴阿里规范，调整成适合本项目的分层模型）
图中默认上层依赖于下层，箭头关系表示可直接依赖，如：开放接口层可以依赖于
Controller 层，也可以直接依赖于 Biz、Service 层，依此类推。
开放接口层：开放给其他第三方调用的接口，可直接封装Service方法暴露成PRC接口；通过Web封装成HTTP接口等
终端显示层：各个端的默认渲染层。如：模板引擎渲染、移动端展示、Vue展示等
请求处理层（Controller）：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等 。
分布式事务业务逻辑层（Biz）（可选）：具于分布式事务、跨库操作（查询和写入）的业务逻辑服务层。
若业务无分布式事务或跨库操作Controller可以直接调用Service层；若Biz层涉及切换数据库，Biz层一定不能加
@Transactional注解，否则动态数据源跨库操作将会失效。业务逻辑层（Service）：相对具体的业务逻辑服务层，只保证单个数据源本地事务。对多个Manager的组合复用。
通用处理层（Manager）：通用业务处理层， 它有如下特征：
1） 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理。
2） 与 DAO 层交互，对多个 DAO 的组合复用。
3） 继承Mybatis-plus的ServiceImpl接口，封装了单表的业务操作。
数据持久层（Mapper/Dao）：数据访问层，与底层 MySQL、Oracle、Hbase、OB 等进行数据交互。
缓存或第三方接口：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。
注意
biz的方法都是跨数据源或跨服务的且需要保证事务的
service的save方法更加贴切实际业务,可操作多个表，并组合逻辑
manager 的save方法只负责单个表的保存操作(可以对字段进行一些默认值设置)
mapper 的insert 方法只负责原封不动的插入数据库。
调用只能从上往下，不能反着调用，最好也不要平层调用，严禁平层交叉调用。
领域模型
- Entity： 跟数据库表一一对应
- DTO：数据传输对象，Service或Manager 使用的对象
- Query：数据查询对象，各层接收上层的查询请求。建议超过3个参数的查询进行封装。
- VO：显示层对象，Controller层接收和返回参数。
八、请求头
3.x 版本，系统每次请求携带的请求头为：
- Authorization: Basic {Base64加密的客户端id和密码}
- tenant: {Base64加密的租户编码}
- token: Bearer {JWT 生成的token}
4.x 版本，系统每次请求携带的请求头为：
- Authorization: {Base64加密的客户端id和密码}
- TenantId: {雪花算法生成的租户ID}
- Token: {JWT 生成的token}
- ApplicationId: {雪花算法生成的应用ID}
- Path: [可选]当前访问页面的路由地址，仅数据权限页面需要携带
- gray_version: [可选]灰度版本号， 仅灰度发布或服务隔离时需要携带
区别：
- Authorization的值去除了Basic前缀。
- tenant(加密租户编码)变更为TenantId(雪花租户ID)。
- token变更为Token，并将值除去了Bearer前缀。
- 新增了ApplicationId（雪花应用ID），用于记录请求来自那个应用。
调整理由： 方便新手入门成本、降低出错率、降低系统复杂度。Base64加密无加密意义，还徒增项目的复杂度。
有朋友可能觉得不加密不安全，可以自行思考如何进行安全的加密传输。
- 可以使用 https 协议
- 请求头明文参数不安全，普通的参数明文传输就安全了吗？请求头要加密，普通参数也要想办法加密。
- 3.x版本使用Base64加密请求头基本无意义，因为直接Base64解密即可。
九、权限配置、分配和鉴权
名词解释：
| 异同点 | 3.x | 4.x |
|---|---|---|
| 在那配置资源？ | 系统管理 -> 菜单管理 | 开发运营系统 -> 应用管理 -> 资源维护 |
| 在那分配权限？ | 系统管理 -> 角色管理 | 1. 基础平台 -> 系统功能 -> 角色权限维护 2. 用户中心 -> 员工维护 |
| URI权限在那鉴权？ | 后端服务AOP拦截鉴权 | 网关统一拦截URI请求鉴权 |
| 按钮权限在那鉴权？ | 自定义指令 | 自定义指令 或 filter方式 |
| 菜单权限在那鉴权？ | 后端控制菜单数据！ | 后端控制菜单数据！ |
| 字段权限在那鉴权？ | 不支持 | 自定义指令 或 filter方式 |
| 表结构 | c_menu + c_resource | def_resource + def_resource_api |
| 表所在数据库 | 租户库 (lamp_base_{租户编码}) | 默认库（lamp_defaults） |
| 缺点 | 1. 每个租户都需要维护一份相同的资源数据，且不能让租户自己修改。 2. 每次调整资源数据，需要更新所有的租户库。 | 需要跨库查询。 |
| 优点 | 查询方便 | 资源表全局唯一，仅由开发者维护，不易出错。 |
十、分布式事务
3.x 没有主动在业务上使用分布式事务，二次开发时可以根据你们自身需求来决定是否使用seata。
4.x 的业务发生了巨大的变化，为了使得流程更加贴合实际，所以DATASOURCE、DATASOURCE_COLUMN模式必须使用seata！介意使用分布式事务的可以根据情况等待COLUMN模式发布。
❗️❗️❗️若评论区无法显示，请使用"手机热点"或"科学上网"。