杭州湖畔网络技术有限公司是一家专业提供SaaS化电商ERP服务的创业公司，主要用户群体为经营淘宝、天猫、京东等主流电商平台、自建商城、线下渠道的商家及中小企业。作为SaaS服务提供商，服务数万乃至数十万级用户是业务架构初期就必须考虑的问题。庞大的用户群以及海量的用户数据意味着基础设施的构建必须兼顾高效与稳定，而按照通用的基础设施建设方案的话，需要面对成本过高、实现复杂、需要投入太多精力等问题，这对当时的湖畔网络这样的初创公司来说，完全不能承受。因此，更经济、更方便扩展的云服务平台成为首选。在对比现有各家云服务后，我们选择了稳定性与成熟度都经过大量用户检验的阿里云。

但要构建高性能的SaaS应用，仅凭云服务基础设施是不够的。如何基于云服务平台设计并实施符合自身业务特点的系统架构，也是决定产品性能的关键。本文将讲述我们如何利用云服务，使用相对经济的方案，解决海量用户的数据库使用问题。

架构

我们的SaaS化电商ERP服务的整体架构是基于阿里云服务平台实施的，如图1所示。

通过该方案，不仅发挥了阿里云的优势（不涉及物理机器的维护和折损，灵活地配置升级，成熟的备份与快照方案），而且通过集群，避免了系统可能会遇到的单点故障，提高了系统弹性扩容的灵活性和可用性。

作为一个SaaS化、数据更集中、数据体量庞大的企业应用，数据库是我们整体架构中的关键节点，如何保证其稳定与性能，是本文讲述的重点。当用户进入快速增长期后，随着业务量迅速增加，核心业务表的存量数据和增长速度绝对不是单个DB所能承受的（几乎所有单DB配置都存在性能物理上限瓶颈，即使选择升级配置也会受到成本和资源上限的约束）。因此，我们一开始就将数据库分库分片（Sharding）作为一个可行方案优先考虑，主要分析如下：

考虑到业务特性，我们最终采用了行业比较通用的水平拆分+垂直拆分策略，并自主完成DAO与JDBC之间的数据访问封装层开发工作。

水平拆分：按用户将数据拆分到多个库的相同表中

水平拆分的思路，就是将原本存放在单个RDS数据库中的数据，根据业务ID不同，拆分到多个数据库中（参见图2）。拆分后，各库的表数量及表结构都保持一致。水平拆分首先需要确立唯一的业务主表，即其他所有表的数据都与主表ID（前文所说的业务ID）存在直接或间接的主从关系，可以通过主表ID对全部数据做很好的切分。我们选择的业务主表为用户表，其他业务表或表的父表都包含一个用户ID。因此，我们切分的目标就是将不同用户数据存放到不同的数据库中。

确定了拆分规则后，下一步是着手封装Sping数据访问封装层（DBWrapper）。DBWrapper介于DAO与JDBC之间，每个业务DAO进行数据库基本操作，都会经过DBWrapper。它的主要作用是将数据库架构的变化对业务层透明，业务层可以如同操作单个DB一样，调用DBWrapper提供的数据库操作接口，而判断操作哪个数据库的逻辑，则全部交由DBWrapper封装完成（参见图3）。

DBWrapper主要提供新用户初始化和数据库操作接口。在新增用户初始化到系统时，需先动态判断系统各库的负载分布情况。粗略一点的算法就是判断各库的用户数，如共有4个库，可以根据user_id%4的情况决定目标库；再精细一点可以挖掘下核心业务数据的分布情况，具体分配算法需要基于业务设定（如考虑不同用户的平均订单量）。通过各库压力综合计算后，分析出压力最小的目标数据库，并将该新增用户数据存放到指定的目标库，同时更新路由信息（Router）。

当用户完成初始化进行业务操作时，则需由业务层调用DBWrapper的操作接口。DBWrapper接收到请求后，会根据业务层传入的User_id匹配Router，判断最终需要操作的RDS实例和数据库。判断完成后，只需要按部就班地开连接执行就可以了。具体的代码实现，需要结合自身的持久层框架，找一名研究过持久层框架实现的开发人员即可完成。这样就将系统用户整体数据压力，相对均匀地分布到多个RDS实例与数据库上。事实证明，这确实是一个非常有效的方案，尤其是对于数据量大、增长迅猛的表。只是在后续实施过程中，我们发现有时会有单个用户的业务压力比较突出，针对这种情况，我们可以通过一些人工干预（如迁移数据到单独的库）进行微调，当然最终的解决方案还是要不断调优路由算法。

