閱讀(11.3k) 書簽贊(0) 我要糾錯(cuò)

如何在AWS云平臺(tái)上構(gòu)建千萬級(jí)用戶應(yīng)用

2024-12-03 17:48 更新

作者方國偉

AWS服務(wù)概述

高擴(kuò)展性應(yīng)用建設(shè)并非把應(yīng)用直接遷移到云平臺(tái)上就能輕易實(shí)現(xiàn)，相反我們需要根據(jù)云平臺(tái)的特性進(jìn)行專門的設(shè)計(jì)，這包括選擇合適的云服務(wù)類型并進(jìn)行良好的應(yīng)用架構(gòu)設(shè)計(jì)。對(duì)于希望基于AWS構(gòu)建千萬級(jí)用戶應(yīng)用的開發(fā)者而言，不僅需要對(duì)區(qū)域（Region）、可用區(qū)（AZ）和邊緣站點(diǎn)等基礎(chǔ)設(shè)施的分布有所了解，更需要了解不同的AWS服務(wù)各自的特點(diǎn)和最佳實(shí)踐。

AWS的服務(wù)可大致按照其所處層面分為三類，從下到上依次是基礎(chǔ)服務(wù)層、應(yīng)用服務(wù)層、部署和管理層?；A(chǔ)服務(wù)層也有兩層，下層是計(jì)算（EC2、WorkSpaces）、存儲(chǔ)（S3、EBS、Glacier、Storage Gateway）、網(wǎng)絡(luò)（VPC、Direct Connect、ELB、Route53），上層是數(shù)據(jù)庫（RDS、Dynamo、ElastiCache、RedShift）、數(shù)據(jù)分析（EMR、Data Pipeline、Kinesis）、內(nèi)容分發(fā)（CloudFront）。應(yīng)用服務(wù)層主要是把郵件服務(wù)、消息隊(duì)列服務(wù)等通用的功能單獨(dú)抽離出來。部署和管理層則有用于監(jiān)控的CloudWatch，用于部署運(yùn)維工作的BeanStalk、OpsWorks、CloudFormation和CloudTrail等，以及IAM、Federation等身份管理服務(wù)。

單機(jī)到多實(shí)例

傳統(tǒng)的單機(jī)服務(wù)，到AWS上面就是跑在一個(gè)EC2實(shí)例上，這個(gè)實(shí)例上跟以前的服務(wù)器一樣上面安裝所有的Web應(yīng)用、數(shù)據(jù)庫等，搭配一個(gè)EIP，外部用Route53做DNS。遇到瓶頸后，簡(jiǎn)單的擴(kuò)展就是將小的實(shí)例換成大的實(shí)例，比如small換成2xlarge、8xlarge，服務(wù)結(jié)構(gòu)不變，可以快速實(shí)現(xiàn)，但是最終都會(huì)遇到極限。

到了這一步，就要從單實(shí)例服務(wù)變成多實(shí)例。這一步驟涉及到Web實(shí)例和數(shù)據(jù)庫實(shí)例的拆分，數(shù)據(jù)庫可以開始考慮選擇SQL或者NoSQL。SQL大家比較熟悉，優(yōu)點(diǎn)很明顯，缺點(diǎn)主要在規(guī)模變大之后呈現(xiàn)，不過一般對(duì)于百萬級(jí)用戶量?jī)?nèi)的應(yīng)用，SQL是能夠滿足需求的；但如果數(shù)據(jù)量增長速度很快，數(shù)據(jù)是非結(jié)構(gòu)化或者半結(jié)構(gòu)化的，應(yīng)用要求的延時(shí)低、寫入的速度要求快，那考慮NoSQL會(huì)更合適一些。

幾百個(gè)用戶的情況，一個(gè)RDS實(shí)例+一個(gè)Web實(shí)例即可滿足需求，前端直接用一個(gè)EIP，即單機(jī)的情況；用戶上千的情況，建議啟動(dòng)兩個(gè)RDS實(shí)例+Web實(shí)例并將實(shí)例部署在不同的可用區(qū)，前端用ELB做負(fù)載均衡。

對(duì)于百萬級(jí)以下用戶的規(guī)模，每一個(gè)可用區(qū)內(nèi)會(huì)有多個(gè)Web實(shí)例和RDS實(shí)例組成的集群，其中Active RDS實(shí)例和Standby RDS實(shí)例要放在不同的可用區(qū)，其他RDS實(shí)例均為只讀。

