业务流量的流向是渠道层→业务产品层→核心层→基础服务层，其中业务产品层各产品之间的业务隔离，数据也隔离，业务产品层和核心层可以按照用户信息进行分库分表，如图3-1-13所示。
数据库集群要结合应用架构、相关应用对业务的影响、分库分表的维度进行设计，减轻集群故障的影响。基础服务层中PaaS、分布式消息等进行独立集群部署；用户、产品进行独立集群部署并进行主备多集群保障；账务、交换等公共服务库独立部署；对存款、信贷、理财、支付结算等业务分别部署10套集群，分库均分到集群中，单集群故障影响面降低到10%。在业务集群分拆过程中，需各业务库统一分库维度，避免因分库维度不同导致的故障影响放大，例如：单集群中两个业务库维度不同，则该集群发生故障时业务的影响由10%增加到19%（即1－0.9×0.9）。
容器化部署
为什么要进行容器化部署
架构设计上为避免集群的单点，而将业务分摊到更多集群上。分布式数据库集群是由多台物理机构成的，在高可用方面集群存在多种单点，一方面集群强依赖“心跳”、系统租户等单点，另一方面，具备自动选主能力的分布式集群，遇到SQL导致进程中断或崩溃的情况。有限数量的物理机无法创建更多集群，而容器化技术可以在一定数量的物理机中创建出更多的数据库集群，待后面机器数量增加后，这些集群可以迁移到不同的物理硬件上，从而实现集群数量、容灾能力的提升。
如何进行容器化部署
如图3-1-14所示，容器化部署在物理机中按一定规格虚拟出容器，在容器中部署分布式数据库以增加集群数量。从ECS部署切换到ECS+容器化部署可按如下步骤实现灰度化。（1）在集群中增加容器化节点，并将库的一个备节点切至容器化节点，如图3-1-15所示。
（2）依次替换两个容器化节点，并将主节点切至容器节点。设置选主优先级，若ECS5崩溃，则数据库将ECS1的备节点选为主节点，如图3-1-16所示。
（3）此时，若出现单容器故障，仍可回滚到ECS上，运行一段时间检查无误后，将ECS1节点替换为容器化节点，如图3-1-17所示。
分区与容器化
分区与容器化既有联系又有区别，它们都为数据库的应用提供了扩展性。业务规模较小时，容器化可以创建多套集群，满足架构设计上对多集群的需求，此时表分区通常用不到。业务规模较大时，分区在集群数量不变的情况下提供容量的扩展性，容器化提供了更细粒度的管理能力。例如，可以将同一个业务链路的上下游的相同用户的分区放到同一台或者同一组物理机上，减小单台物理机上业务链路用户范围。分区是分布式数据库提供的能力，而容器化不属于数据库本身。
