浅谈各类架构遇到的问题解决方案

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

• 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的替代事务方案， 有区别性的考量吗？	待补充

参考

• http://mp.weixin.qq.com/s/4UB4AZe2R0lVCT6f5ExEMw