1)单体应用架构

先看如下图所示的单体应用架构，请求到网关接口，网关接口直接调应用或者服务，服务调存储层查询或写入数据，一竿子捅到底。

这种架构模式最大的风险是服务、存储都是单点的，访问容量和性能受限于存储和应用的容量和性能，容灾方面，一旦发生故障只能死等单点应用或存储的恢复。

2)分布式架构

后来工程师们开始对应用做水平拆分，对服务做垂直拆分。

水平拆分应该都很熟悉，就是加服务器，每台服务器都部署实例，垂直拆分就是把服务按域做拆分，比如一个交易系统，有商户域、商品域、用户域、订单域等，拆分成多个微服务，服务解耦，服务可以独立发布，应用的复杂度会更高。

这个分布式架构解决了服务单点的问题，某台服务器宕机，服务还是可用的，但是存储层还是单点的，而且随着业务增长，扩容加的机器越多，大家发现查询写入效率耗时到一定阶段反倒是变慢了，分析发现存储层出现了性能瓶颈。上面图只花了2台服务器连接数据库，真实分布式系统可能几十百来台，甚至上千台，如果都连一台DB，连接数、锁争用等问题, SQL性能变慢可想而知。

3)读写分离架构

后来的事情大家也都知道，互联网公司开始纷纷做读写分离，把读请求和写请求分开。

读写分离这里面隐含了一个逻辑，那就是数据写入之后，不会立即被使用。

数据从写入到被立即使用有个时间差，等从库同步数据才会被读取，实际统计发现，常规的应用，90%的数据确实在写入之后不会立即被使用，当然我这里说的立即的时间单位是ms，一般同步延迟也就是几毫秒，不超过10 ~20ms。

4）分库分表分布式架构

但是这个架构并没有解决写的问题，随着业务量的增长，写数据成为了瓶颈。分库分表应运而生，分库分表的中间件开始变得流行起来，现在基本成了中大型互联网公司的标配。

基本思想就是把数据按照指定维度拆分，比较常见的是userId维度，例如取userId的后2位，可以拆分成百库百表，也有的除以指定模数取余数，例如除以64取余，可以按余数范围0-63拆成64个库。

关于分库分表，很多人都知道有垂直拆分和水平拆分二种（上面说的垂直和水平是系统的拆分，这里指的是存储的），垂直拆分就是按照业务维度拆分，把同一个业务类型的表放到一个库，经常会按领域模型的概念拆分，比如订单库、用户库、商品库等，水平拆分就是把大数据量的表（库）切分成很多个小数据量的表（库），减小库和表的访问压力，可以和系统的水平垂直切分比一下：

为什么叫水平和垂直呢？其实很好理解，你想象一张用户表，里面放了很多字段，如下图：

那垂直拆分，就是垂直从中间划一刀，把蓝色的用户信息表和右边绿色的订单信息表拆分成2张表。库拆分成用户库和订单库。

水平拆分，就是水平划一刀，把数据量降低。

大家看到这，是不是以为问题都解决了，上面分库分表之后，如果应用层面扛得住，数据库层面的确能做到并发量到万这个级别。但是容量要再上一个数量级就有点困难了。

5）单元化分布式架构

因为一个库实例是被所有应用共享的，也就是你每增加一台机器，数据库连接就会相应的增加一些，增量是至少机器设置的最小连接数。

①为什么应用需要连接所有的数据库实例？

网关层的流量可能走到任何一台服务器，比如A用户的请求到服务器上了，这时服务器一定要有A这个用户userId 分片的数据库连接，否则要么把流量路由走，要么执行失败。

分库分表只是解决了单库单表访问压力的问题，但是由于每一台服务器都同时连接所有的分库实例，到一定阶段是没发继续扩容的，因为库实例的连接数有瓶颈。

②数据库存在瓶颈应该怎么弄?

相信聪明的你们其实已经猜到了，那就是按userId 分片在应用层就做隔离，在网关层流量路由的时候把指定uid分片的流量路由到指定应用单元执行，这个应用单元流量内部自消化，如下图：

比如uid = 37487834，最后二位是34 属于 00-49范围，那用户流量直接路由到00-49这个应用分组，在这个单元内的完成所有数据交互的操作。

这样uid 00-49 这个分组单元中的应用只用连userId 00-49 分库的数据库，uid 50-99分组单元的应用也是如此，数据库的连接数一下直接降一半，而且还可以拆分单元，现在是2个单元，最多可以拆分到100个单元。

而单元是LDC中核心概念，下面重点说一下单元这个词的具体含义。

单元在蚂蚁有个名称叫做 Zone，Zone内部署的是完整的服务，例如，一个用户在一个Zone内可以完成一整套业务流程，流量不需要其他Zone 来提供服务，拥有完成一整套服务的能力，在单个Zone就能完成一整套业务，是逻辑自包含的，这样有什么好处，某个Zone如果出现故障，路由层直接把这个Zone流量转移到其他Zone，接受这个Zone流量的其他几个Zone可以分摊流量，流量调拨很方便。