dubbo 提供的集中負載均衡策略
dubbo 默認使用 RandomLoadBalance
圖 1
具體看select方法 返回具體的 invoker對象，
圖2
select 方法
sticky 粘性？這里不太懂，大概是選中invoker后，每次都選同一個invoker, 這里不糾結了，暫時跳過, 直接看 deselect方法
圖3
deselect 方法，如果invokers size是1，直接返回，如果兩個輪詢 ,這里有個不太明白的地方 selected 是在每次調用中初始化的，如何知道上次選擇了哪個invoker?
經過debug發現這個輪詢是指在失敗的情況下，兩個invoker交替使用 ，dubbo默認使用的是FailoverClusterInvoker（When invoke fails, log the initial error and retry other invokers (retry n times, which means at most n different invokers will be invoked), 默認重試2+1次。所以這個selected list放的是一次遠程調用中已經調用過的invoker，當selected list 不為空，說明肯定存在調用失敗的invoker
在圖二中可以發現，當 i>0 (首次調用失敗之后) 會調用checkWhetherDestroyed方法
圖4
繼續看 loadbalance.select方法
圖5
具體實現在子類實現的 doSelect方法中，這里使用的是RandomLoadBalance
圖6
這里循環計算每個invoker的weight, 如果weight相同就隨機返回一個，不同的話 隨機獲取一個[0, totalWeight)之間的數， offset = offset - weight,如果 offset 小於0，則選中，
很明顯weight大的更容易讓offset的值小於0,
舉個例子 有 4個invoker 權重分別為（1，2， 3， 4）,totalWeight = 10, 假如 offset = 6, 6 - 1 = 5, 5大於0，繼續 5 - 2 = 3 大於0，3 - 3 = 0， 0 - 4 小於0 ，所以選擇權重為4的 invoker, 這里可以發現只要offset >= 6 則選擇權重為4的invoker, 正好是40%。
我們看下getWeight方法
圖7
默認weight是100，這里有個根據預熱時間來計算權重的算法，先獲取provider端的啟動時間，在通過當前時間減去provider端啟動的時間得到已經啟動的時間 uptime
,獲取配置warmup時長，如果uptime 小於 warmup,說明還在預熱階段，需要相應的減少權重。算法見上圖中 33行 calculateWarmupWeight, 獲取啟動 uptime時長對應的權重
weight / warmup 得到單位時間的權重，再乘以已經啟動的時長uptime 得到 uptime 時長對應的權重。
預熱這里老版本之前取的 consumer端的啟動時間是沒有預熱效果的
總體流程
AbstractClusterInvoker invoke -> doInvoke
FailoverClusterInvoker doInvoke -> select
AbstractClusterInvoker select -> doSelect
AbstractClusterInvoker doSelect -> loadbalance select