我們都經歷過巨石應用，單一應用某個功能誘發的故障導致整個站點掛掉，任何人都無法訪問，只能一一排錯再部署上線，這樣造成的影響就是使用者的流失。而分布式應用就沒有這樣的問題，就算某個節點出現故障，那麼主備切換，替換主節點，整個系統還是照樣執行，完全沒有訪問不了的現象。
要使系統達到一定的容錯性，那麼
首先要實現的就是高可用，最簡單的就是進行節點集群化，使用心跳機制讓好的節點替換壞的節點。
其次要保證系統的穩定性，如果運維有事沒事上去重啟一次，這樣也不太好吧（其實很多應用在一開始都是每週重啟一次的）
然後整個系統平台的安全性當然要提高，比如防csrf攻擊，防iis攻擊等等，安全性一旦提高系統崩潰的機率也相應降低。
最後就是系統的可維護性，這個在我看來是最高端別的，一旦系統難以維護，那麼開發人員以及運維人員的工作量是巨大的，甚至會出現有人不想維護而離職不幹，這都是會發生的情況，所以乙個系統的可維護性非常考驗架構師的能力。
對於故障的分類有**級別的，也有硬體方面的，硬體的故障咱們姑且不說，而**方面的故障我們要做的就是日誌分析了，設定好日誌級別，在很多發生業務的地方會產生大量的日誌，這個時候就需要elk來進行分析了，通過日誌來解決**放的bug，也是必要的。
分布式系統的那些事兒（四） MQ時代的通訊
之前在講rpc通訊的各種好處，特別好用，但是rpc並不是萬能的，也並不是適用於各種場景的，因為他是同步的 現如今很多場景下的呼叫都是非同步的，系統a呼叫b後，並不需要知道b的結果，而且對b的結果無所謂，甚至你b掛了都無所謂，那麼這個時候使用訊息佇列是十分ok的。最簡單的場景就是傳送簡訊和email，...
分布式系統的那些事兒（七） 微服務架構體系
微服務的出現，標誌了又乙個新的里程碑，似乎你不知道微服務就代表你好像out了一樣。微服務是業務服務化，將soa更好的延續了下去。配合restful也能夠更好的提供api介面。簡單來說就是微服務把各種各樣的小的服務區分開來當做乙個當度的應用跑在伺服器上，並且他的通訊機制也是十分簡單的，使用rest或者...
分布式 常見的容錯機制
常見容錯機制 failover failsafe，failfase failback，forking，於阿里的定義。當出現失敗，重試其它伺服器，通常用於讀操作 推薦使用 重試會帶來更長延遲。只發起一次呼叫，失敗立即報錯,通常用於非冪等性的寫操作。如果有機器正在重啟，可能會出現呼叫失敗 出現異常時，直...