One, foreword

What are the open source RPC frameworks?

One is tied to a particular language platform, and the other is language-independent that is, cross-language platform.

There are several open source RPC frameworks tied to the language platform.

  • Dubbo: The earliest open source RPC framework in China, developed by Alibaba and opened source at the end of 2011, only supporting Java language.
  • Motan: RPC framework for internal use of Weibo, opened source in 2016, only supports Java language.
  • Tars: RPC framework for internal use in Tencent, opened source in 2017, only supports C++ language.
  • Spring Cloud: An open source RPC framework developed by Pivotal in 2014, which supports only Java language
The open source RPC frameworks across language platforms mainly include the following.

  • GRPC: Google open source cross-language RPC framework in 2015, supporting multiple languages.
  • Thrift: A cross-language RPC framework for internal systems originally developed by Facebook. It was contributed to the Apache Foundation in 2007 as part of the Apache open source project and supports multiple languages.
If your business scenario is limited to just one language, you can choose one of the RPC frameworks tied to that language.

If mutual calls between multiple language platforms are involved, a cross-language RPC framework should be chosen.



What are the differences between RPC frameworks?

1. Dubbo

Let’s talk about Dubbo first. Dubbo can be said to be the earliest open source RPC framework in China. Currently, it only supports Java language.



As you can see from the figure, Dubbo’s architecture mainly consists of four roles: Consumer is the service Consumer, Provider is the service Provider, Registry is the Registry, and Monitor is the monitoring system.

The specific interaction process is that the Consumer side obtains the Provider node through the registry, establishes a connection with the Provider through the client SDK of Dubbo, and initiates the invocation. The Provider side receives the request from the Consumer through Dubbo’s server SDK, processes it, and returns the result to the Consumer.

2. Motan

Motan is another well-known open source RPC framework in China, which also supports only Java language implementation. Its architecture can be described in the following figure.



Motan and Dubbo have similar architectures, which require the introduction of SDK on the Client side (service consumer) and Server side (service provider). Motan framework mainly contains the following functional modules.

  • Register: Used to interact with the registry, including registration service, subscription service, service change notification, service heartbeat, and other functions.
  • Protocol: used to describe RPC services and configure and manage RPC services. Filters of different functions can be added at this layer to complete statistics and concurrency limitation.
  • Serialize: Serializes and deserializes parameters and results in RPC requests
  • Transport: used for remote communication. The default mode is Netty NIO TCP long link.
  • Cluster: The request selects an available Server for remote invocation based on different high availability and load balancing policies.

3. Tars

Tars is an open source project summarized by Tencent based on its internal practice of using micro-service architecture for many years. It only supports C++ language. Its architecture is shown as follows.



Tars architecture interaction mainly includes the following processes:

  • Service release process: Upload the server release package to patch in the Web system. After the upload is successful, submit the server release request on the Web, which is transmitted to Node by Registry service. Then the Node pulls the server release package to the local and pulls up the Server service.
  • Management command flow: The web system can submit the management server service command request, which is transmitted by Registry service to Node service, and then the Node sends the management command to server.
  • Heartbeat reporting process: After the server service is running, the server periodically reports heartbeat information to the Node. The Node then reports the heartbeat information to the Registry service for centralized management.
  • Information reporting process: After the server service is running, it periodically reports statistics to stat, prints remote logs to log, periodically reports property information to prop, reports exception information to notify, and pulls service configuration information from Config.
  • Process for a client to access a Server: The client can access the server indirectly through the object name Obj of the server. The client will pull the routing information (such as IP and Port information) of the server from Registry, and then according to the specific service characteristics (synchronous or asynchronous, Access the server through TCP or UDP (the client can also access the server through IP address or Port).

4. Spring Cloud

Spring Cloud integrates excellent components in the open source industry by using the Spring Boot feature, and provides a set of service governance solutions in the micro-service architecture.

Only the Java language platform is supported, and its architecture diagram can be described in the following diagram.





It can be seen that the Spring Cloud microservice architecture is composed of multiple components, and the interaction flow of each component is as follows.

  • Requests to access internal services through Zuul, the API gateway, are authenticated by Token.
  • After security certification, the gateway Zuul gets a list of available service nodes from the registry Eureka.
  • Select one of the available service nodes and distribute requests to that node.
  • During the whole request process, Hystrix component is responsible for handling service timeout fuse, Turbine component is responsible for monitoring calls and fuse-related indicators between services, Sleuth component is responsible for call chain monitoring, and ELK is responsible for log analysis.

5. gRPC

First look at gRPC, its principle is through IDL (Interface Definition Language) file to define the parameters and return value type of the service Interface, and then through the code generation program to generate the specific implementation code of the server and client, so in gRPC, A client application can call the corresponding method on another server as if it were a local object.



Its main features include three aspects.

  • The communication protocol uses HTTP/2, because HTTP/2 provides connection reuse, two-way flow, server push, request priority, header compression and other mechanisms
  • IDL uses ProtoBuf, a data serialization protocol developed by Google, with high compression and transmission efficiency and simple syntax
  • Multi-language support, which can automatically generate client and server codes of corresponding languages based on multiple languages.

6. Thrift

Thrift is a lightweight cross-language RPC communication scheme that supports up to 25 programming languages. Like gRPC, Thrift also has its own interface definition language IDL to support multiple languages. It can generate SDK codes on the Client and Server sides of various programming languages through code generators, thus ensuring that different languages can communicate with each other. Its architecture diagram can be described in the following figure.



You can see the characteristics of the Thrift RPC framework in this diagram.

  • Supports multiple serialization formats: Binary, Compact, JSON, Multiplexed, etc.
  • Supports multiple communication modes such as Socket, Framed, File, Memory, zlib, etc.
  • The server supports multiple processing modes, such as Simple, Thread Pool, and non-blocking.


I summed up a technical route about micro services, to share with you



Three, the last


Welcome everyone to exchange, like the article remember to click a “like” yo, thanks for your support!