話說條條大路通羅馬，Ribbon提供了這么多的策略,，我該用哪個(gè)策略才好呢?都說原配的才是最合適的,，那我干脆就用默認(rèn)的負(fù)載均衡策略好了。

　　事情真的這么簡單嗎?讓我們從一個(gè)遠(yuǎn)古神話說起,。

　　人月神話

　　《人月神話》是FrederickP.Brooks的著作,，被稱為軟件工程四大名著之一。Brooks結(jié)合了大量軟件工程實(shí)踐,，向大家闡釋了大型項(xiàng)目中普遍存在的難題,，以及解決問題的方法和思路。

　　在這本書中引入了一個(gè)觀點(diǎn)叫“沒有銀彈”(No Silver Bullet),，「銀彈」就是指白銀做的子彈,，在歐洲民間傳說中，銀色子彈往往被描繪成具有驅(qū)魔功效的武器,，是針對狼人等超自然怪物的特效武器,。在《人月神話》中“沒有銀彈”的意思是：沒有任何技術(shù)或管理上的解決方案，能夠獨(dú)立地許諾十年內(nèi)使軟件系統(tǒng)項(xiàng)目生產(chǎn)率,、 可靠性或簡潔性獲得數(shù)量級上的進(jìn)步,。簡單來說就是沒有萬能方案。

　　人類從古到今一直都在各種問題中尋找一個(gè)萬能方案,，比如永動(dòng)機(jī)，最初起源于1200年前的印度,，經(jīng)伊斯蘭世界傳入西方,，過去幾百年引得幾代人苦苦研究，連跨界小能手達(dá)芬奇也摻和了一腳,?？涩F(xiàn)實(shí)告訴我們，沒有一勞永逸解決問題的方法,，還是要靠人類的智慧對具體問題做具體分析,。

　　那么在負(fù)載均衡領(lǐng)域中也有銀彈嗎?當(dāng)然是沒有的，否則Ribbon只提供一個(gè)萬能負(fù)載均衡策略就好了,。那針對具體業(yè)務(wù)我們都有哪些需要注意的呢?且聽我一一道來,。

　　Retry - 有多少愛可以重來

　　正所謂有的愛一旦過去就過去了,，有些人你永遠(yuǎn)不必等。比如說,，我們開發(fā)了一個(gè)庫存補(bǔ)貨接口,，每次調(diào)用后就自動(dòng)補(bǔ)貨上架100個(gè)商品。假如這個(gè)接口發(fā)生了超時(shí),，調(diào)用方收到timeout異常,，但實(shí)際上庫存服務(wù)在后臺(tái)還在執(zhí)行，只不過最終結(jié)果無法通知到調(diào)用方,。也就是說實(shí)際補(bǔ)貨成功,，但調(diào)用方那邊卻超時(shí)了。

　　在上面這種情況下,，如果一次次不停重試,，可能你馬上就要爆倉了。之所以類似的服務(wù)不能進(jìn)行retry的原因,，在于接口沒有實(shí)現(xiàn)冪等性,。

　　番外篇 - 關(guān)于冪等性

　　剛工作不久的時(shí)候，有次晚上加班和老大討論技術(shù)需求,，他對我說：“你需要冪等”,，我以為他要我「瞇瞪」一會(huì)兒，讓我補(bǔ)一覺再回來,，我應(yīng)了一聲起身就走,。然后，然后就是覺沒補(bǔ)成,，倒被叫住補(bǔ)了一腳,。從那以后我就學(xué)會(huì)了什么是冪等性。

