亞馬遜 CTO Werner Vogels 談大型分佈式系統的設計原則。

原文標題:《不要將自己鎖定在自己的架構中》
撰文:tshi

早在 2006 年,事務處理的開山鼻祖,數據庫領域圖領獎得主 Jim Gray 與 Werner Vogels 進行了「第一次」對話。對話的主題是「向亞馬遜技術平臺學習」,而弔詭之處在於,Jim Gray 所開創的事務處理是亞馬遜電子商務的技術基礎。

最近,Akamai 董事 Tom Killalea 與亞馬遜 CTO Werner Vogels 進行了一場「第二次」對話。對話的主題是大規模簡單存儲系統 S3 的進化設計。而弔詭之處在於,就在一個月前,一個可以對標 S3 的最大區塊鏈存儲項目 Filecoin 剛剛升空。

「我認爲重要的是要首先意識到亞馬遜是一家技術公司」,在「第一次」對話中,Werner Vogels 反覆對 Jim Gray 解釋稱,亞馬遜不應該僅僅被視爲一家在線書店,而應該被視爲一家科技公司。並且,就是在這次談話中,亞馬遜首次公開了 S3,一個簡單存儲服務。

「Amazon.Com Books」,這個名字並不能反映我們的雄心壯志。Tom Killalea 說到。當 Tom Killalea 在 1998 年加入亞馬遜時(Tom Killalea 於 2018 年 3 月加入 Akamai,擔任董事),該公司只是一個銷售書籍的網站:一個簡單 C 應用 Obidos,一個部署在 Berkeley DBs 上的鍵值存儲,一個命名爲「ACB」的關係數據庫(代指「Amazon.Com Books」),這些應用部署在 5 臺服務器上。

不斷擴大的客戶和訂單,讓亞馬遜放棄了單體架構,走向去中心化的服務化架構。當 Jim Gray 問及亞馬遜最大的經驗教訓時,Werner Vogels 說道:

  • 第一個教訓,也是最重要的教訓,更是元教訓:服務意識。嚴格的面向服務是實現隔離的優秀技術,你會達到一個前所未見的擁有和控制的水平。通過使用服務,不僅技術方面得到了改進,開發和業務進程也大大受益於它。服務模型是創建以客戶爲中心的快速創新團隊的關鍵推動。每個服務都有一個與之關聯的團隊,該團隊完全負責服務——從確定功能範圍,到架構、構建和運維。

  • 第二個教訓是,通過禁止客戶端直接訪問數據庫,可以在不涉及客戶端的情況下對服務狀態進行可伸縮性和可靠性改進。這些經驗教訓與如何訪問服務有關:如果你希望能夠輕鬆地聚合服務,如果你希望插入高級基礎設施技術,如分佈式請求路由或分佈式請求跟蹤,你需要一個統一的服務訪問機制。

  • 第三個教訓:賦予開發人員運維職責大大提高了服務的質量,無論是從客戶的角度還是從技術的角度。傳統的模式是,將軟件放在分隔開發和運維的牆上,然後將其拋諸腦後。在亞馬遜不是這樣,誰建立,誰運行。這使開發人員接觸到軟件的日常運維。這也讓開發人員每天都與客戶接觸。這種客戶反饋迴路對提高服務質量至關重要。

「如果不把技術用於服務客戶的更大利益上,技術就毫無用處。我們是一家強烈以客戶爲導向的公司,我們經常使用「從客戶逆向工作」的方法。這意味着,在你的思考過程中,從客戶開始,然後逆向工作,直到找到滿足新客戶需求所需的簡單而最小的技術。重要的是,來到亞馬遜工作的工程師要明白,我們不是爲了技術而開發技術,而是爲了支持客戶。」

「面向服務的架構,我們的擴展方式,我們服務客戶的方式——我認爲我們最大的成功是亞馬遜已經成爲一個其他企業可以從中受益的平臺。」

通過技術和業務的服務化,亞馬遜與用戶構建了一個快速反饋週期,進入一個飛速增長的飛輪之中。

2006 年 3 月啓動 S3 時,S3 只有 8 項服務。到 2019 年,S3 已達到 262 種服務。在與 Tom Killalea 的談話中,Werner Vogels 說道:「我完全同意這是空前的規模。即使在今天,即使現在的互聯網服務已經達到了令人難以置信的規模,我認爲 S3 仍然比它領先兩到三代。」

