AWS服務(wù)概述
高擴展性應(yīng)用建設(shè)并非把應(yīng)用直接遷移到云平臺上就能輕易實現(xiàn)，相反我們需要根據(jù)云平臺的特性進(jìn)行專門的設(shè)計，這包括選擇合適的云服務(wù)類型并進(jìn)行良好的應(yīng)用架構(gòu)設(shè)計。對于希望基于AWS構(gòu)建千萬級用戶應(yīng)用的開發(fā)者而言，不僅需要對區(qū)域(Region)、可用區(qū)(AZ)和邊緣站點等基礎(chǔ)設(shè)施的分布有所了解，更需要了解不同的AWS服務(wù)各自的特點和最佳實踐。
AWS的服務(wù)可大致按照其所處層面分為三類，從下到上依次是基礎(chǔ)服務(wù)層、應(yīng)用服務(wù)層、部署和管理層。基礎(chǔ)服務(wù)層也有兩層，下層是計算(EC2、WorkSpaces)、存儲(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ù)、消息隊列服務(wù)等通用的功能單獨抽離出來。部署和管理層則有用于監(jiān)控的CloudWatch，用于部署運維工作的BeanStalk、OpsWorks、CloudFormation和CloudTrail等，以及IAM、Federation等身份管理服務(wù)。
單機到多實例
傳統(tǒng)的單機服務(wù)，到AWS上面就是跑在一個EC2實例上，這個實例上跟以前的服務(wù)器一樣上面安裝所有的Web應(yīng)用、數(shù)據(jù)庫等，搭配一個EIP，外部用Route53做DNS。遇到瓶頸后，簡單的擴展就是將小的實例換成大的實例，比如small換成2xlarge、8xlarge，服務(wù)結(jié)構(gòu)不變，可以快速實現(xiàn)，但是最終都會遇到極限。
到了這一步，就要從單實例服務(wù)變成多實例。這一步驟涉及到Web實例和數(shù)據(jù)庫實例的拆分，數(shù)據(jù)庫可以開始考慮選擇SQL或者NoSQL。SQL大家比較熟悉，優(yōu)點很明顯，缺點主要在規(guī)模變大之后呈現(xiàn)，不過一般對于百萬級用戶量內(nèi)的應(yīng)用，SQL是能夠滿足需求的;但如果數(shù)據(jù)量增長速度很快，數(shù)據(jù)是非結(jié)構(gòu)化或者半結(jié)構(gòu)化的，應(yīng)用要求的延時低、寫入的速度要求快，那考慮NoSQL會更合適一些。
幾百個用戶的情況，一個RDS實例+一個Web實例即可滿足需求，前端直接用一個EIP，即單機的情況;用戶上千的情況，建議啟動兩個RDS實例+Web實例并將實例部署在不同的可用區(qū)，前端用ELB做負(fù)載均衡。
對于百萬級以下用戶的規(guī)模，每一個可用區(qū)內(nèi)會有多個Web實例和RDS實例組成的集群，其中Active RDS實例和Standby RDS實例要放在不同的可用區(qū)，其他RDS實例均為只讀。
到了這個規(guī)模之后，再要往上擴展到百萬級，就需要改變部分工作負(fù)載的設(shè)計方式了。
改變部分工作負(fù)載的設(shè)計方式
第一步可以引入S3和CloudFront。把靜態(tài)內(nèi)容從Web實例中遷移到S3上，適合的文件類型包括靜態(tài)數(shù)據(jù)(CSS、JS、圖片、視頻)、日志、備份等。S3具備11個9的持久性，本身是海量存儲，可以支撐大量的并發(fā)訪問，而且成本很低。CDN方面，CloudFront以Web Service接口的方式提供服務(wù)，支持動態(tài)和靜態(tài)內(nèi)容、流式視頻，支持根域，支持客戶化SSL證書。
第二步可以引入ElastiCache和DynamoDB。ElastiCache是托管的Memcached和Redis服務(wù)，API是一樣的，兩者都是非常快的緩存服務(wù)(毫秒級別)，區(qū)別在于Memcached使用一個AZ，Redis可以跨AZ復(fù)制。DynamoDB是NoSQL服務(wù)，后臺存儲基于SSD，平均延時在毫秒級別。
這時候我們可以開始考慮彈性的問題，即應(yīng)用的自動擴展。彈性的實現(xiàn)有四個前提：
1.完善的、基于指標(biāo)的監(jiān)控體系
2.自動化構(gòu)建
3.自動化部署
4.集中化日志管理
在AWS上實現(xiàn)自動構(gòu)建部署，可以選擇Beanstalk、OpsWorks或CloudFormation，也可以完全自己寫腳本配合定制AMI來實現(xiàn)。Elastic Beanstalk是全自動化的，基于容器實現(xiàn)，適合常規(guī)的Web應(yīng)用;OpsWorks是半自動化的，適合較為復(fù)雜的應(yīng)用開發(fā)流程，可以對資源配給、配置管理、應(yīng)用部署、軟件升級、監(jiān)控、身份控制進(jìn)行定制化;CloudFormation是基于模板的管理模式，可定制的范圍更大。
如果以上都做到，那么一個百萬級用戶量的應(yīng)用基本上可以比較好的管理起來。進(jìn)一步到千萬級用戶量的規(guī)模，我們需要更多的引入面向服務(wù)的架構(gòu)設(shè)計，即SOA。
SOA、SOA、SOA
SOA在04、05年講得比較多，到現(xiàn)在基本上已經(jīng)是大家都認(rèn)可的做法，非常適合大規(guī)模應(yīng)用的場景，其核心在于松耦合。
比如消息隊列服務(wù)SQS，加在模塊A和模塊B之間，這樣即使模塊A宕掉了，模塊B也仍然可以正常運行一段時間。美國大選網(wǎng)站就是采用了這樣的思路，在SQL實例壓力大的時候把實例關(guān)掉，換上一個更大的實例，因為前面有SQS頂著才可以這樣做。
而AWS上的通知服務(wù)(SNS)、郵件服務(wù)(SES)，也建議大家多多采用，而不要自己搭建Web實例來做，因為此類服務(wù)在處理海量請求方面的能力要遠(yuǎn)遠(yuǎn)超過一般的實現(xiàn)。
千萬級規(guī)模對數(shù)據(jù)庫的性能挑戰(zhàn)是很大的，對于SQL，聯(lián)邦(federation)、分片(sharding)都是常用的方法，將“熱”表、快速寫數(shù)據(jù)遷移到NoSQL也是一種思路。應(yīng)用的性能挑戰(zhàn)方面，重點則在于即時獲得反饋(完善實時的監(jiān)控+報警)，以及持續(xù)的調(diào)優(yōu)各個模塊。
京公網(wǎng)安備 11010502049343號