原文链接：A Beginner’s Guide To Scaling To 11 Million+ Users On Amazon’s AWS
译者：杰微刊–汪建
一个系统从一个用户到多于1100万用户访问，你将如何对你的系统进行扩展？Amazon的web服务解决方案架构师乔尔?威廉姆斯就此话题给出了一个精彩的演讲：2015扩展你的第一个一千万用户。
如果你是一个拥有较丰富的AWS使用经验的用户，这个演讲将不太适合你，但如果你作为一个刚接触云、刚接触AWS的新用户，或者你还没有跟上Amazon源源不断对外发布的AWS新特性，它将是一个很好的入门资料。
正如大家所期望的，这个演讲讨论Amazon服务如何针对问题提出先进且主流的解决方案，Amazon平台总是令人印象深刻且拥有指导性。对于如何把所有产品组合在一起Amazon做了大量工作去提取出用户需要的是什么，并且确保Amazon对于每个用户的需求都拥有一个产品能满足这部分的需求。
演讲的一些有趣的要点：
1、一般刚开始时使用SQL而在必要时刻转向NoSQL。
2、一致的观点是通过引入组件去解耦系统，使用组件便于扩展并且组件故障不会影响到其他模块。组件便于使系统分层和构建微服务。
3、只把区别于已有任务的部分作为你的业务逻辑，不要重复发明轮子。
4、可伸缩性和冗余性不是两个互相独立的概念，你经常要将两个概念同时放在一起考虑。
5、没有提及成本，成为AWS解决方案被批评的一个主要方面。
基本情况
AWS覆盖全世界12个国家区域
1. 每个区域都对应着世界上的一个物理位置，每个位置都有弹性计算云提供多个可用区域（Availability Zones），这些区域包含北美、南美、欧洲、中东、非洲、亚太等地区。
2. 每个可用区域（AZ）实质上是单个数据中心，尽管它可由多个数据中心构造。
3. 每个可用区域都拥有很强的隔离性，他们各自拥有独立的电源和网络。
4. 可用区域之间只能通过低延迟网络互相连接，它们可以相距5或15英里，但网络的速度相当快以至于你的应用程序像在同一个数据中心。
5. 每个区域至少有2个可用区域，可用区域总共有32个。
6. 借助若干可用区域即可构建一个高可用的架构供你的应用使用。
7. 在即将到来的2016年将会增加至少9个可用区域和4个区域。
AWS在世界上拥有53个边缘位置
1. 这些边缘位置被用于Amazon的内容分发网络CDN、Route53、CloudFront以及Amazon的DNS管理服务器。
2. 边缘位置使用户可以在世界的任何角落低延迟地访问网页。
构建块服务
1. AWS已经使用多个可用区域构架了大量服务供使用，这些服务内部拥有高可用性和容错性。以下是可供使用的服务列表。
2. 你可以在你的应用中直接使用这些服务，它们是收费的，但使用它们你可以不必自己考虑高可用性。
3. 每个可用区域都提供很多服务，包括CloudFront, Route 53, S3, DynamoDB, 弹性负载均衡, EFS, Lambda, SQS, SNS, SES, SWF。
4. 即使这些服务只存在于一个单一的可用区域，通过使用这些服务任然可以构建一个高可用架构。
一个用户
在这种情况下，你是作为仅有的用户，你仅仅只想让web应用跑起来。
你的架构看起来像下面几点：
1. 运行在单独的实例上，可能是t2.micro型。实例类型包括了CPU、内存、存储和网络的不同组合，通过选择这些不同实例类型组成一个适合你的web应用的资源。
2. 在单独的实例上运行整个web栈，例如web应用程序、数据库以及各种管理系统等。
3. 使用Amazon的Route53作为DNS服务。
4. 在此实例上添加一个的弹性IP。
5. 在一段时间内运行的良好。
纵向扩展
1、你需要一个更大的容器放置你的应用，最简单的扩展方法是选择一个更大的实例类型，例如c4.8xlarge或者m3.2xlarge。
2、这种方法称为纵向扩展。
3、需要做的仅仅是选择一个新型实例取代原来的实例，应用跑起来即可以更加强大。
4、提供多种不同的硬件配置混搭选择，可以选择一个244G内存的系统（2TB的RAM即将到来），也可以选择40个CPU内核的系统，可以组成I/0密集型实例、CPU密集型实例以及高存储型实例。
5、Amazon的一些服务使用可配置的IOPS选项来保证性能，你可以使用小一点的实例去跑你的应用，对于需要扩展的服务独立使用Amazon的可扩展服务，例如DynamoDB。
6、纵向扩展有一个很大的问题：它不具备failover功能，同时也不具备冗余性。就像把所有鸡蛋都放在同一个篮子里，一旦实例发生故障你的web也会宕掉。
7、一个单独的实例最终能做到的也就这些，想要更加强大需要其他的措施。
10+用户
将单个主机分为多个主机
1. Web应用使用一台主机。
2. 数据库使用一台主机，你可以在上面跑任意数据库，只要负责数据库的管理。
3. 将主机分离成多个主机可以让web应用和数据库各自独立对自己进行扩展，例如在某种情况下可能你需要的数据库比web应用更大的规模。
或者你可以不自己搭建数据库转而使用Amazon的数据库服务
1. 你是一个DBA吗？你真的想要担心数据备份的问题吗？担心高可用？担心数据库补丁？担心操作系统？
2. 使用Amazon数据库服务有一大优势，你只要简单一点击即可完成多可用区域的数据库的安装，而且你不必担心这些可用区域之间的数据备份或其他类似的事情，这些数据库具备高可用性高可靠性。
正如你所想，Amazon有几种类型的完全托管数据库服务供出售：
1. Amazon RDS(Relational Database Service)，可供选择的数据库类型相当多，包括Microsoft SQL Server, Oracle, MySQL, PostgreSQL, MariaDB, Amazon Aurora.
2. Amazon DynamoDB，一个NoSQL数据库。
3. Amazon Redshift，一个PB级的数据仓库系统。
更多Amazon 特性
1. 拥有自动扩展存储到64TB的能力，你不再需要限定你的数据存储。
2. 多大15个读副本。
3. 持续增量备份到S3。
4. 多达6路备份到3个可用区域，有助于处理故障。
5. MySQL兼容。
用SQL数据库取代NoSQL数据库
1. 建议使用SQL数据库。
2. SQL数据库相关技术完善。
3. 存在大量开源源码、社区、支持团队、书籍和工具。
4. 千万用户级别系统的还不足以拖垮SQL数据库，除非你的数据非常巨大。
5. 具有清晰的扩展模式。
什么时候你才需要使用NoSQL数据库
1. 如果你一年需要存储超过5TB的数据，或者你有一个令人难以置信的数据密集任务。
2. 你的应用具有超低延迟需求。
3. 你的应用需要一个非常高的吞吐量，需要在数据的读写I/O上进行优化。
4. 你的应用没有任何关系型数据。
100+用户
在web层进行主机分离。
使用Amazon RDS存储数据，它把数据库的所有工作都揽下了。
上面两点做好即可。
1000+用户
现在你构建的应用存在可用性问题，你的web应用将会宕掉如果你web服务的主机宕掉了。
你需要在另外一个可用区域上搭建另外一个web实例，由于可用区域之间拥有毫秒级别的低延迟，他们看起来就像互相挨着。
同样，你需要在另外一个可用区域上搭建一个RDS数据库slave，组成主备数据库，一旦主数据库发生故障你的web应用将会自动切换到slave备数据库。由于你的应用总是使用相同的端，failover不会带给应用任何改变。
在两个可用区域中分布着两个web主机实例，使用弹性负载均衡器（ELB）将用户访问分流到两个web主机实例。
弹性负载均衡器（ELB）
1. ELB是一个高可用的负载均衡器，它存在于所有的可用区域中，对于你的应用来说它是一个DNS服务，只需要把他放到Route53即可，它就会在你的web主机实例中进行负载分发。
2. ELB有健康检查机制，这个机制保证流量不会分发到宕掉的主机上。
3. 不用采取任何措施即可完成扩展，当它发现额外流量时它将在后台通过横向和纵向扩展，随着你的应用不断扩展，它也会自动不断扩展，而且这些都是系统自动完成的，你不必对ELB做任何管理。
10000到100000用户
前面例子中说到ELB后面挂载两个web主机实例，而实际上你可以在ELB后面挂载上千个主机实例，这就叫横向扩展。
添加更多的读副本到数据库中，或者添加到RDS中，但需要保持副本的同步。
通过转移一些流量到web层服务器减轻web应用的压力，例如从你的web应用中将静态内容抽离出来放到Amazon S3和Amazon CloudFront上，CloudFront是Amazon的CDN，它会将你的静态内容保存在全世界的53个边缘地区，通过这些措施提高性能和效率。
Amazon S3是一个对象仓库。
1. 它不像EBS，它不是搭载在EC2实例上的存储设备，它是一个对象存储而不是块存储。
2. 对于静态内容如JavaScript、css、图片、视频等存放在Amazon S3上再合适不过，这些内容没必要放到EC2实例上。
3. 高耐用性，11个9的可靠性。
4. 无限制的可扩展，只要你想可以往里面扔尽可能多的数据，用户在S3上存储了PB级别的数据。
5. 支持最大5TB的对象存储。
6. 支持加密，你可以使用Amazon的加密，或者你自己的加密，又或者第三方的加密服务。
Amazon CloudFront对你的内容提供缓存
1. 它将内容缓存在边缘地区以便供你的用户低延迟访问。
2. 如果没有CDN，将导致你的用户更高延迟地访问你的内容，你的服务器也会因为处理web层的请求而处于更高的负载。
3. 例如有个客户需要应对60Gbps的访问流量，CloudFront将一切都处理了，web层甚至都不知道有这么大的访问流量存在。
你还可以通过转移session状态减轻你的web层的负载
1. 将session状态保存到ElastiCache或DynamoDB。
2. 这个方法也让你的系统在未来可以自动扩展。
你也可以将数据库的一些数据缓存在ElastiCache减轻应用负载
数据库没有必要处理所有获取数据的请求，缓存服务可以处理这些请求从而让宝贵的数据库资源处理更加重要的操作。
Amazon DynamoDB——全托管的NoSQL数据库
1. 根据你自己想要的吞吐量，定制你想要的读写性能。
2. 支持高性能。
3. 具备分布式和容错性，它部署在多个可用区域中。
4. 它以kv结构存储，且支持JSON格式。
5. 支持最大400k大的文件。
Amazon Elasticache ——全托管的Memcached或Redis
1. 维护管理一个memcached集群并不会让你赚更多的钱，所以让Amazon来做。
2. Elasticache集群会自动帮你扩展，它是一个具备自我修复特性的基础设施，如果某些节点宕掉了其它的新节点即会自动启动。
你也可以转移动态内容到CloudFront减轻负载
众所周知CloudFront能处理静态内容，例如文件，但除此之外它还还能处理某些动态内容，这个话题不再进行深入的探讨，可以看看这个链接。
自动扩展
对于黑色星期五，假如你不用做任何扩展就足够处理这些峰值流量，那么你是在浪费钱。如果需求和计算能力相匹配自然是最好的，而这由自动扩展帮你实现，它会自动调整计算集群的大小。
作为用户，你可以决定集群的最小实例数和最大实例数，通过实例池中设置最小和最大实例数即可。
云监控是一种嵌入应用的管理服务
1. 云监控的事件触发扩展。
2. 你准备扩展CPU的数量吗？你准备优化延迟吗？准备扩展带宽吗？
3. 你也可以自定义一些指标到云监控上，如果你想要指定应用针对某些指标自动扩展，只需将这些指标放到云监控上，告诉根据云监控根据这些指标分别扩展哪些资源。
500000+用户
前面的配置可以自动扩展群组添加到web层，在两个可用区域里自动扩展群组，也可以在三个可用区域里扩展，在不同可用区域中的多实例模式不经可以确保可扩展性，同时也保证了可用性。
论题中的案例每个可用区域只有3个web层实例，其实它可以扩展成上千个实例，而你可以设置实例池中最小实例数为10最大实例数为1000。
ElastiCache用于承担数据库中热点数据的读负载。
DynamoDB用于Session数据的负载。
你需要增加监控、指标以及日志。
1. 主机级别指标，查看自动扩展的集群中的某一CPU参数，快速定位到问题的位置。
2. 整体级别指标，查看弹性负载均衡的指标判断整个实例集群的整体性能。
3. 日志分析，使用CloudWatch日志查看应用有什么问题，可以使用CloudTrail对这些日志进行分析管理。
4. 外部站点监控，使用第三方服务例如New Relic或Pingdom监控作为终端用户看到了什么情况。
你需要知道你的用户的反馈，他们是不是访问延迟很慢，他们在访问你的web应用时是不是出现了错误。
从你的系统结构中尽可能多地排出性能指标，这有助于自动扩展的决策，你可不希望你的系统CPU使用率才20%。
自动化运维
随着基础设施越来越大，它扩展到了上千个实例，我们有读副本，我们有水平横线扩展，对于这些我们需要一些自动化运维措施去对他们进行管理，我们可不希望对着每个实例一个一个单独地管理。
自动化运维工具分为两个层级
1. DIY层，包括Amazon EC2和AWS CloudFormation。
2. 更高层次的服务，包括AWS Elastic Beanstalk和AWS OpsWorks。
AWS Elastic Beanstalk，为你的应用自动管理基础设施，很方便。
AWS OpsWorks，应用程序管理服务，用于部署和操作不同形态规模的应用程序，它还能做到持续集成。
AWS CloudFormation
1. 提供了最大的灵活性，它提供了你的应用栈的模板，它可以构建你的整个应用栈，或者仅仅是应用栈中的某个组件。
2. 如果你要更新你的应用栈你只要更新CloudFormation模板，它将更新你的整个应用。
3. 它拥有大量的控制，但缺乏便利性。
AWS CodeDeploy，部署你的程序到整个EC2实例集群
1. 可以部署一到上千个实例。
2. Code Deploy可以指向一个自动扩展配置。
3. 可连同Chef和Puppet一起使用。
解耦基础设施
使用SOA/微服务，从你的应用抽离出不同服务，就像前面你将web层与数据库层分离出来那样，再分别创建这些服务。
这些独立出来的服务就可以根据自己需要扩展，它给你系统的扩展带来了灵活性，同时也保证了高可用性。
SOA是Amazon搭建架构关键的组成部分。
松耦合解放了你
1. 你可以对某些服务单独地扩展和让它失效。
2. 如果一个工作节点从SQS拉取数据失败，没有没关系？没有，只要重启另外一个工作节点即可，所有操作都有可能发生故障，所以一定要搭建一个可以处理故障的架构，提供failover功能。
3. 将所有模块设置成黑盒。
4. 把交互设计成松耦合方式。
5. 优先考虑内置了冗余性和可扩展性的服务，而不是靠自己构建实现。
不要重复发明轮子
只需把你区别于已有任务的部分作为你的业务逻辑。
Amazon的很多服务本身具备容错能力，因为他们跨多个可用区域，例如：队列、邮件、转码、搜索、数据库、监控、性能指标采集、日志处理、计算等服务，没有必要自己搭建。
SQS：队列服务
1. Amazon提供的第一个服务。
2. 它是跨可用区域的所以拥有容错性。
3. 它具备可扩展性、安全性、简单性。
4. 队列可以帮助你的基础设施上的不同组件之间传递消息。
5. 以图片管理系统为例，图片收集系统和图片处理系统是两个不同的系统，他们各自都可以独立地扩展，他们之间具备松耦合特性，摄取照片然后扔进队列里面，图片处理系统可以拉取队列里面的图片再对其进行其他处理。
AWS Lambda，用于代码部署和服务管理。
1. 提供解耦你的应用程序的工具。
2. 在前面图片系统的例子中，Lambda可以响应S3的事件，就像S3中某文件被增加时Lambda相关函数会被自动触发去处理一些逻辑。
3. 已经在EC2上集成，供应用扩展。
百万级别用户
当用户数量达到百万级别时，这就要求前面提到的所有方案都要综合考虑。
1. 扩展多为可用区域。
2. 在所有层之间使用弹性负载均衡，不仅在web层使用，而且还要在应用层、数据层以及应用包含的其他所有层都必须使用弹性负载均衡。
3. 自动伸缩能力。
4. 面向服务的架构体系。
5. 巧妙使用S3和CloudFront部署一部分内容。
6. 在数据库前面引入缓存。
7. 将涉及状态的对象移除出Web层。
使用Amazon SES发送邮件。
使用CloudWatch监控。
千万级别用户
当我们的系统变得越来越大，我们会在数据层遇到一些问题，你可能会遇到竞争写主库的数据库问题，这也就意味着你最多只能发送这么多写流量到一台服务器上。
你如何解决此问题？
1. Federation，根据你的应用功能把数据库分成多个库。
2. Sharding，分表分片，使用多个服务器分片。
3. 把部分数据迁移到其他类型的数据库上，例如NoSQL、graph等。
Federation——根据应用功能切分成多个库
1. 例如，创建一个论坛数据库、一个用户数据库、一个产品数据库，你可能之前就是一个数据库包含这所有类型的数据，所以现在要将他们拆分开。
2. 按照功能分离出来的数据库可以各自独立进行扩展。
3. 缺点：不能做跨数据库查询。
Sharding——将数据分割到多主机上
1. 应用层变得更加复杂，扩展能力更强。
2. 例如，对于用户数据库，三分之一的用户被发送到一个分片上，三分之一发到另一个分片上，最后三分之一发到第三个分片。
将数据迁移到其他类型的数据库上
1. 考虑NoSQL数据库。
2. 如果你的数据不要求复杂的join操作，比如说排行榜，日志数据，临时数据，热表，元数据/查找表等等，满足这些情况可以考虑迁移到NoSQL数据库上。
3. 这意味着他们可以各自单独扩展。
11000000用户
扩展是一个迭代的过程，当你的系统变得越来越大，你总有更多的事情需要你解决。
调整你的应用架构。
更多的SOA特性和功能。
从多可用区域到多区域。
自定义解决方案去解决你的特定问题，当用户量到达十亿级别时自定义解决方案是必要的。
深入分析你的整个应用栈。
回顾
使用多可用区域的基础设施提升可靠性。
使用自带扩展能力的服务，比如ELB，S3，SQS，SNS，DynamoDB等等。
每一层级都建立冗余，可扩展性和冗余性不是两个分开单独的概念，经常需要同时考虑两者。
刚开始使用传统关系型数据库。
在你的基础设施的里面和外面都考虑缓冲数据。
在你的基础设施中使用自动化工具。
确保你的应用有良好的指标采样、系统监控、日志记录，确保收集你的用户访问你的应用过程中产生的问题。
将各个层分拆成独立的SOA服务，让这些服务能保持最大的独立性，可以各自进行扩展，及时发生故障也不波及其他。
一旦做了足够的准备及可使用自动扩展功能。
不重复发明轮子，尽量使用托管服务而不是自己构建，除非非要不可。
必要的情况下转向NoSQL数据库。
参考资料
On HackerNews / On Reddit
http://aws.amazon.com/documentation
http://aws.amazon.com/architecture
http://aws.amazon.com/start-ups
From：http://www.jfh.com/jfperiodical/article/1242
