有沒有人能對twitter的finagle和國內的dubbo做個對比？

01-21

如題

dubbo相對是較老而且沒有更新的框架了，本身在jdk 6時代非常成熟，代碼質量和設計也很好。

但是（起碼在介面層）對現在流行的非同步併發模式支持欠佳，其非同步調用僅僅支持了Java7的不成熟Future介面，無法compose，導致很難擺脫微服務中的"thread pool and callback hell"問題，而Finagle基於scala，對這些問題考慮較完善，如 Finagle Concurrent Programming with Futures。如果dubbo支持guava的ListenableFuture或java8的CompletableFuture，也能較好的解決這個問題。

上面兩個鏈接非常推薦仔細閱讀，但是關於Future Compose的問題可以簡單解釋如下：

Async Call - Dubbo 裡面給出的例子：

fooService.findFoo(fooId); Future& fooFuture = RpcContext.getContext().getFuture();


barService.findBar(barId);

Future& barFuture = RpcContext.getContext().getFuture(); 
// 此時findFoo和findBar的請求同時在執行，客戶端不需要啟動多線程來支持並行，而是藉助NIO的非阻塞完成。
Foo foo = fooFuture.get(); // 如果foo已返回，直接拿到返回值，否則線程wait住，等待foo返回後，線程會被notify喚醒。

Bar bar = barFuture.get(); // 同理等待bar返回。

// 如果foo需要5秒返回，bar需要6秒返回，實際只需等6秒，即可獲取到foo和bar，進行接下來的處理。

這樣確實節省了遠程調用的線程。

但很自然的，熟悉非同步編程的就會想，這段代碼最後還是在調用層阻塞了啊，後端某個服務慢一下或者網路波動，阻塞在這兒的線程可能就會大量增加，從而填滿了對應的線程池。

而這些Future 如果可以

CompletableFuture.allOf(List of Future).thenApply(lists -&> {...callback code ...} );

就可以不block，而是等待全部完成後，再執行callback code。

由於dubbo底層還是用了nio+非同步，所以改進是可能的。網上有個dubbo的fork kubbo/dubbo-async · GitHub，部分解決了這一點，但是似乎不太流行，不確定穩定度如何。

公司部分項目在用dubbo，當然也基於一部分歷史原因，就胡亂上了這套東西。最近也在了解finagle相關的RPC框架，讀了一些github的一些文檔。大致總結了下，本人膚淺認為兩者主要用以下幾點不同：

1. 架構上，因為dubbo主要使用ZK來進行服務治理以及請求dispatch，finagle則通過wrap一層控制邏輯來對RPC調用控制，如retry，fail錯誤鑒定，load balance策略, connection pool等等。可以看出，使用finagle稍顯笨重，同時服務狀態通過客戶端outgoing請求的結果得知。而使用ZK的dubbo，屏蔽了大量的複雜的服務node管理與探測，使客戶端實現更為輕量、透明。在系統需要水平擴展時，客戶端不會因此波及。

2. 定位上，dubbo更focus在服務治理以及對於後端業務網路topology的隱藏，更貼近SOA的思想。然而finagle將更多功夫用在制定統一的、協議無關的服務集成。因為finagle具備接入Thrift，Redis， Memcached，MySQL等協議的集成能力，用finagle來搭建大型系統內部微服務（Microservices）再合適不過。但是在服務治理上，dubbo明顯更勝一籌。

3. 實現上，dubbo選擇了使用綁定Spring框架。finagle的實現更為乾淨，基於Scala，幾乎無任何框架或者plugin的強依賴。

PS, Finagle實現的基於MUX的Thrift實現，可以對client到server端的有狀態訪問。相對而言，dubbo一般為無狀態訪問，對於已經發起的請求無法進行update或者cancel。

補充一篇blog，使用Finagle-ServerSet通過ZK來做服務治理的，個人感覺不是很好，還是不能使Client更輕量化。Finagle ServerSet Clusters using Zookeeper （可以用DNS拿來類比一下）

如有錯誤之處，歡迎指正，謝謝。

現狀：

目前開源的分散式服務框架也不少（參照開源中國），比較有代表性的包括Twitter的Finagle(基於Scala語言)，Flipkart(印度最大的B2C網站)的Phantom(文檔比較少)，Apache的Tuscany(比較老，不適合互聯網公司)等等。

Dubbo優勢：

其實國內也有少數開源了Java服務框架，但dubbo在其功能完善性、架構優雅性，使用簡便（官文提供了完善的文檔）等方面有相對獨特的優勢。

還有一個最大的優勢是，現在阿里巴巴SOA服務治理的核心方案就是DUBBO。每天為2000+多個服務提供著30億+次的訪問，如果你還發愁服務治理，如果你還在選型，我覺得你都不用猶豫了。

參照：

DUBBO by dubbo

試試 TCP 介面服務框架 - C# 高性能自動化服務端框架 - 凹凸架構，直接面向函數的調用模式（僅支持C#）。