作者：匿名用戶
鏈接：https://www.zhihu.com/question/39560697/answer/187538165
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
鏈接：https://www.zhihu.com/question/39560697/answer/187538165
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
首先現在Netty/Grizzly/xio/Mina那么成熟，基於NIO框架寫個RPC通訊框架也不是那么復雜么。 其次Dubbo應該是定位為RPC框架， 在Remoting層支持netty，mina，http這些(見下圖)，個人覺的這樣得擴展性靈活性是中看不中用。
下面表述下個人的看法。
- RPC層面不在於擴展性，而在於性能的高低，dubbo協議設計是比較重，無論是速度還是網絡包大小都是比較高的。
- SOA/微服務的服務框架除了RPC最基礎的能力外， 最重要最復雜的是為線上運維升級提供便利（也就是基礎服務組件應該與容器集成，同時與業務代碼的發布升級做獨立），同時為開發提供隔離能力(如果沒有解決過類沖突問題的開發可能很難體會到這一點)。
- 最后說一重要的點。能夠設計研發支持10w/100w級別的服務地址中心是有點技術挑戰， 無論是zk還是dubbo提供的registry都只能支持千級別的長連接。 在阿里要面向10w級以上的長連接地址管理是要慎重選擇，選擇經得起考驗的服務注冊中心。
如果是體量沒有阿里這么大，在運維或者性能或者地址服務上要求沒那么高，dubbo是最好的選擇。當然一定要安利企業級分布式應用服務 EDAS產品，具備高性能和穩定的服務節點支持，同時也支持dubbo的使用方式。
針對上面吐槽HSF的一回答，沒有一個又很“輕”，又能滿足在架構和運維治理上都爽的“銀彈”。如果你用過SOFA，那會更加重。我是用了兩年SOFA，作為過來人，開始用時吐槽；但用久了，真的會發現其用心良苦。