老李分享:如何搭建千万级别用户的应用系统 3

自动化运维

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数据库。


你可能感兴趣的:(测试)