Hi,

I'm very new to Dubbo but I'd like to share some ideas. I am playing around
trying to implement a simple monitor for Dubbo (this one
https://github.com/bitstorm/wicket-coreui). To start grasping what I have
to do I've looked at what dubbo-monitor-simple (
https://github.com/apache/incubator-dubbo-ops) already does. While the
overall mechanism is quite clear I find difficult working with the current
URL-based notification mechanism (I'm referring to interface
NotifyListener). Extracting informations from url is not trivial and I
think we might use a more complex and clear object for this task. In
particular is difficult to be notified if a consumer application has been
unregistered.

Hope this could be helpful for future improvements.

Thank you.

On Mon, Jul 9, 2018 at 9:32 AM, Liujie Qin <[email protected]> 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 ~
>



-- 
Andrea Del Bene.
Apache Wicket committer.

Reply via email to