這是如何提高阿里雲上應用的可用性系列文章的第二篇，第一篇傳送門。
在單體應用時代，最大的問題是如何解決資料庫瓶頸，而微服務之下，一個大應用被拆分成了幾十個甚至上百個微服務，資料訪問的壓力被傳導到了服務之間的網路，服務強弱依賴，服務雪崩等各種問題隨之而來，那麼如何保障服務的可用性以及整個應用的健壯性呢？常見的做法包括：
超時
程式設計師和女朋友約會在樓下等她的時候一般都會約定 “等你30分鐘啊”， 這就是一種超時約定，如果等了半小時女朋友還沒有下來，該怎麼辦？一般有服務治理意識的程式設計師都會選擇超時退出及時止損（不知道這是不是程式設計師沒有女朋友的原因之一）
在應用設計中，為避免叢集雪崩或資源耗盡，一切呼叫都應該設定超時時間，包括RPC/DB/快取，服務端超時是必選配置。在實際的電商實際場景中，一般服務級別的超時時間通常會設定在100ms～300ms之間。
超時的設定需要注意一個問題就是超時的傳遞問題， 假設服務A呼叫服務B，A的超時設定為100ms，B為300ms，那麼這個設定就是有問題，因為一旦B的呼叫時間超過了100ms，A無論如何都會超時，而B的繼續呼叫就會成為一種資源浪費，而在特別複雜的服務依賴關係中，超時的設定一定要考慮傳遞的問題
重試
當程式設計師給喜歡的女孩子表白被拒絕了怎麼辦，一般可以做出萬分痛苦狀接一句“要不要再考慮一下”，這就是一種重試，在服務呼叫中，重試就是當對服務端的呼叫出現異常或者錯誤時，自動的再次發起呼叫請求，可見這種方式在服務端出現偶發性抖動或者網路出現抖動的時候可以比較好的提高服務呼叫的成功率，但同時，如果服務端處在出現故障的邊緣時，也有可能成為壓垮駱駝的最後一根稻草，所以在生產環境中一定要慎用
熔斷
家裡面使用的保險絲就是一種典型的熔斷，一旦電流過大的時候，就是斷開以保護整個電路，在程式設計中，一旦服務端的呼叫的異常或者錯誤比例超過一定的閾值時，就停止對此服務的呼叫，此時處於close狀態，經過一段時間的熔斷期後會嘗試重新發起呼叫，此時處於close-open狀態，如果呼叫成功則放開呼叫，切換到open狀態，否則繼續回到close狀態
隔離
遠洋大船的內部都會設計多個水密倉，這樣一旦事故出現船體破損，也可以把影響控制在水密倉級別而不至於整個船沉默，這就是一種隔離策略，在程式設計中，為了達到資源隔離和故障隔離，通常有兩種做法，一種是通過執行緒池來進行隔離，對於不同型別資源新建不同的執行緒池，然後通過設定執行緒池的大小和超時時間來起到隔離資源使用的效果，但是這種方式由於需要新建執行緒池，對於資源開銷比較大，另外一種方式就是通過觀察執行緒的訊號量也就是同型別資源的執行緒數，當超過相應的閾值時快速拒絕新的資源請求。
限流和流控
本質上這兩種方式都是對於超出服務提供能力的請求進行限制，區別是限流的話是立刻拒絕，而流控是讓請求進行排隊，這種方式對於流量的削峰填谷有著比較好的效果
以上的這些能力一般都會在微服務框架中整合提供，如阿里的Dubbo以及Spring Cloud的Hystrix，通過引入jar包在程式碼中需要增強的地方加入新增相應的高可用程式碼，需要在應用系統設計之初就充分考慮進去， 後期業務新增或變更時也需及時維護
接下來隨之而來的一個問題就是如何測試驗證這些高可用措施是有效的？閾值的設定是否合理？
常用的做法有兩個：
壓測
通過在雲端模擬大量的使用者請求來測試應用系統面對突發流量的能力和進行容量規劃，這裡介紹一款阿里雲的PTS產品，可以在雲端模擬百萬併發，以此可以檢測各鏈路是否有限流降級的措施，是否設定合理-傳送門。
故障演練
故障演練是一種比較新的高可用測試的方式，通過軟體層面模擬各種可能出現的故障，觀察應用系統對於故障的隔離和降級能力。 這一專門的領域稱之為Chaos engineering， 在阿里內部，通過故障演練平臺，每天都在進行著各種型別的故障演練，這些故障包括作業系統層面的故障如程式意外退出，CPU記憶體飈高， 也包括網路層面的故障如網路延遲丟包，DNS解析錯誤， 還包括了應用服務層面的故障如服務介面延遲，異常返回等。通過這種方式可以比較有效的驗證應用的高可用能力，找到潛在風險問題。
當然對於種種原因沒有整合高可用框架，也沒有自己搭建故障演練平臺的各位同學，阿里雲推出了應用高可用服務這一業界首款快速提高應用高可用能力的SaaS產品，來自於多年雙十一穩定性保障的經驗，具有無需修改程式碼，全介面操作和效能穩定的特點，下面舉例示意如何給雲上的應用新增限流和降級的能力（傳送門：如何接入應用高可用服務）
對關鍵介面進行限流
對非關鍵業務進行降級處理
作者： 中介軟體小哥