Dubbo, Dubbox, Motan, thrift, GRPC, etc. RPC framework comparison and selection-Service of service-practical

Overview

The previous time project will be serviced, so I compare the pros and cons of some of the most popular RPC frameworks and the usage scenarios, and ultimately choose to use Dubbox as the RPC Basic service framework combined with the actual situation of the project itself. The following is a brief introduction to RPC Framework technology selection process. RPC Overview

This series of articles will describe the following Helloword examples of RPC framework and its implementation principles, because each RPC framework of the principle of different and more complex, if you want to further study also please go to the official website or other technical blog to learn.
RPC Framework Responsibilities
The RPC framework masks various complexities to the calling Fang and shields the service providers from all kinds of complexity: The caller feels like a local function. Service provider feels like implementing a local function to implement a service

RPC Framework is the primary basic component of Architecture (micro) service, which can greatly reduce the cost of architecture micro-service, improve the efficiency of the caller and service provider, and mask the complex details of calling functions (services) across processes.
The responsibility of the RPC framework is to make the caller feel like calling a local function, calling the remote function, and making the service provider feel like implementing a local function to implement the service

For those who are not very understanding of the service, you can look at these two articles:
Evolution and practice of service architecture
Talking about the service structure

The benefits of service
Why does the Internet architecture need to be serviced? Split principle of service architecture

Service Split principle: vertically and horizontally split around business functions. Size granularity is a difficult problem and is the focus of team debate. Bad practice is measured by the amount of code, such as within 500 lines. The smaller the granularity of the split, the better, for example, with the operation granularity of a single resource as the dividing principle. Recommended Principles of functional integrity, and responsibility of the single. The granularity is moderate and the team is acceptable. Iterative evolution, not overnight. Version compatibility of APIs is preferred.

The amount of code can not be used as a measure of the reasonableness of the micro-service division, because we know the same service, the complexity of the function itself, the amount of code is different. It is also important to emphasize that in the beginning of the project, do not expect the division of micro-services to be accomplished overnight.
The evolution of a micro-service architecture should be a step-by-step process. In a company, a project team, it also requires a step-by-step process of evolution. It doesn't matter if you start out badly. When it comes to a stage where the cost of deployment, testing, and operation of a micro-service is very low, this is a good micro-service for your team. The development principle of service architecture

The development of micro-service will also face the problem of dependency lag. For example: A To do an ID number checksum, relying on service provider B. Because B to check the identity card number of service development priority row is relatively low, can not meet the delivery point of time. A will face either waiting, or implementing an ID number check function.

Before the monomer architecture, what people need, often like what they write, this is actually not too serious dependency problem. But in the era of micro-service, micro-service is a team or a team to provide, this time there must be no way at a certain time to provide all the services, "demand implementation lag" is inevitable.

A good Practice strategy is interface first, language neutrality, service providers and consumers decoupling, parallel development, improve capacity. Regardless of the number of services, the first need to identify and define the interface, and then the two sides based on interface for contract-driven development, the use of mock service providers and consumers, mutual decoupling, parallel development, to achieve dependency decoupling.

Using contract-driven development, if the demand is not stable or constantly changing, it will face a frequent change of interface contract problem. For service providers, it is not possible to delay external interfaces because of concerns about interface changes, but to embrace change rather than complaining and resisting. To solve this problem, a better practice is management + technology two-pronged: Allow interface changes, but the frequency of changes to be strictly controlled. Provides full online API documentation services, such as the swagger UI, to turn offline API documentation into online, interactive API documentation services. The proactive notification mechanism for API changes to allow all consumers consuming the API to be aware of changes in the API in a timely manner. Contract-driven testing for regression testing of compatibility. Testing Principles for service architecture

Micro-service development needs to be tested after it is completed. Micro-service testing includes unit testing, interface testing, integration testing, and behavioral testing, the most important of which is contract testing:

Using the mock mechanism provided by the micro-service framework, the client test pile and the provider's service test pile can be generated respectively, and both sides can test the interface contract of the micro-service based on mock test pile, neither of them need to wait for each other's function code to develop and realize parallel development and test. Improve the efficiency of micro-service construction. Interface-based contract testing can also quickly detect incompatible interface changes, such as modifying field types, deleting fields, and so on. Deployment Principles for service architectures

After the test is complete, you need to automate the deployment of the Micro service. Deployment principles for Micro Services: Standalone deployment and lifecycle management, infrastructure automation. There is a need for a CI/CD-like assembly line for infrastructure automation, which can refer to Netflix's Open source micro-service continuous delivery pipeline spinnaker:

