共计 697 个字符，预计需要花费 2 分钟才能阅读完成。
之前所写的都是单体架构的我的项目, 适宜于小我的项目, 对于较大一些的我的项目, 模块多并发多, 所有的业务模块都写在一起, 如果呈现问题, 可能就会影响整个我的项目的运行;
所以绝对于单体架构, 由对应的分布式我的项目思维的呈现;
整体架构图如下:
分布式思维
概念
将大型的我的项目依照特定的规定进行拆分
目标
缩小我的项目架构的耦合性
形式
既然分布式的思维就是将大型项目依照特定规定进行拆分, 那就有不同的规定:
- 按业务性能拆分: 例如一个商城我的项目能够按: 登录零碎 / 秒杀零碎 / 购物车零碎等等.
- 按层级拆分: 依照我的项目的业务层级分类 – 前端 /controller/service/mapper 等.
问题
依据之前的思路咱们将大型项目进行了分布式拆分, 然而拆分后多个小我的项目仍旧是一个整体的我的项目, 那咱们分布式系统中的 jar 包该如何治理? 本人编写的工具类 API 该如何治理?
1. 我的项目中的 jar 包
我的项目中对立的 jar 包治理, 咱们能够用一个父级工程导入 jar 包, 而后让咱们的我的项目去继承他 –> 通过 pom.xml 文件中 <parent> 标签的应用 –> 能够称为我的项目的继承, 然而留神最小的单位是 jar 包, 继承的都是第三方的
2. 我的项目中的工具类 API
下面我的项目的继承解决了 jar 包导入的问题, 那工具类 API 怎么办, 首先这些工具类 API 是咱们本人写的, 封装的, 其次是要先写类,.java 文件, 再打包成 jar 包的, 所以就要不能通过继承的形式来解决;
通过我的项目的依赖来解决, 通过 pom.xml 中来导入仓库中打包的工具 API 依赖来引入咱们本人的工具类 API.
这仅仅是一个简略的概述, 随着我本人学习的深刻, 再持续更新. 大家加油.
正文完
