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-pro	核心工具集
lamp-job	lamp-job-pro	分布式定时调度器

项目	gitee	github	备注
lamp-util	lamp-util	lamp-util	核心工具集
lamp-job	lamp-job	lamp-job	分布式定时调度器

后端

项目	datasource模式（gitlab）	column模式（gitlab）	none模式（已开源）	备注
lamp-cloud	lamp-cloud-pro	lamp-cloud-pro	lamp-cloud	微服务版
lamp-boot	lamp-boot-pro	lamp-boot-pro	lamp-boot	单体版

项目	none模式（gitee）	none模式（github）	备注
lamp-cloud	lamp-cloud	lamp-cloud	微服务版
lamp-boot	lamp-boot	lamp-boot	单体版

前端

项目	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 优化了以下功能：

  1. 租户在线创建
  2. 在线初始化各个微服务数据源
  3. 在线初始化各个租户的数据库建表脚本和初始数据
  4. 每个租户的数据源失败重连
  5. 数据源链接情况查看
  6. 租户拥有的应用授权、续期、查看
  7. 租户拥有的租户管理员绑定、解绑、查看

• 应用-资源体系

  ​ 平台级的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的分层更适合于长期迭代、业务复杂、对接第三方的系统。

1. 应用分层 （借鉴阿里规范，调整成适合本项目的分层模型）

   图中默认上层依赖于下层，箭头关系表示可直接依赖，如：开放接口层可以依赖于

   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 方法只负责原封不动的插入数据库。

     • 调用只能从上往下，不能反着调用，最好也不要平层调用，严禁平层交叉调用。

2. 领域模型

   • 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: [可选]灰度版本号， 仅灰度发布或服务隔离时需要携带

区别：

1. Authorization的值去除了Basic前缀。
2. tenant(加密租户编码)变更为TenantId(雪花租户ID)。
3. token变更为Token，并将值除去了Bearer前缀。
4. 新增了ApplicationId（雪花应用ID），用于记录请求来自那个应用。

调整理由： 方便新手入门成本、降低出错率、降低系统复杂度。Base64加密无加密意义，还徒增项目的复杂度。

有朋友可能觉得不加密不安全，可以自行思考如何进行安全的加密传输。

1. 可以使用 https 协议
2. 请求头明文参数不安全，普通的参数明文传输就安全了吗？请求头要加密，普通参数也要想办法加密。
3. 3.x版本使用Base64加密请求头基本无意义，因为直接Base64解密即可。

九、权限配置、分配和鉴权

名词解释：

1. 配置：通过系统的数据库或UI，为需要鉴权的配置全局唯一的资源编码^[1]
2. 分配：先给角色绑定资源^[2]，在将角色分配给用户^[3]（或给用户绑定角色）
3. 鉴权：鉴定用户是否拥有访问某些资源的权限

异同点	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模式发布。

---

1. 资源编码：确定资源的唯一编码，全系统不能重复 ↩︎

2. 资源：3.x 的菜单表(c_menu) + 资源表(c_resource) = 4.x的资源表(def_resource) + 资源接口表(def_resource_api)，4.x的资源包括：菜单、视图(隐藏的菜单)、按钮、URI（API）、字段等，你要你想通过权限来控制不同的人看到或访问不同的东西，它都可以称作资源。（注意区分通过业务状态控制显示/隐藏和通过权限控制显示/隐藏的区别！） ↩︎

3. 用户：3.x没有用户和员工的概念；4.x一个用户可以属于多企业，在不同的企业拥有不同的员工身份。 ↩︎