閱讀(11.2k) 書簽贊(0) 我要糾錯

如何在AWS云平臺上構建千萬級用戶應用

2024-12-03 17:48 更新

作者方國偉

AWS服務概述

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

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

單機到多實例

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

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

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

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

到了這個規(guī)模之后，再要往上擴展到百萬級，就需要改變部分工作負載的設計方式了。

改變部分工作負載的設計方式

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

第二步可以引入ElastiCache和DynamoDB。ElastiCache是托管的Memcached和Redis服務，API是一樣的，兩者都是非?？斓木彺娣眨ê撩爰墑e），區(qū)別在于Memcached使用一個AZ，Redis可以跨AZ復制。DynamoDB是NoSQL服務，后臺存儲基于SSD，平均延時在毫秒級別。

這時候我們可以開始考慮彈性的問題，即應用的自動擴展。彈性的實現(xiàn)有四個前提：

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

? 自動化構建

? 自動化部署

? 集中化日志管理

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

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

SOA、SOA、SOA

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

比如消息隊列服務SQS，加在模塊A和模塊B之間，這樣即使模塊A宕掉了，模塊B也仍然可以正常運行一段時間。美國大選網站就是采用了這樣的思路，在SQL實例壓力大的時候把實例關掉，換上一個更大的實例，因為前面有SQS頂著才可以這樣做。

而AWS上的通知服務（SNS）、郵件服務（SES），也建議大家多多采用，而不要自己搭建Web實例來做，因為此類服務在處理海量請求方面的能力要遠遠超過一般的實現(xiàn)。

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