如何在AWS云平台上构建千万级用户应用

AWS 服务概述

高扩展性应用建设并非把应用直接迁移到云平台上就能轻易实现，相反我们需要根据云平台的特性进行专门的设计，这包括选择合适的云服务类型并进行良好的应用架构设计。对于希望基于 AWS 构建千万级用户应用的开发者而言，不仅需要对区域（Region）、可用区（AZ）和边缘站点等基础设施的分布有所了解，更需要了解不同的 AWS 服务各自的特点和最佳实践。

AWS 的服务可大致按照其所处层面分为三类，从下到上依次是基础服务层、应用服务层、部署和管理层。基础服务层也有两层，下层是计算（EC2、WorkSpaces）、存储（S3、EBS、Glacier、Storage Gateway）、网络（VPC、Direct Connect、ELB、Route53），上层是数据库（RDS、Dynamo、ElastiCache、RedShift）、数据分析（EMR、Data Pipeline、Kinesis）、内容分发（CloudFront）。应用服务层主要是把邮件服务、消息队列服务等通用的功能单独抽离出来。部署和管理层则有用于监控的 CloudWatch，用于部署运维工作的 BeanStalk、OpsWorks、CloudFormation 和 CloudTrail 等，以及 IAM、Federation 等身份管理服务。

单机到多实例

传统的单机服务，到 AWS 上面就是跑在一个 EC2 实例上，这个实例上跟以前的服务器一样上面安装所有的 Web 应用、数据库等，搭配一个 EIP，外部用 Route53 做 DNS。遇到瓶颈后，简单的扩展就是将小的实例换成大的实例，比如 small 换成 2xlarge、8xlarge，服务结构不变，可以快速实现，但是最终都会遇到极限。

到了这一步，就要从单实例服务变成多实例。这一步骤涉及到 Web 实例和数据库实例的拆分，数据库可以开始考虑选择 SQL 或者 NoSQL。SQL 大家比较熟悉，优点很明显，缺点主要在规模变大之后呈现，不过一般对于百万级用户量内的应用，SQL 是能够满足需求的；但如果数据量增长速度很快，数据是非结构化或者半结构化的，应用要求的延时低、写入的速度要求快，那考虑 NoSQL 会更合适一些。

几百个用户的情况，一个 RDS 实例+一个 Web 实例即可满足需求，前端直接用一个 EIP，即单机的情况；用户上千的情况，建议启动两个 RDS 实例 +Web 实例并将实例部署在不同的可用区，前端用 ELB 做负载均衡。

对于百万级以下用户的规模，每一个可用区内会有多个 Web 实例和 RDS 实例组成的集群，其中 Active RDS 实例和 Standby RDS 实例要放在不同的可用区，其他 RDS 实例均为只读。

到了这个规模之后，再要往上扩展到百万级，就需要改变部分工作负载的设计方式了。

改变部分工作负载的设计方式

第一步可以引入 S3 和 CloudFront。把静态内容从 Web 实例中迁移到 S3 上，适合的文件类型包括静态数据（CSS、JS、图片、视频）、日志、备份等。S3 具备 11 个 9 的持久性，本身是海量存储，可以支撑大量的并发访问，而且成本很低。CDN 方面，CloudFront 以 Web Service 接口的方式提供服务，支持动态和静态内容、流式视频，支持根域，支持客户化 SSL 证书。

第二步可以引入 ElastiCache 和 DynamoDB。ElastiCache 是托管的 Memcached 和 Redis 服务，API 是一样的，两者都是非常快的缓存服务（毫秒级别），区别在于 Memcached 使用一个 AZ，Redis 可以跨 AZ 复制。DynamoDB 是 NoSQL 服务，后台存储基于 SSD，平均延时在毫秒级别。

这时候我们可以开始考虑弹性的问题，即应用的自动扩展。弹性的实现有四个前提：

1. 完善的、基于指标的监控体系
2. 自动化构建
3. 自动化部署
4. 集中化日志管理

在 AWS 上实现自动构建部署，可以选择 Beanstalk、OpsWorks 或 CloudFormation，也可以完全自己写脚本配合定制 AMI 来实现。Elastic Beanstalk 是全自动化的，基于容器实现，适合常规的 Web 应用；OpsWorks 是半自动化的，适合较为复杂的应用开发流程，可以对资源配给、配置管理、应用部署、软件升级、监控、身份控制进行定制化；CloudFormation 是基于模板的管理模式，可定制的范围更大。

如果以上都做到，那么一个百万级用户量的应用基本上可以比较好的管理起来。进一步到千万级用户量的规模，我们需要更多的引入面向服务的架构设计，即 SOA。

SOA、SOA、SOA

SOA 在 04、05 年讲得比较多，到现在基本上已经是大家都认可的做法，非常适合大规模应用的场景，其核心在于松耦合。

比如消息队列服务 SQS，加在模块A和模块B之间，这样即使模块A宕掉了，模块B也仍然可以正常运行一段时间。美国大选网站就是采用了这样的思路，在 SQL 实例压力大的时候把实例关掉，换上一个更大的实例，因为前面有 SQS 顶着才可以这样做。

而 AWS 上的通知服务（SNS）、邮件服务（SES），也建议大家多多采用，而不要自己搭建 Web 实例来做，因为此类服务在处理海量请求方面的能力要远远超过一般的实现。

千万级规模对数据库的性能挑战是很大的，对于 SQL，联邦（federation）、分片（sharding）都是常用的方法，将“热”表、快速写数据迁移到 NoSQL 也是一种思路。应用的性能挑战方面，重点则在于即时获得反馈（完善实时的监控+报警），以及持续的调优各个模块。

参考资料

• AWS 官网
• AWS 参考架构
• AWS 白皮书
• AWS 英文博客
• 在线动手实验

本文链接