罕見！云計算一哥CTO，現場不發產品只講教訓

金磊 明敏 發自 拉斯維加斯

量子位 | 公眾號 QbitAI

罕見，著實罕見。

一場近2小時的活動，CTO竟然全程沒有發布任何新品！

這就是亞馬遜云科技的CTO——Werner Vogels，剛剛在自家年度盛宴re:Invent24上演的一幕。

但有一說一，即便如此，諾大的現場，幾乎無人離席。

為什么？

因為比起新產品，Werner相當于是把他入職亞馬遜20年背后更珍貴的經驗給公開出來了。

而且劍指生成式AI，共計六大Lesson：

• Lesson1：未雨綢繆，Make evolvability a requirement.
• Lesson2：化繁為簡，Break complexity into pieces.
• Lesson3：各司其職，Align organization to architecture.
• Lesson4：小而精美，Organize into cells.
• Lesson5：未卜先知，Design predictable systems.
• Lesson6：機器代勞，Automate complexity.

之所以會如此，是因為在Werner看來，現在不論是數據還是大模型的參數規模都在呈現指數級的增長，面對越發復雜和龐大的系統，行業亟需一個方法論。

而這個方法論，簡而言之，就是把Complexity（復雜性）變為Simplexity（簡單性）。

這又該如何理解？

Werner舉了一個非常形象的例子——自行車。

他認為系統的組件數量并不能直接衡量其復雜性。例如：

• 獨輪車（Unicycle）：只有最少的組件，看起來很簡單，但實際操作卻非常困難，需要很高的技術和努力。
• 三輪車（Tricycle）：組件稍多，穩定性更強，但在靈活性方面受到限制，比如轉彎不夠方便。
• 普通自行車（Bicycle）：組件數量介于兩者之間，卻提供了最佳的平衡點，既靈活又易于掌握。

普通自行車雖然比獨輪車和三輪車有更多的組件，但其設計達到了功能和體驗的最佳平衡，因此也讓它成為了現在最簡單易用的交通工具。

一言蔽之，簡單性不僅僅是減少組件，而是系統整體體驗的優化。

Werner今天提出的這套方法論，正是把亞馬遜云科技多年來在實踐中“踩過坑”后總結而來。

所以，正如那句“還要啥自行車”，亞馬遜云科技都幫我們整理完了，趕緊來看下吧~

Lesson1：未雨綢繆，系統可演化是必要

Make evolvability a requirement — Evolvability is a precondition for managing complexity.

將可演化性作為一項要求，可演化性是應對復雜性的一種預判

首先第一課，Werner Vogels提出，可進化性是必須的，這是進行復雜管理的先決條件。

什么意思？

隨著時間推移，系統是一定會發生變化的。因此在設計之初，就要確保架構能夠輕松適應新的需求。

而且進化能力不同于可維護性，前者是長期的、粗粒度的功能或結構增強，而后者是短期的、細粒度的局部變化。

不然就會像溫水煮青蛙一樣，等意識到問題時，或許就太晚了。

在系統設計初期時，就應該做好前期規劃、管理系統復雜性。

最直接的例子就是Amazon S3的發展。

最初，S3的設計目標是提供一個簡單、耐用且具有成本效益的云存儲服務。

后來隨著客戶數量以及服務量增加，S3不得不改進其技術和架構。比如從單引擎系統升級為支持多個微服務和分布式存儲的架構。

實際上，每一年S3都會增加新功能，但從不影響現有服務的穩定性。好比給高速運轉的引擎加部件。

這得益于其在系統設計時就考慮到了未來的升級需求，設計了靈活、可擴展的架構，以應對未知的挑戰，因此才可以在未來逐步擴展能力。

這種可進化性使得它能不斷引入新技術、新功能和新流程，以適應新市場需求，保持競爭力。

不過，隨著系統不斷進化，復雜性就會增加。如何控制系統的復雜程度、提高可維護性，這是Werner Vogels講的第二課。

Lesson2：化繁為簡，提出微服務架構

Break complexity into pieces — Disaggregate into building blocks with high cohesion and well-defined APIs.

將復雜性拆解成多個部分，分解為內聚性高且有明確定義API的構建模塊。

亞馬遜云科技最初采用單體架構，后面隨著業務發展，系統變得越來越復雜，單體架構表現出了擴展性差、可維護性低等問題。

所以，亞馬遜云科技決定將單體架構拆解為多個獨立的小型服務，即微服務架構。

每個服務負責一個業務功能，獨立部署和維護，并定義良好的API接口以便它們相互通信。

在微服務架構劃分中，遵循單一職責原則，即每個服務只負責一個單一的功能或智能。

