Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

[yuneng xie <xi...@gmail.com>]

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 <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：

> Hi Ian Luo,
>
> OK, i'd start to work on it soon.
>
> Ian Luo <ia...@gmail.com> 于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 <xi...@gmail.com> 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 <ia...@gmail.com> 于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 liujieqin@apache.org on
>> > > dev@dubbo.apache.org
>> > >
>> >
>>
>

Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really should start it ASAP

[jun liu <ke...@gmail.com>]

Great! With this we would be able to support Rx programming model and Stream communication.

I’d like to give a review on it.

Jun

> On Mar 7, 2019, at 3:05 PM, yuneng xie <xi...@gmail.com> wrote:
> 
> 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 <xi...@gmail.com> 于2019年1月22日周二 下午2:25写道：
> 
>> Hi Ian Luo,
>> 
>> OK, i'd start to work on it soon.
>> 
>> Ian Luo <ia...@gmail.com> 于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 <xi...@gmail.com> 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 <ia...@gmail.com> 于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 liujieqin@apache.org on
>>>>> dev@dubbo.apache.org
>>>>> 
>>>> 
>>> 
>>