AWS（Amazon Web Service） 開始於 2006 年 3 月 14 日 Amazon S3 的發布，距今已有十年時間。回首過去十年，我們在構建和運營 AWS 雲計算服務中積累了大量的經驗教訓
- 這些服務不僅需要確保安全性、可用性和可擴展性
- 同時還要以盡可能低廉的成本提供可預測的性能
考慮到 AWS 是世界範圍內構建和運營此類服務的開拓者，這些經驗教訓對我們的業務來說至關重要。正如我們多次重申的
- “經驗不存在壓縮算法”
考慮到 AWS擁有每月超過一百萬的活躍用戶，而這些用戶也許會為數以億計的自家客戶提供服務。因此
- 積累上述經驗教訓的機會在 AWS 比比皆是
- 在這些經驗教訓中，我挑選了一些分享給大家，希望對各位也能有所幫助。
從做 AWS 的第一天開始，我們就清楚地認識到
- 做的這套軟體不是一勞永逸的
- 現在可以用的軟體，一年之後很可能將不再適用
- 我們的預期是，隨著（用戶）數量級的增加一或兩次，我們都需要重新檢視和適當修改我們已有的架構
- 以便解決擴展性的問題。
但是我們無法采取過去常用的通過檢修停機進行系統升級的方式來實現上述目標
- 因為世界各地都依賴著我們平台所提供的7 x 24 小時的可用性
因此
- 我們需要構建一個在引入新的軟體構件時不會引起服務癱瘓的架構
故障是註定的，隨時間，一切終將歸於失敗
- 從路由器到硬盤
- 從操作系統到存儲單元損壞的TCP數據包
- 從瞬時誤差到永久失效
- 無論你用的是最高 level 的硬件還是最低成本的，這都是理所當然的。
在服務規模變得很大之後
- 這個問題愈加地凸顯
舉例來說
- 當 Amazon S3 服務處理萬億級存儲交易時，即使誤差概率極小的事件也將成為現實
在設計和構建階段
- 這些故障場景中的一部分事先會被考慮到
- 但更多的則是未知數
因此
- 我們需要構建的是將故障視為自然發生的系統
- 即使我們並不知道故障是什麽
這個系統應該要做到
- 即使在“後院已經著火”的情況下依然可以繼續運行
- 重要的是在不需要引起整個系統宕機的情況下就能管理好「受影響的局部組件」
對此，我們已經發展出一套控制故障發生影響範圍的基本技能，以期系統的總體健康狀態得以維持。
我們很快開始發現
- 用戶大都喜歡在 AWS 提供的服務上持續構建和演進自己的業務系統
- 在擺脫了傳統 IT 硬件和數據中心的束縛之後，他們開始以一種全新、有趣的、之前從未出現過的使用模式開發自己的系統
- 也正是因為如此，為了滿足用戶多樣的需求，我們的架構需要保持高度的靈活性。
關於這一點，最重要的機制之一就是
- 我們提供給用戶的是一系列基元(Primitives)和工具
- 用戶可以選擇他們喜歡的方式來使用AWS雲服務
- 而不是由我們提供一個大而全的統一的框架
- 這個機制給我們的用戶帶來了巨大的成功
- 甚至 AWS 自身後續的一些服務也用上了這套機制，就像我們的普通用戶一樣。
同樣重要的一點是
- 我們很難在用戶還沒開始使用一個服務之前，就準確預知到對用戶而言該服務需要優先考慮的問題
- 這也是為什麽所有的新服務最初都會以最小的功能集發布
- 然後借助用戶的反饋，再對該服務進行後續的擴展。
開發一個需要持續維護的「軟體服務」和開發一個「最終交付給客戶的軟體」有著巨大的差異
- 管理一個像 AWS 這種規模的系統，需要一種完全不同的觀念
- 才能確保滿足用戶對可用性、性能以及可擴展性的要求。
實現這個目標的一個主要的機制，就是
- 避免容易產生誤差的手工操作
- 盡可能地將管理工作自動化
為此，我們需要
- 構建一套可以控制主要功能的管理 API
- 通過將應用分解成一個個獨立的模塊，每個模塊都有自己的管理 API
- 可以很方便地定義自動化規則來進行大規模的維護
判斷自動化做的是不是到位
- 可以思考一下你是不是還需要使用 SSH 登陸到某台服務器進行運維操作？
- 如果答案是 yes，說明你的自動化做得還不夠好。
我們在 Amazon 零售項目中已經接受過類似的教訓，但對於 AWS 這種以 API 為中心的服務，這個原則變得更加重要
- 一旦用戶開始用我們的 API 開發他們的應用和系統，我們就不可能再對這些 API 進行變更了
因為 API 的任何改動都會影響到用戶已有的項目
- 因此我們充分意識到，在 API 給到用戶之前，我們只有一次將 API 做對的機會
當你為一項服務確定計費模式的時候
- 請務必確保你有一份關於該服務的資源成本和運營的數據
- 對於邊際成本很低的業務尤其如此
作為服務提供商，AWS
- 需要對服務成本保持足夠的敏感
- 以便我們能清楚地認識到我們是否承擔得起某項服務
- 同時也能夠定位到一些可以通過提高運營效率而進一步降低成本的地方，並借此降低服務價格，最終惠及用戶。
舉例
- 早期我們對於 Amazon S3 服務所用到的資源成本並不是很清晰
我們當時假定
- 存儲和帶寬應該是我們首要考慮的收費點
後來運行了一段時間之後，我們才意識到
- 請求數量跟存儲與帶寬同等重要
- 如果某個用戶有大量的小文件要存儲
- 這種情況下，即使是百萬量級的請求，都不會占用太多的存儲和帶寬資源
- 最終我們做了調整，將請求數量也納入了計費模型，以便 AWS 在收支上可以保證這項服務的可持續性。
保護你的用戶
- 這優先級永遠都應該排在第一位
在 AWS 也不例外
- 不光要從運營的角度，還要從工具和機制的角度保證這一點
對此，我們也將繼續保持最高的支持與投入。我們很快就學到的一個經驗就是
- 為了實現安 全的服務，我們需要在服務設計的最初階段就抱有這種安全意識
- 安全團隊的任務不是在一項服務實現完了之後才開始安全檢查
相反地
- 安全團隊的工作應該和開發團隊一道，貫穿於整個項目的生命周期，以確保項目的安全性
- 總之，涉及到安全的問題，沒有任何妥協的余地。
數據加密，是保證用戶數據安全的重要機制。十年前，數據加密相關的工具和服務還不夠完善，直到 AWS 剛開始運營的最初幾年，我們才逐步積累了很多關於在服務中集成數據加密的最佳實踐。
Amazon S3 最初提供的
- 是服務器端的加密機制
- 當我們在數據中心移除帶有用戶數據的磁盤的時候，這些數據就無法被訪問到了
- 但是後續上線的諸如 Amazon CloudHSM 和 Amazon Key 管理服務，均向用戶提供了自定義加密密鑰的機制
- 這樣一來，AWS 就不需要替用戶維護這些加密密鑰了。
現在，AWS 所有的新服務
- 在原型設計階段就會考慮到對數據加密的支持
- 比如，在 Amazon Redshift 服務中，每一個數據塊都通過一個隨機的密鑰進行加密
- 而這些隨機密鑰則由一個主密鑰進行加密存儲
- 用戶可以自定義這個主密鑰，這樣也就保證了只有用戶本人才能訪問這些機密數據或敏感信息。
數據加密在我們的業務中的優先級一直非常高。我們也會持續改進，讓數據加密機制用起來更簡單，最終，讓用戶能更好地保護自己的數據安全。
AWS的服務支撐了各種各樣的負載場景。從高並發處理到影片轉黨，從高性能並行計算到海量的網絡請求。這些不同的負載場景，對網絡的要求也各不相同。
關於數據中心的設計和運營
- AWS 開發了一套獨特的機制，這套機制提供了靈活的網絡基礎設施
- 以便滿足任何用戶的不同負載場景的需求
在這個過程中，我們也認識到，為了讓用戶達成自身的目標，我們必須開發自己的網絡解決方案。這樣也能滿足我們自身的一些定制化的需求
- 比如在保證高安全性的同時，通過網絡來隔離用戶的能力。
AWS 自主開發的這套軟硬件解決方案，也能給用戶帶來進一步的性能提升。關於這一點，有一個成功的例子
- 那就是虛擬機之間的網絡通信。由於網絡通信是一個共享的資源
- 在使用 AWS 自己定制的解決方案之前，用戶時常會遇到網路擁堵的問題
- 最終，AWS 通過開發支持單個根 IO 虛擬化技術的 NIC，實現了給每個虛擬機虛擬出自己的 NIC 的解決方案。這一改動成倍地降低了網絡延遲，同時提升了高達十倍的網絡性能。
隨著時間的推移，AWS 團隊提供了越來越多的服務和功能，這也給我們的用戶創造了一個廣闊的開發平台。但是 AWS 遠不止我們團隊開發的這些功能與服務，一些合作夥伴基於 AWS 提供的服務進一步擴大和豐富了整個系統的生態。比如，我們的合作夥伴 Stripe 提供的支付服務得以讓 Twilio 在 AWS 上支持電話業務。
很多用戶基於 AWS 本身的服務，開發出自己的產品，用於解決特定的垂直領域的問題。比如
- 飛利浦開發了用於健康數據管理的 Healthsuite 數字平台
- Ohpen 則基於 AWS 開發出自己的零售銀行平台
- Eagle Genomics 開發了自己的計算平台用於基因處理等等
這樣的例子不勝枚舉。AWS 並不會限制我們的合作夥伴，規定他們什麽可以做什麽不可以做。“不設限”的原則釋放了創新的動力，為意想不到的創新敞開了大門。
永遠記得，對 AWS 來說，這僅僅是一個新的開始。