作者：匿名用戶
鏈接：https://www.zhihu.com/question/39560697/answer/187538165
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

首先現在Netty/Grizzly/xio/Mina那么成熟，基于NIO框架寫個RPC通訊框架也不是那么復雜么。 其次Dubbo應該是定位為RPC框架， 在Remoting層支持netty，mina，http這些(見下圖)，個人覺的這樣得擴展性靈活性是中看不中用。

<img src="https://pic2.zhimg.com/v2-113e95a484a28836662e5d4b2ff9a8b1_b.png" data-rawwidth="845" data-rawheight="494" class="origin_image zh-lightbox-thumb" width="845" data-original="https://pic2.zhimg.com/v2-113e95a484a28836662e5d4b2ff9a8b1_r.png">

下面表述下個人的看法。

RPC層面不在于擴展性，而在于性能的高低，dubbo協議設計是比較重，無論是速度還是網絡包大小都是比較高的。

SOA/微服務的服務框架除了RPC最基礎的能力外， 最重要最復雜的是為線上運維升級提供便利（也就是基礎服務組件應該與容器集成，同時與業務代碼的發布升級做獨立），同時為開發提供隔離能力(如果沒有解決過類沖突問題的開發可能很難體會到這一點)。

最后說一重要的點。能夠設計研發支持10w/100w級別的服務地址中心是有點技術挑戰， 無論是zk還是dubbo提供的registry都只能支持千級別的長連接。 在阿里要面向10w級以上的長連接地址管理是要慎重選擇，選擇經得起考驗的服務注冊中心。

如果是體量沒有阿里這么大，在運維或者性能或者地址服務上要求沒那么高，dubbo是最好的選擇。當然一定要安利企業級分布式應用服務 EDAS產品，具備高性能和穩定的服務節點支持，同時也支持dubbo的使用方式。

針對上面吐槽HSF的一回答，沒有一個又很“輕”，又能滿足在架構和運維治理上都爽的“銀彈”。如果你用過SOFA，那會更加重。我是用了兩年SOFA，作為過來人，開始用時吐槽；但用久了，真的會發現其用心良苦。

轉載于:https://www.cnblogs.com/ceshi2016/p/7198163.html

總結

以上是生活随笔為你收集整理的阿里巴巴为什么主推HSF?比Dubbo有哪些优势?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。