　　冪等性往往針對的是執(zhí)行“update”操作的接口,，也就是常說的“寫”操作,。簡單理解就是對一個(gè)具備冪等性的接口進(jìn)行一次請求調(diào)用，和多次請求調(diào)用(每次調(diào)用的參數(shù)也相同),，在執(zhí)行結(jié)果上沒有區(qū)別,，接口并不會(huì)因?yàn)槎嗾{(diào)用了幾次就產(chǎn)生不同結(jié)果。因此就需要從業(yè)務(wù)層面和代碼層面做資源檢查或鎖定,，來保證冪等性,，這也是目前常用的分布式事務(wù)TCC方案的核心知識點(diǎn)。

　　用時(shí)間換空間?

　　在魔都買房子就得采取“用時(shí)間換空間”的策略,，甭管老破小先上車再說,，過個(gè)幾年再換個(gè)大house。在Ribbon這里,，時(shí)間和空間經(jīng)常要被換來換去,，時(shí)間代表著接口響應(yīng)時(shí)間(下文簡稱RT：Response Time),，空間表示服務(wù)器的可用連接數(shù)。

　　在Ribbon里有兩個(gè)和時(shí)間與空間密切相關(guān)的負(fù)載均衡策略,，BestAvailableRule(簡稱BA)和WeightedResponseTimeRule(簡稱WRT),。他們都有同一個(gè)夢想，那就是希望世界和平,，那就是選擇壓力較小的服務(wù)節(jié)點(diǎn),，但這兩個(gè)策略努力的方向不同。BA會(huì)根據(jù)服務(wù)節(jié)點(diǎn)過去一段時(shí)間的請求數(shù),，選擇并發(fā)量最小的機(jī)器(選擇空間);WRT則是根據(jù)響應(yīng)時(shí)間的統(tǒng)計(jì)結(jié)果,，選擇響應(yīng)時(shí)間最快的服務(wù)(選擇時(shí)間)。

　　我們知道服務(wù)的RT受很多因素制約,，服務(wù)本身響應(yīng)時(shí)間,，網(wǎng)絡(luò)連接時(shí)間，容器狀態(tài)甚至JVM的full GC等等都會(huì)影響最終的RT,。我們來設(shè)想這樣一個(gè)場景,，現(xiàn)在有一個(gè)非常輕量級的微服務(wù)，他的業(yè)務(wù)代碼耗時(shí)大概在2ms范圍內(nèi),，只占整個(gè)接口響應(yīng)時(shí)間的20%,，而剩下80%基本都用在了網(wǎng)絡(luò)連接的開銷上。

　　在上面這個(gè)例子中,，如果我們以RT作為指標(biāo),，其實(shí)并不能客觀獲取服務(wù)節(jié)點(diǎn)當(dāng)前的性能數(shù)據(jù)，因?yàn)榻涌诒旧淼奶幚頃r(shí)間在RT分布中只占有很小的比例,，甚至短時(shí)間的網(wǎng)絡(luò)抖動(dòng)都會(huì)對RT采樣造成很大影響,。而由于接口響應(yīng)時(shí)間較短，因此性能瓶頸更容易被連接線程數(shù)卡住,。線程數(shù)量達(dá)到上限會(huì)延長新請求的等待時(shí)間,，從而增加RT，但這種情況下active的線程數(shù)量有更靈敏的指示作用,，因?yàn)榈鹊絉T顯著增加的時(shí)候,，線程池可能早已被吃滿了。對待這類問題,，我們的實(shí)踐經(jīng)驗(yàn)是：

　　連接數(shù)敏感模型 對響應(yīng)時(shí)間較短，或RT和業(yè)務(wù)復(fù)雜度是非線性相關(guān)關(guān)系的接口,，采用基于可用連接數(shù)的負(fù)載均衡策略更加合適

　　同樣的,，假設(shè)某個(gè)接口比較重量級，接口的處理時(shí)間與接收到的參數(shù)強(qiáng)相關(guān),。打個(gè)比方,，訂單導(dǎo)出服務(wù),，如果發(fā)起10個(gè)請求，每個(gè)請求都需要導(dǎo)出當(dāng)前用戶過去一整年的訂單數(shù)據(jù),，那么這10個(gè)請求都會(huì)耗費(fèi)大量的系統(tǒng)資源(CPU,，內(nèi)存)參與業(yè)務(wù)，同時(shí)RT時(shí)間也會(huì)相應(yīng)拉長,。在另一臺(tái)機(jī)子上,，同樣是10個(gè)請求，但是只需要導(dǎo)出1個(gè)月的數(shù)據(jù),，相比較第一臺(tái)機(jī)器,，連接數(shù)相等的情況下，系統(tǒng)資源的占用率卻大大不同,。在這樣的場景下,，基于RT的指標(biāo)具有更高的敏感度，我們的實(shí)踐經(jīng)驗(yàn)是：

　　RT敏感模型 對重量級接口,，尤其是根據(jù)參數(shù)不同會(huì)導(dǎo)致系統(tǒng)資源使用率浮動(dòng)較大的接口(RT與業(yè)務(wù)復(fù)雜度線性相關(guān))，建議采用基于響應(yīng)時(shí)間的負(fù)載均衡策略,。

　　當(dāng)斷則斷

　　假如集成了Hystrix熔斷器,，而當(dāng)前服務(wù)正處于熔斷狀態(tài)，你還想往火坑里跳嗎?這時(shí)我們就需要根據(jù)熔斷狀態(tài)做過濾,，使用AvailabilityFilteringRule便是極好的,。

　　I Don’t Care

　　那還說啥，默認(rèn)負(fù)載均衡策略走起不就不行了,。Who cares.

　　小結(jié)

　　在這里想跟大家分享一個(gè)學(xué)習(xí)的經(jīng)驗(yàn),。我們學(xué)習(xí)技術(shù)，不是簡單的記憶+堆砌知識點(diǎn),，更重要的是建立在自己理解之上的進(jìn)一步思考,。比如課程前面提到的7種負(fù)載均衡策略，如果沒有進(jìn)一步的思考理解,，你對Ribbon的理解就會(huì)停留在“Ribbon有7種策略,，他們分別是xxxx”這種表面知識之上。技術(shù)只是工具,，工具就是為了解決問題,，我們要多思考幾個(gè)“為什么”，比如“為什么Ribbon的負(fù)載均衡策略側(cè)重不同,，他們都可以解決哪類問題?”,。提煉知識，多思考，幾年之后,，你就會(huì)發(fā)現(xiàn)與自己周圍的人拉開了很大的差距,。