# 认证服务： lamp-oauth 主要包括 登录接口、获取用户权限接口、常用数据接口(如前端获取的字典、枚举接口）等接口和功能。 # 租户服务： lamp-tenant 主要包括 租户管理、给租户创建独立数据源（数据源模式）、租户管理员维护、 租户表结构初始化、租户表数据初始化 等功能。 # 权限服务： lamp-authority 主要包括 组织机构管理、岗位管理、租户下的用户管理、系统设置、权限配置等功能。 # 消息服务： lamp-msg 主要包括 站内信（通知、公告、待办、预警）、短信功能、邮件功能(尚未实现) 等。 支持多种第三方短信、多种第三方邮件。 # 文件服务： lamp-file 主要包括 文件存储、文件下载、文件回显等功能。支持多种第三方OSS存储。 # 网关服务： lamp-gateway 主要包括 token解析、用户uri权限拦截、黑白名单、限流等功能。 # 工作流服务 （会员版）： lamp-activiti 工作流配置功能 # SpringBootAdmin监控： lamp-monitor 监控功能 # lamp-cloud 目录结构 ``` ├── 01-docs # 文档 │   ├── activiti # (会员版)工作流模板 │   ├── dockerfile # 常用工具的dockerfile │   ├── image │   ├── shells # 运行脚本 │   ├── sql # 数据库脚本 ├── 01-third-party # 第三方配置 │   ├── nacos # 项目需要的nacos配置 │   └── seata # 项目需要的seata配置 ├── lamp-activiti # (会员版)工作流服务 │   ├── lamp-activiti-biz │   ├── lamp-activiti-controller │   ├── lamp-activiti-entity │   └── lamp-activiti-server ├── lamp-authority # 权限服务 │   ├── lamp-authority-api │   ├── lamp-authority-biz │   ├── lamp-authority-controller │   ├── lamp-authority-entity │   └── lamp-authority-server ├── lamp-file # 文件服务 │   ├── lamp-file-api │   ├── lamp-file-biz │   ├── lamp-file-controller │   ├── lamp-file-entity │   └── lamp-file-server ├── lamp-gateway # 网关服务 │   ├── lamp-gateway-biz # (会员版) │   └── lamp-gateway-server ├── lamp-msg # 消息服务 │   ├── lamp-msg-api │   ├── lamp-msg-biz │   ├── lamp-msg-controller │   ├── lamp-msg-entity │   ├── lamp-msg-server │   ├── lamp-sms-biz │   └── lamp-sms-controller ├── lamp-oauth # 认证服务 │   ├── lamp-oauth-api │   ├── lamp-oauth-biz │   ├── lamp-oauth-controller │   └── lamp-oauth-server ├── lamp-public # 公共模块 │   ├── lamp-common │   ├── lamp-common-api │   ├── lamp-file-sdk │   ├── lamp-tenant-datasource # (会员版) 数据源模式 │   └── lamp-tenant-datasource-init # (会员版) 数据源模式初始化sdk ├── lamp-support # 支撑服务 │   └── lamp-monitor # spring boot admin 监控 ├── lamp-tenant # 租户服务 │   ├── lamp-tenant-biz │   ├── lamp-tenant-controller │   ├── lamp-tenant-entity │   └── lamp-tenant-server └── src └── main └── filters └── config-dev.properties # 开发环境全局配置 └── config-prod.properties # 生产环境全局配置 ``` # 项目结构介绍 - lamp_cloud  # 概念声明 1. 层： - API层： 包含lamp-authority-api、lamp-file-api、lamp-msg-api 、lamp-oauth-api 等模块 - 业务层：包含lamp-authority-biz、lamp-tenant-biz、lamp-file-biz、lamp-msg-biz 、lamp-sms-biz、lamp-oauth-biz等模块 - 控制层：包含lamp-authority-controller、lamp-tenant-controller、lamp-file-controller、lamp-msg-controller 、lamp-sms-controller、lamp-oauth-controller等模块 - 实体层：包含lamp-authority-entity、lamp-tenant-entity、lamp-file-entity、lamp-msg-entity 、lamp-sms-entity等模块 - 启动层：包含lamp-authority-server、lamp-tenant-server、lamp-file-server、lamp-msg-server 、lamp-sms-server、lamp-oauth-server等模块 2. 模块： (模块和层可以混着说, 知道团队的人懂即可) - lamp-util 项目下的每个包. 如 lamp-core、 lamp-cloud-starter - lamp-cloud 项目下的每个包. 如lamp-authority-api、lamp-common等 - lamp-boot 项目下的每个包. 如lamp-authority-server、lamp-common等 3. 服务: - 认证服务：lamp-oauth下的所有模块组成权限服务 - 租户服务：lamp-tenant下的所有模块组成租户服务 - 权限服务：lamp-authority下的所有模块组成权限服务 - 文件服务：lamp-file下的所有模块组成文件服务 - 网关服务：lamp-gateway下的所有模块组成网关服务 - 消息服务：lamp-msg下的所有模块组成消息服务 - 监控服务：lamp-monitor 4. lamp-public 目录下存放 业务服务公共模块和收费的插件 ： - lamp-common 模块用于存放跟大多数服务有关的常量类和工具类等 - lamp-common-api 模块公共api层 - lamp-tenant-datasource (会员版)： DATASOURCE模式的实现类 - lamp-tenant-datasource-init (会员版) ： DATASOURCE模式的初始化数据源模块，用于业务服务启动时，初始化租户数据源 - lamp-file-sdk: 附件sdk，用于业务服务保存和查询业务附件信息 总结： 一个服务可以包含多个模块，一个模块可以包含多个层。 比如：权限服务包含 租户模块和权限模块， 权限模块包含api层、业务层、控制层、实体层、启动层， 但租户模块没有api层和启动层， 因为租户模块是依赖权限模块的用户相关接口的，若独立成租户服务，会涉及跨服务访问，故合并成一个服务。 # 疑问🤔️ 都已经是微服务项目了, 为什么还要将项目按模块拆封得如此细? 1. 受到原来项目的“影响“, 已经习惯了将一个大项目按照功能拆封成多个模块的习惯 2. 按照大功能将代码物理拆分成多个模块后, 强制按照server -> controller -> biz -> entity 层的依赖关系来开发功能 - 可以让项目结构更加清晰, 是典型的低耦合、高内聚体现; - 可以避免开发水平参差不齐的团队,胡乱添加依赖, 胡乱注入Bean. (只允许: Controller 调用 Service, Service调用Mapper) 3. 当某个项目不需要功能时(如没有站内信、没有短信发送、没有操作日志等), 按模块拆分的短信和站内信可以很轻松的在消息服务排除或者删除这2个功能, 而想要排除操作日志功能,必须得在权限服务一个类一个类的删除或注释, 异常的麻烦. # 服务拆分模块建议 原则上推荐一个服务最好包含5个模块(api模块、entity模块、biz模块、controller层、server层), 但任何事情都不是绝对的,具体怎么分模块可以根据业务自身情况来定. 如: 消息服务希望将站内消息、短信、邮件等相关等逻辑集成到消息服务, 这几个功能既有独立性, 做得更细一些,甚至可以将站内消息、短信、邮件等功能独立成单独的服务, 但这务必会增加系统部署开销, 所以综合考虑, 将站内消息、短信、邮件等功能按模块开发,然后组合成一个服务, 即降低了部署等成本,也将每个功能独立出来,方便日后独立成单独的服务和禁用某些功能. # API层 说明： 服务于服务之间互相访问时，通过api模块来调用。api 模块实际上就是通过声明式FeignClient实现的接口，B服务调用A服务的UserApi接口时，FeignClient将该次调用封装成Http请求， 最后访问的是A服务的 Contoller层接口。 # 业务层 说明： 主要存放Servce接口及实现，Redis操作类、Mapper接口以及Xml（resources目录下）。 约定如下： > AService 能注入BServce，但禁止直接或间接循环注入。如AService -> BService ，BService->AService > 在Service 层封装 业务逻辑, 操作缓存接口、Mapper接口的操作 # 实体层 说明： 存放实体po、文件传输对象DTO(本项目忽略VO)、枚举类型等，不涉及逻辑的一些类。 # 控制层说明： 主要存放一些服务的 Contrller 接口， 用于对外访问。 约定如下： > Controller 不能互相注入调用（我不说，真有人这么干！） > Controller 只能调用Service，禁止调用Mapper(Dao) > Controller 主要负责参数验证、转换等操作，尽量别写业务代码 # 启动层说明： 主要存放一些服务所需的启动类、配置类、配置文件、消息队列消费方监听入口等 # 每个层的依赖关系： 每个服务一般情况下都包含5个层： server、controller、biz、entity、api （特殊情况可以删减一些），他们的依赖依赖关系为： `server -> controller -> biz -> entity` ，api层独立，用于其他服务依赖。 # lamp-cloud项目模块依赖图 （图片适用于3.0+版本）  # 调用流程（lamp-cloud)