切分后，不可避免地需要考虑数据字典（DD）和数据路由（Router）的处理。暂时我们采用的方法是将所有数据字典与路由放入独立的库，这也是后文中垂直拆分的一种应用。需要说明的是，数据库仅是这两个业务的一种实现方式，一般还可以通过或结合分布式缓存来处理这些业务（我们选用了OCS）。而对于可能出现的单点障碍，预留的扩展方案为水平拆分或创建只读节点（只读节点可以使用RDS最新提供的只读实例，目前还在内测阶段）。

垂直拆分：按业务将表分组拆分到多个库中

与水平拆分相比，垂直拆分要更简单一些。其基本思路就是将存放在单个数据库的表分组，把其中业务耦合度较高、联系紧密的表分为一组，拆分到其他DB中（参见图4）。拆分后，各库的表结构及其业务意义将完全不同。虽然规则简单、实施方便，但垂直拆分总是需打断些关联，因为实际操作中，基础资源常常出现在各个业务场景，在切分时又不得不切分到两个库中，此时就需要业务层多次查询后，在内存处理数据，实现数据库Join的效果。

垂直拆分同样需要DBWrapper，但封装规则与水平拆分略有不同，需要针对不同的业务，建立不同的DBWrapper。此时不再是完全业务层无感知，需要业务层根据业务场景有针对性使用。单个DBWrapper的实现与水平拆分一致。

垂直拆分的好处在于，将整体业务数据切分成相对独立的几块，隔离了不同业务之间的性能影响。而由于拆分后的数据库业务比较集中，也更容易找到业务主表，更有利于水平拆分。

对于垂直拆分，目前我们主要用于解决数据路由（包含了用户的基本信息）、数据字典模块，以及常见的冷数据问题。冷数据的处理一直是行业的常见问题（其实对于冷数据的划分，也是水平拆分），目前我们采用的方案是集中存储，即按自己的冷数据切分方式，通过自行开发的迁移程序将判定的冷数据增量迁移到一个库中。这个方案既能够分离冷数据对热点数据的操作影响，也可以为大数据的挖掘提供比较便利的条件。使用相对独立的冷数据存储结构，能方便以后采用更高效、成本更低廉的存储介质。当然该方案存在一些潜在问题，如果冷数据库满了该怎么办？目前我们预留的设计方案是，历史库的水平拆分，也可以考虑其他存储形式。

水平拆分与垂直拆分组合使用

拆分一直是数据库优化的关键词（无论是库表结构还是SQL写法），它是每个高并发产品最终都要经历的一步。拆分方案的核心主要在于可以通过添加更多RDS实例和数据库（常常为了节约成本，多个数据库可以部署在一个RDS实例上），灵活扩容系统的负载能力。在数据库架构中，水平拆分和垂直拆分一般都是搭配使用的，两者的先后顺序视具体情况而定。一般而言，垂直拆分更容易，也可以为水平拆分做铺垫，一是业务集中，便于提取主表，二是垂直拆分后，可以只水平拆分压力高的表，而业务增长缓慢的表则可以保留单DB，从而提高拆分效率以及降低实施成本（参见图5）。

我们之所以优先水平拆分，主要原因还是成本和效率及当时的一些局限性。只按业务ID（用户）做好路由配置，这样各个库中的结构完全一致，保留了原本的业务逻辑与实现，避免了跨库关联，能大大节省实现成本。

尽管拆分有种种好处，但由于分布式事务及跨库Join的实现复杂度较高及可用性较差，所以分布式事务一般都通过业务层使用乐观锁控制。而跨库的表间关联一定要打断，否则性能和实现复杂度都会超出可接受范围。对于跨库的Join、Group by等问题，都需要在业务层处理。目前我们采用的是分批查询，在业务层组装结果的方式。

有些遗憾的是，由于我们早期使用RDS时，阿里云尚未推出DRDS（分布式数据库）产品，所以上述拆分的数据库底层架构均是由我们自行研发的，投入了大量的精力。而现在有了DRDS，正准备做拆分的团队，则无需再自己造轮子，直接拿来用即可，这样团队可以将更多的精力放在业务上。

小处大有可为

虽然我们在架构上做了优化，但在产品发展过程中还是会出现性能不太理想的情况。在阿里云支持中心和论坛上，也可以看到其他业务型团队反馈使用RDS时遇到类似的情况。最初大家都怀疑是不是RDS的底层资源隔离有问题，多个用户共享资源时发生争抢，导致RDS的性能问题。但在阿里云DBA的指导和协助下，发现是由于产品设计时对数据库的使用太“不拘小节”，而随着并发压力与数据量增加，大量细小的性能问题被放大，集中暴露出来。

