1.dubbo一個提供方和一個消費方，默認使用單一長連接
如果消費方調用提供方其中一個服務比較慢，則會造成其它服務緩慢，解決辦法是設置多個連接。
但連接數過多也會造成服務端連接暴滿的問題，需要根據實際情況設置。
全局設置：
<dubbo:protocol name="dubbo" connections="2" />
單個服務設置：
<dubbo:service connections=”2”>或<dubbo:reference connections=”2”>表示該服務使用獨立兩條長連接。
2.事件分發模式
Dispatcher
all 所有消息都派發到線程池，包括請求，響應，連接事件，斷開事件，心跳等。
direct 所有消息都不派發到線程池，全部在IO線程上直接執行。
message 只有請求響應消息派發到線程池，其它連接斷開事件，心跳等消息，直接在IO線程上執行。
<dubbo:protocol name="dubbo" port="20880" dispatcher="all" threadpool="fixed" threads="100" />
3.服務提供方，儘量與服務消費方在同一局域網
spring cloud提供調用優先級。優先調用同機房服務，沒有則調用同一個城市服務。
4.超時時間設置
根據不同業務設置超時時間，有些後臺任務，需要設置長點。默認超時時間爲6秒。
面向用戶的服務，超時時間不能過長，如果這個服務出現問題，會導致雪崩。
5.讀服務可以重試，寫服務一般不建議重試
6.設置處理線程池的大小和類型
<dubbo:protocol name="dubbo" port="${dubbo.protocol.port}" server="netty" client="netty" serialization="dubbo" charset="UTF-8" threadpool="fixed" threads="500" queues="0" buffer="8192" accepts="0"
payload="8388608"
iothreads=“9” />
默認線程池核心線程數爲：200,最大線程數爲200,queue爲SyncronouseQueue。
考慮下，如果出現請求200個處理線程都不夠，再來一個請求會發生什麼情況？
底層會拋一個RejectedExecutionException，使用的是dubbo自己的拒絕策略：AbortPolicyWithReport。
這裏最好不要設置queues。
如果設置了，因爲在請求比較多時，如果服務提供方處理不過來，會將請求存儲在queue，但因爲是先進先出，所以之前早點的請求會被先處理，處理完後由於有dubbo超時時間這批請求實際是無效的。
接着導致之後新的請求就算服務已經恢復正常速度，由於還要先處理之前舊的請求導致這批請求都無效。
初始化代碼：
public Executor getExecutor(URL url) {
String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);
int threads = url.getParameter(Constants.THREADS_KEY, Constants.DEFAULT_THREADS);
int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);
return new ThreadPoolExecutor(threads, threads, 0, TimeUnit.MILLISECONDS,
queues == 0 ? new SynchronousQueue<Runnable>() :
(queues < 0 ? new LinkedBlockingQueue<Runnable>()
: new LinkedBlockingQueue<Runnable>(queues)),
new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
}
7.dubbo調用鏈監控
使用開源的cat，pinpoint或自研。
8.現在dubbo用的是netty3，nett4之後做了很多優化，其中包括緩存池的利用可以提升不少性能。
期望dubbo之後能有升級。
9.dubbo限流
針對某個接口做限流
服務消費方：
<dubbo:reference>connections
防止服務提供方接收過多連接：
<dubbo:protocolname="dubbo"accepts="1000"/>
10.請求響應數據大小限制
<dubbo:protocal> payload
默認8M
不要傳送大包
11.業務的熔斷降級
dubbo默認不提供，可以使用hystrix去做
12.服務提供方及消費者限制調用某個服務的併發數
//限制服務端，這個服務可以同時併發的線程數
<dubbo:service interface="com.foo.BarService" executes="10" />
//限制服務端，這個服務可以同時存在的連接數
<dubbo:service interface="com.foo.BarService" actives="10" />
<dubbo:reference interface="com.foo.BarService" actives="10" />
13.dubbo本身上層有心跳，底層還設置了tcp的keepAlive
這樣做的原因可能是擔心dubbo線程池無可用線程用於心跳檢測，導致服務端連接不釋放。
14.服務不能拆的太細
原因：
1.在組裝某個業務結果時，涉及遠程調用太多
2.服務方過多，消費方建立的socket也會比較多。