Hi All, Dubbo has become a excellent RPC framework with the efforts of various partners in the community. However, in the process of development, we found some shortcomings of Dubbo 2.x, which is listed as follows:
- The maintainability is relatively poor. The code uses a lot of dynamically generated classes. It is difficult to understand and difficult to debug. The code hierarchy is not clear enough, and the calling logic is confusing. As an experienced Dubbo developer, sometimes it is difficult for me to sort out the calling process of Dubbo 2.x; the more developed, the more difficult it is to maintain, so it needs to be refactored in order to develop better. - Some extensions cannot meet current needs, such as service addresses push monitoring, performing Filter early interception requests before service addresses selection, printing the process of route selection, etc. - The underlying Dubbo 2.X is based on synchronous calls. The asynchronous call is wrapped synchronously. This introduces inaccuracies such as RT during asynchronous calls. - At present, the service metadata information and the address of the Dubbo service are coupled together. Most of the metadata is the same, and the metadata is redundant. At the same time, as the size of the machine increases, the Registry is under great pressure, especially when machine restart. - The service registry and the configuration center are coupled together, and after splitting, the management and storage of service governance rule data such as routing rules can be better handled. - The core is written based on JDK 1.6 and cannot use the newer JDK features. It is recommended to upgrade JDK to 1.8 and above. For the above reasons, in order to better develop Dubbo and attract more people to participate in the development of the Dubbo community, I propose to refactor the Dubbo 2.x code. The newly developed version number is Dubbo 3.x. Refactoring Dubbo 3.x will have the following advantages: - Refactoring core modules to make the code more concise and understandable - Refactoring the routing process, Making the route process to Pipeline style,Making the route process can be observed - Add new extension points to make it easier for developers to extend the framework - Add the Service Domain Model to enable developers to handle its lifecycle - Supports asynchronous interface, unified call process returns CompleteFuture, synchronous call process uses CompleteFuture wrapper; Solve the problem of inaccurate statistics such as RT during asynchronous call - Splitting out the Configuration Center and Registry for better control and support for larger clusters - Prepare for new features such as Http2 stream、Reactive stream - Performance improvement - And so on Of course, refactoring Dubbo 3.x also faces the following challenges: - A wide range of refactorings that can cause extension points to be incompatible - The Dubbo team may need to maintain two branches at the same time for a longer period of time For the following challenges, we can do this: - For major extension points, such as Fitler, etc., be sure to ensure compatibility and enable developers to smoothly upgrade - For some extension points, the Dubbo team will listen to the community and selectively fix compatibility issues with some extension points. Comments welcome! thank you ~
