以下是亞馬遜CTO（Werner Vogels）在演講當中總結他20年的架構經驗時提到的一些架構設計原則
原文影片地址，參見：AWS re:Invent 2023 - Keynote with Dr. Werner Vogels
法則一 將成本視為一種非功能性需求
所謂非功能性需求，就是用於判斷系統操作的標準，與具體特性或功能無關。可訪問性、可用性、可擴充套件性、安全性、可移植性、可維護性和合規性等都在此列。而成本往往是其中受到忽略的一條。
“在我們設計的時候，成本是非功能方面的要求，跟安全、合規、可用性、效能這些最經典元素一樣，你必須記在心裡面，時刻把它體現出來。畢竟我們不僅僅是為了打造技術而打造技術，我們打造這個技術是為了支援業務運營需求的。”
在Werner看來，業務之所以身陷困境，往往是因為他們沒有考慮到各個階段中的相應成本——從設計到開發、再到運營——也可能是未能正確量化成本。這背後的原理非常簡單：如果成本比收入還高，那還做業務幹嘛呢。
架構師需要儘可能早的、以更加可持續的方式考慮成本影響，才能在系統設計過程中在功能、上市時間和效率之間尋求平衡。這樣開發團隊可以專注於維護更加精簡高效的程式碼，運營部門可以最佳化資源用量和支出，從而最大限度提高盈利能力。
法則二：確保系統的最終成本與業務保持一致
系統能否長治久安，取決於其成本是否與業務模式高度匹配。在設計和構建系統時，架構師必須考慮收入來源和利潤槓桿。更重要的是，必須找到能夠產生利潤的維度，確保架構規劃始終圍繞收益展開。
例如，在電子商務領域，這個核心維度可能是訂單數量。當訂單增加時，基礎設施和運營成本也會隨之上升。但沒關係，只要系統架構設計良好，我們就能享受規模經濟帶來的紅利。最重要的是基礎設施成本對業務的影響始終精確、可以量化。
作為架構師，大家需要關注收入，並據此指導技術選型。任何不計代價的增長只會招致毀滅。正如Werner強調的：“你要很確定，我們業務基礎設施擴充套件的方式，能讓成本成長低於銷售收入的增長。”
法則三：架構設計是一系列權衡的集合
在架構當中，每項決定都涉及相應的權衡。成本、彈性和效能這些非功能性需求之間，往往相互衝突、難以調和。
常言道“萬事萬物終將隕落。”要想抵禦這種失敗的風險，就必須關注彈性，同時犧牲掉一部分效能。
在技術與業務需求間找到適當的平衡將至關重要，也就是把握住風險承受能力與預算額度間的最佳比例。請記住，儉約是為了最大限度提升價值，而不只是儘可能控制支出。因此，在必須得花的錢上別吝嗇。
Werner還在這個環節指出，創新設計時需要平衡成本、安全性還有洞察力/內情這三樣東西，“Amazon Lambda就是在這樣的過程中一邊探索一邊打造出來的。我們在做設計時，始終要保持三個方面的關係，有時候你可能需要在成本方面做一些犧牲，來達到其他的技術或者安全的要求。再往上，我們一定要建一個演化的基礎結構，我們要確定我們做事情不能影響到客戶，這也是Lambda成功的關鍵。”
法則四：無法觀測的系統將帶來無法估量的成本
如果不認真觀察和測量，系統運營的真實成本將難以把控。就如同隱藏在地下室中的電錶一樣，這種直觀性的缺失必然導致浪費。所以一定要把指標擺在明面上，這將深刻改變運營行為。
Werner用建築舉了個例子，“上面兩個房子是一模一樣的，其中一個房子使用的能源量比另外一個房子少了1/3。為什麼呢?關鍵在於其中一個裝了測量器，會自動調整冷暖氣。”
儘管實現可觀測性需要投入，但這筆錢絕對會物有所值。有句格言說“如果無法量化，也就無法管理。”請始終堅持對利用率、支出、錯誤等至關重要的成本管理指標保持關注。
當工程師和業務合作伙伴能夠隨時檢視關鍵成本指標時，自然就會催生出更具可持續性的實踐策略。持續檢查能幫我們發現非必要支出，並調整運營以減少浪費。總之，可觀測性帶來的回報往往遠超過前期投入。
最重要的是，這本身也是對成本的強調，能在企業中塑造出鼓勵可持續性實踐的文化。
法則五：依託成本感知架構實現成本控制
儉約架構的本質，在於強大監控與成本最佳化能力的結合。精心設計的系統能幫助大家抓住改進的機會。為此，請將應用程式拆分成一系列可以調節的構建塊。
也就是說，不同的元件一定要有相應的工具來掌控，來操縱這些內容的程式，同時來除錯它的矩陣和效能，要能做到隨時隨地想開啟哪些元件就能開啟它們，想關上的時候也能及時關上。這個開關必須要置於業務運營的關鍵環節上，保障你能夠輕鬆控制業務的運營。
一種常見的方法就是按重要性對元件進行分層。T1層元件必不可少，應當不計成本進行最佳化;T2層元件非常重要，但暫時縮小規模也不會產生重大影響;T3層元件則屬於“錦上添花”，要保證其成本低廉且易於控制。
明確定義各層，即可在成本及其他要求之間求得平衡。對元件的精細控制則能最佳化成本和體驗。基礎設施、語言、資料庫都應具備可調節性，並在系統的設計和構建階段考慮收入和利潤。總之，成本最佳化必須可量化，且與業務影響直接掛鉤。
法則六：成本最佳化是個漸進的過程
追求成本效率是個持續的過程。即使在部署之後，我們也必須隨時審視系統以逐步尋求最佳化。其中的關鍵在於不斷提問、深入研究。程式語言往往提供分析工具以追蹤程式碼效能，雖然這需要額外的精力和專業知識，但精細的調優足以帶來幾毫秒的差異。而這種看似微小的最佳化，累積起來足以產生超出想象的成本優勢。
在運營中，大部分時間都被用於執行現有系統。所以請把握一切機會，分析資源使用情況並減少浪費。亞馬遜雲科技持續監控生產中的服務，發現運營模式並消除低效因素。儉約是堅持的結果——透過逐步降低延遲和基礎設施成本，服務成本才能最終得到最佳化。
只要不懈努力，我們總能找到改進空間。而今天省下的資源，就是明天創新的燃料。
法則七：沒經歷過挫折會讓人盲目自信
如果軟體團隊在取得重大成功的過程中，從未經歷過任何嚴重失敗或者阻礙，則往往會出現自滿情緒。這是一種危險的傾向，會導致團隊成員對原本的方法、工具和實踐變得盲目資訊。
軟體團隊經常陷入這樣的陷阱：僅憑以往的工作經驗，他們就認為當前的技術、架構或語言永遠是最佳選擇。這可能會產生一種錯誤的安全感，阻礙對現狀的質疑，更會打擊對可能更加高效、更具成本效益或可擴充套件性更強的新選項的探索。
說到程式語言，人們往往會說“我們是一家Java公司”。這話大有問題，其底層邏輯無疑是在扼殺創新。唾手可得的成功會滋生自滿情緒，而只有質疑才能不斷激發新的最佳化與改進思路。
Grace Hopper的名言，準確反映了這一值得高度警惕的陷阱：“我們一直都是這樣做的。”