在今天的文章中，我整理出了大量當(dāng)初曾經(jīng)錯(cuò)過(guò)、而至今仍將我追悔莫及的Amazon Web Services（簡(jiǎn)稱(chēng)AWS）使用心得。在幾年來(lái)的實(shí)踐當(dāng)中，我通過(guò)在AWS之上新手構(gòu)建及部署各類(lèi)應(yīng)用程序而積累到了這些經(jīng)驗(yàn)。雖然內(nèi)容有些雜亂，但相信仍然能給各位帶來(lái)一點(diǎn)啟示。

從物理服務(wù)器向“云環(huán)境”轉(zhuǎn)移的過(guò)程不僅僅是一項(xiàng)技術(shù)任務(wù)，同時(shí)也意味著我們的思維方式需要作出針對(duì)性的轉(zhuǎn)變?？傮w而言，在物理環(huán)境下我們需要關(guān)注的只是每一臺(tái)獨(dú)立主機(jī); 它們各自擁有自己的靜態(tài)IP，我們能夠?qū)ζ浞謩e加以監(jiān)控。而一旦其中一臺(tái)發(fā)生故障，我們必須盡大可能讓其快速恢復(fù)運(yùn)轉(zhuǎn)。大家可以以為只要將基礎(chǔ)設(shè)施轉(zhuǎn)移到AWS環(huán)境之下，就能直接享受到“云”技術(shù)帶來(lái)的種種收益了。遺憾的是，事情可沒(méi)那么簡(jiǎn)單(相信我，我親身嘗試過(guò)了)。在AWS環(huán)境之下，我們必須轉(zhuǎn)變思維，而且這方面的任務(wù)往往不像技術(shù)難題那么容易被察覺(jué)。因此，受到了SehropeSarkuni最近一篇帖子的啟發(fā)，我將自己幾年來(lái)積累得出的AWS 使用心得匯總于此，而且說(shuō)實(shí)話(huà)、我真希望自己當(dāng)初剛剛接觸AWS時(shí)能有人告訴我這些寶貴經(jīng)驗(yàn)。這些心得總結(jié)自我在AWS之上部署個(gè)人及工作應(yīng)用程序時(shí)的親身感受，其中一部分屬于需要高度關(guān)注的“疑難雜癥”(我自己就是直接受害者)，而另一部分則是我聽(tīng)其他朋友說(shuō)起過(guò)、并隨后親自確認(rèn)有效的解決方案。不過(guò)總體而言，為了積累這些經(jīng)驗(yàn)，我確實(shí)付出了相當(dāng)慘痛的代價(jià)：)

應(yīng)用程序開(kāi)發(fā)

千萬(wàn)不要把應(yīng)用程序狀態(tài)保存在自己的服務(wù)器上。

之所以這么說(shuō)，是因?yàn)橐坏┪覀兊姆?wù)器發(fā)生故障，那么應(yīng)用程序狀態(tài)很可能也隨之徹底消失。有鑒于此，會(huì)話(huà)應(yīng)當(dāng)被存儲(chǔ)在一套數(shù)據(jù)庫(kù)(或者其它某些集中式存儲(chǔ)體系、memcached或者redis當(dāng)中)而非本地文件系統(tǒng)內(nèi)。日志信息應(yīng)當(dāng)通過(guò)系統(tǒng)日志(或者其它類(lèi)似方案)進(jìn)行處理，并被發(fā)送至遠(yuǎn)程位置加以保存。上傳內(nèi)容應(yīng)當(dāng)直接指向S3(舉例來(lái)說(shuō)，不要將其存儲(chǔ)在本地文件系統(tǒng)內(nèi)，并通過(guò)其它流程隨后遷移到S3)。再有，任何已經(jīng)處理過(guò)或者需要長(zhǎng)期運(yùn)行的任務(wù)都應(yīng)該通過(guò)異步隊(duì)列(SQS非常適合處理此類(lèi)任務(wù))來(lái)實(shí)現(xiàn)。

編輯點(diǎn)評(píng):對(duì)于S3上傳內(nèi)容而言，HN用戶(hù)Krallin指出，我們可以徹底避免其與自有服務(wù)器的接觸，并利用預(yù)簽名URL保證用戶(hù)的上傳數(shù)據(jù)被直接發(fā)送至S3當(dāng)中。

將額外信息保存在日志當(dāng)中。

日志記錄通常包含有時(shí)間戳以及pid等信息。大家也可能希望將實(shí)例id、服務(wù)區(qū)域、可用區(qū)以及環(huán)境(例如分步環(huán)境或者生產(chǎn)環(huán)境等)添加進(jìn)來(lái)，而這些都能在日后的調(diào)試工作中作為參考。大家可以從instance metadata service當(dāng)中獲取到這些信息。我所采用的方法是將這些信息作為引導(dǎo)腳本的組成部分，并將其以文件形式存儲(chǔ)在文件系統(tǒng)當(dāng)中(例如/env/az或者 /env/region等)。這樣一來(lái)，我就用不著持續(xù)查詢(xún)?cè)獢?shù)據(jù)服務(wù)來(lái)獲取這些信息了。大家應(yīng)當(dāng)確保這些信息能夠在實(shí)例重新啟動(dòng)時(shí)得到正確更新，畢竟我們都不希望在保存AMI時(shí)發(fā)現(xiàn)其中的數(shù)據(jù)還跟上次完全一樣，這肯定屬于非正常狀況。

如果我們需要與AWS進(jìn)行交互，請(qǐng)?jiān)诋?dāng)前語(yǔ)言中使用對(duì)應(yīng)SDK。

千萬(wàn)不要試圖自己動(dòng)手。我當(dāng)初就犯過(guò)這個(gè)錯(cuò)誤，因?yàn)槲艺J(rèn)為自己只是單純需要向S3上傳內(nèi)容，但隨著后續(xù)服務(wù)的持續(xù)增加、我發(fā)現(xiàn)自己的決定簡(jiǎn)直愚蠢至極。AWS SDK的編寫(xiě)質(zhì)量很高，能夠自動(dòng)處理驗(yàn)證、處理重試邏輯，而且由Amazon官方負(fù)責(zé)維護(hù)與迭代。此外，如果大家使用EC2 IAM角色(大家絕對(duì)應(yīng)該這么做，這一點(diǎn)我們后面會(huì)進(jìn)一步提到)，那么該SDK將幫助我們自動(dòng)獲取到正確的證書(shū)。

利用工具查看應(yīng)用程序日志。

大家應(yīng)當(dāng)采用管理員工具、系統(tǒng)日志查看器或者其它方案，從而幫助自己在無(wú)需在運(yùn)行中實(shí)例內(nèi)使用SSH的方式查看當(dāng)前實(shí)時(shí)日志信息。如果大家擁有集中式日志記錄系統(tǒng)(我強(qiáng)烈建議大家使用此類(lèi)系統(tǒng))，那么當(dāng)然希望能在不使用SSH的情況下完成日志內(nèi)容查看任務(wù)。很明顯，將SSH引入正處于運(yùn)行狀態(tài)的應(yīng)用程序?qū)嵗龝?huì)引發(fā)諸多弊端。