AWS(Amazon Web Service) 開始于 2006 年 3 月 14 日 Amazon S3 的發(fā)布，距今已有十年時間?；厥走^去十年，我們在構(gòu)建和運營 AWS 云計算服務(wù)中積累了大量的經(jīng)驗教訓(xùn)——這些服務(wù)不僅需要確保安全性、可用性和可擴展性，同時還要以盡可能低廉的成本提供可預(yù)測的性能?？紤]到 AWS 是世界范圍內(nèi)構(gòu)建和運營此類服務(wù)的開拓者，這些經(jīng)驗教訓(xùn)對我們的業(yè)務(wù)來說至關(guān)重要。正如我們多次重申的，“經(jīng)驗不存在壓縮算法”。考慮到 AWS擁有每月超過一百萬的活躍用戶，而這些用戶也許會為數(shù)以億計的自家客戶提供服務(wù)。因此，積累上述經(jīng)驗教訓(xùn)的機會在 AWS 比比皆是， 在這些經(jīng)驗教訓(xùn)中，我挑選了一些分享給大家，希望對各位也能有所幫助。

[[176486]]

1.構(gòu)建可持續(xù)演進的系統(tǒng)

從做 AWS 的***天開始，我們就清楚地認(rèn)識到，我們在做的這套軟件不是一勞永逸的?，F(xiàn)在可以用的軟件，一年之后很可能將不再適用。我們的預(yù)期是，隨著(用戶)數(shù)量級的增加一或兩次，我們都需要重新檢視和適當(dāng)修改我們已有的架構(gòu)，以便解決擴展性的問題。

但是我們無法采取過去常用的通過檢修停機進行系統(tǒng)升級的方式來實現(xiàn)上述目標(biāo)，因為世界各地諸多業(yè)務(wù)都依賴著我們平臺所提供的7 x 24 小時的可用性。因此，我們需要構(gòu)建一個在引入新的軟件構(gòu)件時不會引起服務(wù)癱瘓的架構(gòu)。Amazon 杰出的工程師 Marvin Theimer 有一次開玩笑說，Amazon S3 這項服務(wù)的持續(xù)演進用開飛機來形容最為貼切。我們最開始開的是一架單引擎的賽斯納，一段時間后升級成一架波音 737，之后又換成了一支波音 747 小隊，而現(xiàn)在更像是由空中巨無霸空客 A380 組成的一支大型機隊。自始至終，我們一邊通過空中加油確保飛機的正常飛行，一邊在萬米高空上將 AWS 的用戶從一架舊飛機挪到另一架新的上面去。同時，AWS 的用戶對此毫不知情。

2. 預(yù)料到不可預(yù)料的情況

故障是注定的;隨著時間的流逝，一切終將歸于失?。簭穆酚善鞯接脖P，從操作系統(tǒng)到存儲單元損壞的TCP數(shù)據(jù)包，從瞬時誤差到***失效，無論你用的是***質(zhì)量的硬件還是***成本的組件，這都是理所當(dāng)然的。

在服務(wù)規(guī)模變得很大之后，這個問題愈加地凸顯：舉例來說，當(dāng)Amazon S3 服務(wù)處理萬億級存儲交易時，即使誤差概率極小的事件也將成為現(xiàn)實。在設(shè)計和構(gòu)建階段，這些故障場景中的一部分事先會被考慮到，但更多的則是未知數(shù)。

因此，我們需要構(gòu)建的是將故障視為自然發(fā)生的系統(tǒng)，即使我們并不知道故障是什么。這個系統(tǒng)應(yīng)該要做到，即使在“后院已經(jīng)著火”的情況下依然可以繼續(xù)運行。重要的是在不需要引起整個系統(tǒng)宕機的情況下就能管理好受影響的局部組件。對此，我們已經(jīng)發(fā)展出一套控制故障發(fā)生影響范圍的基本技能，以期系統(tǒng)的總體健康狀態(tài)得以維持。

3. 提供基元而非框架

很快我們開始發(fā)現(xiàn)，用戶大都喜歡在 AWS 提供的服務(wù)上持續(xù)構(gòu)建和演進自己的業(yè)務(wù)系統(tǒng)。在擺脫了傳統(tǒng) IT 硬件和數(shù)據(jù)中心的束縛之后，他們開始以一種全新、有趣的、之前從未出現(xiàn)過的使用模式開發(fā)自己的系統(tǒng)。也正是因為如此，為了滿足用戶多樣的需求，我們的架構(gòu)需要保持高度的靈活性。

