《架構即將來》中最經常使用的15個架構原則

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

1.N+1設計

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

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

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

2.回滾設計

確保系統能夠回滾到之前發佈過的任何版本。

之前作遊戲的時候常常遇到回滾，有時候是數據庫回滾，有時候是服務器端回滾，通常都是回滾到上個版本。

3.禁用設計

可以關閉任何發佈的功能。

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

4.監控設計

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

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

5.設計多活數據中心

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

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

6.只用成熟的技術

只用確實好用的技術。

無論用什麼技術，都要確保是一個成熟的技術。也許某個新技術有衆多優勢，好比，下降開發成本，提升開發效率，提升可擴展能力，減小終端用戶的響應時間。可是，只要這項技術故障率比較高，就毫不能使用。

7.異步設計

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

異步適合併發。

8.無狀態系統

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

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

9.水平擴展非垂直升級

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

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

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

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

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

11.非核心則購買

若是不是你最擅長的，也提供不了差別化的競爭優點則直接購買。

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

12.使用商品化硬件

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

硬件這塊兒，知足需求便可，在必要的時候增長配置。

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

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

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

14.隔離故障

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

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

15.自動化

設計和構建自動化的過程。若是機器能夠作，就不要依賴於人。

人常犯錯誤，更使人沮喪的是，他們每每會以不一樣的方式屢次犯一樣的錯誤。