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

1.N+1設計

要確保任何你所開發的系統在發生故障時，至少有一個冗餘的例項。

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

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

2.回滾設計

確保系統可以回滾到以前釋出過的任何版本。

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

3.禁用設計

能夠關閉任何釋出的功能。

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

4.監控設計

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

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

5.設計多活資料中心

不要被一個數據中心的解決方案把自己限制住。

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

6.只用成熟的技術

只用確實好用的技術。

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

7.非同步設計

只有在絕對必要的時候才進行同步呼叫。

非同步適合併發。

8.無狀態系統

只有當業務確實需要的時候，才使用狀態。

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

9.水平擴充套件非垂直升級

永遠不要依賴更大、更快的系統。

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

10.設計至少有兩個步驟的前瞻性

在擴充套件性問題發生前考慮好下一步的行動計劃。

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

11.非核心則購買

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

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

12.使用商品化硬體

在大多數情況下，便宜的是最好的。

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

13.小構建，小發布，快試錯

全部研發要小構建，不斷迭代，讓系統不斷地成長。

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

14.隔離故障

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

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

15.自動化

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

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