云服務(wù)器平臺的選擇上，我們都知道Amazon Web
Services(AWS)作為云計算和數(shù)據(jù)解決方案領(lǐng)導(dǎo)者的重要性。隨著越來越多的公司發(fā)現(xiàn)自己正在處理大量數(shù)據(jù)，確保訪問大數(shù)據(jù)解決方案以計算和分析此數(shù)據(jù)非常重要。
AWS提供了各種各樣的云計算工具，可提供從計算大數(shù)據(jù)的框架到用于理解該數(shù)據(jù)的分析等所有內(nèi)容。
互聯(lián)數(shù)據(jù)除了大家熟悉的國內(nèi)三大廠阿里云、騰訊云、華為云等國際站平臺提供代充服務(wù)外，國外也有好多優(yōu)質(zhì)的云廠商支持代充服務(wù)，如：AWS、Azure、谷歌云等，相較于國內(nèi)云廠商，因不同的商業(yè)條件，導(dǎo)致各自的服務(wù)差異化，在其中，AWS亞馬遜云也是眾多用戶熱門選擇之一。
AWS云計算解決方案：http://www.bxgb88.com/zt/2023-05-06/
AWS的技術(shù)解決方案有哪些?
1、容災(zāi)：既然我們講到了云服務(wù)商的事故，那么，就先從容災(zāi)講起。AWS在此踩了很多坑，也收獲了很多寶貴的經(jīng)驗。
首先是availability zone。availibility
zone是容災(zāi)的最重要一環(huán)。在aws分布全球的若干個region里，每個region都有若干個物理上相隔一定距離但又不太遠(yuǎn)(大概5-15miles)的數(shù)個獨立的data
center，也叫availibility
zone(AZ)。物理上獨立的意義是：獨立的機(jī)房，獨立的供電系統(tǒng)，獨立的ISP接入系統(tǒng)等。這保證在一個AZ完全掛掉的情況下(比如電力故障，網(wǎng)絡(luò)故障，甚至修路施工隊的愚蠢的「實習(xí)生」挖斷了光纜導(dǎo)致的ISP故障等)，你的應(yīng)用在另一個AZ還能正常使用。
這一點很重要。若干AZ保持距離但又不太遠(yuǎn)保證了能夠物理容災(zāi)的同時，你還可以將其幾乎等同于同一個data
center進(jìn)行應(yīng)用層面的容災(zāi)，比如說database的master/savle分別架在兩個不同的AZ而不必過分擔(dān)心網(wǎng)絡(luò)層面的性能(round
trip幾乎可以忽略不計，也就幾百us到至多幾個ms，請自行用光速和距離計算)。
當(dāng)然一個城市的電力系統(tǒng)可能整體出故障，一個國家的跨海光纜可能被海嘯切斷，所以AWS還有region的概念。這些region分跨數(shù)個大洲，保障物理上一個region整體掛掉的情況下，如果應(yīng)用做了跨region的容災(zāi)，還能繼續(xù)服務(wù)。但應(yīng)用程序跨region的容災(zāi)不好做，距離上增加了兩個量級，使得region之間的網(wǎng)絡(luò)傳輸可能高達(dá)上百ms至幾百ms，量變到質(zhì)變，一些簡單的應(yīng)用層容災(zāi)手段(比如直接采用數(shù)據(jù)庫的master/slave)，便無法使用。
不過說句實話，大部分使用云服務(wù)商的應(yīng)用程序還到不了需要跨region容災(zāi)的程度(到了這個程度，應(yīng)該有一只強悍的devops
team來處理這種happy sorrow了)，所以，考慮跨AZ就好。
如果你選擇一個云服務(wù)商，問問他們是否有類似AZ的概念，你的web server，database
server能不能跨AZ部署。這是一個應(yīng)用過了種子期(有了上千用戶)首先該考慮的事情。當(dāng)然，如果你直接上AWS，那么基本的容災(zāi)無憂了。
容災(zāi)的另一個層面是數(shù)據(jù)備份。你需要合適的backup/restore機(jī)制。AWS提供了S3/Glacier來存儲文件類型的數(shù)據(jù)。數(shù)據(jù)備份是應(yīng)對Murphy’s
law的，當(dāng)最壞的事情發(fā)生(數(shù)據(jù)丟失)，對于服務(wù)恢復(fù)，你究竟有多大的容忍度，決定了你有多大的操作空間。如果你能容忍丟失至多一個小時的數(shù)據(jù)，那么，起碼設(shè)置每隔10-30分鐘的數(shù)據(jù)(增量)備份，這樣，當(dāng)DBMS上的數(shù)據(jù)被惡意刪除(并且被同步到了slave)，或者出現(xiàn)掉電文件系統(tǒng)corrupt的情況，備份就是你可耐的七舅老爺。
但是，備份一定不要僅僅放在本地，請務(wù)必存儲在某個靠譜的，像S3這樣的自帶數(shù)據(jù)冗余的云存儲服務(wù)上。這樣的服務(wù)一般是把一份數(shù)據(jù)分成N個切片存在不同的物理位置，只要其中K個切片可用，就能還原出文件。基本上，存儲在類似的系統(tǒng)上的文件可以認(rèn)為是不會丟失的。當(dāng)然，關(guān)鍵性的數(shù)據(jù)最好分級備份甚至線下備份，AWS就為此提供了glacier這樣的慢速存儲，存儲空間幾乎無限，價格便宜(S3的1/3)，但如果想從中恢復(fù)數(shù)據(jù)，需要幾個小時數(shù)據(jù)才能準(zhǔn)備好(因此有wikipedia上有推斷glacier是用tape，或者blue
ray disk這樣的離線方式存儲數(shù)據(jù))。
陳舊的備份的數(shù)據(jù)也可以定期清除，節(jié)省開銷。
2、安全：一個好的云服務(wù)商不僅僅要為你提供合適的計算能力和存儲能力來部署你的應(yīng)用，還需要提供某些安全保障。我們看AWS提供了哪些安全手段。
首先是IAM(Identity and Access Management)，也就是身份可權(quán)限管理系統(tǒng)。安全的首要原則是least
previlige。就像你永遠(yuǎn)不該使用root來訪問一臺遠(yuǎn)程設(shè)備(最好disable
root)一樣，當(dāng)你訪問一個云提供商，你也不應(yīng)該將初始賬戶(相當(dāng)于root)分享給每個團(tuán)隊成員使用，你應(yīng)該為每個不同的角色創(chuàng)建不同的賬號(如果云提供商提供這樣的功能，如果沒有，你的云提供商需要重新學(xué)習(xí)security
101)，提供最低的訪問權(quán)限。比如說，devops可以控制production環(huán)境，但dev/qa不能。不但權(quán)限分離，任何操作都要有可以用于事后審計的log：誰在哪一天做了什么操作(比如說創(chuàng)建了一個instance，誰disable了某個服務(wù))，需要一清二楚。
其次是內(nèi)外網(wǎng)分離。絕大多數(shù)情況下，你的大部分服務(wù)器，如database，是不需要暴露在公網(wǎng)上的。你最好部署一個(至多個)擁有公網(wǎng)IP的load
balancer(LB)，類似于AWS的ELB(Elastic Load
balancer)，將你N-tier的應(yīng)用隱藏在LB之后。這樣，除了對外的LB之外，其他服務(wù)器均在一個內(nèi)網(wǎng)之內(nèi)，沒有公有IP，阻斷黑客直接入侵的可能。
當(dāng)然你的團(tuán)隊需要訪問這些服務(wù)器。你可以在網(wǎng)絡(luò)的邊界部署跨內(nèi)外網(wǎng)的服務(wù)器，可以以這臺服務(wù)器為跳板，登入同一個子網(wǎng)內(nèi)的內(nèi)網(wǎng)的其他服務(wù)器。更安全的方式是設(shè)置openVPN，通過SSLVPN的方式接入到內(nèi)網(wǎng)，從而訪問這些設(shè)備(詳細(xì)信息請參考我之前的文章：應(yīng)用開發(fā)中的網(wǎng)絡(luò)安全)。
之后你需要認(rèn)真考慮網(wǎng)絡(luò)的訪問權(quán)限，設(shè)置物理的或者虛擬的防火墻。AWS的Security Group(SG)就是這樣一個簡單的基于ACL(Access
List)的防火墻，你可以在這個級別設(shè)置允許流入流出的端口，以及源IP地址。當(dāng)然，在服務(wù)器的iptables里，你也需要做相應(yīng)的設(shè)置。安全是有層級的，不能打造了個無比強硬的門就高枕無憂了：城外的地壕，護(hù)城河，城墻，城內(nèi)的翁城都是要配置的。
這一切還不夠，按照你的開發(fā)部署流程，你很可能需要dev環(huán)境，staging環(huán)境(QA
testing)，還有production的環(huán)境，每套按照上面的定義，都各自有不同的安全標(biāo)準(zhǔn)和訪問許可。在AWS里，VPC(Virtual Private
Cloud)可以很方便地幫你定義出這些環(huán)境，你的云服務(wù)商最好也有相同的概念，或者你通過劃分子網(wǎng)(和子網(wǎng)的訪問權(quán)限)，自行提供簡單的隔離。
3、服務(wù)可伸縮
很多人言及AWS，談到的首先是EC2的auto scaling。scaling不是簡單的computation scale
up/out的概念，而是一攬子解決方案。在考慮scaling之前，最好先把基本的容災(zāi)(起碼備個份)，和安全(行行好，最起碼不要把你的數(shù)據(jù)庫裸奔在公網(wǎng)上，不要直接用密碼登陸你的ssh服務(wù)器等等)做好，有了這個基礎(chǔ)，再談scaling。沒有容災(zāi)和安全的scaling，就像在地震活躍帶，打個淺淺的地基，蓋了一個沒有門沒有窗，四處透風(fēng)的摩天大廈。
AWS提供幾個層面的scaling：
Computation：EC2 auto scaling。配合ELB，可以讓服務(wù)的計算能力隨業(yè)務(wù)需求自動增減。
Storage：S3可以認(rèn)為是一個無窮大的，訪問時間恒定的storage。
Database：無需做任何管理，只需關(guān)心業(yè)務(wù)邏輯和配額的dynamodb(NoSQL);以及需要基本的管理(但不需要做打patch這樣的事)的RDS(Relational)。
SQS：無需任何管理，可以認(rèn)為容量無限大，訪問速度恒定的Message Queue
Cache：需要一定管理的Elastic Cache(使用memcached或redis)
這基本上是不需要大數(shù)據(jù)處理，不需要流媒體處理，不需要machine
learning的應(yīng)用的基本服務(wù)了(AWS都有對應(yīng)的服務(wù))。當(dāng)然，在早期的產(chǎn)品里，面臨的scaling的問題還主要集中在web/app
server和database server上，你更多地考慮在LB后面根據(jù)需要在不同的AZ下放置更多的web/app
server(如果你的云服務(wù)商能夠做auto
scaling再好不過，沒有在早期也不是大事)，然后數(shù)據(jù)庫除了跨AZ的Master/Slave的配置外，加上若干個Read
replica。一寫多讀能應(yīng)付大部分scaling的需求，除非你的應(yīng)用是特殊的，寫多讀少的應(yīng)用(此時考慮那些專門設(shè)計的，優(yōu)先寫速度的數(shù)據(jù)庫服務(wù)器，如cassandra)。
再往后的scaling，其實主要也是在數(shù)據(jù)層面騰挪：靜態(tài)資源放CDN，session
store使用ElastiCache或者DynamoDB，某些復(fù)雜的查詢結(jié)果塞到ElastiCache里減少對數(shù)據(jù)庫的請求;然后數(shù)據(jù)庫進(jìn)一步切分，根據(jù)讀寫的量級，把不同量級的表獨立在不同的數(shù)據(jù)庫，然后對讀寫頻繁的設(shè)置更多的read
replica。這個一個數(shù)據(jù)庫切分多個數(shù)據(jù)庫，運行在不同的replica set里。
走過了這一步，如果數(shù)據(jù)層面無法換或者不想換DynamoDB，依舊使用RDS，AWS能幫你的也不多了。接下來就是應(yīng)用程序的切分。應(yīng)用的不同部分也許可以通過queue
decouple，然后每個獨立發(fā)展，獨立scale out，就像數(shù)據(jù)庫所做的那樣。這便是所謂的micro service，或者service oriented
architecture(SOA)。AWS提供了SQS幫你完成這個變化，如果你的云服務(wù)商沒有類似的能力，也可依服務(wù)的需求部署kafka(沒用過)，rabbitmq等消息隊列和消息分發(fā)軟件。
再往后，用戶還在瘋漲，如果你已經(jīng)成功切換到DynamoDB，那么只需要提供更多的讀寫配額，讓AWS替你scale out，但如果還對SQL
DB不離不棄，就要走數(shù)據(jù)庫表的sharding，不過這個時候，你可能已經(jīng)接近于下一個instagram了。所以，即便切表切得肉疼，心情還是舒爽的，任何問題都不過相當(dāng)于躺在馬爾代夫的沙灘椅上吹著海風(fēng)，看著比基尼，享受精油按摩的時候，被不開眼的蚊子叮了個包而已。
稍微多說兩句DynamoDB。DynamoDB是AWS的私有技術(shù)，不過Amazon
publish相關(guān)的paper，催生了riak這樣帶著同樣理念的開源產(chǎn)品。按照我粗淺的理解，這類可以無限擴(kuò)容的NoSQL數(shù)據(jù)庫，其核心是consistent
hashing：
consistent
hashing的概念是我有一個足夠大的keyspace(2的160次方，比較一下：IPv6是2的128次方)，我們記作X，然后將X放在一個環(huán)形的空間里劃分成大小相等的Y個partition，依次循環(huán)排列(如圖)，每個partition由一個vnode(riak的概念)管理，當(dāng)你有M個database
server(node)，Y個vnode再平均映射到M個node上。當(dāng)數(shù)據(jù)要插入時，將其主鍵(hash
key)映射到K中的一個地址(addr)，對應(yīng)到某個vnode，再進(jìn)一步對應(yīng)到某個node，如果這個數(shù)據(jù)需要N個replica，則將數(shù)據(jù)寫入addr(vnode
a)，addr + 1(vnode b)， …，add + N(vnode
n)。在這種設(shè)置下，M就是你的shards，N是replica。以后添加新的node時，映射發(fā)生變化，只需要把相應(yīng)的變化了的vnode遷移到新的node上即可。在這種結(jié)構(gòu)下，sharding/replica對程序員基本上是透明的。
所以最后看AWS的解決方案，想想它為何提供這樣的工具，有助于我們思考自己的application的架構(gòu)，以及在不得已的情況下，尋找替代產(chǎn)品。
上一篇：
年人百萬，什么服務(wù)器上行速度1G，支持IP偽裝.數(shù)據(jù)包發(fā)送？
下一篇：
選擇阿里云國際站代充為什么更便宜？
