金磊 明敏 發自 拉斯維加斯量子位 | 公眾號 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吧~—完—點這里?關注我，記得標星哦～一鍵三連「分享」、「點贊」和「在看」科技前沿進展日日相見 ~