Dubbo RPC is the core high-performance, high-throughput remote calling method in the Dubbo system.
dubbo RPC is mainly used for remote calls between two dubbo systems, especially suitable for Internet scenarios with high concurrency and small data.
Serialization also plays a vital role in the response speed, throughput, network bandwidth consumption, etc. of remote calls.
- Specifically for the Java language: Kryo, FST, etc.
-
The performance of most of these serialization methods is significantly better than hessian2 (even including the immature dubbo serialization).
In view of this, we introduced two efficient Java serialization implementations, Kryo and FST, for dubbo to gradually replace hessian2.
-
In applications for production environments, I recommend Kryo to be preferred at the moment.
-
Enable Kryo and FST
Using Kryo and FST is very simple, just add an attribute in dubbo RPC's XML configuration:
<dubbo:protocol name="dubbo" serialization="kryo"/>
<dubbo:protocol name="dubbo" serialization="fst"/>
Register the serialized class
To allow Kryo and FST to fully utilize their high performance, it is best to register the classes that need to be serialized into the dubbo system. For example, we can implement the following callback interface:
public class SerializationOptimizerImpl implements SerializationOptimizer { public Collection<Class> getSerializableClasses() { List<Class> classes = new LinkedList<Class>(); classes.add(BidRequest.class); classes.add(BidResponse.class); classes.add(Device.class); classes.add(Geo.class); classes.add(Impression.class); classes.add(SeatBid.class); return classes; } }Then add in XML configuration:
<dubbo:protocol name="dubbo" serialization="kryo" optimizer="com.alibaba.dubbo.demo.SerializationOptimizerImpl"/>
After registering these classes, serialization performance may be greatly improved, especially for a small number of nested objects.
-
Of course, when serializing a class, there may be cascading references to many classes, such as Java collection classes. In response to this situation, we have automatically registered common classes in the JDK, so you do not need to register them again (of course it will have no effect if you register them repeatedly), including:
-
GregorianCalendar InvocationHandler BigDecimal BigInteger Pattern BitSet URI UUID HashMap ArrayList LinkedList HashSet TreeSet Hashtable Date Calendar ConcurrentHashMap SimpleDateFormat Vector BitSet StringBuffer StringBuilder Object Object[] String[] byte[] char[] int[] float[] double[]
Comparison of byte sizes generated by different serializations in Dubbo RPC
The size of the bytecode generated by serialization is a relatively deterministic indicator, which determines the network transmission time and bandwidth usage of remote calls.
The results for complex objects are as follows (the smaller the number, the better):
| Serialization implementation | Number of bytes requested | Response bytes |
|---|---|---|
| Kryo | 272 | 90 |
| FST | 288 | 96 |
| Dubbo Serialization | 430 | 186 |
| Hessian | 546 | 329 |
| FastJson | 461 | 218 |
| Json | 657 | 409 |
| Java Serialization | 963 | 630 |
Comparison of different serialization response times and throughput in Dubbo RPC
| Remote calling method | average response time | Average TPS (transactions per second) |
|---|---|---|
| REST: Jetty + JSON | 7.806 | 1280 |
| REST: Jetty + JSON + GZIP | ALL | ALL |
| REST: Jetty + XML | ALL | ALL |
| REST: Jetty + XML + GZIP | ALL | ALL |
| REST: Tomcat + JSON | 2.082 | 4796 |
| REST: Netty + JSON | 2.182 | 4576 |
| Dubbo: FST | 1.211 | 8244 |
| Dubbo: kyro | 1.182 | 8444 |
| Dubbo: dubbo serialization | 1.43 | 6982 |
| Dubbo: hessian2 | 1.49 | 6701 |
| Dubbo: fastjson | 1.572 | 6352 |
