分布式-单机 集群 并发 单模块-多模块

1 分布式（微服务）和单机模式

分布式（微服务）就是把项目根据业务拆分为多个模块，不同模块可以打包为不同的jar包，再部署到同一个或者不同的服务器上。

单机模式就是整个项目都被打在一个jar包里，部署到一台服务器上。

2 集群

2.1 集群的概念

集群就是指设置复数设备，比如多台mysql，多台tomcat服务器。

无论是分布式还是单机模式都能设置集群。

2.2 单机-集群

单机模式设置集群就是搞多台服务器，都部署相同的jar包，用Nginx进行反向代理实现负载均衡

2.3 分布式-集群

分布式设置集群则是根据业务需求，按需添加服务器，比如只有A模块的压力大，此时就可以把A模块的jar包部署在多台服务器上，其他模块则依然是单台服务器甚至几个模块共享一台服务器，这就能做到针对性利用服务器，再使用注册中心Eureka等分布式（微服务）组件将这些服务器关联起来。

3 并发

当前端同时发送多个请求给后端时，后端为了能快速处理这些请求，就会使用各种技术以实现“短时间内以最低成本处理最多请求”，使用的技术包括并不限于多线程技术、消息队列中间件、CDN缓存加速等等。

如果并发量很高，那么就是高并发场景，但是这个“高”是一个相对概念，得看具体业务场景，还得依靠各种指标进行判断，比如QPS，TPS，PV等。

无论是分布式还是单机，都会出现并发场景，也都会遇到高并发场景。

一般从商业代价和系统维护等角度看，项目大都是从单机起步，当业务越做越大后，并发越来越高，单机模式解决高并发的代价越来越大，才考虑转为分布式架构。

当然，如果公司很有信心项目会做大，那么一开始就上分布式也不是不行。

4 单模块和多模块

https://www.cnblogs.com/owenma/p/8029518.html

4.1 概念

多模块和单模块是相对概念。

一般小一点的项目，都是单模块。

    单模块下首先分包，比如controller、service、mapper、entity、common，然后根据业务进一步分包，比如controller下分goods包和order包。

而大一点的项目，或者由小项目重构的项目，就会进阶到多模块。

    多模块下首先根据需求划分模块，比如system、order、goods，分模块后每个模块单独开发，都有自己的pom文件和启动类，而具体要进一步细分哪些包（比如domin、controller、service、mapper），得看这个模块是干什么的。

4.2 多模块的必要性

单模块方便项目启动和调试，也方便排查，但是随着项目的不断发展，需求的不断细化与添加，工程项目中的代码越来越多，包结构也越来越复杂这时候工程的进展就会遇到各种问题：

1. 不同方面的代码之间相互耦合，这时候一系统出现问题很难定位到问题的出现原因，即使定位到问题也很难修正问题，可能在修正问题的时候引入更多的问题。

2. 多方面的代码集中在一个整体结构中，新入的开发者很难对整体项目有直观的感受，增加了新手介入开发的成本，需要有一个熟悉整个项目的开发者维护整个项目的结构（通常在项目较大且开发时间较长时这是很难做到的）。

3. 开发者对自己或者他人负责的代码边界很模糊，这是复杂项目中最容易遇到的，导致的结果就是开发者很容易修改了他人负责的代码且代码负责人还不知道，责任追踪很麻烦。

将一个复杂项目拆分成多个模块是解决上述问题的一个重要方法，多模块的划分可以降低代码之间的耦合性（从类级别的耦合提升到jar包级别的耦合），每个模块都可以是自解释的（通过模块名或者模块文档），

模块还规范了代码边界的划分，开发者很容易通过模块确定自己所负责的内容。

实际开发时，一个项目可以拆分为公共模块、系统相关模块、业务相关模块。

公共模块和系统相关模块可以交由经验丰富的中高级工程师进行维护和开发。

业务相关模块可以拆分、细化，按照开发难度交给不同级别的工程师进行开发。

4.3 分布式和单机

如果一个项目是分布式（微服务），那么一定是多模块的。

如果一个项目是单机模式，可以用单模块（初创阶段，项目并不复杂）也可以用多模块（项目复杂度足够或者一开始就定位于复杂项目），单模块和多模块是可以通过代码重构互相转的。

4.4 单机-单模块

单机-单模块，可以看到整个项目只有一个模块，在这个模块下直接分包。

在同一个包比如common下，可以进一步根据不同业务功能细分不同的包，整个包看起来结构清晰，赏心悦目。

又比如controller下，也是根据业务细分不同的包，比如aftersale、sales，如果有人偷懒，直接把类写在“根目录”下，虽然也行，但是可能会挨骂。

4.5 单机-多模块

单机-多模块，用ruoyi框架举例，可以看到整个项目按照不同的功能划分为不同模块，如果后续要拓展新的模块，直接在项目中创建新的模块即可。

比如quartz，可以看成一开始没有，后面要实现定时任务才创建的“新模块”

每一个模块根据自己的职责进一步分包。

• 根据当前模块是否要操作数据库，决定是否设立mapper包，在这个包里写接口，再基于mybatis这种ORM框架实现对数据库的操作。

• 根据当前模块是否要保存数据，决定是否设立domin包，在这个包里写entity、vo等各种实体类。

• 根据当前模块是否要和前端联系，决定是否设立controller包，在这个包里写接口。

• 有的模块只对项目内部的其他模块服务，不操作数据库，也不设立接口，这种模块，一般就只有业务逻辑，根据

拿ruoyi框架举例

system不对外服务，所以没有controller包

framework和common只对内部模块服务，所以没有controller、mapper、domin

generator用于代码生成，所以什么层都有

admin作为项目的权限架构，需要对外，而具体的业务逻辑实现涉及许多类，这些类按照各自的定位存放到包中，方便管理

4.6 分布式-多模块

分布式一般直接上多模块，通常要为不同的分布式组件准备相应的模块，各个模块进一步分包的思路依然是根据这个模块的作用而定。