Hi folks, the first stage of the reative-stream support has been finished. we now can using Mono/Flux as return value. i have raised a pr : https://github.com/apache/incubator-dubbo/pull/3609 . all code is in the module called dubbo-rpc-rsocket.
i would try to complete the feature so that we can use Mono/Flux as args in rpc. yuneng xie <[email protected]> 于2019年1月22日周二 下午2:25写道： > Hi Ian Luo, > > OK, i'd start to work on it soon. > > Ian Luo <[email protected]> 于2019年1月17日周四 下午2:01写道： > >> Hi Yuneng, >> >> Sounds interesting. I am especially interested in reactive programming >> support. Pls. go ahead to try implement it on 3.x branch. >> >> Thanks, >> -Ian. >> >> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <[email protected]> wrote: >> >> > 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] >> > > >> > >> >
