从“如何设计用户超过1亿的应用”说起---数据库调优实战

《从“如何设计用户超过1亿的应用”说起---数据库调优实战》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、从“如何设计用户超过1亿的应用”说起---数据库调优实战本文章来自于阿里云云栖社区作为SaaS服务提供商，数万乃至数十万级用户是业务架构设计上一开始就必须面对的问题。庞大的用户群以及海量的用户数据意味着基础设施的构建必须兼顾高效与稳定，更经济、扩展更方便的云服务平台就成为了首选，如何基于云服务平台设计并实施符合自身业务特点的系统架构，也是决定产品性能的关键。...本文首发于阿里云&《程序员》杂志联合出品的《凌云》专刊中。作者： 杭州湖畔网络技术经理 王鑫鹏杭州湖畔网络技术有限公司是一家专业提供SaaS化电商ERP服务的创业公司，主要用户群体为经营淘宝、天猫、京东等主流电商平台、自

2、建商城、线下渠道的商家及中小企业。作为SaaS服务提供商，服务数万乃至数十万级用户是业务架构初期就必须考虑的问题。庞大的用户群以及海量的用户数据意味着基础设施的构建必须兼顾高效与稳定，而按照通用的基础设施建设方案的话，需要面对成本过高、实现复杂、需要投入太多精力等问题，这对当时的湖畔网络这样的初创公司来说，完全不能承受。因此，更经济、更方便扩展的云服务平台成为首选。在对比现有各家云服务后，我们选择了稳定性与成熟度都经过大量用户检验的阿里云。      但要构建高性能的SaaS应用，仅凭云服务基础设施是不够的。如何基于云服务平台设计并实施符合自身业务特点的系统架构，也是决定产品性能

3、的关键。本文将讲述我们如何利用云服务，使用相对经济的方案，解决海量用户的数据库使用问题。      架构      我们的SaaS化电商ERP服务的整体架构是基于阿里云服务平台实施的，如图1所示。       ■采用SLB（ServerLoadBalance，负载均衡）作为Web集群访问入口，负责为Web端的多台服务器进行流量分发。SLB是基于集群建设的，并且可以随时变配，按量付费。它不仅为我们实现了成熟的负载均衡方案，其稳定性与灵活性也为Web集群提供了更多可能。      ■后端配置多台ECS（ElasticComputeService，云服务器）实例，将主要应用服务都部署在

4、ECS上。除了可弹性扩容这一特性，ECS提供的安全防护和快照备份为服务器安全和容灾提供了非常成熟的解决方案，这恰恰是我们这种业务型创业团队积累相对最薄弱的方面。另外，ECS多线接入骨干网络能保证网络的稳定和性能，使得任何网络的用户访问应用服务都非常顺畅。      ■DB集群由多台RDS（RelationalDatabaseService，关系型数据库服务）实例组成。RDS是云数据库，简单易用，使用方法与自行部署的数据库完全一样。其成熟的双机热备与底层资源隔离，保证了我们这两年来数据库的平稳运行。另外，强大的iDBCloud控制台、专业的DBA团队支持，为我们监控数据库运行状况、

5、定位和解决数据库问题，提供了非常多的建议和帮助。      ■集群之间的共享资源统一存放在OCS（OpenCacheService，开放缓存服务）中。我们用OCS来存放数据路由和实时性不高的业务数据。缓存作为我们架构性能中非常重要的一个环节，在承受了来自整个集群各方面压力的同时，还要保证响应稳定高速。      通过该方案，不仅发挥了阿里云的优势（不涉及物理机器的维护和折损，灵活地配置升级，成熟的备份与快照方案），而且通过集群，避免了系统可能会遇到的单点故障，提高了系统弹性扩容的灵活性和可用性。      作为一个SaaS化、数据更集中、数据体量庞大的企业应用，数据库是我们整体架

6、构中的关键节点，如何保证其稳定与性能，是本文讲述的重点。      当用户进入快速增长期后，随着业务量迅速增加，核心业务表的存量数据和增长速度绝对不是单个DB所能承受的（几乎所有单DB配置都存在性能物理上限瓶颈，即使选择升级配置也会受到成本和资源上限的约束）。因此，我们一开始就将数据库分库分片（Sharding）作为一个可行方案优先考虑，主要分析如下。      ■场景：业务热点数据持续增加，团队有一定的数据库架构积累能支撑独立研发或熟悉成熟的中间件（如Cobar）。      ■优点：成本低（可以利用开源免费的数据库集群替代大型商业DB）；可灵活扩容（不断增加新的数据库切片即可

7、）；相对均匀分布的数据读写，避免单点障碍。      ■缺点：需要研发团队在数据库架构上投入大量精力；数据库集群维护需要成本投入。      考虑到业务特性，我们最终采用了行业比较通用的水平拆分+垂直拆分策略，并自主完成DAO与JDBC之间的数据访问封装层开发工作。      水平拆分：按用户将数据拆分到多个库的相同表中      水平拆分的思路，就是将原本存放在单个RDS数据库中的数据，根据业务ID不同，拆分到多个数据库中（参见图2）。拆分后，各库的表数量及表结构都保持一致。水