摘要: 這是如何提升阿里雲上應用的可用性系列文章的第二篇,第一篇傳送門。 在單體應用時代,最大的問題是如何解決數據庫瓶頸,而微服務之下,一個大應用被拆分紅了幾十個甚至上百個微服務,數據訪問的壓力被傳導到了服務之間的網絡,服務強弱依賴,服務雪崩等各類問題隨之而來,那麼如何保障服務的可用性以及整個應用的健壯性.html
這是如何提升阿里雲上應用的可用性系列文章的第二篇,第一篇傳送門。程序員
在單體應用時代,最大的問題是如何解決數據庫瓶頸,而微服務之下,一個大應用被拆分紅了幾十個甚至上百個微服務,數據訪問的壓力被傳導到了服務之間的網絡,服務強弱依賴,服務雪崩等各類問題隨之而來,那麼如何保障服務的可用性以及整個應用的健壯性呢?常見的作法包括:數據庫
程序員和女友約會在樓下等她的時候通常都會約定 「等你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產品,來自於多年雙十一穩定性保障的經驗,具備無需修改代碼,全界面操做和性能穩定的特色,下面舉例示意如何給雲上的應用添加限流和降級的能力(傳送門:如何接入應用高可用服務)