穩定性思考-強弱依賴

淘寶系統依賴關系比較複雜。a系統依賴b系統資源，當b系統發生故障的時候，a系統勢必會被拖累，導緻a系統也發生故障

                                 圖：[ a]--依賴-->[b]

這裡的依賴要區分兩種情況

1、a強依賴于b

    任何強依賴都要盡可能的轉化成弱依賴，因為強依賴本身意味着一榮俱榮，一損俱損。老婆管賬，但是老公又沒有私房錢，對老公來說強依賴于老婆，也許是很幸福的事情。在系統角度來說這并不是好事情，比如支付系統強依賴銀行的支付，一旦銀行支付出現問題，那麼隻能幹等着。是以需要盡量的擴充銀行的支付通道，讓單個節點影響到最小。

    對于強依賴b這個場景，從穩定性來說我們還是可以做一些事情：當b發生故障，雖然a系統不能正常執行業務，但是a不能挂掉，一旦b系統恢複，a系統也要做到立即恢複。同時a有責任對b要進行流量保護，而不是對b進行摧殘。

    我和小賭對淘寶某一前台系統做過一次分流壓測（和ab，httpload等壓測不同，是直接将正常的使用者請求不斷引入的壓測方式，本質差別是分流壓測方式使用者數會持續不斷的增加，ab等則是固定使用者數）：a系統單機的容量是4，目前的進入的流量是1。進行分流壓測，不斷增加單機的流量，直到該單機的流量到4，此時一切正常，流量增加到5，此時響應時間突增，減少流量到4，響應時間還是很長，持續一段時間不能自己恢複，再減少到3，系統還是沒有恢複，直到減少到2之後，系統恢複。原因是系統被壓垮之後，其容量發生了變化，原來容量是4，壓垮之後容量變成了2.5。

    此時系統會有比較頻繁的fullgc産生，做個簡單的分析，因為使用者不斷增加，而容量有不夠隻能堆積，導緻線程數量大增，直到max-limit值，并且由于強資源，導緻每個線程完成工作的時間變長，minagc發生的時候大量的eden區對象不能被回收，拷貝到s0 or s1又放不下或者超過交換次數後被拷貝到了old區。

    是以摧殘一個系統不好，同時也說明如果系統沒有做特殊的保護，當分流的量大于了單機的容量，持續一段時間後，系統将不能很好的恢複，即便我們把分流進入的量減少到系統容量以下也不能快速恢複。

2、a弱依賴于b

此時b如果發生了故障，那麼大家都期望a繼續能提供正常的服務

場景1：a調用b，a的主流程不需要等待b的傳回結果

浏覽器弱依賴：a從浏覽器上發起異步請求，如果b挂了，那麼隻會出現頁面某一個區域不顯示b的内容，如果對于使用者互動可以接受，那麼系統層面無任何問題，商品詳情頁面的評論清單和購買記錄就是這個情況

異步線程：a調用b的時候隻發送消息，然後調用動作由另外的線程來執行，并且不需要即時回報結果，一般作為消息通知，軌迹記錄等場景使用。不過為了防止堆積，也需要控制隊列的大小

場景2：a調用b，a的主流程需要等待b的傳回結果

設定逾時時間：如果b響應逾時，則抛出逾時異常，絕對大部分情況下ok；不過兩種影響要考慮：1、逾時時間設定過長或者過短導緻的副作用 2、大量異常抛出

設定最大并發請求數閥值，一旦超過閥值就跳過通路b

兩種方式相結合使用最佳