如何在AWS上部署千万用户级别服务

Posted 2023-02-18

基础架构

AWS分布在全球12个区域里

每个区域对应着一个地理位置，里面含有多个Availability
Zones(可用区)。这些区域设置在北美，南美，欧洲，中东，非洲，亚太区。
每个AZ实质上是单个数据中心，尽管它们可由多个数据中心构建。
每个AZ有着独立的供电系统和互联网连接。
不同AZ之间以低延迟网络进行连接，这种快速网络可消除物理位置带来的速度影响。
每个区域含有至少两个AZ，共计32个AZs。
借助AZ可创建高可用性的程序架构。

AWS在全球还分布有53个偏远区域(Edge locations)

偏远区域的使用对象是CloudFront，这是Amazon的内容分发网络(CDN)和DNS服务器。
偏远区域的存在使得全球用户都可以享用低延迟网络而不论他们身在何处。建立区块服务(Block Services)
Amazon透过AWS创建了大量高可用和高容错的服务，具体的服务清单可点击这里查看。
缴纳一定的费用，你就可以在个人的应用中使用这些服务而不必为高可用性而忧心。
部分服务位于一个AZ中：CloudFront, Route 53, S3, DynamoDB, Elastic Load
Balancing, EFS, Lambda, SQS, SNS, SES, SWF。
即使是使用单个AZ的服务，其高可用架构也是足够强大的。

1个用户

在这个时候，开发者=用户。你的架构看起来是这样的：

运行单个实例，如t2.micro。你可以为你的服务器选择不同的CPU，内存，存储设备和网络环境。
该服务器承载了全部web任务，如：web应用，数据库，管理器等。
使用AmazonRoute 53进行DNS管理。
为该实例附加一个Elastic IP地址。

那么随着用户数的增加，我们需要如何进行升级改造，直至能为千万用户提供优质的服务呢？强调文字

优化策略

采用多主机模式

尝试使用Amazon数据库服务，如Amazon RDS(关系数据库)，Amazon DynamoDB(NoSQL数据库)，Amazon Redshift。
逐步从SQL数据库转为NoSQL数据库，特别是数据量超过5TB，你的应用对低延迟敏感的时候。
使用Elastic Load Balancer(弹性负载均衡器)，它可以对主机进行健康检测以确保网络的通畅，同时可以帮助实现网络的扩展。

垂直升级

需要更强的实例类型，例如c4.8xlarge或者m3.2xlarge。
停止使用当前的服务器，换用功能更强大的机器，如：244GB RAM，40核CPU。
某些Amazon服务提供了Provisined IOPS选项以便用户自行配置变更，这样一来用户可以使用类似DynamoDB的扩展服务。
类似上面的做法就叫做垂直升级。但其有个缺点，就是一旦机器出错，你的网站也会停止运作了。所以要尽量避免单个实例的做法。

自动扩展

如果你一直在为峰值负载而努力，如黑色星期五，那么其实是在浪费金钱。更好的解决方案

列表内容
是按需分配，这就是Auto Scaling(自动扩展)，在计算机群组中实现自动化的大小变更。
你可以为你的容量池定义最大值和最小值。
CloudWatch是一个管理服务，已内置到所有的Amazon应用中。
CloudWatch事件会触发扩展。
触发事件可以是CPU占用率，时间延迟，网速等等。
你也可以向CloudWatch导入自定义基线，按照你的意愿来触发扩展。

架构分解

使用SOA/微服务，使你的服务层组件化。
这样做的好处是单独的服务可以独立地进行扩展，从而大大增加了灵活性和可用性。
SOA是Amazon提供的重要架构组件。

避免重复劳动

把精力投入到能使你的业务与众不同的事情上。
Amazon提供了很多高容错的服务。例如，排队(SQS服务)，邮件，转码，搜索，数据库，监控等等。所以类似的服务都不必再次编写了。

用户数>千万+

当用户达到千万级别的时候，你考虑的策略应该是这样的：

多AZs模式

在不同层之间执行ELB(弹性负载平衡)。除了web层，在应用层，数据层等层里也需要进行ELB。

能够自动扩展

使用面向服务的架构
缓存架构内和外的数据
使用Amazon S3和CloudFront。S3用于存储静态数据，如js，CSS，图像等，具有足够的扩展性。CloudFront可对数据进行缓存。
使用Amazon SES来进行邮件发送。
使用CloudWatch进行监控。

对数据写入执行如下的策略：

联结 – 根据功能划分不同的数据库。
分表 – 把一个数据集分解到多个主机上。
把部分功能放到其他类型的数据库上（NoSQL,graph等）。
不断优化你的应用和整个架构堆栈，针对瓶颈进行分析并找出解决方法。 参考技术A 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，平均延时在毫秒级别。
这时候我们可以开始考虑弹性的问题，即应用的自动扩展。弹性的实现有四个前提：
完善的、基于指标的监控体系
自动化构建
自动化部署
集中化日志管理
在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也是一种思路。应用的性能挑战方面，重点则在于即时获得反馈（完善实时的监控+报警），以及持续的调优各个模块。