《架構即未來》這本書的第12章簡單闡述了架構設計的一些常用的原則（後面章節會詳細闡述）。這些原則中很多都是在架構一開始的設計中就要考慮進去的，這樣在出現任何問題時，我們都能夠及時的處理，和把問題影響的範圍有效的縮小。否則就像我現在的專案，一開始設計時，考慮的很少，出問題時，沒有做到及時的反饋，和縮小影響範圍，只能在事故的代價中將所需要的原則新增進來，慢慢完善。
要確保任何你所開發的系統在發生故障時，至少有乙個冗餘的例項。乙個例項確實很危險，當這個例項出現不明原因的問題不能對外服務，需要debug的時候，如果優先debug，那當前例項就要暫停服務直到你找到問題為止。如果你直接重啟例項恢復服務，就沒有事故現場進行debug了。而這時如果有乙個冗餘的例項，就可以先讓冗餘的例項對外服務，事故現場的環境也得以保留。
多個例項來做負載均衡也是一種不錯的選擇。
確保系統可以回滾到以前發布過的任何版本。以前做遊戲的時候經常遇到回滾，有時候是資料庫回滾，有時候是伺服器端回滾，一般都是回滾到上個版本。
能夠關閉任何發布的功能。當乙個功能出現嚴重問題不得不關閉時，如果關閉整個系統代價就有點大了，所有要有單個功能的開關。像**系統的支付功能就一定要有開關，如果出現比較嚴重的bug，可以關閉支付而不影響下單。
在設計階段就必須要考慮監控，而不是在實施完成之後補充。如果監控做的好，不僅能發現服務的死活，檢查日誌檔案，還能收集系統相關的資料，評估終端使用者的響應時間。如果系統和應用在設計和構建時就考慮好監控，那麼即使不能自我修復，也至少可以自我診斷。
不要被乙個資料中心的解決方案把自己限制住。有錢就多建乙個，讓股東放心。
只用確實好用的技術。不管用什麼技術，都要確保是乙個成熟的技術。也許某個新技術有眾多優點，比如，降低開發成本，提高開發效率，提高可擴充套件能力，減少終端使用者的響應時間。但是，只要這項技術故障率比較高，就絕不能使用。
只有在絕對必要的時候才進行同步呼叫。非同步適合併發。
只有當業務確實需要的時候，才使用狀態。無狀態的系統更利於擴充套件，更利於做負載均衡。
永遠不要依賴更大、更快的系統。微服務是水平擴充套件的乙個例子，不要把所有的功能都集中在乙個系統裡面。必要的時候把需求分為多個系統，而不是公升級原有的系統。
在擴充套件性問題發生前考慮好下一步的行動計畫。想的更遠一點，就能減少重構的次數。
如果不是你最擅長的，也提供不了差異化的競爭優勢則直接購買。雲服務這種的就購買好了。
在大多數情況下，便宜的是最好的。硬體這塊兒，滿足需求即可，在必要的時候增加配置。
全部研發要小構建，不斷迭代，讓系統不斷地成長。小版本的失敗率較低，因為失敗率與解決方案中的變更數量直接相關。
實現隔離故障設計，通過斷路保護避免故障傳播和交叉影響。避免多系統之間的互相影響，這個很重要。
設計和構建自動化的過程。如果機器可以做，就不要依賴於人。人常犯錯誤，更令人沮喪的是，他們往往會以不同的方式多次犯同樣的錯誤。
《架構即未來》中最常用的15個架構原則
架構即未來 這本書的第12章簡單闡述了架構設計的一些常用的原則 後面章節會詳細闡述 這些原則中很多都是在架構一開始的設計中就要考慮進去的，這樣在出現任何問題時，我們都能夠及時的處理，和把問題影響的範圍有效的縮小。否則就像我現在的專案，一開始設計時，考慮的很少，出問題時，沒有做到及時的反饋，和縮小影響...
軟體架構設計最常用的15個原則
架構原則 1 n 1設計 永遠不少於兩個，通常三個。2 回滾設計。確保系統可以回滾到以前發不過的任何版本。3 禁用設計。能夠關閉任何發布的功能。4 監控設計。在設計階段就必須要考慮監控，而不是在實施完成之後補充。5 設計多活資料中心。不要被乙個資料中心的解決方案把自己限制住。6 使用成熟的技術。只用...
Visual Studio中最常用的13個快捷鍵
2009 04 30 15 26 佚名 中國it實驗室 字型大小 t t 本文將為大家介紹visual studio中最常用的13個快捷鍵，輔以的介紹一定能讓大家更加熟練地使用這些快捷鍵，提高工作效率。ad 2013雲計算架構師峰會超低價搶票中 1.f5 啟動除錯 2.f7 shift f7 顯示 ...