当业务场景不断发展，单体架构变得臃肿，代码耦合度高，并发达到上限，数据量也逐步上升，系统吞吐量遇到瓶颈。此时，单体架构就被拆分。水平拆分就形成了水平分层架构，垂直拆分就形成了SOA架构。
SOA架构
SOA架构，即面向服务架构，是单体架构垂直拆分的结果。
比如我们以电商为例。原来的一个完整的电商项目，在垂直拆分下，就变成了若干个项目，比如用户服务项目，商品服务项目，订单服务项目等。相应的，数据库也拆分成了用户库，商品库，订单库。如下：
单体架构拆分成SOA根据上图，我们发现，SOA中的每个服务，其实就是一个单体架构，都包含了处理用户请求，处理业务逻辑，处理数据交互等。只不过，原来是一个项目中，相当于是一个进程。而现在，是根据业务划分的多个进程，性能肯定会有一个提升。并且，某个服务的发布对其它服务的影响是有限的，从代码层面来说，基于业务也达成了一定的解耦。
SOA架构，把原来的一个完整的服务，垂直拆分成了若干个服务。那么，就必须要解决服务之间的通信问题。通常来说，一般用ESB来解决这个问题。
ESB，中文可译为企业服务总线。它就像是一根管道，把各个服务联结成为一个整体。如下：
SOA和ESB水平分层架构
单体架构进行水平拆分，就形成了水平分层架构。水平分层是基于功能性的。比如用户请求的处理，演化成了网关层，业务逻辑处理，成了业务层，数据交换处理成了数据层。如下：
水平分层架构网关层的功能主要有：
请求鉴权。判断客户端是否具备访问接口的权限。数据完整性检查。检查客户端发来的数据是否完整。协议转换。将客户端请求协议下的数据类型转换成系统内部交互所用的协议下的数据类型。路由转发。根据相应规则，将请求转发到不同的下层服务。服务治理。完成一些服务治理相关的工作，如限流，降级，熔断等。需要注意的是，网关层的所有功能都应该是业务无关的。
一些常见的可以用做网关的组件有：
1.Netflix的Zuul，已被整合进SpringCloud体系。
2.SpringCloudGateway，Spring自研网关。
3.Nginx，其实网关不是它的核心能力，它的核心能力是负载均衡。
4.Kong，基于Nginx扩展来的网关。
5.Tyk，由Go语言开发的网关，基于NIO。
6.Nodejs，js，也可以作为网关提供相关能力。
综上，我们最推荐的网关产品，其实是Zuul，因为相对于其它产品来说，Zuul算是一个相对完善、专业、成熟的网关产品。当然了，对于有条件的公司来说，自研网关也是一个不错的选择。
业务逻辑层就是原来的业务逻辑。
数据访问层则需要提供以下一些功能，如：
1.CRUD，数据的增删改查。
2.ORM，数据和对象之间的转换。
3.分库分表，提供对分库分表的支持。
4.屏蔽底层存储复杂性。无论是MySQL，还是Orcale，又或者是Redis，都可以支持，且不影响上层业务的调用方式。
事实上，数据存储是在不断发展的，这导致数据访问层也出现了一些变化。比如说，从原来的SQL（关系型）数据库，到NoSQL数据库，再到NewSQL数据库。
SQL数据库的优势在于支持事务，但是扩展性较差，分库分表实现起来较为复杂。
NoSQL则是扩展性强，可集群部署，但是不支持事务，或简单的支持事务（MongoDB)。
NewSQL则是将NoSQL和SQL的优势整合起来，即有强大的集群扩展性，又支持事务。比较成熟的产品如TiDB。
TiDB结合了传统RDBMS和NoSQL的最佳特性，有以下一些核心特点：
1.高度兼容MySQL。大多数情况下，从MySQL迁移到TiDB，不需要修改任何代码。
2.水平弹性扩展。可按照需要进行水平扩展，满足高并发，海量数据的需求。
3.支持事务。%支持事务。
4.金融级高可用。
5.一站式HTAP解决方案。
6.云原生SQL数据库。
假设，我们使用了NewSQL数据库，那么，我们的数据访问层就不需要再