大约 5 分钟
项目结构
Single
单体架构
优缺点
- 优点
- 小项目开发快 成本低
- 架构简单
- 易于测试
- 易于部署
- 缺点
- 大项目模块耦合严重，不易开发，维护，沟通成本高
- 新增业务困难
- 核心业务与边缘业务混合在一块，出现问题互相影响
项目结构
为了弥补缺点，本项目采用了多模块开发，集中依赖模块运行的方式
.
├── admin 管理模块
│ ├── admin-file 文件管理
│ └── admin-log 日志管理
├── api 接口模块
│ └── api-system 系统模块接口
├── auth 鉴权模块
├── common 通用公共代码
├── laboratory 实验室功能
│ ├── lab-flux 模拟接口(Flux)
│ └── lab-mock 模拟接口
├── modules 业务模块
│ ├── module-lf 流程管制
│ ├── module-scheduling 任务调度
│ └── module-system 系统模块
├── run 运行模块
└── pom.xml 配置依赖/打包管理接口模块
模块与模块之前通过接口相互调用解耦，默认只有系统模块，所以如果后面还有其他模块，并且有需要相互调用的，就继续往下面添加
流程管制
需要结合LogicFlow来使用
运行模块
引入需要运行的业务模块和功能集中运行为一个单服务，可以很方便的部署，并且每个业务模块都是经过打包成 jar 包的，开发运行启动速度也非常快
实验室功能
有些时候，我们写了一些和第三方对接的接口，但是又不能及时和第三对接（可能是网络原因，也可能是人家只是写了接口文档，接口还没部署，或者是我们本身测试环境部署测试比较麻烦），于是我们可以在开发的时候就自己模拟第三方接口返回数据等功能
Clud
微服务架构是分布式架构(SOA)架构的一种拓展，这种架构模式下它拆分粒度更小，服务更独立，把应用拆分一个个微小的服务。微服务的关键在于微小、独立、轻量级通信
优缺点
- 优点
- 便于特定业务功能的聚焦
- 每个微服务都可以被⼀个⼩团队单独实施（开发、测试、部署上线、运维），团队合作⼀定程度解耦，便于实施敏捷开发
- 便于重⽤和模块之间的组装
- 不同的微服务可以使⽤不同的语⾔开发，松耦合
- 更容易引⼊新技术
- 可以更好的实现DevOps 开发运维⼀体化
- 缺点
- 分布式复杂难以管理，当服务量增加，管理越加复杂
- 微服务架构下，分布式链路跟踪难
项目结构
同样为了弥补缺点，本项目推荐使用Dubbo来实现服务模块与模块之间的调用通信，使用SkyWalking来实现链路追踪
.
├── _ini 存放一些初始化配置文件
├── admin 管理模块
│ ├── admin-file 文件管理
│ ├── admin-log 日志管理
│ └── admin-monitor 运行监控
├── api 接口模块
│ ├── api-proxy 代理接口
│ └── api-system 系统模块接口
├── auth 鉴权模块
├── common 通用公共代码
├── gateway 网关模块（后端服务统一入口）
├── laboratory 实验室功能
│ ├── lab-flux 模拟接口(Flux)
│ └── lab-mock 模拟接口
├── modules 业务模块
│ ├── module-es 搜索引擎
│ ├── module-lf 流程管制
│ ├── module-scheduling 任务调度
│ └── module-system 系统模块
├── run 运行模块
└── pom.xml 配置依赖/打包管理代理接口
有的时候我们部署项目，服务器资源提供者（客户）只给我们提供单台有互联网或者有与其他第三方有通讯能力的IP，虽然可能使用Nginx等方式做正/反向代理,但是我们也可以自行写一个单独的小型的纯接口访问的微服务到那台服务器上做对接
运行监控
非必要，可以通过检查日志实现查看各个服务的运行状态，而不需要跑得对应的服务器上去查看，但是是通过暴露一些接口来实现，所以存在很多安全隐患，谨慎使用！！！当然也有很多更先进的工具可以实现服务器运行监控，例如ZABBIX
微服务应用模块
- AuthApplication必须：鉴权服务
- ESApplication可选：全文搜索服务
- FileApplication建议：文件管理服务
- GatewayApplication必须：网关服务
- LogApplication建议：日志服务
- LogicFlowApplication可选：流程管理服务
- MonitorApplication可选：运行监控
- SchedulingApplication建议：任务调度
- SystemApplication必须：系统服务