罕見，着實罕見。
一場近 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 吧 ~
— 完 —
點這裏關注我，記得标星哦～
一鍵三連「分享」、「點贊」和「在看」
科技前沿進展日日相見 ~
>
