自动化运维

l 随着基础设施越来越大，它扩展到了上千个实例，我们有读副本，我们有水平横线扩展，对于这些我们需要一些自动化运维措施去对他们进行管理，我们可不希望对着每个实例一个一个单独地管理。

l 自动化运维工具分为两个层级

1. DIY层，包括Amazon EC2和AWS CloudFormation。

2. 更高层次的服务，包括AWS Elastic Beanstalk和AWS OpsWorks。

l AWS Elastic Beanstalk，为你的应用自动管理基础设施，很方便。

l AWS OpsWorks，应用程序管理服务，用于部署和操作不同形态规模的应用程序，它还能做到持续集成。

l AWS CloudFormation

1. 提供了最大的灵活性，它提供了你的应用栈的模板，它可以构建你的整个应用栈，或者仅仅是应用栈中的某个组件。

2. 如果你要更新你的应用栈你只要更新CloudFormation模板，它将更新你的整个应用。

3. 它拥有大量的控制，但缺乏便利性。

l AWS CodeDeploy，部署你的程序到整个EC2实例集群

1. 可以部署一到上千个实例。

2. Code Deploy可以指向一个自动扩展配置。

3. 可连同Chef和Puppet一起使用。

解耦基础设施

l 使用SOA/微服务，从你的应用抽离出不同服务，就像前面你将web层与数据库层分离出来那样，再分别创建这些服务。

l 这些独立出来的服务就可以根据自己需要扩展，它给你系统的扩展带来了灵活性，同时也保证了高可用性。

l SOA是Amazon搭建架构关键的组成部分。

l 松耦合解放了你

1. 你可以对某些服务单独地扩展和让它失效。

2. 如果一个工作节点从SQS拉取数据失败，没有没关系？没有，只要重启另外一个工作节点即可，所有操作都有可能发生故障，所以一定要搭建一个可以处理故障的架构，提供failover功能。

3. 将所有模块设置成黑盒。

4. 把交互设计成松耦合方式。

5. 优先考虑内置了冗余性和可扩展性的服务，而不是靠自己构建实现。

不要重复发明轮子

l 只需把你区别于已有任务的部分作为你的业务逻辑。

l Amazon的很多服务本身具备容错能力，因为他们跨多个可用区域，例如：队列、邮件、转码、搜索、数据库、监控、性能指标采集、日志处理、计算等服务，没有必要自己搭建。

l SQS：队列服务

1. Amazon提供的第一个服务。

2. 它是跨可用区域的所以拥有容错性。

3. 它具备可扩展性、安全性、简单性。

4. 队列可以帮助你的基础设施上的不同组件之间传递消息。

5. 以图片管理系统为例，图片收集系统和图片处理系统是两个不同的系统，他们各自都可以独立地扩展，他们之间具备松耦合特性，摄取照片然后扔进队列里面，图片处理系统可以拉取队列里面的图片再对其进行其他处理。

l AWS Lambda，用于代码部署和服务管理。

1. 提供解耦你的应用程序的工具。

2. 在前面图片系统的例子中，Lambda可以响应S3的事件，就像S3中某文件被增加时Lambda相关函数会被自动触发去处理一些逻辑。

3. 已经在EC2上集成，供应用扩展。

百万级别用户

l 当用户数量达到百万级别时，这就要求前面提到的所有方案都要综合考虑。

1. 扩展多为可用区域。

2. 在所有层之间使用弹性负载均衡，不仅在web层使用，而且还要在应用层、数据层以及应用包含的其他所有层都必须使用弹性负载均衡。

3. 自动伸缩能力。

4. 面向服务的架构体系。

5. 巧妙使用S3和CloudFront部署一部分内容。

6. 在数据库前面引入缓存。

7. 将涉及状态的对象移除出Web层。

l 使用Amazon SES发送邮件。

l 使用CloudWatch监控。

 

千万级别用户

l 当我们的系统变得越来越大，我们会在数据层遇到一些问题，你可能会遇到竞争写主库的数据库问题，这也就意味着你最多只能发送这么多写流量到一台服务器上。

l 你如何解决此问题？

1. Federation，根据你的应用功能把数据库分成多个库。

2. Sharding，分表分片，使用多个服务器分片。

3. 把部分数据迁移到其他类型的数据库上，例如NoSQL、graph等。

l Federation——根据应用功能切分成多个库

1. 例如，创建一个论坛数据库、一个用户数据库、一个产品数据库，你可能之前就是一个数据库包含这所有类型的数据，所以现在要将他们拆分开。

2. 按照功能分离出来的数据库可以各自独立进行扩展。

3. 缺点：不能做跨数据库查询。

l Sharding——将数据分割到多主机上

1. 应用层变得更加复杂，扩展能力更强。

2. 例如，对于用户数据库，三分之一的用户被发送到一个分片上，三分之一发到另一个分片上，最后三分之一发到第三个分片。

l 将数据迁移到其他类型的数据库上

1. 考虑NoSQL数据库。

2. 如果你的数据不要求复杂的join操作，比如说排行榜，日志数据，临时数据，热表，元数据/查找表等等，满足这些情况可以考虑迁移到NoSQL数据库上。

3. 这意味着他们可以各自单独扩展。

11000000用户

l 扩展是一个迭代的过程，当你的系统变得越来越大，你总有更多的事情需要你解决。

l 调整你的应用架构。

l 更多的SOA特性和功能。

l 从多可用区域到多区域。

l 自定义解决方案去解决你的特定问题，当用户量到达十亿级别时自定义解决方案是必要的。

l 深入分析你的整个应用栈。

回顾

l 使用多可用区域的基础设施提升可靠性。

l 使用自带扩展能力的服务，比如ELB，S3，SQS，SNS，DynamoDB等等。

l 每一层级都建立冗余，可扩展性和冗余性不是两个分开单独的概念，经常需要同时考虑两者。

l 刚开始使用传统关系型数据库。

l 在你的基础设施的里面和外面都考虑缓冲数据。

l 在你的基础设施中使用自动化工具。

l 确保你的应用有良好的指标采样、系统监控、日志记录，确保收集你的用户访问你的应用过程中产生的问题。

l 将各个层分拆成独立的SOA服务，让这些服务能保持最大的独立性，可以各自进行扩展，及时发生故障也不波及其他。

l 一旦做了足够的准备及可使用自动扩展功能。

l 不重复发明轮子，尽量使用托管服务而不是自己构建，除非非要不可。

必要的情况下转向NoSQL数据库。