Finally, look at the operating container for the micro-service: micro-deployment can be deployed on dorker containers, PAAs platforms (VMS), or physical machines. Deploying micro services with Docker brings a number of priorities: a consistent environment, consistent online environments. Avoid reliance on a particular cloud infrastructure provider. Reduce the burden of the operational team. High performance near bare metal performance. Multiple tenants.

Compared to traditional physical machine deployments, micro services can be implemented by PAAs platform for micro-service automation deployment and lifecycle management. In addition to deployment and operational automation, the micro Services cloud can also fully enjoy more flexible resource scheduling: The elasticity and agility of the cloud. The dynamic nature of the cloud and resource isolation. Governance Principles for Service architecture

After the service is deployed online, the most important task is service governance. Micro-service Governance principles: online governance, real-time dynamic entry into force.
The common governance strategy of micro-service: Flow control: Dynamic and static flow control. Service demotion. Timeout control. Priority scheduling. Traffic migration. Call chain tracking and parsing. Service routing. Service on-line approval, the referral notice. SLA policy control. The micro-service governance model is shown below:

At the top is the UI interface for service governance, which provides an online, configured governance interface for operation and maintenance personnel to use. The SDK layer is a variety of interfaces that provide micro-service governance for service governance portal invocation. The bottom is the management of the micro-service cluster, cluster nodes will listen to the operation of service governance to do real-time refresh. For example, after modifying the flow control threshold, the Service governance service will brush the new flow control threshold to the service registry, and the service provider and consumer monitor the threshold change, get the new threshold and flush it into memory, and implement it in real time. Because the current service governance policy data volume is not particularly large, it is possible to put service governance data into the service registry (such as Etcd/zookeeper), and there is no need to do it alone. Service Best Practices

After introducing the implementation of micro-service, let's study the best practice of micro-service together.
Service route: Local short-circuit policy. Key technical points: priority calls to internal service providers for this JVM, followed by the same host or VM, and finally across network calls. The local short circuit can avoid the network overhead of remote call, reduce the delay of service call and improve the success rate. The principle is as follows:

Service invocation mode: Synchronous invocation, asynchronous invocation, parallel invocation. A service invocation, which usually means that a service call thread will be hung. With asynchronous invocation, you can avoid thread blocking and improve the throughput and reliability of the system. However, there are some drawbacks to the asynchronous invocation in the actual project, which makes the use not particularly extensive:
It is necessary to write asynchronous callback logic, which is inconsistent with traditional interface invocation and is difficult to develop.
Some scenarios require caching context information and introducing reliability issues.
Parallel invocation is applicable to multiple service invocations without context-dependent, logically parallel processing, similar to JDK's fork/join, parallel service invocation involves synchronous asynchronous, asynchronous synchronization, result aggregation and so on, technology implementation is difficult, many service frameworks are not supported at present. By using parallel service invocation, the traditional serial service invocation can be optimized into parallel processing, which can shorten the service call delay greatly.

Micro-Service Fault isolation: thread-level, process-level, container-level, VM-level, physical machine-level, etc. Key technical points: support services deployed to different thread/thread pools. Core Services and Non-core service isolation deployments. To prevent thread bloat, two thread pool policies are supported for sharing and exclusive.

When it comes to distribution, there's no problem with transactional consistency: most businesses can be solved by final consistency, and very few require strong consistency.

The specific strategy is as follows: Final consistency, which can be implemented based on message middleware. Strong consistency, using the TCC framework. The service framework itself does not provide "distributed transactions" directly, and often supports distributed transactions based on the actual need to move into the distributed transaction framework.

The performance of micro-services three elements: I/O model, this is usually a non blocking, Java inside may be native to Java. The thread scheduling model. Serialization mode.

Within the company, it is recommended to use asynchronous non-blocking I/O (Netty) + binary serialization (thrift compression binary) + reactor thread scheduling model for scenarios with high performance requirements.

Finally, we look at the interface of micro-service compatibility principle: technical support, management synergy. Develop and strictly implement the "micro-service forward compatibility Specification" to avoid incompatible modifications or unauthorized modification without notifying the surrounding situation. Interface Compatibility Technical Support: For example, thrift IDL supports new, modified, and Deleted fields, field-defined location-independent, code stream support chaos, and so on. Continuous delivery of daily build and contract driven testing of the pipeline enables rapid identification and discovery of incompatibilities. The current popular RPC framework: Service governance Type Dubbo Dubbox Motan GRPC Thrift Avro Protocol buffers (Google)

