不要將自己鎖定在自己的架構中

作者：石頭 2020-11-17 06:52:51

早在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設計中保持保守和最小化可以幫助你構建基本工具，你可以在這些工具上添加更多的功能，或者合作伙伴可以在其之上構建新的層次，或者你可以將不同的構建塊組合在一起。這就是我們從一開始的理念：做到極簡主義，這樣我們就可以讓我們的客戶來推動將要發生的事情，而不是我們坐在后面的房間里思考：這個世界應該是什么樣子。”