支付宝的架构

[AdrianHu99]

https://mp.weixin.qq.com/s/OEhuRdUD8i7-weMqOevSYA

[AdrianHu99]

单元化的基本特性，任何一家互联网公司，其想要成倍的扩大自己系统的服务能力，都必然会走向单元化之路。

它的本质是分治，我们把广大的用户分为若干部分，同时把系统复制多份，每一份都独立部署，每一份系统都服务特定的一群用户。

以淘宝举例，这样之后，就会有很多个淘宝系统分别为不同的用户服务，每个淘宝系统都做到十万 TPS 的话，N 个这样的系统就可以轻松做到 N*十万的 TPS 了。

[AdrianHu99]

[AdrianHu99]

單數據庫實例的分佈式服務架構

[AdrianHu99]

讀寫分離的主從DB 分佈式服務架構

[AdrianHu99]

分庫分表的分佈式服務架構

[AdrianHu99]

这种方法做到极致基本能支撑 TPS 在万级甚至更高的访问量了。然而随着相同应用扩展的越多，每个数据库的链接数也巨量增长，这让数据库本身的资源成为了瓶颈。

这个问题产生的本质是全量数据无差别的分享了所有的应用资源，比如 A 用户的请求在负载均衡的分配下可能分配到任意一个应用服务器上，因而所有应用全部都要链接 A 用户所在的分库，数据库连接数就变成笛卡尔乘积了。

在本质点说，这种模式的资源隔离性还不够彻底。要解决这个问题，就需要把识别用户分库的逻辑往上层移动，从数据库层移动到路由网关层。

这样一来，从应用服务器 a 进来的来自 A 客户的所有请求必然落库到 DB-A，因此 a 也不用链接其他的数据库实例了，这样一个单元化的雏形就诞生了

[AdrianHu99]

思考一下，应用间其实也存在交互（比如 A 转账给 B），也就意味着，应用不需要链接其他的数据库了，但是还需要链接其他应用。 如果A要轉賬給B，只要call 一個API 到B的service即可，B 的service會負責和B的db去鏈接，update 數據

[AdrianHu99]

支付宝将单元分成了三类（也称 CRG 架构）：

RZone（Region Zone）：直译可能有点反而不好理解。实际上就是所有可以分库分表的业务系统整体部署的最小单元。每个 RZone 连上数据库就可以撑起一片天空，把业务跑的溜溜的。

GZone（Global Zone）：全局单元，意味着全局只有一份。部署了不可拆分的数据和服务，比如系统配置等。

实际情况下，GZone 异地也会部署，不过仅是用于灾备，同一时刻，只有一地 GZone 进行全局服务。GZone 一般被 RZone 依赖，提供的大部分是读取服务。

CZone（City Zone）：顾名思义，这是以城市为单位部署的单元。同样部署了不可拆分的数据和服务，比如用户账号服务，客户信息服务等。理论上 CZone 会被 RZone 以比访问 GZone 高很多的频率进行访问。

CZone 是基于特定的 GZone 场景进行优化的一种单元，它把 GZone 中有些有着”写读时间差现象”的数据和服务进行了的单独部署，这样 RZone 只需要访问本地的 CZone 即可，而不是访问异地的 GZone。