If the RT is acceptable between the data center, this usage is perfectly fine.
-Ian. On Wed, Jan 23, 2019 at 5:47 PM zhi_guang_...@163.com <zhi_guang_...@163.com> wrote: > I have a similar Question as this mail: > Is Dubbo designed for use on internet? > I have just join a company last year and our business is all around the > world. > So we have servers on US and ASIA and EU. > In this condition we use dubbo on internet and keep security by security > rules that only allow the servers connect to each other. > > I think this is not a pretty useage of dubbo，but I cann't find Strong > evidences to change the situation. > > Can any one help me to answer this questions? Thanks a lot. > > > > ------------------------------ > 您的朋友：刘志广 > > > *From:* Yuhao Bi <byh0...@gmail.com> > *Date:* 2019-01-22 22:55 > *To:* dev <dev@dubbo.apache.org> > *Subject:* Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really > should start it ASAP > Hi lan and community, > > Although I have already heard "Dubbo" a few years ago, > but I just started to learn dubbo after the meetup last year in Chengdu > after it became the Apache Dubbo. > Maybe I'm not such that familiar with the underlying details, but after > the continuous participated > I feel like a part of the community, and free to share my opinion. > > So, here is my question and also consider it my suggestion: > Should we care more about Security? How can we prevent from unauthorized > remote call? > - Should we support Authentication and Authorization > - Should we add Spring Security or Active Directory Service support at the > framework level > > Thanks, > Yuhao > > > jun liu <ken.lj...@gmail.com> 于2019年1月22日周二 下午5:50写道： > > > > I think the online integration test and performance test environment > > should > > > be set up for the new features. > > > > Agree! We should start as soon as possible, from 2.7.x. > > > > Jun > > > > > On Jan 22, 2019, at 5:43 PM, Xin Wang <xin.victorw...@gmail.com> > wrote: > > > > > > I think the online integration test and performance test environment > > should > > > be set up for the new features. > > > > > > Ian Luo <ian....@gmail.com> 于2019年1月22日周二 下午3:04写道： > > > > > >> Yuhao, good idea. > > >> > > >> BTW, do you have any thought on what Dubbo 3.0 should be? > > >> > > >> Thanks, > > >> -Ian. > > >> > > >> > > >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <byh0...@gmail.com> wrote: > > >> > > >>> Once we have decided what to do in the next. > > >>> Should we have a website page to publish it? e.g. [1] > > >>> > > >>> [1]. https://phoenix.apache.org/roadmap.html > > >>> > > >>> yuneng xie <xieyun...@gmail.com> 于2019年1月22日周二 下午2:25写道： > > >>> > > >>>> Hi Ian Luo, > > >>>> > > >>>> OK, i'd start to work on it soon. > > >>>> > > >>>> Ian Luo <ian....@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 <xieyun...@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 <ian....@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 liujie...@apache.org on > > >>>>>>> dev@dubbo.apache.org > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > > >
