1. RPC framework
RPC framework In the microservice platform, the service call between microservices will inevitably encounter a problem, which RPC framework should be selected? Today we invite three RPC frameworks to conduct a beauty contest to see who is more suitable for inter-service calls in the microservice platform.
Dubbo! The biggest feature of Alibaba's open-source distributed service framework is that it is structured in a layered manner, which can decouple (or maximize loose coupling) between layers.
Motan! I am a high-performance, easy-to-use distributed remote service call (RPC) framework open sourced by Weibo.
gRPC! I am a set of high-performance, general-purpose remote invocation frameworks designed by Google for mobile and HTTP/2.
2. Configuration of RPC framework
Configuration method
Motan: I support Xml configuration and Spring annotation configuration.
Dubbo: I support Xml configuration, annotation configuration, attribute configuration, API configuration!
gRPC: Me, I only support API configuration.
Xml configuration is to use xml files to configure protocols, services, registry and other information, which is the most common configuration method of rpc framework, and it is also the most basic;
Property configuration is to use properties file to configure protocol, service, registry and other information, which is similar to Xml configuration;
The annotation configuration is to declare that Annotation is used to specify the package name that needs to be parsed, and use spring-boot to start the service, which is what many RPCs pursue, which simplifies the writing of our code, and Maton only started to support it in the latest version;
API configuration is Dubbo's API configuration only for OpenAPI, ESB, Test, Mock and other system integration. API properties and configuration items are one-to-one.
service communication protocol
Motan: I support Motan protocol, use tcp long connection mode, based on netty communication.
Dubbo: I support Dubbo protocol, Rmi protocol, Hessian protocol, HTTP protocol, WebService protocol, Dubbo Thrift protocol, Memcached protocol!
gRPC: I, I support HTTP/2.0 protocol, based on Netty4.1.3 communication.
Serialization
Motan: I use hessian2 which is more friendly to java for serialization by default, and also supports Json format.
Dubbo: The default serialization of the Dubbo protocol is hessian2, the default of the rmi protocol is java, and the default of the http protocol is json!
gRPC: Humph! When it comes to serialization, I am unique! I use ProtoBuf to define services!
Moderator: ProtoBuf used by gRPC is a data serialization protocol developed by Google. Users use .proto files to define services and support to define multiple types of method parameters. ProtoBuf can serialize data and is widely used in data storage, communication protocols, etc. However, currently gRPC only supports Protobuf and does not support use in browsers. However, since gRPC is designed to support multiple data formats, it is easy to implement support for other data formats (such as XML, JSON, etc.). This is my powerful IDL feature!
load balancing
Motan: I support ActiveWeight, Random, RoundRobin, LocalFirst, Consistent, ConfigurableWeight
Dubbo: I can support Random, RoundRobin, ConsistentHash, LeastActive.
gRPC: Me, I provide a mechanism for pluggable load balancers.
ActiveWeight / LeastActive : Low concurrency is preferred. The smaller the number of calls of the referer at a certain moment, the higher the priority.
Random : Random, set random probability by weight. The probability of collision on a section is high, but the larger the number of calls, the more uniform the distribution, and the more uniform the weights are used according to the probability, which is conducive to dynamically adjusting the provider weights.
RoundRobin: Round Robin, set the round robin ratio according to the weight after the convention. There is a problem of slow providers accumulating requests. For example, the second machine is very slow, but it does not hang. When the request is transferred to the second machine, it is stuck there. Over time, all requests are stuck on the second machine.
LocalFirst : Local service priority acquisition strategy.
Consistent: Consistent Hash, requests with the same parameters are always sent to the same provider. When a certain provider hangs, the request originally sent to the provider will be spread to other providers based on virtual nodes, and will not cause drastic changes.
ConfigurableWeight : Weight configurable load balancing strategy.
fault tolerance
Motan: I support Failover failover, Failfast fail fast.
Dubbo: I support Failover, Failfast, Failsafe, Failback, Forking, Broadcast.
gRPC: Me, I have a failover failover strategy.
Failover: Automatically switch on failure. When a failure occurs, retry other servers. Typically used for read operations, but retries incur longer delays.
Failfast: fail fast, only one call is made, and an error is reported immediately upon failure. Usually used for non-idempotent write operations, such as adding new records.
Failsafe: failsafe, when an exception occurs, ignore it directly. Typically used for operations such as writing to the audit log.
Failback: Automatically recover from failure, record the failed request in the background, and resend it regularly. Typically used for message notification operations.
Forking: Call multiple servers in parallel, and return as long as one succeeds. It is usually used for read operations with high real-time requirements, but it needs to waste more service resources.
Broadcast : Broadcast calls all providers, call them one by one, and reports an error if any one reports an error. Typically used to notify all providers to update local resource information such as caches or logs.
Registry and Service Discovery
Motan: I support using Consul as the registry, Zookeeper as the registry, and point-to-point direct connection.
Dubbo: I support using Zookeeper as a registry, using a Redis registry, using a Multicast registry, and using a Simple registry.
gRPC: I, I can only let users extend the registry themselves.
performance
Motan: In high concurrency and high load scenarios, my average TPS and average response time are still good, and I have high availability in high stress scenarios.
Dubbo: Compared with Dubbo1.0 (which uses hessian2 serialization by default), Dubbo2.0 has improved performance. If you have higher performance requirements, you can use dubbo serialization, which is when dealing with complex objects. The design purpose of Dubbo is to meet the rpc calls with high concurrency and small data volume. The performance under large data volume is not good. It is recommended to use rmi or http protocol.
gRPC: I use the ProtoBuf serialization protocol. Compared with the performance of ProtoBuf and other protocols, it is very obvious that ProtoBuf is far superior to others.
3. The talent competition of RPC framework
Motan: Through spring configuration integration, it can provide distributed invocation capabilities for services without additional coding. No xml configuration files are required at all. Dubbo's annotation configuration also needs to be matched with xml files.
Dubbo: In terms of the supported registry and fault tolerance mechanism, Dubbo has a greater advantage!
Motan: I obviously support load balancing mode more. I have advanced service scheduling capabilities such as custom dynamic load balancing and cross-machine room traffic adjustment.
Dubbo: Can I, with a higher maturity, be worse than you in terms of robustness and scalability? Let me give an example. Speaking of robustness, the failure of the monitoring center does not affect the use, but only loses part of the sampled data; after the database is down, the registry can still provide service list queries through the cache, but cannot register new services; the peer-to-peer cluster of the registry, any one After it goes down, it will automatically switch to another one; after all the registration centers go down, the service provider and the service consumer can still communicate through the local cache; the service provider is stateless, and it will not affect the use after any one goes down; After all the service providers are down, the service consumer applications will be unavailable, and will reconnect indefinitely to wait for the service provider to recover. As for scalability, the registry is a peer-to-peer cluster, which can dynamically add machine deployment instances, and all clients will automatically discover the new registry; the service provider is stateless, and can dynamically add machine deployment instances, and the registry will push new service providers information to consumers.
Motan: Yes, I may not be so comprehensive in terms of functions, but I pay more attention to simplicity, ease of use, and use in high-concurrency and high-availability scenarios. Service discovery flexibly supports a variety of configuration management components, high availability strategy optimization based on high concurrency and high load scenarios, good SPI (Service Provider Interface) expansion, detailed call statistics, and flexible support for multiple RPC transmission protocols.
Dubbo: Having said all that, can you support generic calls? I can! Dubbo provides the GenericService generic calling interface, which makes the user's call more flexible.
Motan: My project dependencies only involve the core 5 modules, and they can be depended on as needed. Look at your piles of projects, tsk tsk...
gRPC: Humph! This baby supports cross-language invocation of services. Currently, the supported language types include C++, JAVA, GO, Python, Ruby, Node.js, Android, C#, PHP, and Objective-C. Can you?
Motan: Well, yeah, we can't, but do you have a service discovery mechanism?
Dubbo: And your load balancing and fault tolerance are too weak...
gRPC: hum hum...
4. The ultimate PK of the RPC framework
As an open source distributed service framework of Alibaba, Dubbo realizes high-performance RPC calls and provides rich management functions
Motan, as Weibo's Motan RPC, tends to be service-governed. Compared with the Dubbo series, its functions may not be as complete, and there are not so many expansion implementations. The high-performance, lightweight and easy-to-use RPC framework

gRPC was only open sourced as google in 2015. The cross-language invocation RPC framework focuses on cross-language invocation of services and can support language-independent invocation in most languages, which is very suitable for multi-language invocation scenarios. If you need an RPC framework that supports multi-language and cross-language calls, choose me!