垂直结构和分层现象区别,水平结构和垂直结构属于什么

上次说到了单体架构的主要缺点耦合度高，而且当业务演进，开发难度会越来越高。最后会导致项目的可维护性变得相当差。淘宝早期就是这种情况，结果是非常惨，每次光是打包、验证、发布、启动，都会花费非常长的时间才能完成。

那么，应该怎么去解决这种问题呢？答案就是对war包进行拆分，方式有多种，例如水平和垂直拆分。这里我们就先介绍水平拆分的架构。

常规讲，分为两种，分为同步和异步，中间就差了一个消息层。现在整体架构不变，我们将WAR包的内容展开，每个单独包装，于是乎，有了如下的架构：

WEB/APP → Nginx → 多个水平War包 → DB

那么这个多个里面有什么呢？

1. 网关层
2. 数据业务层
3. 数据访问层

各个层级的功能如下

网关层

1. 鉴权
2. 完整性检查
3. 转换协议 JSON - HashMap - Protobuf
4. 路由转发
5. 限流、降级、熔断

这一层的主要实现有多重，如

• Zuul
• Spring Cloud
• Nginx
• Kong
• Tok
• Node.js

当然自开发也成。

业务逻辑层

就是各种业务逻辑判断等等，没有什么特别的

DAL 数据访问层

主要的功能，如下：

1. CRUD
2. ORM
3. Sharding

还有一个更重要的工能，是屏蔽底层数据库差异。好处是方便你早下班。

当然，Sharding这里有个问题是，某些时候是不能按照多维度的Sharding，这个就需要另行想办法了。

异步架构也简单，就是在网关层和业务逻辑层中间加上一个消息队列层，也就是常说的分布式消息中间件。

好处是可以缓存大量的请求进来，这样就是实现了相关异步处理。

跟水平的不一样，水平完全是按照代码的逻辑集合进行分类。但是垂直拆分，就是按照业务的逻辑集合进行分类的。 例如一个公司，有不同的销售部门，那么垂直拆分，其实本质就是拆分这些业务。

从技术上讲就是SOA概念的落地，无论是早期的ESB，还是SOAP，还是后来的Web Service，都不能让人完全满意。甚至，因为技术的规定，还引发了管理上的问题。例如某个业务需要修改某个系统的某个接口，但是ESB已经是标准的API了，好多都在用没法改。所以，因为牵一发而动全身，还不如自己做个，这样就导致了一个问题，公司内部还是烟囱林立。

水平或垂直架构特点，都是对系统进行了拆分。优点是：

1. 代码可维护性增强
2. 进行了相关的解耦，系统逻辑更趋同
3. 选型可以做的更多
4. 研发更为简单

当然缺点也是很明显的，无论是水平，还是垂直，单单说并没有完整的解决系统对企业的痛点。因为无论是按照IT模块拆分，还是按照事业部拆分，最后有大量重复性工作在里面。所以需要进一步的处理才能更好的满足企业业务扩展的需要。这个答案就是——微服务架构