增量拆分原則是將整個系統逐步拆分成多個較小的部分，然后逐步迭代進行拆分。

同時還要求一個服務內部組件之間的耦合度要盡可能低，與其他服務之間的依賴性盡可能小。這樣做可以提高服務的獨立性，使得各個服務可以獨立地進行開發、測試、部署和擴展。

這種方法不僅減少了系統間的耦合，還讓團隊能更專注于各自的模塊。全系統可以通過組件的不斷迭代優化而持續演進，并在關鍵時刻平滑過渡，避免服務中斷。

Lesson3：各司其職，組織和架構對齊

Align organization to architecture — Build small teams, challenge the status quo, and encourage ownership.

讓組織與架構相匹配，組建小團隊，挑戰現狀并鼓勵主人翁意識。

Werner Vogels認為，組織構建要和系統架構保持一致。當系統架構被拆分成一個個小模塊后，組織也應該如此。

有多小？一個形象的比方——大概兩塊披薩就能喂飽整個團隊（doge）。

在亞馬遜云科技內部，這種機制也被稱為“兩個披薩團隊”。

它能很好解決傳統職能層次導致的溝通效率低下、決策緩慢等問題。

這種方法不僅提高了團隊的靈活性和自主性，還促進了創新和快速響應市場需求的能力。

讓每個團隊獨立地工作和決策，可以進一步加快產品開發和迭代速度，這也是亞馬遜云科技能夠長期保持競爭力和創新力的訣竅之一。

另一方面也要建立良好的問責機制，營造積極向上的文化氛圍，推動持續改進。

Lesson4：小而精美，一個team就是一個細胞

Organize into cells — In a complex system, you must reduce the scope of impact.

組織成單元形式，在復雜系統中必須縮小影響范圍。

Werner Vogels還提到了一種內部的組織結構，被稱為“細胞化”。

它將應用程序分解成更小的、獨立運行的模塊，使每個模塊都能獨立運行，把問題隔離在特定單元內，不影響其他單元。

就像是一個個細胞，它們擁有自己內部的功能，并通過細胞膜隔絕出一個相對獨立的環境。

這在復雜系統中至關重要，有助于維護系統的穩定性和可靠性。

例如，亞馬遜云科技服務通過散列算法將客戶分配到特定單元，避免單點故障對所有用戶的影響。

當然單元的劃分也要大小適中，既要大到能夠處理最大的工作量，又要小到可以進行實際執行。

Lesson5：未卜先知，降低不確定性

Design predictable systems — Reduce the impact of uncertainty.

設計可預測的系統，降低不確定性的影響。

設計可預測系統的核心目標是減少不確定性對系統的影響，使系統能夠在高度復雜的環境中仍然保持穩定和高效。

設計可預測系統的幾個關鍵策略是：

• 簡單確定
  通過保持系統設計的簡單性，能夠更容易地預測和管理系統的行為。

例如，在負載平衡的處理上，亞馬遜云科技采用了一種更簡單的方法，將所有變化推送到一個文件中，然后在固定的循環中更新負載平衡器的配置。這種方法確保了系統的行為是可預測的，并且能夠處理所有的配置條目。

• 持續工作模式
  使用持續工作模式，從Amazon S3中定期拉取文件，避免積壓和瓶頸。這種模式自然具有自我修復的特性，因為屏幕的可用性極高。
• 自動化和標準化
  自動化是減少復雜性的關鍵手段。通過標準化操作，可以減少人為干預所帶來的不確定性和錯誤。例如，在健康檢查器系統中，定期推送完整的配置文件，而不是每次都推送變化。
• 分布式架構和模塊化
  設計系統時，應將其分解為獨立的模塊，每個模塊可以獨立運行和擴展。這樣可以在某個模塊出現問題時，將影響控制在最小范圍內。
• 高可觀察性
  系統應具備高可觀察性，能夠實時監控和分析系統的運行狀態。通過這種方式，可以及時發現和解決潛在的問題。
• 處理復雜性的策略
  通過將復雜的任務分解為簡單、可管理的部分，可以有效地控制和處理系統的復雜性。亞馬遜云科技一些服務采用固定的處理循環而不是事件驅動架構，從而確保系統的行為可預測，降低了運行時的復雜性。

Lesson6：機器代勞，提高效率

Automate complexity — Automate everything that does not require high judgment.

使復雜性自動化，將不需要高度判斷力的一切事務自動化。

簡單來說，這就是讓機器來幫人處理那些可以簡單判斷的任務，把需要創造性和復雜決策的任務留給人類。

這種自動化能更進一步提高效率。

