保證系統能穩定地執行在生產環境是第一要務，就算是服務質量下降，只要仍在工作，那就是萬幸。常見服務問題
服務超時
依賴的第三方服務因為某種不可抗力超時了？資料庫慢查詢拖垮了整個資料庫？
服務錯誤
某個服務掛了？
服務負載高
突然陡增的訪問量？
解決方法
限時針對服務超時，可以通過超時控制保證介面的返回，可以通過設定超時時間為1s，盡快返回結果，因為大多數情況下，介面超時一方面影響使用者體驗，一方面可能是由於後端依賴出現了問題，如負載過高，機器故障等。某個網際網路公司曾經說，當系統故障時，fail fast。
fallback
有些情況下，即使服務出錯，對使用者而言，也希望是透明的，無感的，設定一些fallback，做一些服務降級，保證使用者的體驗，即使這個服務實際上是掛掉的，返回內容是空的或者是舊的，在此故障期間，程式設計師能趕緊修復，對使用者幾乎沒有造成不良體驗。
電路熔斷
這裡的電路熔斷是對於後端服務的保護，當錯誤、超時、負載上公升到一定的高度，那麼負載再高下去，對後端來說肯定是無法承受，好像和電路熔斷一樣，這三個因素超過了閾值，客戶端就可以停止對後端服務的呼叫，這個保護的措施，幫助了運維人員能迅速通過增加機器和優化系統，幫助系統度過難關。
工具hystrix執行流程可見how it works
以構建乙個對內部rpc呼叫的hystrixcommand為例:
構建乙個hystrixcommand用於rpc呼叫，設定超時時間為1s，fallback為返回空資料
如果快取開啟，結果優先從快取中獲取
如果電路被熔斷，嘗試fallback
如果併發量超過限制，嘗試fallback
不然，執行實際的rpc呼叫，如果呼叫失敗或者超時，嘗試fallback
根據實際情況設定
hystrix的超時時間，fallback，併發量都可以根據需要封裝的指令進行設定，可以說非常靈活，根據自己的具體業務進行合適的設定，能優化使用者體驗。
例如：文章列表api依賴的服務超時，可以通過服務降級拉取快取中的舊資料進行返回，雖然即時性稍遜，但是起碼使用者能讀到幾分鐘前的文章，在此期間，趕緊修復問題。
微服務實踐 什麼是微服務
微服務是一種軟體架構風格，該詞 於martin fowler 的一篇部落格。他在自己部落格中闡述了微服務六個特點 創業初期 很快完成後，找了家雲服務部署上線，開始了創業之路。規模擴大 這一階段存在著很多不合理的地方 做出改變 在程式設計的世界裡，最重要的是抽象能力，通過整理業務邏輯，抽象初公共的業務...
微服務實踐歷程
微服務概念的出現已經有很多年了，有多少公司在真正使用微服務，今天就把我這幾年對微服務的一點感受和大家分享下 首先，在系統建立之初，有乙個問題，到底要不要按照微服務的架構來開始專案？這個時候如果我們是接觸的乙個比較熟悉的行業 熟悉的業務，或者說業務架構師對這一行比較了解，那麼可以考慮進行微服務的設計，...
Abp vNext微服務實踐 服務通訊
服務通訊是微服務架構中必不可少的功能，服務通訊的效率決定了微服務架構的優略。常用的微服務通訊策略有兩種，分別是rpc http，其中rpc以grpc框架為代表使用者最多。abp vnext微服務架構中當然也有服務通訊策略，採用的是http方式進行服務通訊。雖然grpc高效安全，但是相關的.net框架...