Hi folks, I agreed with Ian Luo on the improvement list. I also got some idea in my mind. I'd just share with you two points below in detail which i'm most interested in right now.
1. Upgrade the core abstraction "Invoker", which works in sync mode, to an abstraction works in async mode. then we can construct InvocationChain/FilterChain that works in async mode. A core abstraction works in async mode would simplify the sync/async logic. We no longer need to repeat the logic about sync-mode/async-mode in each ProtocolInvoker. ProtocolInvoker could concentrate on async logic and we could handle sync-mode invoke all in once by wrapping the AsyncInvocationChain into a SyncInvocationChain. 2. Support using stream-value (Fowable, Flux...) as param/returnType. really a nice feature. Please let me known your opinion on my points. I'm also glad to just give it a try and raise a pr. Ian Luo <[email protected]> 于2019年1月10日周四 下午6:00写道： > 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] >
