【編者的話(huà)】 2006年3月14日，亞馬遜發(fā)布Amazon S3，創(chuàng )造性的開(kāi)啟了自己的云時(shí)代。轉眼間，已經(jīng)過(guò)去10年。近日，亞馬遜CTO Werner Vogels在其博客發(fā)表了《10 Lessons from 10 Years of Amazon Web Services》的總結性文章，闡述了這些年踩過(guò)的坑和自己的經(jīng)驗。扇貝網(wǎng)工程師趙余對本文進(jìn)行了全文翻譯，InfoQ授權轉載并發(fā)布。
AWS（Amazon Web Service） 開(kāi)始于 2006 年 3 月 14 日 Amazon S3 的發(fā)布，距今已經(jīng)有十年的時(shí)間了?；剡^(guò)頭來(lái)看，過(guò)去這十年，對于構建和運營(yíng) AWS 這種需要確保安全性、可用性、可擴展性、性能可預知性，同時(shí)價(jià)格還要盡可能低廉的云計算服務(wù)，我們積累了大量的經(jīng)驗教訓?？紤]到 AWS 是云計算行業(yè)的開(kāi)拓者，這些經(jīng)驗教訓對我們來(lái)說(shuō)變得更加重要。就像我們經(jīng)常說(shuō)的那樣，“沒(méi)有面向經(jīng)驗的壓縮算法”，任何經(jīng)驗都來(lái)之不易?？紤]到 AWS 有著(zhù)超過(guò)一百萬(wàn)的月活躍用戶(hù)，而這些用戶(hù)中有些需要服務(wù)的自家用戶(hù)則高達數千萬(wàn)，因此，積累上述經(jīng)驗教訓的機會(huì )在 AWS 比比皆是。
在這些經(jīng)驗教訓中，我挑選了一些分享給大家，希望對各位也能有所幫助。
從做 AWS 的第一天開(kāi)始，我們就清楚地認識到，我們在做的這套系統不是一勞永逸的?，F在可以用的系統，一年之后很可能將不再適用。我們的預期是，隨著(zhù)（用戶(hù)）量級的每一次增加，我們都需要重新檢視和適當修改我們已有的架構，以便解決擴展性的問(wèn)題。
但是我們并沒(méi)有采取過(guò)去常用的，通過(guò)停機維護進(jìn)行系統升級的方式來(lái)實(shí)現上述目標，因為 AWS 支持的大量客戶(hù)背后，是提供 7 x 24 小時(shí)服務(wù)的遍布全球的商業(yè)機構。因此，我們需要構建的，是一個(gè)可以在新增模塊的時(shí)候不停機的架構。Amazon 杰出的工程師 Marvin Theimer 有一次開(kāi)玩笑說(shuō)，Amazon S3 這項服務(wù)的持續演進(jìn)，就好比是開(kāi)飛機。我們最開(kāi)始開(kāi)的是一架單引擎的賽斯納，后來(lái)?yè)Q成了一架波音 737，之后又換成了一個(gè)波音 747 小隊，而現在更像是由空中巨無(wú)霸空客 A380 組成的一個(gè)大型機隊。最重要的是，整個(gè)過(guò)程飛機都沒(méi)有降落過(guò)，我們一邊通過(guò)空中加油確保飛機的正常飛行，一邊在萬(wàn)米高空上將 AWS 的用戶(hù)，從一架舊飛機挪到另一架新的上面去。同時(shí)，AWS 的用戶(hù)對此毫不知情。
出問(wèn)題是肯定的，至于什么時(shí)候出，只是個(gè)時(shí)間問(wèn)題。從路由器到硬盤(pán)，從操作系統到內存里的 TCP 數據損壞，所有的組件都有可能出錯。有時(shí)候，錯誤是暫時(shí)的，有時(shí)候則是完全宕機。不管你用的是最好的還是廉價(jià)的硬件，出問(wèn)題總是不可避免。
在服務(wù)規模變得很大之后，這個(gè)問(wèn)題愈加地凸顯：舉例來(lái)說(shuō)，Amazon S3 服務(wù)時(shí)時(shí)刻刻都在處理著(zhù)萬(wàn)億級的存儲請求，（在這種規模下）任何出錯概率極小的問(wèn)題都會(huì )被放大，進(jìn)而影響到具體的業(yè)務(wù)。在設計和實(shí)現階段，這些問(wèn)題中的一部分事先會(huì )被考慮到，而更多的則是完全不知情。
因此，我們需要構建的，是一個(gè)對于未知錯誤保持高容忍度的系統。這個(gè)系統應該要做到，即使在“后院已經(jīng)著(zhù)火”的情況下依然可以繼續運行。局部組件出現小問(wèn)題的時(shí)候，系統應該能繼續運行，而不是直接宕機。對此，我們學(xué)會(huì )了一套控制未知錯誤的影響范圍的技能，以期將這些錯誤對系統健康度的影響降至最低。
很快我們就發(fā)現，用戶(hù)大都喜歡在 AWS 提供的服務(wù)上持續構建和演進(jìn)自己的業(yè)務(wù)系統。在擺脫了傳統 IT 硬件和數據中心的束縛之后，他們開(kāi)始以一種全新、有趣的、之前從未出現過(guò)的模式開(kāi)發(fā)自己的系統。也正是因為如此，為了滿(mǎn)足用戶(hù)多樣的需求，我們的架構需要保持高度的靈活性。
關(guān)于這一點(diǎn)，很重要的一個(gè)機制就是，我們提供給用戶(hù)的是一系列元語(yǔ)和工具，用戶(hù)可以自由選擇組合來(lái)使用，而不是由我們提供一個(gè)大而全的統一的框架。這個(gè)機制給我們的用戶(hù)帶來(lái)了巨大的成功，甚至 AWS 自身后續的一些服務(wù)也用上了這套機制，就像我們的普通用戶(hù)一樣。
同樣重要的一點(diǎn)是，我們很難在用戶(hù)還沒(méi)開(kāi)始使用一個(gè)服務(wù)之前，就準確預知到該服務(wù)的最終形態(tài)。這也是為什么所有的新服務(wù)最初都會(huì )以最小的功能集發(fā)布，然后借助用戶(hù)的反饋，再對該服務(wù)進(jìn)行后續的擴展。
開(kāi)發(fā)一個(gè)需要持續維護的軟件服務(wù)和開(kāi)發(fā)一個(gè)最終交付給客戶(hù)的軟件有著(zhù)巨大的差異，管理一個(gè)像 AWS 這種規模的系統，需要一種完全不同的觀(guān)念，才能確保滿(mǎn)足用戶(hù)對可用性、性能以及可擴展性的要求。
實(shí)現這個(gè)目標的一個(gè)主要的機制，就是避免手工操作，盡可能的將管理工作自動(dòng)化。為此，我們需要實(shí)現一套可以控制主要功能的管理 API。在這方面，我們同時(shí)也對自己的用戶(hù)給予幫助。通過(guò)將應用解耦成一個(gè)個(gè)獨立的模塊，每個(gè)模塊都有自己的管理 API，你可以很方便的定義自動(dòng)化規則來(lái)進(jìn)行大規模的維護。判斷自動(dòng)化做的是不是到位，可以思考一下你是不是還需要 ssh 到某臺服務(wù)器進(jìn)行一些運維操作？如果答案是 yes，說(shuō)明你的自動(dòng)化做得還不夠好。
我們在 Amazon 零售項目中已經(jīng)接受過(guò)類(lèi)似的教訓，但對于 AWS 這種以 API 為中心的服務(wù)，這個(gè)原則變得更加重要。一旦用戶(hù)開(kāi)始用我們的 API 開(kāi)發(fā)他們的應用和系統，我們就不可能再對這些 API 進(jìn)行變更了。因為 API 的任何改動(dòng)都會(huì )影響到用戶(hù)已有的項目。因此我們充分意識到，在 API 給到用戶(hù)之前，我們只有一次將 API 做對的機會(huì )。
當你為一項服務(wù)確定計費模式的時(shí)候，請務(wù)必確保你有一份關(guān)于該服務(wù)的資源成本和運營(yíng)的數據。對于邊際成本很低的業(yè)務(wù)尤其如此。作為服務(wù)提供商，AWS 需要對服務(wù)成本保持足夠的敏感，以便我們能清楚地認識到我們是否承擔得起某項服務(wù)，同時(shí)也能夠定位到一些可以通過(guò)提高運營(yíng)效率而進(jìn)一步降低成本的地方，并借此降低服務(wù)價(jià)格，最終惠及用戶(hù)。
舉一個(gè)例子，早期的時(shí)候，我們對于 Amazon S3 服務(wù)所用到的資源成本并不是很清晰。我們當時(shí)假定，存儲和帶寬應該是我們首要考慮的收費點(diǎn)；后來(lái)運行了一段時(shí)間之后，我們才意識到，請求數跟存儲與帶寬同等重要。如果某個(gè)用戶(hù)有大量的小文件要存儲，這種情況下，即使是百萬(wàn)量級的請求，都不會(huì )占用太多的存儲和帶寬資源。最終我們做了調整，將請求數也納入了計費模型，以便 AWS 在收支上可以保證這項服務(wù)的可持續性。
保護你的用戶(hù)，這一點(diǎn)的優(yōu)先級永遠都應該排在第一位，在 AWS 也不例外。不光要從運營(yíng)的角度，還要從工具和機制的角度保證這一點(diǎn)。對此，我們也將繼續保持最高的支持與投入。我們很快就學(xué)到的一個(gè)經(jīng)驗就是，為了實(shí)現安全的服務(wù)，我們需要在服務(wù)設計的最初階段就抱有這種安全意識。安全團隊的任務(wù)不是在一項服務(wù)實(shí)現完了之后才開(kāi)始安全檢查，相反地，安全團隊的工作應該和開(kāi)發(fā)團隊一道，貫穿于整個(gè)項目的生命周期，以確保項目的安全性?？傊?，涉及到安全的問(wèn)題，沒(méi)有任何妥協(xié)的余地。
數據加密，是保證用戶(hù)數據安全的重要機制。十年前，數據加密相關(guān)的工具和服務(wù)還不夠完善，直到 AWS 剛開(kāi)始運營(yíng)的最初幾年，我們才逐步積累了很多關(guān)于在服務(wù)中集成數據加密的最佳實(shí)踐。
Amazon S3 最初提供的，是服務(wù)器端的加密機制。當我們在數據中心移除帶有用戶(hù)數據的磁盤(pán)的時(shí)候，這些數據就無(wú)法被訪(fǎng)問(wèn)到了。但是后續上線(xiàn)的諸如 Amazon CloudHSM 和 Amazon Key 管理服務(wù)，均向用戶(hù)提供了自定義加密密鑰的機制，這樣一來(lái)，AWS 就不需要替用戶(hù)維護這些加密密鑰了。
現在，AWS 所有的新服務(wù)，在原型設計階段就會(huì )考慮到對數據加密的支持。比如，在 Amazon Redshift 服務(wù)中，每一個(gè)數據塊都通過(guò)一個(gè)隨機的密鑰進(jìn)行加密，而這些隨機密鑰則由一個(gè)主密鑰進(jìn)行加密存儲。用戶(hù)可以自定義這個(gè)主密鑰，這樣也就保證了只有用戶(hù)本人才能訪(fǎng)問(wèn)這些機密數據或敏感信息。
數據加密在我們的業(yè)務(wù)中的優(yōu)先級一直非常高。我們也會(huì )持續改進(jìn)，讓數據加密機制用起來(lái)更簡(jiǎn)單，最終，讓用戶(hù)能更好地保護自己的數據安全。
服務(wù)支撐了各種各種的負載場(chǎng)景。從高并發(fā)處理到視頻轉碼，從高性能并行計算到海量的網(wǎng)絡(luò )請求。這些不同的負載場(chǎng)景，對網(wǎng)絡(luò )的要求也各不相同。
關(guān)于數據中心的設計和運營(yíng)，AWS 開(kāi)發(fā)了一套獨特的機制，這套機制提供了靈活的網(wǎng)絡(luò )基礎設施，以便滿(mǎn)足任何用戶(hù)的不同負載場(chǎng)景的需求。在這個(gè)過(guò)程中，我們也認識到，為了讓用戶(hù)達成自身的目標，我們必須開(kāi)發(fā)自己的網(wǎng)絡(luò )解決方案。這樣也能滿(mǎn)足我們自身的一些定制化的需求，比如在保證高安全性的同時(shí)，通過(guò)網(wǎng)絡(luò )來(lái)隔離用戶(hù)的能力。
AWS 自主開(kāi)發(fā)的這套軟硬件解決方案，也能給用戶(hù)帶來(lái)進(jìn)一步的性能提升。關(guān)于這一點(diǎn)，有一個(gè)成功的例子，那就是虛擬機之間的網(wǎng)絡(luò )通信。由于網(wǎng)絡(luò )通信是一個(gè)共享的資源，在使用 AWS 自己定制的解決方案之前，用戶(hù)時(shí)常會(huì )遇到網(wǎng)路擁堵的問(wèn)題。最終，AWS 通過(guò)開(kāi)發(fā)支持單個(gè)根 IO 虛擬化技術(shù)的 NIC，實(shí)現了給每個(gè)虛擬機虛擬出自己的 NIC 的解決方案。這一改動(dòng)成倍地降低了網(wǎng)絡(luò )延遲，同時(shí)提升了高達十倍的網(wǎng)絡(luò )性能。
隨著(zhù)時(shí)間的推移，AWS 團隊提供了越來(lái)越多的服務(wù)和功能，這也給我們的用戶(hù)創(chuàng )造了一個(gè)廣闊的開(kāi)發(fā)平臺。但是 AWS 遠不止我們團隊開(kāi)發(fā)的這些功能與服務(wù)，一些合作伙伴基于 AWS 提供的服務(wù)進(jìn)一步擴大和豐富了整個(gè)系統的生態(tài)。比如，我們的合作伙伴 Stripe 提供的支付服務(wù)得以讓 Twilio 在 AWS 上支持電話(huà)業(yè)務(wù)。很多用戶(hù)基于 AWS 本身的服務(wù)，開(kāi)發(fā)出自己的產(chǎn)品，用于解決特定的垂直領(lǐng)域的問(wèn)題。
比如，飛利浦開(kāi)發(fā)了用于健康數據管理的 Healthsuite 數字平臺，Ohpen 則基于 AWS 開(kāi)發(fā)出自己的零售銀行平臺，Eagle Genomics 開(kāi)發(fā)了自己的計算平臺用于基因處理等等，這樣的例子不勝枚舉。AWS 并不會(huì )限制我們的合作伙伴，規定他們什么可以做什么不可以做?！安辉O限”的原則釋放了創(chuàng )新的動(dòng)力，為意想不到的創(chuàng )新敞開(kāi)了大門(mén)。
對于在接下來(lái)的十年里， AWS 的團隊會(huì )學(xué)到哪些經(jīng)驗教訓，我們的用戶(hù)又會(huì )創(chuàng )造出什么樣的價(jià)值，我充滿(mǎn)了期待。
永遠記得，對 AWS 來(lái)說(shuō)，這僅僅是一個(gè)新的開(kāi)始。
《他山之石》是InfoQ中文站新推出的一個(gè)專(zhuān)欄，精選來(lái)自國內外技術(shù)社區和個(gè)人博客上的技術(shù)文章，讓更多的讀者朋友受益，本欄目轉載的內容都經(jīng)過(guò)原作者授權。文章推薦可以發(fā)送郵件到editors@cn.infoq.com。
聯(lián)系客服
