最近在看dubbo的文件,有些內容結合自己的思考記錄一下
1. dubbo的本地存根能夠提公升效能
將與伺服器環境無關的**移到stub中，利用threadlocal本地快取，將校驗，容錯（容錯用mock更好，原理相似）等功能放在客戶端做，應該能提公升效能。這段**是服務端寫好的快取過去的，所以維護也方便。
2. 利用future實現非同步呼叫提公升效能
等待的時間為最長的那個遠端呼叫事件，並且在乙個執行緒中完成，避免了多執行緒切換的開銷和複雜性。
3. 利用injvm提公升本地jvm呼叫效能
4. callback沒看懂，我的理解應該是客戶端註冊了callback，服務端查詢到callback呼叫。並且服務端跟客戶端是長連線，服務端一旦有變動就會發起呼叫通知。
5. 如果spring載入報出wait to lock, 可能是dubbo服務過早暴露引起，設定
6. 提供有狀態服務
7. 配置參考手冊標明了配置的作用，如果要效能調優，可以找找效能調優的配置項
8. 配置快取檔案，可以快取註冊中心和服務提供者，重啟時從這個檔案恢復。當註冊中心宕機可以從快取獲取服務提供者列表。注意多個應用不要使用同乙個檔案。
9.從官網測測試報告看，大資料量呼叫採用http協議+json序列化好， 小資料量（1k或pojo）採用dubbo協議hassian序列化好（注意dubbo序列化為試用）。
10. 從其他的參考資料看dubbo協議+kryo序列化比hassian序列化要好。
關於Mesh中混合路由的思考（原創）
關於mesh 中混合路由的思考 yanjian 2006 10 17 802.11s草案提供了一種預設的路由機制hwmp hybrid wireless mesh protocol hwmp是一種混合的路由機制，它包括兩種路由方法 on demand routing和tree based routi...
Dubbo的一些思考
總覽 眾所周知，dubbo是乙個分布式rpc框架，主要解決服務間互相呼叫的問題。呼叫其實類似介面呼叫，如果想要呼叫不同伺服器上的介面可以使用http直接呼叫的方法，但是這種方法的開銷很大，並且不好處理遠端呼叫 現的各種問題 超時重試 負載均衡等等 也不方便監控服務端的存活情況，介面呼叫的次數等等。而...
原創 一塊抹布引發的關於測試策略的思考
一 其實，這篇文章最開始的標題是 如何用乙個抹布一次清理完乙個落滿灰塵的工位 讀來讀去覺得有點繞，寫到最後也發現，哇，這個抹布好慘呀，就把標題改為 一塊抹布引發的 又感覺有標題黨的嫌疑，最終就確定了目前這個標題。言歸正傳，不知道讀到這的同學裡面有沒有槓精，做測試的話，我相信肯定有，不管怎樣，我先解釋...