讀《架構即未來》後記錄

《架構即未來》這本書的第12章簡單闡述了架構設計的一些常用的原則（後面章節會詳細闡述）。這些原則中很多都是在架構一開始的設計中就要考慮進去的，這樣在出現任何問題時，我們都能夠及時的處理，和把問題影響的範圍有效的縮小。否則就像我現在的項目，一開始設計時，考慮的很少，出問題時，沒有做到及時的反饋，和縮小影響範圍，只能在事故的代價中將所需要的原則添加進來，慢慢完善。


1.N+1設計
要確保任何你所開發的系統在發生故障時，至少有一個冗餘的實例。


一個實例確實很危險，當這個實例出現不明原因的問題不能對外服務，需要debug的時候，如果優先debug，那當前實例就要暫停服務直到你找到問題爲止。如果你直接重啓實例恢復服務，就沒有事故現場進行debug了。而這時如果有一個冗餘的實例，就可以先讓冗餘的實例對外服務，事故現場的環境也得以保留。


多個實例來做負載均衡也是一種不錯的選擇。


2.回滾設計
確保系統可以回滾到以前發佈過的任何版本。


以前做遊戲的時候經常遇到回滾，有時候是數據庫回滾，有時候是服務器端回滾，一般都是回滾到上個版本。


3.禁用設計
能夠關閉任何發佈的功能。


當一個功能出現嚴重問題不得不關閉時，如果關閉整個系統代價就有點大了，所有要有單個功能的開關。像商城系統的支付功能就一定要有開關，如果出現比較嚴重的bug，可以關閉支付而不影響下單。


4.監控設計
在設計階段就必須要考慮監控，而不是在實施完成之後補充。


如果監控做的好，不僅能發現服務的死活，檢查日誌文件，還能收集系統相關的數據，評估終端用戶的響應時間。如果系統和應用在設計和構建時就考慮好監控，那麼即使不能自我修復，也至少可以自我診斷。


5.設計多活數據中心
不要被一個數據中心的解決方案把自己限制住。


有錢就多建一個，讓股東放心。


6.只用成熟的技術
只用確實好用的技術。


不管用什麼技術，都要確保是一個成熟的技術。也許某個新技術有衆多優點，比如，降低開發成本，提高開發效率，提高可擴展能力，減少終端用戶的響應時間。但是，只要這項技術故障率比較高，就絕不能使用。


7.異步設計
只有在絕對必要的時候才進行同步調用。


異步適合併發。


8.無狀態系統
只有當業務確實需要的時候，才使用狀態。


無狀態的系統更利於擴展，更利於做負載均衡。


9.水平擴展非垂直升級
永遠不要依賴更大、更快的系統。


微服務是水平擴展的一個例子，不要把所有的功能都集中在一個系統裏面。必要的時候把需求分爲多個系統，而不是升級原有的系統。


10.設計至少有兩個步驟的前瞻性
在擴展性問題發生前考慮好下一步的行動計劃。


想的更遠一點，就能減少重構的次數。


11.非核心則購買
如果不是你最擅長的，也提供不了差異化的競爭優勢則直接購買。


雲服務這種的就購買好了。


12.使用商品化硬件
在大多數情況下，便宜的是最好的。


硬件這塊兒，滿足需求即可，在必要的時候增加配置。


13.小構建，小發布，快試錯
全部研發要小構建，不斷迭代，讓系統不斷地成長。


小版本的失敗率較低，因爲失敗率與解決方案中的變更數量直接相關。


14.隔離故障
實現隔離故障設計，通過斷路保護避免故障傳播和交叉影響。


避免多系統之間的互相影響，這個很重要。


15.自動化
設計和構建自動化的過程。如果機器可以做，就不要依賴於人。


人常犯錯誤，更令人沮喪的是，他們往往會以不同的方式多次犯同樣的錯誤。