新火種
2024-12-07 
罕見！云計算一哥CTO，現場不發產品只講教訓
罕見，著實罕見。
一場近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：未雨綢繆，系統可演化是必要首先第一課，Werner Vogels提出，可進化性是必須的，這是進行復雜管理的先決條件。
什么意思？
隨著時間推移，系統是一定會發生變化的。因此在設計之初，就要確保架構能夠輕松適應新的需求。
而且進化能力不同于可維護性，前者是長期的、粗粒度的功能或結構增強，而后者是短期的、細粒度的局部變化。
不然就會像溫水煮青蛙一樣，等意識到問題時，或許就太晚了。
在系統設計初期時，就應該做好前期規劃、管理系統復雜性。
最直接的例子就是Amazon S3的發展。
最初，S3的設計目標是提供一個簡單、耐用且具有成本效益的云存儲服務。
后來隨著客戶數量以及服務量增加，S3不得不改進其技術和架構。比如從單引擎系統升級為支持多個微服務和分布式存儲的架構。
實際上，每一年S3都會增加新功能，但從不影響現有服務的穩定性。好比給高速運轉的引擎加部件。
這得益于其在系統設計時就考慮到了未來的升級需求，設計了靈活、可擴展的架構，以應對未知的挑戰，因此才可以在未來逐步擴展能力。
這種可進化性使得它能不斷引入新技術、新功能和新流程，以適應新市場需求，保持競爭力。
不過，隨著系統不斷進化，復雜性就會增加。如何控制系統的復雜程度、提高可維護性，這是Werner Vogels講的第二課。
Lesson2：化繁為簡，提出微服務架構亞馬遜云科技最初采用單體架構，后面隨著業務發展，系統變得越來越復雜，單體架構表現出了擴展性差、可維護性低等問題。
所以，亞馬遜云科技決定將單體架構拆解為多個獨立的小型服務，即微服務架構。
每個服務負責一個業務功能，獨立部署和維護，并定義良好的API接口以便它們相互通信。
在微服務架構劃分中，遵循單一職責原則，即每個服務只負責一個單一的功能或智能。
增量拆分原則是將整個系統逐步拆分成多個較小的部分，然后逐步迭代進行拆分。
同時還要求一個服務內部組件之間的耦合度要盡可能低，與其他服務之間的依賴性盡可能小。這樣做可以提高服務的獨立性，使得各個服務可以獨立地進行開發、測試、部署和擴展。
這種方法不僅減少了系統間的耦合，還讓團隊能更專注于各自的模塊。全系統可以通過組件的不斷迭代優化而持續演進，并在關鍵時刻平滑過渡，避免服務中斷。
Lesson3：各司其職，組織和架構對齊Werner Vogels認為，組織構建要和系統架構保持一致。當系統架構被拆分成一個個小模塊后，組織也應該如此。
有多小？一個形象的比方——大概兩塊披薩就能喂飽整個團隊（doge）。
在亞馬遜云科技內部，這種機制也被稱為“兩個披薩團隊”。
它能很好解決傳統職能層次導致的溝通效率低下、決策緩慢等問題。
這種方法不僅提高了團隊的靈活性和自主性，還促進了創新和快速響應市場需求的能力。
讓每個團隊獨立地工作和決策，可以進一步加快產品開發和迭代速度，這也是亞馬遜云科技能夠長期保持競爭力和創新力的訣竅之一。
另一方面也要建立良好的問責機制，營造積極向上的文化氛圍，推動持續改進。
Lesson4：小而精美，一個team就是一個細胞Werner Vogels還提到了一種內部的組織結構，被稱為“細胞化”。
它將應用程序分解成更小的、獨立運行的模塊，使每個模塊都能獨立運行，把問題隔離在特定單元內，不影響其他單元。
就像是一個個細胞，它們擁有自己內部的功能，并通過細胞膜隔絕出一個相對獨立的環境。
這在復雜系統中至關重要，有助于維護系統的穩定性和可靠性。
例如，亞馬遜云科技服務通過散列算法將客戶分配到特定單元，避免單點故障對所有用戶的影響。
當然單元的劃分也要大小適中，既要大到能夠處理最大的工作量，又要小到可以進行實際執行。
Lesson5：未卜先知，降低不確定性設計可預測系統的核心目標是減少不確定性對系統的影響，使系統能夠在高度復雜的環境中仍然保持穩定和高效。
設計可預測系統的幾個關鍵策略是：
簡單確定通過保持系統設計的簡單性，能夠更容易地預測和管理系統的行為。例如，在負載平衡的處理上，亞馬遜云科技采用了一種更簡單的方法，將所有變化推送到一個文件中，然后在固定的循環中更新負載平衡器的配置。這種方法確保了系統的行為是可預測的，并且能夠處理所有的配置條目。
持續工作模式使用持續工作模式，從Amazon S3中定期拉取文件，避免積壓和瓶頸。這種模式自然具有自我修復的特性，因為屏幕的可用性極高。自動化和標準化自動化是減少復雜性的關鍵手段。通過標準化操作，可以減少人為干預所帶來的不確定性和錯誤。例如，在健康檢查器系統中，定期推送完整的配置文件，而不是每次都推送變化。分布式架構和模塊化設計系統時，應將其分解為獨立的模塊，每個模塊可以獨立運行和擴展。這樣可以在某個模塊出現問題時，將影響控制在最小范圍內。高可觀察性系統應具備高可觀察性，能夠實時監控和分析系統的運行狀態。通過這種方式，可以及時發現和解決潛在的問題。處理復雜性的策略通過將復雜的任務分解為簡單、可管理的部分，可以有效地控制和處理系統的復雜性。亞馬遜云科技一些服務采用固定的處理循環而不是事件驅動架構，從而確保系統的行為可預測，降低了運行時的復雜性。Lesson6：機器代勞，提高效率簡單來說，這就是讓機器來幫人處理那些可以簡單判斷的任務，把需要創造性和復雜決策的任務留給人類。
這種自動化能更進一步提高效率。
比如利用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所說的那句話：
不過有一說一，其實很多服務型企業同樣是把客戶需求放在第一位，那么亞馬遜云科技又有何獨特之處呢？
在新火種與亞馬遜云科技全球客戶技術支持與服務副總裁Uwem Ukpong交流過程中得到了明確的答案：
One More Thing：Werner在亞馬遜就職長達20年之久，是全球最著名的CTO之一。
而看過近幾年re:Invent的小伙伴可以發現，他的專場發布會有一個鮮明的特點，那就是Werner很喜歡出鏡微電影。
最后就來欣賞一下這位“老戲骨”和他的Simplexity吧~
視頻地址：
相關推薦
- 免責聲明
- 本文所包含的觀點僅代表作者個人看法，不代表新火種的觀點。在新火種上獲取的所有信息均不應被視為投資建議。新火種對本文可能提及或鏈接的任何項目不表示認可。 交易和投資涉及高風險，讀者在采取與本文內容相關的任何行動之前，請務必進行充分的盡職調查。最終的決策應該基于您自己的獨立判斷。新火種不對因依賴本文觀點而產生的任何金錢損失負任何責任。
