熔斷:
舉個例子解釋,生活中每家每戶都在用電,小明家的電線因為故障導致了小明家停電了。而小李、小張家的電是正常使用的。電力公司沒有因為小明家有故障線路而停掉其他人家的電,同時小明家沒有使用有故障的電路的電。這時即為熔斷。熔斷的目的是當a服務模組中的某塊程式出現故障後為了不影響其他客戶端的請求而做出的及時回應。
降級:舉個例子解釋,我們去銀行排隊辦理業務,大部分的銀行分為普通視窗、特殊視窗(vip視窗,老年視窗)。某一天銀行大廳排普通視窗的人巨多。這時特殊視窗貼出告示說某時刻之後再開放。那麼這時特殊視窗的工作人員就可以空出來去幫其他視窗辦理業務,提高辦事效率,已達到解決普通視窗排隊的人過的目的。這時即為降級,降級的目的是為了解決整體專案的壓力,而犧牲掉某一服務模組而採取的措施。
兩者其實從有些角度看是有一定的類似性的:
目的很一致,都是從可用性可靠性著想,為防止系統的整體緩慢甚至崩潰,採用的技術手段;
最終表現類似,對於兩者來說,最終讓使用者體驗到的是某些功能暫時不可達或不可用;
粒度一般都是服務級別,當然,業界也有不少更細粒度的做法,比如做到資料持久層(允許查詢,不允許增刪改);
自治性要求很高,熔斷模式一般都是服務基於策略的自動觸發,降級雖說可人工干預,但在微服務架構下,完全靠人顯然不可能,開關預置、配置中心都是必要手段;
而兩者的區別也是明顯的:
觸發原因不太一樣,服務熔斷一般是某個服務(下游服務)故障引起,而服務降級一般是從整體負荷考慮;
管理目標的層次不太一樣,熔斷其實是乙個框架級的處理,每個微服務都需要(無層級之分),而降級一般需要對業務有層級之分(比如降級一般是從最外圍服務開始)
(總結參考來自:
Spring Cloud 微服務實戰筆記
傳統開發所有業務邏輯都在乙個應用中,開發,測試,部署隨著需求增加會不斷為單個專案增加不同業務模組 前端展現也不侷限於html檢視模板的形式,後端向前端支援需要更多的介面模組。隨著需求增多,專案變大,單體系統部署在乙個程序內部,往往修改很小的功能,為了部署上線也會影響其他功能。後期維護成本會變得越來越...
《Spring Cloud微服務實戰》開始預售
京東 亞馬遜已全面開啟預售!快來一起體驗spring cloud所帶來的全家桶式微服務架構解決方案!掃一掃前往京東購買 為什麼選擇spring cloud spring cloud簡介 版本說明 配置詳解 監控與管理 小結eureka詳解 原始碼分析 配置詳解 服務例項類配置 元資料 跨平台支援 原...
微服務實戰經驗分享
在過去的幾個月裡,我們已經聽到很多關於微服務的優缺點了。微服務真的只是soa嗎?微服務確實有助於進行複雜系統架構嗎?不論大家怎麼說,有一些公司已經轉向或正準備轉向基於微服務的方法了。他們在實踐過程中分享自己獲得的正面或負面的經驗,是很自然的事。最近,droplet公司的tom livesey分享了他...