比如利用AI來監測惡意活動，并自動響應，保護客戶業務免受安全威脅。

自動化不僅僅是解決常見問題的工具，它應該成為標準流程的一部分，只有在處理特殊情況時，才需要人工輸入。

亞馬遜云科技內部通過對支持票進行自動分類和優先排序，有效減少了人工操作，提高了問題解決速度。

驗證六個Lesson的價值

Werner提出的方法論，可以說不僅是亞馬遜云科技服務成功的基石，更是現代分布式系統設計的重要指導。

不過在理論之外，他在現場也展示了經得起六大Lesson驗證的產品——Amazon Aurora DSQL。

（注：于re:Invent24第一天，由CEO Matt Garmarn發布，并非Werner首發。）

它是一種新型無服務器分布式數據庫，為的就是解決傳統數據庫在擴展性和性能方面的挑戰。

對應Lesson1，Aurora DSQL可以說是從設計之初就是為未來的可演化性做好了準備。

Aurora DSQL將數據庫功能解耦為獨立組件，如查詢處理器（Query Processor）、協調器（Adjudicator）、日志模塊（Journal）和存儲引擎（Storage Engine）。

這種設計允許每個模塊根據需要獨立升級或替換，而不影響其他部分。

隨著技術的發展，Aurora DSQL能夠通過模塊替換快速適應新需求。例如，日志模塊可根據吞吐量擴展，存儲引擎可優化數據讀取效率，從而支持業務規模的增長。

對應Lesson2，Aurora DSQL完全遵循“化繁為簡”的理念，將復雜性分解為多個獨立且高內聚的模塊。

例如查詢處理器專注于事務處理和快照隔離、日志模塊負責事務持久性和全局排序、存儲引擎優化數據的讀寫性能。

通過清晰的API實現低耦合，各模塊只需要完成特定的輸入輸出任務，無需處理全局邏輯。

對應Lesson3，其各模塊可以由小型團隊獨立開發和維護，這與亞馬遜云科技的“兩塊披薩團隊”理念完全一致。

例如查詢處理器團隊可以專注于事務邏輯優化，而日志模塊團隊則可以重點解決持久性問題，各司其職卻無縫協作。

對應Lesson4，Aurora DSQL采用分布式架構，將系統功能劃分為多個獨立單元以限制故障影響范圍。

例如數據存儲被分為多個分片（Shards），每個分片獨立運行并處理特定數據，確保某個分片故障不會影響全局服務。

而事務協調模塊（Adjudicator）獨立處理沖突，確保并發事務之間的隔離性和一致性，同時減少對核心數據庫存儲的影響。

對應Lesson5，Aurora DSQL解決了分布式系統中時間管理的傳統難題，通過本地時鐘處理事務的“開始時間”和“提交時間”，消除了對復雜分布式一致性算法（如Paxos）的依賴。

同時，存儲引擎采用固定的查詢和數據處理方式，避免了事件驅動架構可能帶來的不可預測性，使系統性能更加穩定。

對應Lesson6，Aurora DSQL日志模塊實現了自動化，事務提交后會立即寫入日志模塊，日志模塊自動排序和分發事務，確保持久性和一致性。

并且其存儲和查詢模塊可以根據負載動態擴展，無需人工干預，提高了資源利用效率。

由此可見，亞馬遜云科技這次提出的六個Lesson，是經過考驗的那種，更是“值得一抄的作業”。

而亞馬遜云科技之所以能到做如此，離不開貫穿這幾天所有Keynote的關鍵詞，那就用戶需求（Customer Needs）。

正如CEO Matt Garman所說的那句話：

Innovation Driven by Customer Needs.
客戶需求驅動創新。

不過有一說一，其實很多服務型企業同樣是把客戶需求放在第一位，那么亞馬遜云科技又有何獨特之處呢？

在量子位與亞馬遜云科技全球客戶技術支持與服務副總裁Uwem Ukpong交流過程中得到了明確的答案：

我們非常擅長精準捕捉客戶的需求，會坐下來面對面刨根問底的程度，不錯過任何細節。

并且我們屬于務實派的那種，先做再說。

One More Thing：

Werner在亞馬遜就職長達20年之久，是全球最著名的CTO之一。

而看過近幾年re:Invent的小伙伴可以發現，他的專場發布會有一個鮮明的特點，那就是Werner很喜歡出鏡微電影。

最后就來欣賞一下這位“老戲骨”和他的Simplexity吧~

視頻地址：https://mp.weixin.qq.com/s/sXKMFKU4Ytnfqb7Ti1l3uA?token=706944461&lang=zh_CN