這是如何提高阿裏雲上應用的可用性系列文章的第二篇，第一篇傳送門。

在單體應用時代，最大的問題是如何解決數據庫瓶頸，而微服務之下，一個大應用被拆分成了幾十個甚至上百個微服務，數據訪問的壓力被傳導到了服務之間的網絡，服務強弱依賴，服務雪崩等各種問題隨之而來，那麽如何保障服務的可用性以及整個應用的健壯性呢？常見的做法包括：

超時
程序員和女朋友約會在樓下等她的時候一般都會約定 “等你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產品，來自於多年雙十一穩定性保障的經驗，具有無需修改代碼，全界面操作和性能穩定的特點，下面舉例示意如何給雲上的應用添加限流和降級的能力（傳送門：如何接入應用高可用服務）

對關鍵接口進行限流

對非關鍵業務進行降級處理

如何提高阿裏雲上應用的可用性（二）