在 2006 年的 S3 發佈公告中,亞馬遜採用了以下分佈式系統設計十大原則來滿足 Amazon S3 的需求 :

  • 去中心化:使用完全去中心化的技術來消除伸縮瓶頸和單點故障。

  • 異步:系統在任何情況下都能繼續工作。

  • 自治:單個組件根據本地信息可以做出決策。

  • 局部責任:每個組件負責實現其自身的一致性,這絕不是其他對等節點的責任。

  • 受控併發:操作被設計成不需要或有限的併發性控制。

  • 容錯:組件故障被視爲正常運行模式,並且在沒有中斷或最小中斷的情況下繼續運行。

  • 受控並行:系統抽象具有這樣的粒度:使用並行來提高性能、恢復健壯性,或者引入新節點。

  • 分解成小的、易於理解的構建塊:不要試圖提供做所有事情的單一服務,而是構建可以用作其他服務構建塊的小組件。

  • 對稱性:系統中的節點在功能方面是相同的,並且不需要或最少需要特定配置才能運行。

  • 簡單性:系統應該儘可能地簡單,而不是更簡單。

上面的十個原則,是亞馬遜構建大規模分佈式系統的方式。S3 只是這些設計原則的例子。

原則是灰色的,而客戶的需求常青。在上面的原則基礎之上,Werner Vogels 提出了演化架構

當時,大多數科技公司提供所有東西和「平臺」,他們會提供一本很厚的書和 10 個不同的合作伙伴,然後告訴客戶如何使用技術。而亞馬遜沒有將自己鎖定在自己的技術中,走上了另外一條道路。傑夫 . 貝佐斯多年前曾說過,那就是構建工具,而不是構建平臺,平臺是大型軟件平臺公司提供技術服務的老方式。

「在我們開始 S3 之前,我們開始意識到我們所做的可能會從根本上改變軟件構建和服務使用的方式。但我們不知道這將如何發展,所以更重要的是構建小型、靈活的工具,讓客戶可以在其上構建(或者我們可以在自己的基礎上構建),而不是在某個特定時刻準備好所有東西和「平臺」。這不是時間問題,更重要的是,我們堅信,無論我們向 S3 的接口添加什麼,向 S3 的功能添加什麼,都應該由我們的客戶驅動——以及下一代客戶將如何開始構建他們的系統。」

「在過去的五到十年裏,軟件發生了根本性的變化。我們需要構建正確的工具,以支持發生根本性變化的速度。這樣,你就無法預測,你必須與你的客戶一起工作,等待他們如何使用你的工具——特別是如果這些工具是以前從未構建過的——並觀察他們做了什麼。然後我們坐下來問自己,最小集合是什麼。」

「你必須有意識地小心設計 API。API 是長遠的。一旦你把 API 放在那裏,也許你可以提供新版本,但你不能把它從你的客戶那裏拿走。在 API 設計中保持保守和最小化可以幫助你構建基本工具,你可以在這些工具上添加更多的功能,或者合作伙伴可以在其之上構建新的層次,或者你可以將不同的構建塊組合在一起。這就是我們從一開始的理念:做到極簡主義,這樣我們就可以讓我們的客戶來推動將要發生的事情,而不是我們坐在後面的房間裏思考:這個世界應該是什麼樣子。」

對話亞馬遜 CTO:分佈式系統該如何設計?

這些設計決策在亞馬遜的數據湖中得到了體現。基於構建塊和工具,S3 的作用遠遠超過了數據湖:圍繞着數據庫,S3 提供了龐大的工具箱(175 種不同的服務)。

在訪談中,S3 的設計決策還包括:

  • 持久性大於可用性

  • 不變性大於分佈式鎖

  • 計算和存儲分離

不要將自己鎖定在自己的架構中。Werner Vogels 在回顧 S3 的設計原則時候,這樣說道。一個有效的複雜系統總是從一個有效的簡單系統演化而來。一個從零開始設計的複雜系統永遠不會工作,也不能通過修補使其工作。你必須從一個簡單可行的系統開始。

也許讀者不需要去閱讀兩篇訪談的原文,但需要記住和思考的是本文總結的幾點:服務意識、分佈式系統設計十大原則、構建工具而不是平臺、不要將自己鎖定在自己的架構中。