觸發(fā)要做服務(wù)化的主要原因會是這三個：
http://blog.sina.com.cn/s/blog_42a0e25b0102wfyv.html
- 底層例如數(shù)據(jù)庫連接到達(dá)上限
系統(tǒng)共用的底層資源在隨著機(jī)器增加的越來越多時，一定會成為瓶頸，這種情況下服務(wù)化會帶來幫助，當(dāng)系統(tǒng)邏輯變簡單的情況下，吞吐量自然也比較容易上升，這個時候使用底層資源的機(jī)器數(shù)自然可以大幅下降。
- 開發(fā)人員規(guī)模龐大
當(dāng)開發(fā)人員規(guī)模變大(100個左右)時，眾多人共同維護(hù)一個系統(tǒng)會變得不可行，這個時候服務(wù)化可以產(chǎn)生巨大幫助，也會成為必須做的事情。
- 業(yè)務(wù)多元化，共享的業(yè)務(wù)邏輯多
RPC VS 消息 同步 VS 異步
FeignClient 和 Ribbon重試區(qū)別與聯(lián)系：
原文：https://blog.csdn.net/woshilijiuyi/article/details/78959759
疑問：一個http請求，如果feign和ribbon都配置了重試機(jī)制，異常情況下一共會請求多少次？
經(jīng)過上面的分析，請求總次數(shù) n 為feignClient和ribbon配置參數(shù)的笛卡爾積：
n(請求總次數(shù))=feign(默認(rèn)5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)
注意：+1是代表ribbon本身默認(rèn)的請求。
其實(shí)二者的重試機(jī)制相互獨(dú)立，并無聯(lián)系。但是因為用了feign肯定會用到ribbon，所以feign的重試機(jī)制相對來說比較雞肋，自己feignClient的時候一般會關(guān)閉該功能。ribbon的重試機(jī)制默認(rèn)配置為0，也就是默認(rèn)是去除重試機(jī)制的，建議不要修改。如果配置不當(dāng)，會因為冪等請求帶來數(shù)據(jù)問題。所以建議關(guān)閉二者的重試功能。
如果開啟的話，建議合理配置Hystrix的超時時間，在一些沒必要的重試請求執(zhí)行時，根據(jù)Hystrix的超時時間，快速失敗，結(jié)束重試。