解决灯下黑：修正业务层的数据库操作陋习

挤掉海绵里的水：优化数据库执行计划

由于执行计划的优化往往涉及到数据库的运行机制与底层设计，此处实难三言两语说清。所以下面仅列举几个我们受益颇深的优化方案。建议大家优化执行计划时，多关注、分析iDB Cloud控制台中的性能报告和建议，也尽量多向阿里云DBA们请教，一般可以通过提工单的方式。有条件或兴趣的话，DBA可以通过预约到阿里云现场学习。另外，执行计划的优化需要大量的调试工作，通过在阿里云控制台创建生产数据库的临时实例，可以准确模拟当前系统的数据结构、分布与压力。

字段类型选择

选择合理的字段，往往可以大大减少数据库行数据的大小，并提高索引匹配的效率，进而大大提升数据库性能。使用更小的数据类型，如日期采用date代替datetime、类型或标记使用tinyint代替smallint和int、使用定长字段代替非定长字段（如char代替varchar），都能或多或少减少数据行大小，提高数据库缓冲池的命中率。而作为表字段中特殊的一员―主键，其选型更会对表索引的稳定和效率带来很大的影响，一般建议考虑数据库自增或自主维护的唯一数值。

高分离度字段建立索引

对于查询来讲，高分离度字段往往意味着精准或部分精准的条件。相对来讲是最好优化的一种场景，只需要对分离度较高的字段单独建立索引即可。当然实际使用中会有更多细节需要摸索。精确条件在各业务中基本都会用到，在越复杂的业务场景中，精确条件优先的原则，将是最有效的优化方案。需要注意的是，尽管高分离度字段单独建立索引效率很高，但过多的索引会影响表写入的效率，所以需要谨慎添加。这一点iDB Cloud中有大表索引的建议可以参考。

覆盖索引（Covering Index）

通俗一点理解，就是执行计划可以通过索引完成数据查找和结果集获取，而无需回表（去缓冲池或磁盘查找数据）。而由于MySQL的索引机制限制，一次查询时，将只用到一个索引或将两个索引聚合（index_merge）起来使用，所以意味着复杂的业务场景中，单独对每个字段建立索引可能没有什么用处。所以对于一些特定的查询场景，建立合适的组合索引，应用覆盖索引方法可以避免大量随机I/O，是更为推荐的优化方案（如果执行计划Explain的Extra中有Using Index，就说明使用了覆盖索引）。但实际业务总是会比索引本身更复杂，业务中需要查找或者获取的字段信息往往是很多的，而组合索引并不能涵盖所有的字段（否则我们将拥有一个比数据还要庞大的索引）。此时，为了应用覆盖索引，就需要使用主键延迟关联（Deferred Join），即先通过组合索引中包含的字段条件，初步查询出相对较小的结果集（面向结果集原则），该结果集只包含主键字段；然后通过获取到的这个主键队列，再对数据表做关联。

适当妥协

见招拆招：升配置

一般业务型的研发团队，很难有额外的精力投入到数据库方面，也没有专业的DBA来不断调优数据库配置、优化数据库服务器性能。所以早期团队可以选择的方案不多，也很难在技术上深挖下去，只能用成本换时间：性能配置不够，那就升级服务器配置。

那么问题来了：自己部署的数据库要升级配置，除了调整数据库配置参数，还会受到物理机的限制，因此就要考虑更加复杂的数据库备份和同步策略。但这是业务团队所不能接受，甚至短期内无法实现的，升配置也就变成了一个复杂的问题。不过我们使用了RDS，其弹性升级策略，正是这个问题的最佳解决方案。

二八原则

在长期的数据库乃至整个产品的优化过程中，我感受最深刻的就是：完美的方案可遇不可求。选择方案时，如果能解决80%的问题，并规避或保留剩下的20%，则将大大提升团队的整体效率。产品与架构都是在不断优化演变的，我们要循序渐进、不断努力，将今天的终点留作明天的起点。

总结与展望

作为一位创业公司的技术开发人员，通过实际使用阿里云产品，我总结了几点关于使用云计算产品的优势。

除了使用云产品的心得，数据库调优实践是本文的重点。在数据库的架构设计与性能优化方面，我秉承的原则是解决主要问题，按先分而击之、再挖掘细节的步骤，周返往复不断进行，同时系统架构也在这个过程中不断演变。相信随着时间推移，会有更多优秀的方案出现。尤其随着云服务不断发展，业务研发团队投入到基础设施的精力与成本，将会无限减少。会有越来越多专注于业务研发的团队，推出更多优秀的互联网产品，用互联网服务推动企业创新，重塑中小企业信息化形态。