關(guān)于這一點，最重要的機制之一就是，我們提供給用戶的是一系列基元和工具，用戶可以選擇他們喜歡的方式來使用AWS云服務(wù)，而不是由我們提供一個大而全的統(tǒng)一的框架。這個機制給我們的用戶帶來了巨大的成功，甚至 AWS 自身后續(xù)的一些服務(wù)也用上了這套機制，就像我們的普通用戶一樣。

同樣重要的一點是，我們很難在用戶還沒開始使用一個服務(wù)之前，就準(zhǔn)確預(yù)知到對用戶而言該服務(wù)需要優(yōu)先考慮的問題。這也是為什么所有的新服務(wù)最初都會以最小的功能集發(fā)布，然后借助用戶的反饋，再對該服務(wù)進行后續(xù)的擴展。

4. 自動化是關(guān)鍵

開發(fā)一個需要持續(xù)維護的軟件服務(wù)和開發(fā)一個最終交付給客戶的軟件有著巨大的差異，管理一個像 AWS 這種規(guī)模的系統(tǒng)，需要一種完全不同的觀念，才能確保滿足用戶對可用性、性能以及可擴展性的要求。

實現(xiàn)這個目標(biāo)的一個主要的機制，就是避免容易產(chǎn)生誤差的手工操作，盡可能地將管理工作自動化。為此，我們需要構(gòu)建一套可以控制主要功能的管理 API。在這方面，我們同時也對自己的用戶給予幫助。通過將應(yīng)用分解成一個個獨立的模塊，每個模塊都有自己的管理 API，你可以很方便地定義自動化規(guī)則來進行大規(guī)模的維護。判斷自動化做的是不是到位，可以思考一下你是不是還需要使用SSH登陸到某臺服務(wù)器進行運維操作?如果答案是 yes，說明你的自動化做得還不夠好。

5. API 定義要嚴(yán)謹(jǐn)，因為一旦上線就無法更改

我們在 Amazon 零售項目中已經(jīng)接受過類似的教訓(xùn)，但對于 AWS 這種以 API 為中心的服務(wù)，這個原則變得更加重要。一旦用戶開始用我們的 API 開發(fā)他們的應(yīng)用和系統(tǒng)，我們就不可能再對這些 API 進行變更了。因為 API 的任何改動都會影響到用戶已有的項目。因此我們充分意識到，在 API 給到用戶之前，我們只有一次將 API 做對的機會。

6. 監(jiān)控你的資源使用情況

當(dāng)你為一項服務(wù)確定計費模式的時候，請務(wù)必確保你有一份關(guān)于該服務(wù)的資源成本和運營的數(shù)據(jù)。對于邊際成本很低的業(yè)務(wù)尤其如此。作為服務(wù)提供 商，AWS 需要對服務(wù)成本保持足夠的敏感，以便我們能清楚地認(rèn)識到我們是否承擔(dān)得起某項服務(wù)，同時也能夠定位到一些可以通過提高運營效率而進一步降低成本的地方，并借此降低服務(wù)價格，最終惠及用戶。

舉一個例子，早期的時候，我們對于 Amazon S3 服務(wù)所用到的資源成本并不是很清晰。我們當(dāng)時假定，存儲和帶寬應(yīng)該是我們首要考慮的收費點;后來運行了一段時間之后，我們才意識到，請求數(shù)量跟存儲與帶寬同 等重要。如果某個用戶有大量的小文件要存儲，這種情況下，即使是百萬量級的請求，都不會占用太多的存儲和帶寬資源。最終我們做了調(diào)整，將請求數(shù)量也納入了計費模型，以便 AWS 在收支上可以保證這項服務(wù)的可持續(xù)性。

7. 從頭開始建立安全機制

保護你的用戶，這一點的優(yōu)先級永遠都應(yīng)該排在***位，在 AWS 也不例外。不光要從運營的角度，還要從工具和機制的角度保證這一點。對此，我們也將繼續(xù)保持***的支持與投入。我們很快就學(xué)到的一個經(jīng)驗就是，為了實現(xiàn)安 全的服務(wù)，我們需要在服務(wù)設(shè)計的最初階段就抱有這種安全意識。安全團隊的任務(wù)不是在一項服務(wù)實現(xiàn)完了之后才開始安全檢查，相反地，安全團隊的工作應(yīng)該和開 發(fā)團隊一道，貫穿于整個項目的生命周期，以確保項目的安全性。總之，涉及到安全的問題，沒有任何妥協(xié)的余地。

8. 數(shù)據(jù)加密是頭等大事

數(shù)據(jù)加密，是保證用戶數(shù)據(jù)安全的重要機制。十年前，數(shù)據(jù)加密相關(guān)的工具和服務(wù)還不夠完善，直到 AWS 剛開始運營的最初幾年，我們才逐步積累了很多關(guān)于在服務(wù)中集成數(shù)據(jù)加密的***實踐。

