Dubbo is an excellent RPC framework, but it does need keep evolving. I think this proposal sends one strong message to the community that we are actively thinking in Dubbo's future in order to make it better.
Community, pls. share your thoughts on this proposal as soon as possible and as much as possible. Thanks, -Ian. 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. > - 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 ~ >