The image above is from Dubbo. Most of the service-management RPC frame structure is divided into service providers, service consumers, registration centers, monitoring and alarming center of several large modules. Service performance

In the service, or the micro-service process, the first consideration is the performance problem, because after the service, the following additional performance costs are added: The client needs to serialize the message, mainly CPU computing resources. Serialization requires the creation of binary arrays that consume either the JVM heap memory or the heap of memory. The client needs to send the serialized binary array to the server, consuming network bandwidth resources. After the service side reads to the code stream, the request datagram needs to be deserialized into the request object, consuming CPU computing resources. The service side invokes the service provider implementation class by reflection, and the reflection itself has a greater impact on performance. The service side serializes the response results and consumes CPU computing resources. The service side sends the response code stream to the client, consuming network bandwidth resources. The client reads the reply code stream, deserializes it into response messages, and consumes CPU resources. High performance design of RPC framework

To improve efficiency, in addition to hardware upgrade, the main consideration is the following three aspects: I/O scheduling model: Synchronous blocking I/O (BIO) or non-blocking I/O (NIO). Selection of the serialization framework: Text protocol, binary protocol, or compressed binary protocol. Thread scheduling model: Serial scheduling or parallel scheduling, lock competition or no lock algorithm.

Io Scheduling is now the mainstream of Netty.
The performance of High-performance serialization at present is the best ice,google PB protocol, FB thrift Protocol, etc.
Thread has nothing to say, certainly multithreading. Of course, it can be Akka (Java) Summary

To sum up, service is now the mainstream of large Internet companies architecture model, now there are more popular micro-services, Docker deployment and so on.

The individual recommends the adoption of Dubbox, integration of other protocols, and at the end of the series there are performance comparisons for each protocol.

The reason why we recommend the use of Dubbox is because, Dubbox has a perfect service governance model, including ZK registry, service monitoring, can be very convenient for our service.
Although Dubbo itself does not support multiple languages, we can integrate other serialization protocols, such as thrift, Avro, to support a variety of introductory languages, and make collaboration between departments more flexible

Of course, in the actual use of the process, especially the integration of other protocols in the process, it is necessary to have a more in-depth understanding of the protocol itself, in order to correctly use. Motan

Sina Weibo open source RPC framework

Helloword example directly to the official website to download the operation can

GitHub Address: Https://github.com/weibocom/motan
Document Address: Https://github.com/weibocom/motan/wiki/zh_quickstart
User's Guide; https://github.com/weibocom/motan/wiki/zh_userguide

# GRPC

Chinese official documents: GRPC official documents Chinese version

Helloword example, I was based on this article, wrote a very detailed: RPC framework of GRPC learning-Hello World

Grpc principle: GRPC Principle Analysis Dubbo

Dubbo has stopped maintenance upgrades with the end of 12, ignoring thrift

Please refer to another article I wrote: Thrift Learning Notes (i) Thrift Introduction and the first Helloword procedure Dubbox

Dubbox is a version of when the team is upgraded based on Dubbo. is a distributed service architecture that can be used directly in a production environment as an SOA service framework.
Dubbo Official website homepage: http://dubbo.io/above has the detailed user's guide and the Official document, introduces the more detailed, here no longer repeat.

When the official GitHub address: Https://github.com/dangdangdotcom/dubbox

Upgrade to Spring4. X (and other dependent components) version of the Dubbox GitHub
Address: Https://github.com/yjmyzz/dubbox.

Reference "blog: Under the Banyan tree under the article is very comprehensive, the introduction has been very detailed":
Dubbox upgrades spring to 4.x and adds LOG4J2 support
Example of getting started with distributed service Framework Dubbo/dubbox
Various management and supervision of Dubbox
Dubbo/dubbox adds native thrift and Avro support

# Each RPC framework performance comparison test environment

Jdk7
Win7 64-bit
Idea
Personal Notebook configuration:

Person object:

private int age;
private String name;
Private Boolean sex;
private int childrencount;

Test data, enter the parameter:

private int agestart;
private int ageend;

return value:

Person.personbuilder builder = Person.builder ();
list<person> list = new arraylist<person> ();
for (short i = 0; i < i++) {List.add (
    builder.age (i). Childrencount (i). Name ("Test" + i). Sex (True). Build ());} return
list;

Configurations used by each protocol test GRPC

RPC Getpersonlist (yjmyzz.grpc.study.dto.QueryParameter) returns (Yjmyzz.grpc.study.dto.PersonList) {} Motan