Amazon S3 最初提供的，是服務(wù)器端的加密機制。當(dāng)我們在數(shù)據(jù)中心移除帶有用戶數(shù)據(jù)的磁盤的時候，這些數(shù)據(jù)就無法被訪問到了。但是后續(xù)上線的諸如 Amazon CloudHSM 和 Amazon Key 管理服務(wù)，均向用戶提供了自定義加密密鑰的機制，這樣一來，AWS 就不需要替用戶維護這些加密密鑰了。

現(xiàn)在，AWS 所有的新服務(wù)，在原型設(shè)計階段就會考慮到對數(shù)據(jù)加密的支持。比如，在 Amazon Redshift 服務(wù)中，每一個數(shù)據(jù)塊都通過一個隨機的密鑰進行加密，而這些隨機密鑰則由一個主密鑰進行加密存儲。用戶可以自定義這個主密鑰，這樣也就保證了只有用戶本人才能訪問這些機密數(shù)據(jù)或敏感信息。

數(shù)據(jù)加密在我們的業(yè)務(wù)中的優(yōu)先級一直非常高。我們也會持續(xù)改進，讓數(shù)據(jù)加密機制用起來更簡單，最終，讓用戶能更好地保護自己的數(shù)據(jù)安全。

9. 網(wǎng)絡(luò)的重要性

AWS的服務(wù)支撐了各種各樣的負(fù)載場景。從高并發(fā)處理到視頻轉(zhuǎn)碼，從高性能并行計算到海量的網(wǎng)絡(luò)請求。這些不同的負(fù)載場景，對網(wǎng)絡(luò)的要求也各不相同。

關(guān)于數(shù)據(jù)中心的設(shè)計和運營，AWS 開發(fā)了一套獨特的機制，這套機制提供了靈活的網(wǎng)絡(luò)基礎(chǔ)設(shè)施，以便滿足任何用戶的不同負(fù)載場景的需求。在這個過程中，我們也認(rèn)識到，為了讓用戶達成自身的目 標(biāo)，我們必須開發(fā)自己的網(wǎng)絡(luò)解決方案。這樣也能滿足我們自身的一些定制化的需求，比如在保證高安全性的同時，通過網(wǎng)絡(luò)來隔離用戶的能力。

AWS 自主開發(fā)的這套軟硬件解決方案，也能給用戶帶來進一步的性能提升。關(guān)于這一點，有一個成功的例子，那就是虛擬機之間的網(wǎng)絡(luò)通信。由于網(wǎng)絡(luò)通信是一個共享的資源，在使用 AWS 自己定制的解決方案之前，用戶時常會遇到網(wǎng)路擁堵的問題。最終，AWS 通過開發(fā)支持單個根 IO 虛擬化技術(shù)的 NIC，實現(xiàn)了給每個虛擬機虛擬出自己的 NIC 的解決方案。這一改動成倍地降低了網(wǎng)絡(luò)延遲，同時提升了高達十倍的網(wǎng)絡(luò)性能。

10. 不設(shè)限，保持平臺的中立與開放

隨著時間的推移，AWS 團隊提供了越來越多的服務(wù)和功能，這也給我們的用戶創(chuàng)造了一個廣闊的開發(fā)平臺。但是 AWS 遠不止我們團隊開發(fā)的這些功能與服務(wù)，一些合作伙伴基于 AWS 提供的服務(wù)進一步擴大和豐富了整個系統(tǒng)的生態(tài)。比如，我們的合作伙伴 Stripe 提供的支付服務(wù)得以讓 Twilio 在 AWS 上支持電話業(yè)務(wù)。

很多用戶基于 AWS 本身的服務(wù)，開發(fā)出自己的產(chǎn)品，用于解決特定的垂直領(lǐng)域的問題。比如，飛利浦開發(fā)了用于健康數(shù)據(jù)管理的 Healthsuite 數(shù)字平臺;Ohpen 則基于 AWS 開發(fā)出自己的零售銀行平臺;Eagle Genomics 開發(fā)了自己的計算平臺用于基因處理等等，這樣的例子不勝枚舉。AWS 并不會限制我們的合作伙伴，規(guī)定他們什么可以做什么不可以做。“不設(shè)限”的原則釋放了創(chuàng)新的動力，為意想不到的創(chuàng)新敞開了大門。

對于在接下來的十年里， AWS 的團隊會學(xué)到哪些經(jīng)驗教訓(xùn)，我們的用戶又會創(chuàng)造出什么樣的價值，我充滿了期待。

永遠記得，對 AWS 來說，這僅僅是一個新的開始。