What I am thinking about the next generation of Dubbo should be: - cloud native: should be well integrated into Kubernetes, and Dubbo protocol should be seamlessly go through service mesh sidecar like Envoy. - reactive: should keep the RPC invocation completely reactive - polyglot: Dubbo service should be invoked across different languages.
The features I think Dubbo should have(maybe in 2.7): - Integration with other microservice components, like API gateway, monitoring and distributed tracing, distributed transaction, scheduling, and etc. - the Dubbo modules should be separated from the framework and can be used as standalone dependency. For example, the load balancing module can be separated as a library and used by other projects - Integration with standards, like HTTP/2 support. This is important because if we support HTTP/2, it will be easier to integrate with other microservice components that supports HTTP/2. On Thu, Jan 10, 2019 at 6:00 PM Ian Luo <[email protected]> wrote: > > Hi folks, > > Finally we managed to ramp down version 2.7.0 development, and hopefully we > can start the vote in the early of the next week. But the main purpose of > this email is not a release announcement. Instead, since we now have > bandwidth, let's consider and discuss what we should focus out from many > stuff we want to do. For example, we may focus more on issue and pull > request on GitHub, or we may plan 2.7 minor releases immediately after we > release 2.7.0. But today I'd like to bring up one longer term plan which > I'm now caring most, that is, how we define what version 3.0 is? and when > can we get start on it? In my opinion, we need to start it right from this > moment. > > I recalled Liujie Qin (@liujieqin) initialed the discussion on the same > topic [1] in July this year. I summarize his points here if you are too > impatient to read through the contents of his email :p: > > 1. Need to enhance the current extension mechanism > 2. Need to enhance the code base for better maintenance > 3. Need to support async > 4. Need to decouple registry server and config server > 5. Need to support Java8 and above so that we can use advanced features in > Dubbo's core > > I agree with most of his points in this good proposal. > > Here I'd like to initial a discussion on how we define Dubbo 3.0, or in the > other word, how do the community expect from Dubbo 3.0. In my opinion, I > think we need to answer the following questions in this major release: > > - Today the boundary between messaging and remoting call gets blur. We may > need to consider to support streaming at the protocol level. > - Reative programming and its fundamental FP start to get adopted. We > should consider to support it. > - Dubbo should be redesigned to support async better, and treats async as > the first class citizen. We do support async feature in 2.7.0 release but > it is not so perfect. > - Micro-services has been widely adopted. How Dubbo works seamlessly with > micro-services becomes a question mark. We need to look into the inter-op > between Dubbo and micro-services's registry server/config server. The > support on separating registry server and config server in 2.7.0 release is > a good start, but there are still lots of further works remaining with no > doubt. > - Once we conquer seamless micro-services support, we still need to take > one step further to think about K8S integration. After all, K8S and service > mesh built above it are now considered the best way for micro-services > deployment. > - How we define mini-dubbo, or phrase in another way, what the minimal > feature set we should define for Dubbo framework. The reason behind this > is, it is very helpful for developing more language supports from the > community. This also means, we need to modularize Dubbo further, to make it > a reference implementation for other languages. > > In short, I suggest we need to focus on streaming protocol, Rx/FP, native > async, micro-services support, refactor/modularize areas. Of course, there > are more I don't mention in this email, for examples: how we make Dubbo > more resilient? how we support HTTP/2? and more. > > Pls. let me know your opinion on what I and Liujie proposed, and share your > thought on what kind of features really matter to you. > > Thanks, > -Ian. > > > 1. Proposal for Dubbo 3.0 from [email protected] on [email protected] -- Best Regards！ Huxing