<motan:basicservice export= "demomotan:8002"
group= "Motan-demo-rpc" accesslog= "false" sharechannel= "true" module= "Motan-demo-rpc"
application= "Mymotandemo" registry= "Registry" id= "Servicebasicconfig"/> Dubbox

<dubbo:protocol name= "Dubbo" serialization= Kryo "optimizer=" Com.alibaba.dubbo.demo.SerializationOptimizerImpl "/>

<dubbo:service interface=" Com.alibaba.dubbo.demo.person.PersonService "ref=" personservice "protocol" = "Dubbo"/>

Thrift

Tnonblockingserver + Tframedtransport Test Results

Rgpc 100000 nettyserver calls, time: 53102 MS, average 1883 times / s [simple grpc]
Rgpc 100000 nettyserver calls, time: 52138 MS, 1917 times / s on average [simple grpc]
Rgpc 100000 nettyserver calls, time: 51800 MS, 1930 times / s on average [simple grpc]
Rgpc 100000 nettyserver calls, time: 51313 MS, average 1948 times / s [simple grpc]
Rgpc 100000 nettyserver calls, time: 56812 MS, average 1760 times / s [2016-10-08 19:17:31] Dubbo service server started! [dubbox. Kryo]
Rgpc 100000 nettyserver calls, time: 55133 MS, average 1813 times / s [2016-10-08 19:18:42] Dubbo service server started! [dubbox. Kryo]
Rgpc 100000 nettyserver calls, time: 52280 MS, 1912 times / s on average [2016-10-08 19:20:01] Dubbo service server started! [dubbox. Kryo]
Rgpc 100000 nettyserver calls, time: 44414 MS, 2251 times / s on average [2016-10-08 19:13:34] Dubbo service server started! [dubbox. FST]
Rgpc 100000 nettyserver calls, time: 44805 MS, 2231 times / s on average [2016-10-08 19:12:25] Dubbo service server started! [dubbox. FST]
Rgpc 100000 nettyserver calls, time: 46245 MS, average 2162 times / s [2016-10-08 19:14:43] Dubbo service server started! [dubbox. FST]
Rgpc 100000 nettyserver calls, time: 12203 MS, average 8194 times / s [2016-10-09 19:52:34] Dubbo service server started! [dubbox. Thrift]
Rgpc 100000 nettyserver calls, time: 14142 MS, average 7071 times / s [2016-10-09 19:30:17] Dubbo service server started! [dubbox. Thrift]
Rgpc 100000 nettyserver calls, time: 13762 MS, average 7266 times / s [2016-10-09 19:30:43] Dubbo service server started! [dubbox. Thrift]
Rgpc 100000 nettyserver calls, time: 44334ms, average 2255 times / s [Motan]
Rgpc 100000 nettyserver calls, time: 37844 MS, average 2642 times / s [Motan]
Rgpc 100000 nettyserver calls, time: 39007 MS, average 2563 times / s [Motan]
Rgpc 100000 nettyserver calls, time: 38610 MS, average 2590 times / s [Motan] 

Test result Description

Using your own laptop test, the way of testing may not be very professional, but can explain the problem. The
above results show that thrift has the best performance and is quite good.

Tests done by other people on the Internet

ICE-DUBBO-THRIFT-GRPC Performance Test Comparison
Performance comparison summary of RPC framework

The main factors that affect RPC performance are: Serialization performance IO performance threading mode

Serialization of words, it must be Google's PB protocol and thrift Best, IO and Thread, the first popular performance is better to use multi-threaded non-blocking io.

Grpc is Google production, the use of PB protocol, but because it appears relatively late, immature, and the use of HTTP protocol, is very suitable for today's micro-service, but the performance of a lot of poor, and like service management and monitoring need additional development work, so give up the GRPC.
Thrift and GRPC, the performance is superior, but the development difficulty compared to Dubbox and Motan is also a little higher, need to write proto files (in fact, this is not difficult for programmers). Like service governance and monitoring, additional development work is required.
Dubbo is older, just discard.
Dubbox and later Motan are better suited to our team. Dubbox later, when the development, introduced the rest-style HTTP protocol, and also support Kryo/fst/dubbo/thrift and other protocols, and other teams are also using Dubbo, integration convenience, service governance monitoring functions, so the final adoption of Dubbox.

In fact, I personally still like thrift, after all, sexual tender superior, in large distributed systems, even a little bit of performance improvement accumulated together is very considerable. However, the specific selection process will be combined with the current situation of the team and other team developers to accept the acceptance of the choice.