浅谈各种架构遇到的问题解决方案-CSDN博客

在讨论分层架构的过程中，我们常常会被问答一下几个问题：

1: 是否需要前后端分离，什么时机分离
2: 是否需要服务化，什么时机服务化
3: 是否需要引入DAO层，什么时机引入
4:是否需要抽取通用中台业务，什么时机抽取

同道们的这些提问，其实很难回答。在不了解业务发展阶段，业务规模，数据量并发量的情况下，妄下YES或NO的结论，本身就是不负责任的。下面我给出一些，我们架构演进的一些观点，同时也经历过系统的一系列的拆分，随便说说自己的感悟。

1 单体应用阶段（第一节段）

单体应用

如上图所示，为应用在单体应用的时候的一般架构图(我们用的技术框架以流行的ssm为例子) 这时候的应用简单，需要的资源少，可以完全支撑起简单的业务，这时，我们的包应该会这样的划分使用的，比如我们有3张表A,B,C 这时就与对应的3个entity, 我们完美的想法是entity与表字段是一一队应的(注意：是完美构想)entity 分别是A,B,C 这时也有对应的Mapper接口对应的CURD,AMapper, BMapper, CMapper, 在业务层的service，我们也会有这样的划分Aservice（AserviceImpl）,Bservice(BserviceImpl), Cservice(CserviceImpl)。此时，我们规定AserviceImpl-->AMapper, BserviceImpl-->BMapper,CserviceImpl-->CMapper,我们是绝对不允许AserviceImpl-->BMapper这种情况发生的，只能AserviceImpl-->Bservice。这样会有利于后期服务化应用的拆分，不会产生胶水代码。当然，这种情况往往是我们想象的完美情况，但是实际中我们应用的发展，不会这样的，比如，我们有一个统计功能，需要left join A表和B表，这是后，会在entity 中添加一些非表的属性所有的字段，或新增一个DTO的实体来处理这种情况，而保留entity 与DB 表的一一对应的纯洁性，保持纯洁性以有利于我们对业务的梳理。此时 service 层可能会增加一个Manager层的包，处理各个service的数据聚合的业务处理。manager层中的包不会含有Mapper。

如果此时业务量在迅猛发展(公司资金流和人口红利大)，需要加入缓存来解决一系列业务的时候，可以考虑拆分的问题。

这个阶段可能会遇到的问题，以及解决方案：

问题	解决方案
restful-code	链接1
MySQL 使用自增ID主键和UUID	链接1
单JVM事务传递	链接

2 两段式架构

如果要实施服务化，他的架构可能是这样的：输入图片说明

客户端：型调用方是browser或者APP
站点应用层（web-service）：实现核心业务逻辑，从下游获取数据，对上游返回html或者json
业务层(mod-service): 提供服务的业务处理的。
数据-缓存层：加速访问存储
数据-数据库层：固化数据存储（可能不是RDBS）

这个阶段会遇到的问题，以及解决方案：

问题	解决方案
spring事务	单JVM事务

3 三段式架构

注意，架构分层越多，维护层本就越大，资源的费用也是越大的，这是团队不断快速发展，增加人手，快速迭代的分层演进。输入图片说明

这个阶段会遇到的问题和解决方案：

问题	解决方案
跨应用的事务处理	链接1 链接2
业界难题-“跨库分页”的四种方案	解决方案

4 业务方案

问题	解决方案
淘宝网商品SKU系统设计经验分享	链接
提一个问题，单JVM 跨库的替代事务的方案，和跨应用多JVM的替代事务方案，有区别性的考量吗？	待补充