我們知道，在單體應用的架構下一旦程序發生了故障，那么整個應用可能就沒法使用了，所以我們要把單體應用拆分成具有多個服務的微服務架構，來減少故障的影響范圍。但是在微服務架構下，有一個新的問題就是，由於服務數變多了，假設單個服務的故障率是不變的，那么整體微服務系統的故障率其實是提高了 ...

本文首先介紹微服務架構存在的風險，然后針對如何避免微服務架構的故障，提出了多種有效的微服務架構中的方法和技術，其中例如服務降級、變更管理、健康檢查和修復、斷路器、限流器等。 目錄 微服務架構的風險 優雅的服務降級 變更管理 健康檢查和負載均衡 自我修復 故障轉移緩存 ...

一、服務雪崩 問題描述 我們的系統由微服務架構組成，A調用B，B調用C，C調用D；在正常情況下，A、B、C、D都是正常的； 當某個時間點服務D突然掛掉了，此時的服務C還在瘋狂的調用服務D，由於D已經掛掉了，所以服務C調用服務D必須等待服務超時。而每次的C去調用服務D的時候都會創建線程，高並發 ...

關注哦！ 上篇我們已經了解到微服務中重要的組件之一 --- 服務網關Gateway 。我們在取精排 ...

保證系統能穩定地運行在生產環境是第一要務，就算是服務質量下降，只要仍在工作，那就是萬幸。 常見服務問題 服務超時 依賴的第三方服務因為某種不可抗力超時了？數據庫慢查詢拖垮了整個數據庫？ 服務錯誤 某個服務掛了？ 服務負載高 突然陡增的訪問量？ 解決方法 ...

博主 本文為微服務連載第一篇，如果有幸看到，還請找個時間仔細閱讀，歡迎收藏或轉載，如有不足之處煩請留言指正，共同進步，希望對你有幫助，謝謝 引言 和朋友聊天，招聘，看個行業要聞都是微服務... 最近幾年確實是火到沒朋友，至微服務架構出現后，越來越多的組織，企業，個人投入到該領域進行探索 ...

解析微服務架構系列文章將分幾篇描述微服務的定義、特點、應用場景、企業集成架構的演進以及微服務轉型思路和技術決策考慮等內容，並以IBM技術為例介紹如何實現微服務架構轉型。 為什么需要微服務架構 “微服務”架構是近期軟件應用領域非常熱門的概念。讓我們先來看看傳統IT架構面臨的一些問題 ...

為什么需要容錯限流 復雜分布式系統通常有很多依賴，如果一個應用不能對來自依賴 故障進行隔離，那么應用本身就處在被拖垮的風險中。在一個高流量的網站中，某個單一后端一旦發生延遲，將會在數秒內導致 所有應用資源被耗盡（一個臭雞蛋影響一籃筐）。 如秒殺、搶購、雙十一等場景，在某一時間點會有爆發 ...