「everything fails, all the time」，無論是在傳統軟體時代還是在網際網路、雲時代，系統終究會在某個時間點失敗，面向失敗的設計理念數十年來並沒有多大的變化，不同的是在分布式、雲架構的網際網路時代：失敗將由小概率偶發事件變成常態，同時應對和處理失敗的具體實現方式也大相徑庭。
1、硬體問題
首先，硬體是有生命週期的，它一定會老化，並且你不知道它會在什麼時候壞；其次，硬體是乙個實體，它存在於客觀環境當中，它的狀態會受外部環境干擾，比如火災、**等外力因素都可能導致硬體損壞；最後，所有硬體都會存在殘次品，你很可能就是那個不幸者。通常情況下單個硬體出問題的概率不高，但是當有幾十萬的硬體裝置，硬體的失敗問題每天都會發生。
2、軟體bug
即便是最優秀程式設計師寫出來的程式，經過最優秀測試同學的嚴格測試後的**，上線依然無法做到完全沒有bug。網際網路業務迭代往往講究乙個「快」字，以往幾個月或者幾年公升級一次的軟體程式，現在一周就需要公升級一次或者多次，這大幅提公升了軟體出錯的可能性。
3、配置變更錯誤
系統執行態的日常運維過程當中，難免會因為疏忽或者考慮不周全導致災難。當上萬名技術同學跟上百個變更系統做笛卡爾積，哪怕是6個9的可靠性，依舊無法做到萬無一失。全域性的流量入口、許可權與安全驗證體系、統一閘道器與介面平台等技術環節是可能促發全站不可用的重要風險點，對於影響面大的配置的變更需要尤為謹慎。
4、系統惡化
原本工作得很好的程式隨著時間的推移可能有一天不再正常工作，舉幾個常見的例子：自增變數執行了很長一段時間後出現越界、快取隨著資料量的逐漸變大而出現空間不足、資料庫連線池隨著機器的擴容而不夠用等等。千萬不要認為執行良好的系統是不會出問題的，它的**裡面可能藏了定時炸彈，只是你不知道會在什麼時間點**。
5、超預期流量
某一天你的系統可能突然會承受遠超過預期的每秒請求數，特別是在「中國特色」的網際網路場景之下，你很難精確預估系統各個時間點的業務訪問量。
6、外部攻擊
你需要考慮各種攻擊行為，包含流量攻擊和安全攻擊。你的系統可能隨時會面臨著ddos和cc類攻擊，你傳輸的資料可能會被盜取或者篡改。
ddos：分布式拒絕服務攻擊(英文意思是distributed denial of service，簡稱ddos)是指處於不同位置的多個攻擊者同時向乙個或數個目標發動攻擊，或者乙個攻擊者控制了位於不同位置的多台機器並利用這些機器對受害者同時實施攻擊。由於攻擊的發出點是分布在不同地方的，這類攻擊稱為分布式拒絕服務攻擊，其中的攻擊者可以有多個。
分布式拒絕服務攻擊原理分布式拒絕服務攻擊ddos是一種基於dos的特殊形式的拒絕服務攻擊，是一種分布的、協同的大規模攻擊方式。乙個完整的ddos攻擊體系由攻擊者、主控端、**端和攻擊目標四部分組成。主控端和**端分別用於控制和實際發起攻擊，其中主控端只發布命令而不參與實際的攻擊，**端發出ddos的實際攻擊包。
7、依賴庫問題
你的系統很可能會用大量的二方庫或者三方庫，它們對你來說是黑盒子，你不了解它們存在哪些風險，並且你無法掌控。這些庫可能會存在漏洞、可能會有bug，可能會大量消耗你的系統資源，總之不要太信任它們。
8、依賴服務問題
你依賴的服務也一定不會100%可用，它們可能會超時，可能會失敗。當依賴服務超時的時候，如果你沒有很好地處理，可能會導致你自己的系統無法工作，在分布式場景下，這種失敗狀態會持續輻射，最終導致大面積的不可用。
在一開始的系統設計階段就考慮到以上各種失敗場景，把面向失敗當成系統設計的一部分，並且準備好從失敗中恢復的策略，這有助於更好地提公升整個系統的可用性。只有你意識到事情會隨著時間的推移而失敗，並將這種思想融入到體系結構中，那麼在失敗發生的時候你才能完全不受影響或者將失敗損失降到最低。面向失敗的設計理念數十年來並沒有多大的變化，一些好的經典原則在今天依舊被廣泛運用。
1、冗餘設計避免單點故障
硬體和軟體都不可靠，環境和人都存在極大的不確定性，雖然無法避免失敗場景的發生，但是可以通過冗餘設計來規避區域性失敗對系統的影響。冗餘設計避免單點故障這一策略在網際網路技術架構中處處可見，比如重要的服務通常都會部署多個、資料庫的主備結構、服務呼叫的重試機制、儲存的多副本等概念都屬於這一範疇。
2、服務能力與依賴呼叫自我保護
軟體系統由兩部分構成：系統自身的**和依賴的庫以及服務。「服務能力與依賴呼叫自我保護」需要從這兩塊分別切入構建系統在任意情況都始終工作在最佳狀態的能力。服務限流、系統負載保護、給依賴的服務設定超時或者資源限制等都是相應的應對策略。
3、精細化的監控體系
面向失敗設計不僅要求你的系統足夠健壯，同時要求你能夠在第一時間感知到失敗的發生。無論是自動化的系統恢復，還是人為介入，如果你壓根都不知道是**出問題了，一切都將束手無策。精細化的監控體系一方面能夠在出現問題的時候以最快的速度將最準確的資訊傳遞到人或者運維系統，同時它還能夠展現趨勢、進行提前預警。ai技術的結合使得監控領域在近幾年得到了新的發展驅動力：智慧型監控報警、根因定位、智慧型**、智慧型決策等能力都是學術界和工程界非常熱衷的課題。
4、自動化運維管控
大量的系統故障是因為人的失誤造成的，唯一的解決辦法便是在運維過程當中盡可能降低人為操作的比重。系統化、白屏化是第乙個階段——將人為的操作步驟固化成系統程式，避免操作失誤；自動化以及智慧型化是第二個階段——將正確的決策過程也固化成智慧型程式，避免決策失誤。同時所有的運維動作都需要遵循灰度原則，做到可灰度、可監測、可回滾，即便出現了失誤也能控制好**半徑，並且做到快速恢復。
物件導向系統設計備忘
物件導向的系統設計，說的簡單一點，就是關注點拆分的問題 系統拆分成子系統 子系統拆分成模組 大的模組拆分成的小的模組 小的模組拆分成類 類拆分成結構體和功能點 經過這樣的拆分，系統實際上會被抽象成物件的結構和物件的功能 以及物件之間的協作。而在系統設計的過程中，需要關注的東西，除了模型的抽象之外，怎...
物件導向設計 設計原則
職責單一 例如乙個類的只能負責單一的職責 開放 封閉原則 對擴充套件的開放，對修改的封閉。用新的類處理問題，不去修改現有類 liscov替換原則 子類可以替換父類 在沒有過載方法的情況下 依賴倒置原則 依賴介面，不要依賴具體實現。針對介面程式設計，不針對實現程式設計 緊耦合 類似於電腦中可插拔 更換...
物件導向設計
物件導向設計 object oriented design，ood 方法是oo方法中乙個中間過渡環節。其主要作用是對ooa分析的結果作進一步的規範化整理，以便能夠被oop直接接受。物件導向設計 ood 是一種軟體設計方法，是一種工程化規範。這是毫無疑問的。按照bjarne stroustrup的說法...