到了這個(gè)規(guī)模之后，再要往上擴(kuò)展到百萬級(jí)，就需要改變部分工作負(fù)載的設(shè)計(jì)方式了。

改變部分工作負(fù)載的設(shè)計(jì)方式

第一步可以引入S3和CloudFront。把靜態(tài)內(nèi)容從Web實(shí)例中遷移到S3上，適合的文件類型包括靜態(tài)數(shù)據(jù)（CSS、JS、圖片、視頻）、日志、備份等。S3具備11個(gè)9的持久性，本身是海量存儲(chǔ)，可以支撐大量的并發(fā)訪問，而且成本很低。CDN方面，CloudFront以Web Service接口的方式提供服務(wù)，支持動(dòng)態(tài)和靜態(tài)內(nèi)容、流式視頻，支持根域，支持客戶化SSL證書。

第二步可以引入ElastiCache和DynamoDB。ElastiCache是托管的Memcached和Redis服務(wù)，API是一樣的，兩者都是非?？斓木彺娣?wù)（毫秒級(jí)別），區(qū)別在于Memcached使用一個(gè)AZ，Redis可以跨AZ復(fù)制。DynamoDB是NoSQL服務(wù)，后臺(tái)存儲(chǔ)基于SSD，平均延時(shí)在毫秒級(jí)別。

這時(shí)候我們可以開始考慮彈性的問題，即應(yīng)用的自動(dòng)擴(kuò)展。彈性的實(shí)現(xiàn)有四個(gè)前提：

? 完善的、基于指標(biāo)的監(jiān)控體系

? 自動(dòng)化構(gòu)建

? 自動(dòng)化部署

? 集中化日志管理

在AWS上實(shí)現(xiàn)自動(dòng)構(gòu)建部署，可以選擇Beanstalk、OpsWorks或CloudFormation，也可以完全自己寫腳本配合定制AMI來實(shí)現(xiàn)。Elastic Beanstalk是全自動(dòng)化的，基于容器實(shí)現(xiàn)，適合常規(guī)的Web應(yīng)用；OpsWorks是半自動(dòng)化的，適合較為復(fù)雜的應(yīng)用開發(fā)流程，可以對(duì)資源配給、配置管理、應(yīng)用部署、軟件升級(jí)、監(jiān)控、身份控制進(jìn)行定制化；CloudFormation是基于模板的管理模式，可定制的范圍更大。

如果以上都做到，那么一個(gè)百萬級(jí)用戶量的應(yīng)用基本上可以比較好的管理起來。進(jìn)一步到千萬級(jí)用戶量的規(guī)模，我們需要更多的引入面向服務(wù)的架構(gòu)設(shè)計(jì)，即SOA。

SOA、SOA、SOA

SOA在04、05年講得比較多，到現(xiàn)在基本上已經(jīng)是大家都認(rèn)可的做法，非常適合大規(guī)模應(yīng)用的場(chǎng)景，其核心在于松耦合。

比如消息隊(duì)列服務(wù)SQS，加在模塊A和模塊B之間，這樣即使模塊A宕掉了，模塊B也仍然可以正常運(yùn)行一段時(shí)間。美國大選網(wǎng)站就是采用了這樣的思路，在SQL實(shí)例壓力大的時(shí)候把實(shí)例關(guān)掉，換上一個(gè)更大的實(shí)例，因?yàn)榍懊嬗蠸QS頂著才可以這樣做。

而AWS上的通知服務(wù)（SNS）、郵件服務(wù)（SES），也建議大家多多采用，而不要自己搭建Web實(shí)例來做，因?yàn)榇祟惙?wù)在處理海量請(qǐng)求方面的能力要遠(yuǎn)遠(yuǎn)超過一般的實(shí)現(xiàn)。

千萬級(jí)規(guī)模對(duì)數(shù)據(jù)庫的性能挑戰(zhàn)是很大的，對(duì)于SQL，聯(lián)邦（federation）、分片（sharding）都是常用的方法，將“熱”表、快速寫數(shù)據(jù)遷移到NoSQL也是一種思路。應(yīng)用的性能挑戰(zhàn)方面，重點(diǎn)則在于即時(shí)獲得反饋（完善實(shí)時(shí)的監(jiān)控+報(bào)警），以及持續(xù)的調(diào)優(yōu)各個(gè)模塊。