天天看點

Java微服務RPC選型Dubbo還是SpringCloud?(下)總結

1.2.2 Thrift

最初是由Facebook開發的内部系統跨語言的RPC架構,2007年貢獻給了Apache。輕量級的跨語言RPC通信方案,支援多達25種程式設計語言。為了支援多種語言,跟gRPC一樣,Thrift也有一套自己的接口定義語言IDL,可以通過代碼生成器,生成各種程式設計語言的Client端和Server端的SDK代碼,這樣就保證了不同語言之間可以互相通信。

架構

Java微服務RPC選型Dubbo還是SpringCloud?(下)總結

特性

  • 序列化格式

    Binary、Compact、JSON、Multiplexed等。

  • 通信方式

    Socket、Framed、File、Memory、zlib等。

  • 服務端支援多種處理方式

    Simple 、Thread Pool、Non-Blocking等。

選型

那麼涉及跨語言的服務調用場景,到底該選擇gRPC還是Thrift呢?

從成熟度上來講,Thrift因為誕生的時間要早于gRPC,是以使用的範圍要高于gRPC,在HBase、Hadoop、Scribe、Cassandra等許多開源元件中都得到了廣泛地應用。而且Thrift支援多達25種語言,這要比gRPC支援的語言更多,是以如果遇到gRPC不支援的語言場景下,選擇Thrift更合适。

但gRPC作為後起之秀,因為采用了HTTP/2作為通信協定、ProtoBuf作為資料序列化格式,在移動端裝置的應用以及對傳輸帶寬比較敏感的場景下具有很大的優勢,而且開發文檔豐富,根據ProtoBuf檔案生成的代碼要比Thrift更簡潔一些,從使用難易程度上更占優勢,是以如果使用的語言平台gRPC支援的話,建議還是采用gRPC比較好。

總結

Java微服務RPC選型Dubbo還是SpringCloud?(下)總結

是以若你的業務場景僅一種語言,可選擇跟語言綁定的RPC架構

如果涉及多個語言平台之間的互相調用,必須選擇跨語言平台的RPC架構。

支援多語言是RPC架構未來的發展趨勢。正是基于此判斷,各個RPC架構都提供了Sidecar元件來支援多語言平台之間的RPC調用。

Dubbo也引入Sidecar元件來建構Dubbo Mesh提供多語言支援,如 dubbo-go。

Motan也開源了其内部的Sidecar元件:Motan-go,目前支援PHP、Java語言之間的互相調用。

Spring Cloud也提供了Sidecar元件spring-cloud-netflix-sideca,可以讓其他語言也可以使用Spring Cloud的元件。

是以語言不會成為使用上面這幾種RPC架構的限制,而gRPC和Thrift雖然支援跨語言的RPC調用,但是因為它們隻提供了最基本的RPC架構功能,缺乏一系列配套的服務化元件和服務治理功能的支撐,是以使用它們作為跨語言調用的RPC架構,就需要自己考慮注冊中心、熔斷、限流、監控、分布式追蹤等功能的實作,不過好在大多數功能都有開源實作,可以直接采用。