上次说到了单体架构的主要缺点耦合度高，而且当业务演进，开发难度会越来越高。最后会导致项目的可维护性变得相当差。淘宝早期就是这种情况，结果是非常惨，每次光是打包、验证、发布、启动，都会花费非常长的时间才能完成。
那么，应该怎么去解决这种问题呢？答案就是对war包进行拆分，方式有多种，例如水平和垂直拆分。这里我们就先介绍水平拆分的架构。
水平分层同步架构常规讲，分为两种，分为同步和异步，中间就差了一个消息层。现在整体架构不变，我们将WAR包的内容展开，每个单独包装，于是乎，有了如下的架构：
WEB/APP → Nginx → 多个水平War包 → DB
那么这个多个里面有什么呢？
- 网关层
- 数据业务层
- 数据访问层
各个层级的功能如下
网关层
- 鉴权
- 完整性检查
- 转换协议 JSON - HashMap - Protobuf
- 路由转发
- 限流、降级、熔断
这一层的主要实现有多重，如
- Zuul
- Spring Cloud
- Nginx
- Kong
- Tok
- Node.js
当然自开发也成。
业务逻辑层
就是各种业务逻辑判断等等，没有什么特别的
DAL 数据访问层
主要的功能，如下：
- CRUD
- ORM
- Sharding
还有一个更重要的工能，是屏蔽底层数据库差异。好处是方便你早下班。
当然，Sharding这里有个问题是，某些时候是不能按照多维度的Sharding，这个就需要另行想办法了。
水平分层异步架构异步架构也简单，就是在网关层和业务逻辑层中间加上一个消息队列层，也就是常说的分布式消息中间件。
好处是可以缓存大量的请求进来，这样就是实现了相关异步处理。
垂直分层架构跟水平的不一样，水平完全是按照代码的逻辑集合进行分类。但是垂直拆分，就是按照业务的逻辑集合进行分类的。 例如一个公司，有不同的销售部门，那么垂直拆分，其实本质就是拆分这些业务。
从技术上讲就是SOA概念的落地，无论是早期的ESB，还是SOAP，还是后来的Web Service，都不能让人完全满意。甚至，因为技术的规定，还引发了管理上的问题。例如某个业务需要修改某个系统的某个接口，但是ESB已经是标准的API了，好多都在用没法改。所以，因为牵一发而动全身，还不如自己做个，这样就导致了一个问题，公司内部还是烟囱林立。
水平或垂直架构特点，都是对系统进行了拆分。优点是：
- 代码可维护性增强
- 进行了相关的解耦，系统逻辑更趋同
- 选型可以做的更多
- 研发更为简单
当然缺点也是很明显的，无论是水平，还是垂直，单单说并没有完整的解决系统对企业的痛点。因为无论是按照IT模块拆分，还是按照事业部拆分，最后有大量重复性工作在里面。所以需要进一步的处理才能更好的满足企业业务扩展的需要。这个答案就是——微服务架构
,
