Hi, On Mon, Jul 9, 2018 at 3:32 PM, Liujie Qin <liujie...@apache.org> wrote: > 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.
+1 to separate service registration data and service configuration data. > - 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. +1 to rewrite Dubbo using 1.8 > > 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 Strong +1 > - 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 If there were 3.x, we will have: * 2.5.x: Java 6+ * 2.6.x: Java 6+ * 2.7.x: Java 8+ * 3.0.x: Java 8+ What is the difference between 2.7.x and 3.0.x? > > 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. I suggest we note down all the incompatible changes and provide a migration guide for them. > > Comments welcome! > > thank you ~ -- Best Regards！ Huxing
