[case3]聊聊系統設計中的trade-off

序

本文主要小結一下系統設計當中的trade-off

trade-off

trade-off翻譯過來大體是折中的意思，也就是說系統設計一般牽扯的點比較多，有的設計方案這個方面比較好，可是又有其餘缺點，沒有十全十美的方案，只是在特定的上下文，特定的約束條件下，權衡選取比較合適的方案。可是一旦這個上下文或約束條件隨着業務變化，基礎設施變化等等，原來的折中的方案可能也就不合適了。因而就須要從新架構。

常見的trade-off

• 緩存

以空間換取時間，犧牲內存來加快讀取速度，但同時也帶來一致性維護問題

• 數據庫三範式

以時間換取空間，數據庫的範式設計，有些表僅僅有主鍵，可是業務查詢常常須要帶上姓名等其餘字段，這個時候就得在展現層去根據用戶id再去獲取用戶姓名去組裝數據，在持久層保持了一致性，可是對於展現層來講得額外再去關聯表或查詢姓名，犧牲了時間。

• CAP

好比nosql大可能是選擇以AP爲主，犧牲C

• 微服務

將單體架構拆分爲微服務，則在部署成本上可能比單體架構要多一些，可是帶來的是服務的拆分隔離以後的相對穩定性和可維護性，可是同時也可能帶來諸多一致性問題。

• 高級語言vs彙編語言

高級語言比彙編語言更容易讓人掌握，可是最後仍是要轉爲機器懂的0和1，相比彙編是犧牲了性能，可是帶來的是可維護性。

• bean vs map

java bean比map的好處是裏頭的屬性類型肯定，不像map是個黑盒，每次用數據都得根據key去換取，而後強轉，無形之中就給編碼帶來不少坑，提醒了易錯性，可是map的好處是通用；bean就是相對不如map那麼萬能，可是因爲每一個屬性肯定，用的時候直接調用getter去獲取，也不用類型強轉，有多少屬性也很明瞭，提高了編程的可靠性，可是壞處就是不通用。

小結

本文只是粗略列舉了一些trade-off，其餘的還有待後續進一步提煉。

doc

• Software Design Tradeoff Factors