You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by jun liu <ke...@gmail.com> on 2018/12/07 12:11:31 UTC
[DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and
implementations.
Hi, All
I’ve just posted some blogs[4] on Github issues relating to the design principles and implementations of V2.7.0, the content are based mainly on my own understanding of the 2.7.0 codebase (hosted on branch dev-metadata[1]) and the previous discussions[2][3].
Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on metadata refactoring, I am happy to see that v2.7.0 is on a right direction to meet community requirements and keeps evolving. The main changes or features already included in v2.7.0 branch are:
* Config Center: Zookeeper, Apollo, Nacos
* Externalized Configuration
* Service governance enhancement: dynamic configuration & routing rule
* Repackage to 'org.apache.dubbo'
* Java 8 support
* Async programming support
Most of the features above have been mentioned or discussed on the mailing list or Github issues days or months ago. But during the design and coding process, more details come up that need to be further discussed and decided. The design principles and implementations on v2.7.0 branch now are far from the the final decision, they may be not the best choice or even turn to be unreasonable, so you can think them as a prototype implementation provided for your reference. Now, we need to know your opinions on v2.7.0, please help to review the designs and codes, whenever you have better ideas or suggestions, please don’t hesitate to let the community know.
FYI: If you want to know more implementation details and try to read the codes or commits directly, you may find it hard to follow, because there’re too much file changes in there. So I would suggest you read the summaries I wrote in the blogs first and then dive into the code related to the part you interest one by one.
1. https://github.com/apache/incubator-dubbo/tree/dev-metadata
2. https://github.com/apache/incubator-dubbo/issues/2030
3. https://github.com/apache/incubator-dubbo/issues/2341
4. https://github.com/apache/incubator-dubbo/issues/2919
Jun
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.
Posted by Ian Luo <ia...@gmail.com>.
This is really a milestone to get all UTs pass. Since it is now officially
on the master branch, I am expecting more eyes on the code quality and the
design.
Cheers,
-Ian.
On Thu, Dec 27, 2018 at 11:07 PM jun liu <ke...@gmail.com> wrote:
> Hi, All
>
> Good news. All UTs in master has passed the Travis CI.
> The next goal would be to push this branch to release ready, I suggest we
> focus on code/design review and feature test. I’ll start a new thread to
> summary current status, todos and discuss about possible release schedules.
>
> Jun
>
> > On Dec 25, 2018, at 10:29 AM, yuhang xiu <ca...@gmail.com> wrote:
> >
> > Hi, all
> >
> > I also found out that the master ci has failed.
> > This caused some misunderstanding for me to deal with a pending pr[1].
> > After observing the log, I found that the issue[2] with @xin wang
> feedback
> > is the same problem.
> > Since the ci of the module of the cluster has passed and the code is
> well,
> > I will merge the pr first.
> >
> > [1] https://github.com/apache/incubator-dubbo/pull/2822
> > [2] https://github.com/apache/incubator-dubbo/issues/3052
> >
> > jun liu <ke...@gmail.com> 于2018年12月24日周一 下午5:27写道：
> >
> >>> Now the travis ci of master branch faile， I create an issue
> >>> https://github.com/apache/incubator-dubbo/issues/3052
> >>> Please take a look at it
> >>
> >> Thanks, I noticed too, I’ll take care of it.
> >>
> >> Jun
> >>
> >>> On Dec 24, 2018, at 5:25 PM, Xin Wang <xi...@gmail.com>
> wrote:
> >>>
> >>> hi, Jun
> >>>
> >>> Now the travis ci of master branch faile， I create an issue
> >>> https://github.com/apache/incubator-dubbo/issues/3052
> >>> Please take a look at it
> >>>
> >>> Xin Wang <xi...@gmail.com> 于2018年12月24日周一 下午4:38写道：
> >>>
> >>>>> I have just merged dev-metadata branch into master, from now on, the
> >>>> master branch will work as the develop and release codebase of v2.7.0.
> >>>> Branch dev-metadata does not need to be kept anymore, I will delete
> >>>> dev-metadata later today if there’re no more PRs come to it.
> >>>>
> >>>> Great work, looking forward to the new features!
> >>>>
> >>>> jun liu <ke...@gmail.com> 于2018年12月24日周一 下午4:33写道：
> >>>>
> >>>>> Hi, All
> >>>>>
> >>>>> I have just merged dev-metadata branch into master, from now on, the
> >>>>> master branch will work as the develop and release codebase of
> v2.7.0.
> >>>>> Branch dev-metadata does not need to be kept anymore, I will delete
> >>>>> dev-metadata later today if there’re no more PRs come to it.
> >>>>>
> >>>>> Jun
> >>>>>
> >>>>>> On Dec 21, 2018, at 11:37 AM, jun liu <ke...@gmail.com> wrote:
> >>>>>>
> >>>>>> Two more things to mention:
> >>>>>>
> >>>>>> 1. I am thinking of merge this dev-metadata branch back to the
> master.
> >>>>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
> >>>>> together consist of v2.7’s release candidates. While they are
> evolving
> >> at
> >>>>> the same time concurrently, conflicts keep happening. I have been
> kept
> >>>>> merging the master branch to dev-metadata to try to avoid conflicts
> to
> >> the
> >>>>> most extend during the development of dev-metadata. Now, since the
> >> changes
> >>>>> in dev-metadata are stable enough, at least it won’t be a block for
> the
> >>>>> development in master (which is also the biggest concern why we
> created
> >>>>> this new branch), I think it’s time for us to merge the changes back
> >> and
> >>>>> work on the unified master branch.
> >>>>>>
> >>>>>> 2. Is there any plan for the release of OPS? Most of the new
> features
> >>>>> introduced in v2.7 are service governance related abilities and most
> >> users
> >>>>> have get used to using Dubbo OPS to do interoperability with their
> >> Dubbo
> >>>>> services. Thus I think it would be great if an OPS version supporting
> >> these
> >>>>> features can be released at the same time as v2.7 or slightly after
> it
> >> .
> >>>>>> @Minxuan @Majinkai, I know you guys are working on OPS project, any
> >>>>> news to update?
> >>>>>>
> >>>>>> Jun
> >>>>>>
> >>>>>>> On Dec 21, 2018, at 10:35 AM, jun liu <ken.lj.hz@gmail.com
> <mailto:
> >>>>> ken.lj.hz@gmail.com>> wrote:
> >>>>>>>
> >>>>>>>> 1. Prioritization of centralized configuration
> >>>>>>>
> >>>>>>> Now, the centralized configuration or externalized configuration is
> >>>>> implemented to has the highest priority by default. For flexible
> >> concerns,
> >>>>> a switch is designed and opened to users so that they can override
> the
> >>>>> default value, for example, you can use the following JVM property to
> >> give
> >>>>> centralized configuration a lower priority than the local one:
> >>>>> dubbo.configCenter.highestPriority=false.
> >>>>>>>
> >>>>>>>> 2. The logic of the route is more complicated, and the
> compatibility
> >>>>> with
> >>>>>>>> the original low version is guaranteed.
> >>>>>>>
> >>>>>>> When saying of complexity, I guess you mainly refer to the routing
> >>>>> module, because this module is one of the most evident parts that has
> >>>>> changed in this version and is also newly introduced. Its main
> purpose
> >> is
> >>>>> to improve the performance of the runtime. After all, there will be
> >> some
> >>>>> performance loss when routing is executed for address filtering every
> >> time
> >>>>> an RPC is executed.
> >>>>>>> However, I agree we should be really careful about this cache part
> >>>>> since it works as an crucial path on the RPC wire. Some possible
> >> drawbacks
> >>>>> I can come up with it now are: excessive resource usage, priority
> >> guarantee
> >>>>> of routers in chain, etc. I think we can discuss more about the
> >> technical
> >>>>> details of this part, give it more test and then decide whether to
> >> release
> >>>>> it this time or wait until it’s mature enough.
> >>>>>>>
> >>>>>>>> 3.Tag routing has been modified, how is the compatibility with the
> >>>>> original?
> >>>>>>>
> >>>>>>> It has full backward compatibility with the original implementation
> >>>>> with only the supporting of of DynamicConfiguration added.
> >>>>>>>
> >>>>>>>> 4. How does the Environment clear responsibility? It is best to
> have
> >>>>> an
> >>>>>>>> independent description.
> >>>>>>>
> >>>>>>> Sorry, I don’t understand this one. Basically, you can think
> >>>>> Environment as the counterpart of that in Spring. I agree we should
> >> add a
> >>>>> document describing the design purpose and how to use it.
> >>>>>>>
> >>>>>>> Jun
> >>>>>>>
> >>>>>>>> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com
> >> <mailto:
> >>>>> shenglicao2@gmail.com>> wrote:
> >>>>>>>>
> >>>>>>>> All of this features are the biggest concert in the community.
> >>>>>>>> I have some questions：
> >>>>>>>> 1.中心化配置的优先级
> >>>>>>>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
> >>>>>>>> 3.Tag路由改造了，和原来的兼容性怎么样？
> >>>>>>>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
> >>>>>>>> ----------
> >>>>>>>> 1. Prioritization of centralized configuration
> >>>>>>>> 2. The logic of the route is more complicated, and the
> compatibility
> >>>>> with
> >>>>>>>> the original low version is guaranteed.
> >>>>>>>> 3.Tag routing has been modified, how is the compatibility with the
> >>>>> original?
> >>>>>>>> 4. How does the Environment clear responsibility? It is best to
> have
> >>>>> an
> >>>>>>>> independent description.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>>
> >>>>> 于2018年12月7日周五 下午8:11写道：
> >>>>>>>>
> >>>>>>>>> Hi, All
> >>>>>>>>>
> >>>>>>>>> I’ve just posted some blogs[4] on Github issues relating to the
> >>>>> design
> >>>>>>>>> principles and implementations of V2.7.0, the content are based
> >>>>> mainly on
> >>>>>>>>> my own understanding of the 2.7.0 codebase (hosted on branch
> >>>>>>>>> dev-metadata[1]) and the previous discussions[2][3].
> >>>>>>>>>
> >>>>>>>>> Recently, I spent plenty of my spare times on 2.7.0, mainly
> >> focusing
> >>>>> on
> >>>>>>>>> metadata refactoring, I am happy to see that v2.7.0 is on a right
> >>>>> direction
> >>>>>>>>> to meet community requirements and keeps evolving. The main
> changes
> >>>>> or
> >>>>>>>>> features already included in v2.7.0 branch are:
> >>>>>>>>>
> >>>>>>>>> * Config Center: Zookeeper, Apollo, Nacos
> >>>>>>>>> * Externalized Configuration
> >>>>>>>>> * Service governance enhancement: dynamic configuration & routing
> >>>>> rule
> >>>>>>>>> * Repackage to 'org.apache.dubbo'
> >>>>>>>>> * Java 8 support
> >>>>>>>>> * Async programming support
> >>>>>>>>>
> >>>>>>>>> Most of the features above have been mentioned or discussed on
> the
> >>>>> mailing
> >>>>>>>>> list or Github issues days or months ago. But during the design
> and
> >>>>> coding
> >>>>>>>>> process, more details come up that need to be further discussed
> and
> >>>>>>>>> decided. The design principles and implementations on v2.7.0
> branch
> >>>>> now are
> >>>>>>>>> far from the the final decision, they may be not the best choice
> or
> >>>>> even
> >>>>>>>>> turn to be unreasonable, so you can think them as a prototype
> >>>>>>>>> implementation provided for your reference. Now, we need to know
> >> your
> >>>>>>>>> opinions on v2.7.0, please help to review the designs and codes,
> >>>>> whenever
> >>>>>>>>> you have better ideas or suggestions, please don’t hesitate to
> let
> >>>>> the
> >>>>>>>>> community know.
> >>>>>>>>>
> >>>>>>>>> FYI: If you want to know more implementation details and try to
> >> read
> >>>>> the
> >>>>>>>>> codes or commits directly, you may find it hard to follow,
> because
> >>>>> there’re
> >>>>>>>>> too much file changes in there. So I would suggest you read the
> >>>>> summaries I
> >>>>>>>>> wrote in the blogs first and then dive into the code related to
> the
> >>>>> part
> >>>>>>>>> you interest one by one.
> >>>>>>>>>
> >>>>>>>>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <
> >>>>> https://github.com/apache/incubator-dubbo/tree/dev-metadata>
> >>>>>>>>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <
> >>>>> https://github.com/apache/incubator-dubbo/issues/2030>
> >>>>>>>>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <
> >>>>> https://github.com/apache/incubator-dubbo/issues/2341>
> >>>>>>>>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <
> >>>>> https://github.com/apache/incubator-dubbo/issues/2919>
> >>>>>>>>>
> >>>>>>>>> Jun
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> Best Regard!
> >>>>>>>> cvitory
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>
> >>
>
>
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and
implementations.
Posted by jun liu <ke...@gmail.com>.
Hi, All
Good news. All UTs in master has passed the Travis CI.
The next goal would be to push this branch to release ready, I suggest we focus on code/design review and feature test. I’ll start a new thread to summary current status, todos and discuss about possible release schedules.
Jun
> On Dec 25, 2018, at 10:29 AM, yuhang xiu <ca...@gmail.com> wrote:
>
> Hi, all
>
> I also found out that the master ci has failed.
> This caused some misunderstanding for me to deal with a pending pr[1].
> After observing the log, I found that the issue[2] with @xin wang feedback
> is the same problem.
> Since the ci of the module of the cluster has passed and the code is well,
> I will merge the pr first.
>
> [1] https://github.com/apache/incubator-dubbo/pull/2822
> [2] https://github.com/apache/incubator-dubbo/issues/3052
>
> jun liu <ke...@gmail.com> 于2018年12月24日周一 下午5:27写道：
>
>>> Now the travis ci of master branch faile， I create an issue
>>> https://github.com/apache/incubator-dubbo/issues/3052
>>> Please take a look at it
>>
>> Thanks, I noticed too, I’ll take care of it.
>>
>> Jun
>>
>>> On Dec 24, 2018, at 5:25 PM, Xin Wang <xi...@gmail.com> wrote:
>>>
>>> hi, Jun
>>>
>>> Now the travis ci of master branch faile， I create an issue
>>> https://github.com/apache/incubator-dubbo/issues/3052
>>> Please take a look at it
>>>
>>> Xin Wang <xi...@gmail.com> 于2018年12月24日周一 下午4:38写道：
>>>
>>>>> I have just merged dev-metadata branch into master, from now on, the
>>>> master branch will work as the develop and release codebase of v2.7.0.
>>>> Branch dev-metadata does not need to be kept anymore, I will delete
>>>> dev-metadata later today if there’re no more PRs come to it.
>>>>
>>>> Great work, looking forward to the new features!
>>>>
>>>> jun liu <ke...@gmail.com> 于2018年12月24日周一 下午4:33写道：
>>>>
>>>>> Hi, All
>>>>>
>>>>> I have just merged dev-metadata branch into master, from now on, the
>>>>> master branch will work as the develop and release codebase of v2.7.0.
>>>>> Branch dev-metadata does not need to be kept anymore, I will delete
>>>>> dev-metadata later today if there’re no more PRs come to it.
>>>>>
>>>>> Jun
>>>>>
>>>>>> On Dec 21, 2018, at 11:37 AM, jun liu <ke...@gmail.com> wrote:
>>>>>>
>>>>>> Two more things to mention:
>>>>>>
>>>>>> 1. I am thinking of merge this dev-metadata branch back to the master.
>>>>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
>>>>> together consist of v2.7’s release candidates. While they are evolving
>> at
>>>>> the same time concurrently, conflicts keep happening. I have been kept
>>>>> merging the master branch to dev-metadata to try to avoid conflicts to
>> the
>>>>> most extend during the development of dev-metadata. Now, since the
>> changes
>>>>> in dev-metadata are stable enough, at least it won’t be a block for the
>>>>> development in master (which is also the biggest concern why we created
>>>>> this new branch), I think it’s time for us to merge the changes back
>> and
>>>>> work on the unified master branch.
>>>>>>
>>>>>> 2. Is there any plan for the release of OPS? Most of the new features
>>>>> introduced in v2.7 are service governance related abilities and most
>> users
>>>>> have get used to using Dubbo OPS to do interoperability with their
>> Dubbo
>>>>> services. Thus I think it would be great if an OPS version supporting
>> these
>>>>> features can be released at the same time as v2.7 or slightly after it
>> .
>>>>>> @Minxuan @Majinkai, I know you guys are working on OPS project, any
>>>>> news to update?
>>>>>>
>>>>>> Jun
>>>>>>
>>>>>>> On Dec 21, 2018, at 10:35 AM, jun liu <ken.lj.hz@gmail.com <mailto:
>>>>> ken.lj.hz@gmail.com>> wrote:
>>>>>>>
>>>>>>>> 1. Prioritization of centralized configuration
>>>>>>>
>>>>>>> Now, the centralized configuration or externalized configuration is
>>>>> implemented to has the highest priority by default. For flexible
>> concerns,
>>>>> a switch is designed and opened to users so that they can override the
>>>>> default value, for example, you can use the following JVM property to
>> give
>>>>> centralized configuration a lower priority than the local one:
>>>>> dubbo.configCenter.highestPriority=false.
>>>>>>>
>>>>>>>> 2. The logic of the route is more complicated, and the compatibility
>>>>> with
>>>>>>>> the original low version is guaranteed.
>>>>>>>
>>>>>>> When saying of complexity, I guess you mainly refer to the routing
>>>>> module, because this module is one of the most evident parts that has
>>>>> changed in this version and is also newly introduced. Its main purpose
>> is
>>>>> to improve the performance of the runtime. After all, there will be
>> some
>>>>> performance loss when routing is executed for address filtering every
>> time
>>>>> an RPC is executed.
>>>>>>> However, I agree we should be really careful about this cache part
>>>>> since it works as an crucial path on the RPC wire. Some possible
>> drawbacks
>>>>> I can come up with it now are: excessive resource usage, priority
>> guarantee
>>>>> of routers in chain, etc. I think we can discuss more about the
>> technical
>>>>> details of this part, give it more test and then decide whether to
>> release
>>>>> it this time or wait until it’s mature enough.
>>>>>>>
>>>>>>>> 3.Tag routing has been modified, how is the compatibility with the
>>>>> original?
>>>>>>>
>>>>>>> It has full backward compatibility with the original implementation
>>>>> with only the supporting of of DynamicConfiguration added.
>>>>>>>
>>>>>>>> 4. How does the Environment clear responsibility? It is best to have
>>>>> an
>>>>>>>> independent description.
>>>>>>>
>>>>>>> Sorry, I don’t understand this one. Basically, you can think
>>>>> Environment as the counterpart of that in Spring. I agree we should
>> add a
>>>>> document describing the design purpose and how to use it.
>>>>>>>
>>>>>>> Jun
>>>>>>>
>>>>>>>> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com
>> <mailto:
>>>>> shenglicao2@gmail.com>> wrote:
>>>>>>>>
>>>>>>>> All of this features are the biggest concert in the community.
>>>>>>>> I have some questions：
>>>>>>>> 1.中心化配置的优先级
>>>>>>>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>>>>>>>> 3.Tag路由改造了，和原来的兼容性怎么样？
>>>>>>>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>>>>>>>> ----------
>>>>>>>> 1. Prioritization of centralized configuration
>>>>>>>> 2. The logic of the route is more complicated, and the compatibility
>>>>> with
>>>>>>>> the original low version is guaranteed.
>>>>>>>> 3.Tag routing has been modified, how is the compatibility with the
>>>>> original?
>>>>>>>> 4. How does the Environment clear responsibility? It is best to have
>>>>> an
>>>>>>>> independent description.
>>>>>>>>
>>>>>>>>
>>>>>>>> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>>
>>>>> 于2018年12月7日周五 下午8:11写道：
>>>>>>>>
>>>>>>>>> Hi, All
>>>>>>>>>
>>>>>>>>> I’ve just posted some blogs[4] on Github issues relating to the
>>>>> design
>>>>>>>>> principles and implementations of V2.7.0, the content are based
>>>>> mainly on
>>>>>>>>> my own understanding of the 2.7.0 codebase (hosted on branch
>>>>>>>>> dev-metadata[1]) and the previous discussions[2][3].
>>>>>>>>>
>>>>>>>>> Recently, I spent plenty of my spare times on 2.7.0, mainly
>> focusing
>>>>> on
>>>>>>>>> metadata refactoring, I am happy to see that v2.7.0 is on a right
>>>>> direction
>>>>>>>>> to meet community requirements and keeps evolving. The main changes
>>>>> or
>>>>>>>>> features already included in v2.7.0 branch are:
>>>>>>>>>
>>>>>>>>> * Config Center: Zookeeper, Apollo, Nacos
>>>>>>>>> * Externalized Configuration
>>>>>>>>> * Service governance enhancement: dynamic configuration & routing
>>>>> rule
>>>>>>>>> * Repackage to 'org.apache.dubbo'
>>>>>>>>> * Java 8 support
>>>>>>>>> * Async programming support
>>>>>>>>>
>>>>>>>>> Most of the features above have been mentioned or discussed on the
>>>>> mailing
>>>>>>>>> list or Github issues days or months ago. But during the design and
>>>>> coding
>>>>>>>>> process, more details come up that need to be further discussed and
>>>>>>>>> decided. The design principles and implementations on v2.7.0 branch
>>>>> now are
>>>>>>>>> far from the the final decision, they may be not the best choice or
>>>>> even
>>>>>>>>> turn to be unreasonable, so you can think them as a prototype
>>>>>>>>> implementation provided for your reference. Now, we need to know
>> your
>>>>>>>>> opinions on v2.7.0, please help to review the designs and codes,
>>>>> whenever
>>>>>>>>> you have better ideas or suggestions, please don’t hesitate to let
>>>>> the
>>>>>>>>> community know.
>>>>>>>>>
>>>>>>>>> FYI: If you want to know more implementation details and try to
>> read
>>>>> the
>>>>>>>>> codes or commits directly, you may find it hard to follow, because
>>>>> there’re
>>>>>>>>> too much file changes in there. So I would suggest you read the
>>>>> summaries I
>>>>>>>>> wrote in the blogs first and then dive into the code related to the
>>>>> part
>>>>>>>>> you interest one by one.
>>>>>>>>>
>>>>>>>>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <
>>>>> https://github.com/apache/incubator-dubbo/tree/dev-metadata>
>>>>>>>>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <
>>>>> https://github.com/apache/incubator-dubbo/issues/2030>
>>>>>>>>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <
>>>>> https://github.com/apache/incubator-dubbo/issues/2341>
>>>>>>>>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <
>>>>> https://github.com/apache/incubator-dubbo/issues/2919>
>>>>>>>>>
>>>>>>>>> Jun
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Best Regard!
>>>>>>>> cvitory
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>
>>
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.
Posted by yuhang xiu <ca...@gmail.com>.
Hi, all
I also found out that the master ci has failed.
This caused some misunderstanding for me to deal with a pending pr[1].
After observing the log, I found that the issue[2] with @xin wang feedback
is the same problem.
Since the ci of the module of the cluster has passed and the code is well,
I will merge the pr first.
[1] https://github.com/apache/incubator-dubbo/pull/2822
[2] https://github.com/apache/incubator-dubbo/issues/3052
jun liu <ke...@gmail.com> 于2018年12月24日周一 下午5:27写道：
> > Now the travis ci of master branch faile， I create an issue
> > https://github.com/apache/incubator-dubbo/issues/3052
> > Please take a look at it
>
> Thanks, I noticed too, I’ll take care of it.
>
> Jun
>
> > On Dec 24, 2018, at 5:25 PM, Xin Wang <xi...@gmail.com> wrote:
> >
> > hi, Jun
> >
> > Now the travis ci of master branch faile， I create an issue
> > https://github.com/apache/incubator-dubbo/issues/3052
> > Please take a look at it
> >
> > Xin Wang <xi...@gmail.com> 于2018年12月24日周一 下午4:38写道：
> >
> >>> I have just merged dev-metadata branch into master, from now on, the
> >> master branch will work as the develop and release codebase of v2.7.0.
> >> Branch dev-metadata does not need to be kept anymore, I will delete
> >> dev-metadata later today if there’re no more PRs come to it.
> >>
> >> Great work, looking forward to the new features!
> >>
> >> jun liu <ke...@gmail.com> 于2018年12月24日周一 下午4:33写道：
> >>
> >>> Hi, All
> >>>
> >>> I have just merged dev-metadata branch into master, from now on, the
> >>> master branch will work as the develop and release codebase of v2.7.0.
> >>> Branch dev-metadata does not need to be kept anymore, I will delete
> >>> dev-metadata later today if there’re no more PRs come to it.
> >>>
> >>> Jun
> >>>
> >>>> On Dec 21, 2018, at 11:37 AM, jun liu <ke...@gmail.com> wrote:
> >>>>
> >>>> Two more things to mention:
> >>>>
> >>>> 1. I am thinking of merge this dev-metadata branch back to the master.
> >>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
> >>> together consist of v2.7’s release candidates. While they are evolving
> at
> >>> the same time concurrently, conflicts keep happening. I have been kept
> >>> merging the master branch to dev-metadata to try to avoid conflicts to
> the
> >>> most extend during the development of dev-metadata. Now, since the
> changes
> >>> in dev-metadata are stable enough, at least it won’t be a block for the
> >>> development in master (which is also the biggest concern why we created
> >>> this new branch), I think it’s time for us to merge the changes back
> and
> >>> work on the unified master branch.
> >>>>
> >>>> 2. Is there any plan for the release of OPS? Most of the new features
> >>> introduced in v2.7 are service governance related abilities and most
> users
> >>> have get used to using Dubbo OPS to do interoperability with their
> Dubbo
> >>> services. Thus I think it would be great if an OPS version supporting
> these
> >>> features can be released at the same time as v2.7 or slightly after it
> .
> >>>> @Minxuan @Majinkai, I know you guys are working on OPS project, any
> >>> news to update?
> >>>>
> >>>> Jun
> >>>>
> >>>>> On Dec 21, 2018, at 10:35 AM, jun liu <ken.lj.hz@gmail.com <mailto:
> >>> ken.lj.hz@gmail.com>> wrote:
> >>>>>
> >>>>>> 1. Prioritization of centralized configuration
> >>>>>
> >>>>> Now, the centralized configuration or externalized configuration is
> >>> implemented to has the highest priority by default. For flexible
> concerns,
> >>> a switch is designed and opened to users so that they can override the
> >>> default value, for example, you can use the following JVM property to
> give
> >>> centralized configuration a lower priority than the local one:
> >>> dubbo.configCenter.highestPriority=false.
> >>>>>
> >>>>>> 2. The logic of the route is more complicated, and the compatibility
> >>> with
> >>>>>> the original low version is guaranteed.
> >>>>>
> >>>>> When saying of complexity, I guess you mainly refer to the routing
> >>> module, because this module is one of the most evident parts that has
> >>> changed in this version and is also newly introduced. Its main purpose
> is
> >>> to improve the performance of the runtime. After all, there will be
> some
> >>> performance loss when routing is executed for address filtering every
> time
> >>> an RPC is executed.
> >>>>> However, I agree we should be really careful about this cache part
> >>> since it works as an crucial path on the RPC wire. Some possible
> drawbacks
> >>> I can come up with it now are: excessive resource usage, priority
> guarantee
> >>> of routers in chain, etc. I think we can discuss more about the
> technical
> >>> details of this part, give it more test and then decide whether to
> release
> >>> it this time or wait until it’s mature enough.
> >>>>>
> >>>>>> 3.Tag routing has been modified, how is the compatibility with the
> >>> original?
> >>>>>
> >>>>> It has full backward compatibility with the original implementation
> >>> with only the supporting of of DynamicConfiguration added.
> >>>>>
> >>>>>> 4. How does the Environment clear responsibility? It is best to have
> >>> an
> >>>>>> independent description.
> >>>>>
> >>>>> Sorry, I don’t understand this one. Basically, you can think
> >>> Environment as the counterpart of that in Spring. I agree we should
> add a
> >>> document describing the design purpose and how to use it.
> >>>>>
> >>>>> Jun
> >>>>>
> >>>>>> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com
> <mailto:
> >>> shenglicao2@gmail.com>> wrote:
> >>>>>>
> >>>>>> All of this features are the biggest concert in the community.
> >>>>>> I have some questions：
> >>>>>> 1.中心化配置的优先级
> >>>>>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
> >>>>>> 3.Tag路由改造了，和原来的兼容性怎么样？
> >>>>>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
> >>>>>> ----------
> >>>>>> 1. Prioritization of centralized configuration
> >>>>>> 2. The logic of the route is more complicated, and the compatibility
> >>> with
> >>>>>> the original low version is guaranteed.
> >>>>>> 3.Tag routing has been modified, how is the compatibility with the
> >>> original?
> >>>>>> 4. How does the Environment clear responsibility? It is best to have
> >>> an
> >>>>>> independent description.
> >>>>>>
> >>>>>>
> >>>>>> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>>
> >>> 于2018年12月7日周五 下午8:11写道：
> >>>>>>
> >>>>>>> Hi, All
> >>>>>>>
> >>>>>>> I’ve just posted some blogs[4] on Github issues relating to the
> >>> design
> >>>>>>> principles and implementations of V2.7.0, the content are based
> >>> mainly on
> >>>>>>> my own understanding of the 2.7.0 codebase (hosted on branch
> >>>>>>> dev-metadata[1]) and the previous discussions[2][3].
> >>>>>>>
> >>>>>>> Recently, I spent plenty of my spare times on 2.7.0, mainly
> focusing
> >>> on
> >>>>>>> metadata refactoring, I am happy to see that v2.7.0 is on a right
> >>> direction
> >>>>>>> to meet community requirements and keeps evolving. The main changes
> >>> or
> >>>>>>> features already included in v2.7.0 branch are:
> >>>>>>>
> >>>>>>> * Config Center: Zookeeper, Apollo, Nacos
> >>>>>>> * Externalized Configuration
> >>>>>>> * Service governance enhancement: dynamic configuration & routing
> >>> rule
> >>>>>>> * Repackage to 'org.apache.dubbo'
> >>>>>>> * Java 8 support
> >>>>>>> * Async programming support
> >>>>>>>
> >>>>>>> Most of the features above have been mentioned or discussed on the
> >>> mailing
> >>>>>>> list or Github issues days or months ago. But during the design and
> >>> coding
> >>>>>>> process, more details come up that need to be further discussed and
> >>>>>>> decided. The design principles and implementations on v2.7.0 branch
> >>> now are
> >>>>>>> far from the the final decision, they may be not the best choice or
> >>> even
> >>>>>>> turn to be unreasonable, so you can think them as a prototype
> >>>>>>> implementation provided for your reference. Now, we need to know
> your
> >>>>>>> opinions on v2.7.0, please help to review the designs and codes,
> >>> whenever
> >>>>>>> you have better ideas or suggestions, please don’t hesitate to let
> >>> the
> >>>>>>> community know.
> >>>>>>>
> >>>>>>> FYI: If you want to know more implementation details and try to
> read
> >>> the
> >>>>>>> codes or commits directly, you may find it hard to follow, because
> >>> there’re
> >>>>>>> too much file changes in there. So I would suggest you read the
> >>> summaries I
> >>>>>>> wrote in the blogs first and then dive into the code related to the
> >>> part
> >>>>>>> you interest one by one.
> >>>>>>>
> >>>>>>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <
> >>> https://github.com/apache/incubator-dubbo/tree/dev-metadata>
> >>>>>>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <
> >>> https://github.com/apache/incubator-dubbo/issues/2030>
> >>>>>>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <
> >>> https://github.com/apache/incubator-dubbo/issues/2341>
> >>>>>>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <
> >>> https://github.com/apache/incubator-dubbo/issues/2919>
> >>>>>>>
> >>>>>>> Jun
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>> Best Regard!
> >>>>>> cvitory
> >>>>>
> >>>>
> >>>
> >>>
>
>
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and
implementations.
Posted by jun liu <ke...@gmail.com>.
> Now the travis ci of master branch faile， I create an issue
> https://github.com/apache/incubator-dubbo/issues/3052
> Please take a look at it
Thanks, I noticed too, I’ll take care of it.
Jun
> On Dec 24, 2018, at 5:25 PM, Xin Wang <xi...@gmail.com> wrote:
>
> hi, Jun
>
> Now the travis ci of master branch faile， I create an issue
> https://github.com/apache/incubator-dubbo/issues/3052
> Please take a look at it
>
> Xin Wang <xi...@gmail.com> 于2018年12月24日周一 下午4:38写道：
>
>>> I have just merged dev-metadata branch into master, from now on, the
>> master branch will work as the develop and release codebase of v2.7.0.
>> Branch dev-metadata does not need to be kept anymore, I will delete
>> dev-metadata later today if there’re no more PRs come to it.
>>
>> Great work, looking forward to the new features!
>>
>> jun liu <ke...@gmail.com> 于2018年12月24日周一 下午4:33写道：
>>
>>> Hi, All
>>>
>>> I have just merged dev-metadata branch into master, from now on, the
>>> master branch will work as the develop and release codebase of v2.7.0.
>>> Branch dev-metadata does not need to be kept anymore, I will delete
>>> dev-metadata later today if there’re no more PRs come to it.
>>>
>>> Jun
>>>
>>>> On Dec 21, 2018, at 11:37 AM, jun liu <ke...@gmail.com> wrote:
>>>>
>>>> Two more things to mention:
>>>>
>>>> 1. I am thinking of merge this dev-metadata branch back to the master.
>>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
>>> together consist of v2.7’s release candidates. While they are evolving at
>>> the same time concurrently, conflicts keep happening. I have been kept
>>> merging the master branch to dev-metadata to try to avoid conflicts to the
>>> most extend during the development of dev-metadata. Now, since the changes
>>> in dev-metadata are stable enough, at least it won’t be a block for the
>>> development in master (which is also the biggest concern why we created
>>> this new branch), I think it’s time for us to merge the changes back and
>>> work on the unified master branch.
>>>>
>>>> 2. Is there any plan for the release of OPS? Most of the new features
>>> introduced in v2.7 are service governance related abilities and most users
>>> have get used to using Dubbo OPS to do interoperability with their Dubbo
>>> services. Thus I think it would be great if an OPS version supporting these
>>> features can be released at the same time as v2.7 or slightly after it .
>>>> @Minxuan @Majinkai, I know you guys are working on OPS project, any
>>> news to update?
>>>>
>>>> Jun
>>>>
>>>>> On Dec 21, 2018, at 10:35 AM, jun liu <ken.lj.hz@gmail.com <mailto:
>>> ken.lj.hz@gmail.com>> wrote:
>>>>>
>>>>>> 1. Prioritization of centralized configuration
>>>>>
>>>>> Now, the centralized configuration or externalized configuration is
>>> implemented to has the highest priority by default. For flexible concerns,
>>> a switch is designed and opened to users so that they can override the
>>> default value, for example, you can use the following JVM property to give
>>> centralized configuration a lower priority than the local one:
>>> dubbo.configCenter.highestPriority=false.
>>>>>
>>>>>> 2. The logic of the route is more complicated, and the compatibility
>>> with
>>>>>> the original low version is guaranteed.
>>>>>
>>>>> When saying of complexity, I guess you mainly refer to the routing
>>> module, because this module is one of the most evident parts that has
>>> changed in this version and is also newly introduced. Its main purpose is
>>> to improve the performance of the runtime. After all, there will be some
>>> performance loss when routing is executed for address filtering every time
>>> an RPC is executed.
>>>>> However, I agree we should be really careful about this cache part
>>> since it works as an crucial path on the RPC wire. Some possible drawbacks
>>> I can come up with it now are: excessive resource usage, priority guarantee
>>> of routers in chain, etc. I think we can discuss more about the technical
>>> details of this part, give it more test and then decide whether to release
>>> it this time or wait until it’s mature enough.
>>>>>
>>>>>> 3.Tag routing has been modified, how is the compatibility with the
>>> original?
>>>>>
>>>>> It has full backward compatibility with the original implementation
>>> with only the supporting of of DynamicConfiguration added.
>>>>>
>>>>>> 4. How does the Environment clear responsibility? It is best to have
>>> an
>>>>>> independent description.
>>>>>
>>>>> Sorry, I don’t understand this one. Basically, you can think
>>> Environment as the counterpart of that in Spring. I agree we should add a
>>> document describing the design purpose and how to use it.
>>>>>
>>>>> Jun
>>>>>
>>>>>> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com <mailto:
>>> shenglicao2@gmail.com>> wrote:
>>>>>>
>>>>>> All of this features are the biggest concert in the community.
>>>>>> I have some questions：
>>>>>> 1.中心化配置的优先级
>>>>>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>>>>>> 3.Tag路由改造了，和原来的兼容性怎么样？
>>>>>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>>>>>> ----------
>>>>>> 1. Prioritization of centralized configuration
>>>>>> 2. The logic of the route is more complicated, and the compatibility
>>> with
>>>>>> the original low version is guaranteed.
>>>>>> 3.Tag routing has been modified, how is the compatibility with the
>>> original?
>>>>>> 4. How does the Environment clear responsibility? It is best to have
>>> an
>>>>>> independent description.
>>>>>>
>>>>>>
>>>>>> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>>
>>> 于2018年12月7日周五 下午8:11写道：
>>>>>>
>>>>>>> Hi, All
>>>>>>>
>>>>>>> I’ve just posted some blogs[4] on Github issues relating to the
>>> design
>>>>>>> principles and implementations of V2.7.0, the content are based
>>> mainly on
>>>>>>> my own understanding of the 2.7.0 codebase (hosted on branch
>>>>>>> dev-metadata[1]) and the previous discussions[2][3].
>>>>>>>
>>>>>>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing
>>> on
>>>>>>> metadata refactoring, I am happy to see that v2.7.0 is on a right
>>> direction
>>>>>>> to meet community requirements and keeps evolving. The main changes
>>> or
>>>>>>> features already included in v2.7.0 branch are:
>>>>>>>
>>>>>>> * Config Center: Zookeeper, Apollo, Nacos
>>>>>>> * Externalized Configuration
>>>>>>> * Service governance enhancement: dynamic configuration & routing
>>> rule
>>>>>>> * Repackage to 'org.apache.dubbo'
>>>>>>> * Java 8 support
>>>>>>> * Async programming support
>>>>>>>
>>>>>>> Most of the features above have been mentioned or discussed on the
>>> mailing
>>>>>>> list or Github issues days or months ago. But during the design and
>>> coding
>>>>>>> process, more details come up that need to be further discussed and
>>>>>>> decided. The design principles and implementations on v2.7.0 branch
>>> now are
>>>>>>> far from the the final decision, they may be not the best choice or
>>> even
>>>>>>> turn to be unreasonable, so you can think them as a prototype
>>>>>>> implementation provided for your reference. Now, we need to know your
>>>>>>> opinions on v2.7.0, please help to review the designs and codes,
>>> whenever
>>>>>>> you have better ideas or suggestions, please don’t hesitate to let
>>> the
>>>>>>> community know.
>>>>>>>
>>>>>>> FYI: If you want to know more implementation details and try to read
>>> the
>>>>>>> codes or commits directly, you may find it hard to follow, because
>>> there’re
>>>>>>> too much file changes in there. So I would suggest you read the
>>> summaries I
>>>>>>> wrote in the blogs first and then dive into the code related to the
>>> part
>>>>>>> you interest one by one.
>>>>>>>
>>>>>>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <
>>> https://github.com/apache/incubator-dubbo/tree/dev-metadata>
>>>>>>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <
>>> https://github.com/apache/incubator-dubbo/issues/2030>
>>>>>>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <
>>> https://github.com/apache/incubator-dubbo/issues/2341>
>>>>>>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <
>>> https://github.com/apache/incubator-dubbo/issues/2919>
>>>>>>>
>>>>>>> Jun
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Best Regard!
>>>>>> cvitory
>>>>>
>>>>
>>>
>>>
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.
Posted by Xin Wang <xi...@gmail.com>.
hi, Jun
Now the travis ci of master branch faile， I create an issue
https://github.com/apache/incubator-dubbo/issues/3052
Please take a look at it
Xin Wang <xi...@gmail.com> 于2018年12月24日周一 下午4:38写道：
> >I have just merged dev-metadata branch into master, from now on, the
> master branch will work as the develop and release codebase of v2.7.0.
> Branch dev-metadata does not need to be kept anymore, I will delete
> dev-metadata later today if there’re no more PRs come to it.
>
> Great work, looking forward to the new features!
>
> jun liu <ke...@gmail.com> 于2018年12月24日周一 下午4:33写道：
>
>> Hi, All
>>
>> I have just merged dev-metadata branch into master, from now on, the
>> master branch will work as the develop and release codebase of v2.7.0.
>> Branch dev-metadata does not need to be kept anymore, I will delete
>> dev-metadata later today if there’re no more PRs come to it.
>>
>> Jun
>>
>> > On Dec 21, 2018, at 11:37 AM, jun liu <ke...@gmail.com> wrote:
>> >
>> > Two more things to mention:
>> >
>> > 1. I am thinking of merge this dev-metadata branch back to the master.
>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
>> together consist of v2.7’s release candidates. While they are evolving at
>> the same time concurrently, conflicts keep happening. I have been kept
>> merging the master branch to dev-metadata to try to avoid conflicts to the
>> most extend during the development of dev-metadata. Now, since the changes
>> in dev-metadata are stable enough, at least it won’t be a block for the
>> development in master (which is also the biggest concern why we created
>> this new branch), I think it’s time for us to merge the changes back and
>> work on the unified master branch.
>> >
>> > 2. Is there any plan for the release of OPS? Most of the new features
>> introduced in v2.7 are service governance related abilities and most users
>> have get used to using Dubbo OPS to do interoperability with their Dubbo
>> services. Thus I think it would be great if an OPS version supporting these
>> features can be released at the same time as v2.7 or slightly after it .
>> > @Minxuan @Majinkai, I know you guys are working on OPS project, any
>> news to update?
>> >
>> > Jun
>> >
>> >> On Dec 21, 2018, at 10:35 AM, jun liu <ken.lj.hz@gmail.com <mailto:
>> ken.lj.hz@gmail.com>> wrote:
>> >>
>> >>> 1. Prioritization of centralized configuration
>> >>
>> >> Now, the centralized configuration or externalized configuration is
>> implemented to has the highest priority by default. For flexible concerns,
>> a switch is designed and opened to users so that they can override the
>> default value, for example, you can use the following JVM property to give
>> centralized configuration a lower priority than the local one:
>> dubbo.configCenter.highestPriority=false.
>> >>
>> >>> 2. The logic of the route is more complicated, and the compatibility
>> with
>> >>> the original low version is guaranteed.
>> >>
>> >> When saying of complexity, I guess you mainly refer to the routing
>> module, because this module is one of the most evident parts that has
>> changed in this version and is also newly introduced. Its main purpose is
>> to improve the performance of the runtime. After all, there will be some
>> performance loss when routing is executed for address filtering every time
>> an RPC is executed.
>> >> However, I agree we should be really careful about this cache part
>> since it works as an crucial path on the RPC wire. Some possible drawbacks
>> I can come up with it now are: excessive resource usage, priority guarantee
>> of routers in chain, etc. I think we can discuss more about the technical
>> details of this part, give it more test and then decide whether to release
>> it this time or wait until it’s mature enough.
>> >>
>> >>> 3.Tag routing has been modified, how is the compatibility with the
>> original?
>> >>
>> >> It has full backward compatibility with the original implementation
>> with only the supporting of of DynamicConfiguration added.
>> >>
>> >>> 4. How does the Environment clear responsibility? It is best to have
>> an
>> >>> independent description.
>> >>
>> >> Sorry, I don’t understand this one. Basically, you can think
>> Environment as the counterpart of that in Spring. I agree we should add a
>> document describing the design purpose and how to use it.
>> >>
>> >> Jun
>> >>
>> >>> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com <mailto:
>> shenglicao2@gmail.com>> wrote:
>> >>>
>> >>> All of this features are the biggest concert in the community.
>> >>> I have some questions：
>> >>> 1.中心化配置的优先级
>> >>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>> >>> 3.Tag路由改造了，和原来的兼容性怎么样？
>> >>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>> >>> ----------
>> >>> 1. Prioritization of centralized configuration
>> >>> 2. The logic of the route is more complicated, and the compatibility
>> with
>> >>> the original low version is guaranteed.
>> >>> 3.Tag routing has been modified, how is the compatibility with the
>> original?
>> >>> 4. How does the Environment clear responsibility? It is best to have
>> an
>> >>> independent description.
>> >>>
>> >>>
>> >>> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>>
>> 于2018年12月7日周五 下午8:11写道：
>> >>>
>> >>>> Hi, All
>> >>>>
>> >>>> I’ve just posted some blogs[4] on Github issues relating to the
>> design
>> >>>> principles and implementations of V2.7.0, the content are based
>> mainly on
>> >>>> my own understanding of the 2.7.0 codebase (hosted on branch
>> >>>> dev-metadata[1]) and the previous discussions[2][3].
>> >>>>
>> >>>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing
>> on
>> >>>> metadata refactoring, I am happy to see that v2.7.0 is on a right
>> direction
>> >>>> to meet community requirements and keeps evolving. The main changes
>> or
>> >>>> features already included in v2.7.0 branch are:
>> >>>>
>> >>>> * Config Center: Zookeeper, Apollo, Nacos
>> >>>> * Externalized Configuration
>> >>>> * Service governance enhancement: dynamic configuration & routing
>> rule
>> >>>> * Repackage to 'org.apache.dubbo'
>> >>>> * Java 8 support
>> >>>> * Async programming support
>> >>>>
>> >>>> Most of the features above have been mentioned or discussed on the
>> mailing
>> >>>> list or Github issues days or months ago. But during the design and
>> coding
>> >>>> process, more details come up that need to be further discussed and
>> >>>> decided. The design principles and implementations on v2.7.0 branch
>> now are
>> >>>> far from the the final decision, they may be not the best choice or
>> even
>> >>>> turn to be unreasonable, so you can think them as a prototype
>> >>>> implementation provided for your reference. Now, we need to know your
>> >>>> opinions on v2.7.0, please help to review the designs and codes,
>> whenever
>> >>>> you have better ideas or suggestions, please don’t hesitate to let
>> the
>> >>>> community know.
>> >>>>
>> >>>> FYI: If you want to know more implementation details and try to read
>> the
>> >>>> codes or commits directly, you may find it hard to follow, because
>> there’re
>> >>>> too much file changes in there. So I would suggest you read the
>> summaries I
>> >>>> wrote in the blogs first and then dive into the code related to the
>> part
>> >>>> you interest one by one.
>> >>>>
>> >>>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <
>> https://github.com/apache/incubator-dubbo/tree/dev-metadata>
>> >>>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <
>> https://github.com/apache/incubator-dubbo/issues/2030>
>> >>>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <
>> https://github.com/apache/incubator-dubbo/issues/2341>
>> >>>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <
>> https://github.com/apache/incubator-dubbo/issues/2919>
>> >>>>
>> >>>> Jun
>> >>>>
>> >>>>
>> >>>
>> >>> --
>> >>>
>> >>> Best Regard!
>> >>> cvitory
>> >>
>> >
>>
>>
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.
Posted by Xin Wang <xi...@gmail.com>.
>I have just merged dev-metadata branch into master, from now on, the
master branch will work as the develop and release codebase of v2.7.0.
Branch dev-metadata does not need to be kept anymore, I will delete
dev-metadata later today if there’re no more PRs come to it.
Great work, looking forward to the new features!
jun liu <ke...@gmail.com> 于2018年12月24日周一 下午4:33写道：
> Hi, All
>
> I have just merged dev-metadata branch into master, from now on, the
> master branch will work as the develop and release codebase of v2.7.0.
> Branch dev-metadata does not need to be kept anymore, I will delete
> dev-metadata later today if there’re no more PRs come to it.
>
> Jun
>
> > On Dec 21, 2018, at 11:37 AM, jun liu <ke...@gmail.com> wrote:
> >
> > Two more things to mention:
> >
> > 1. I am thinking of merge this dev-metadata branch back to the master.
> Both these two branches have the same version 2.7.0-SNAPSHOT and they
> together consist of v2.7’s release candidates. While they are evolving at
> the same time concurrently, conflicts keep happening. I have been kept
> merging the master branch to dev-metadata to try to avoid conflicts to the
> most extend during the development of dev-metadata. Now, since the changes
> in dev-metadata are stable enough, at least it won’t be a block for the
> development in master (which is also the biggest concern why we created
> this new branch), I think it’s time for us to merge the changes back and
> work on the unified master branch.
> >
> > 2. Is there any plan for the release of OPS? Most of the new features
> introduced in v2.7 are service governance related abilities and most users
> have get used to using Dubbo OPS to do interoperability with their Dubbo
> services. Thus I think it would be great if an OPS version supporting these
> features can be released at the same time as v2.7 or slightly after it .
> > @Minxuan @Majinkai, I know you guys are working on OPS project, any news
> to update?
> >
> > Jun
> >
> >> On Dec 21, 2018, at 10:35 AM, jun liu <ken.lj.hz@gmail.com <mailto:
> ken.lj.hz@gmail.com>> wrote:
> >>
> >>> 1. Prioritization of centralized configuration
> >>
> >> Now, the centralized configuration or externalized configuration is
> implemented to has the highest priority by default. For flexible concerns,
> a switch is designed and opened to users so that they can override the
> default value, for example, you can use the following JVM property to give
> centralized configuration a lower priority than the local one:
> dubbo.configCenter.highestPriority=false.
> >>
> >>> 2. The logic of the route is more complicated, and the compatibility
> with
> >>> the original low version is guaranteed.
> >>
> >> When saying of complexity, I guess you mainly refer to the routing
> module, because this module is one of the most evident parts that has
> changed in this version and is also newly introduced. Its main purpose is
> to improve the performance of the runtime. After all, there will be some
> performance loss when routing is executed for address filtering every time
> an RPC is executed.
> >> However, I agree we should be really careful about this cache part
> since it works as an crucial path on the RPC wire. Some possible drawbacks
> I can come up with it now are: excessive resource usage, priority guarantee
> of routers in chain, etc. I think we can discuss more about the technical
> details of this part, give it more test and then decide whether to release
> it this time or wait until it’s mature enough.
> >>
> >>> 3.Tag routing has been modified, how is the compatibility with the
> original?
> >>
> >> It has full backward compatibility with the original implementation
> with only the supporting of of DynamicConfiguration added.
> >>
> >>> 4. How does the Environment clear responsibility? It is best to have an
> >>> independent description.
> >>
> >> Sorry, I don’t understand this one. Basically, you can think
> Environment as the counterpart of that in Spring. I agree we should add a
> document describing the design purpose and how to use it.
> >>
> >> Jun
> >>
> >>> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com <mailto:
> shenglicao2@gmail.com>> wrote:
> >>>
> >>> All of this features are the biggest concert in the community.
> >>> I have some questions：
> >>> 1.中心化配置的优先级
> >>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
> >>> 3.Tag路由改造了，和原来的兼容性怎么样？
> >>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
> >>> ----------
> >>> 1. Prioritization of centralized configuration
> >>> 2. The logic of the route is more complicated, and the compatibility
> with
> >>> the original low version is guaranteed.
> >>> 3.Tag routing has been modified, how is the compatibility with the
> original?
> >>> 4. How does the Environment clear responsibility? It is best to have an
> >>> independent description.
> >>>
> >>>
> >>> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>>
> 于2018年12月7日周五 下午8:11写道：
> >>>
> >>>> Hi, All
> >>>>
> >>>> I’ve just posted some blogs[4] on Github issues relating to the design
> >>>> principles and implementations of V2.7.0, the content are based
> mainly on
> >>>> my own understanding of the 2.7.0 codebase (hosted on branch
> >>>> dev-metadata[1]) and the previous discussions[2][3].
> >>>>
> >>>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing
> on
> >>>> metadata refactoring, I am happy to see that v2.7.0 is on a right
> direction
> >>>> to meet community requirements and keeps evolving. The main changes or
> >>>> features already included in v2.7.0 branch are:
> >>>>
> >>>> * Config Center: Zookeeper, Apollo, Nacos
> >>>> * Externalized Configuration
> >>>> * Service governance enhancement: dynamic configuration & routing rule
> >>>> * Repackage to 'org.apache.dubbo'
> >>>> * Java 8 support
> >>>> * Async programming support
> >>>>
> >>>> Most of the features above have been mentioned or discussed on the
> mailing
> >>>> list or Github issues days or months ago. But during the design and
> coding
> >>>> process, more details come up that need to be further discussed and
> >>>> decided. The design principles and implementations on v2.7.0 branch
> now are
> >>>> far from the the final decision, they may be not the best choice or
> even
> >>>> turn to be unreasonable, so you can think them as a prototype
> >>>> implementation provided for your reference. Now, we need to know your
> >>>> opinions on v2.7.0, please help to review the designs and codes,
> whenever
> >>>> you have better ideas or suggestions, please don’t hesitate to let the
> >>>> community know.
> >>>>
> >>>> FYI: If you want to know more implementation details and try to read
> the
> >>>> codes or commits directly, you may find it hard to follow, because
> there’re
> >>>> too much file changes in there. So I would suggest you read the
> summaries I
> >>>> wrote in the blogs first and then dive into the code related to the
> part
> >>>> you interest one by one.
> >>>>
> >>>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <
> https://github.com/apache/incubator-dubbo/tree/dev-metadata>
> >>>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <
> https://github.com/apache/incubator-dubbo/issues/2030>
> >>>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <
> https://github.com/apache/incubator-dubbo/issues/2341>
> >>>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <
> https://github.com/apache/incubator-dubbo/issues/2919>
> >>>>
> >>>> Jun
> >>>>
> >>>>
> >>>
> >>> --
> >>>
> >>> Best Regard!
> >>> cvitory
> >>
> >
>
>
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and
implementations.
Posted by jun liu <ke...@gmail.com>.
Hi, All
I have just merged dev-metadata branch into master, from now on, the master branch will work as the develop and release codebase of v2.7.0. Branch dev-metadata does not need to be kept anymore, I will delete dev-metadata later today if there’re no more PRs come to it.
Jun
> On Dec 21, 2018, at 11:37 AM, jun liu <ke...@gmail.com> wrote:
>
> Two more things to mention:
>
> 1. I am thinking of merge this dev-metadata branch back to the master. Both these two branches have the same version 2.7.0-SNAPSHOT and they together consist of v2.7’s release candidates. While they are evolving at the same time concurrently, conflicts keep happening. I have been kept merging the master branch to dev-metadata to try to avoid conflicts to the most extend during the development of dev-metadata. Now, since the changes in dev-metadata are stable enough, at least it won’t be a block for the development in master (which is also the biggest concern why we created this new branch), I think it’s time for us to merge the changes back and work on the unified master branch.
>
> 2. Is there any plan for the release of OPS? Most of the new features introduced in v2.7 are service governance related abilities and most users have get used to using Dubbo OPS to do interoperability with their Dubbo services. Thus I think it would be great if an OPS version supporting these features can be released at the same time as v2.7 or slightly after it .
> @Minxuan @Majinkai, I know you guys are working on OPS project, any news to update?
>
> Jun
>
>> On Dec 21, 2018, at 10:35 AM, jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>> wrote:
>>
>>> 1. Prioritization of centralized configuration
>>
>> Now, the centralized configuration or externalized configuration is implemented to has the highest priority by default. For flexible concerns, a switch is designed and opened to users so that they can override the default value, for example, you can use the following JVM property to give centralized configuration a lower priority than the local one: dubbo.configCenter.highestPriority=false.
>>
>>> 2. The logic of the route is more complicated, and the compatibility with
>>> the original low version is guaranteed.
>>
>> When saying of complexity, I guess you mainly refer to the routing module, because this module is one of the most evident parts that has changed in this version and is also newly introduced. Its main purpose is to improve the performance of the runtime. After all, there will be some performance loss when routing is executed for address filtering every time an RPC is executed.
>> However, I agree we should be really careful about this cache part since it works as an crucial path on the RPC wire. Some possible drawbacks I can come up with it now are: excessive resource usage, priority guarantee of routers in chain, etc. I think we can discuss more about the technical details of this part, give it more test and then decide whether to release it this time or wait until it’s mature enough.
>>
>>> 3.Tag routing has been modified, how is the compatibility with the original?
>>
>> It has full backward compatibility with the original implementation with only the supporting of of DynamicConfiguration added.
>>
>>> 4. How does the Environment clear responsibility? It is best to have an
>>> independent description.
>>
>> Sorry, I don’t understand this one. Basically, you can think Environment as the counterpart of that in Spring. I agree we should add a document describing the design purpose and how to use it.
>>
>> Jun
>>
>>> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> All of this features are the biggest concert in the community.
>>> I have some questions：
>>> 1.中心化配置的优先级
>>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>>> 3.Tag路由改造了，和原来的兼容性怎么样？
>>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>>> ----------
>>> 1. Prioritization of centralized configuration
>>> 2. The logic of the route is more complicated, and the compatibility with
>>> the original low version is guaranteed.
>>> 3.Tag routing has been modified, how is the compatibility with the original?
>>> 4. How does the Environment clear responsibility? It is best to have an
>>> independent description.
>>>
>>>
>>> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>> 于2018年12月7日周五 下午8:11写道：
>>>
>>>> Hi, All
>>>>
>>>> I’ve just posted some blogs[4] on Github issues relating to the design
>>>> principles and implementations of V2.7.0, the content are based mainly on
>>>> my own understanding of the 2.7.0 codebase (hosted on branch
>>>> dev-metadata[1]) and the previous discussions[2][3].
>>>>
>>>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
>>>> metadata refactoring, I am happy to see that v2.7.0 is on a right direction
>>>> to meet community requirements and keeps evolving. The main changes or
>>>> features already included in v2.7.0 branch are:
>>>>
>>>> * Config Center: Zookeeper, Apollo, Nacos
>>>> * Externalized Configuration
>>>> * Service governance enhancement: dynamic configuration & routing rule
>>>> * Repackage to 'org.apache.dubbo'
>>>> * Java 8 support
>>>> * Async programming support
>>>>
>>>> Most of the features above have been mentioned or discussed on the mailing
>>>> list or Github issues days or months ago. But during the design and coding
>>>> process, more details come up that need to be further discussed and
>>>> decided. The design principles and implementations on v2.7.0 branch now are
>>>> far from the the final decision, they may be not the best choice or even
>>>> turn to be unreasonable, so you can think them as a prototype
>>>> implementation provided for your reference. Now, we need to know your
>>>> opinions on v2.7.0, please help to review the designs and codes, whenever
>>>> you have better ideas or suggestions, please don’t hesitate to let the
>>>> community know.
>>>>
>>>> FYI: If you want to know more implementation details and try to read the
>>>> codes or commits directly, you may find it hard to follow, because there’re
>>>> too much file changes in there. So I would suggest you read the summaries I
>>>> wrote in the blogs first and then dive into the code related to the part
>>>> you interest one by one.
>>>>
>>>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <https://github.com/apache/incubator-dubbo/tree/dev-metadata>
>>>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <https://github.com/apache/incubator-dubbo/issues/2030>
>>>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <https://github.com/apache/incubator-dubbo/issues/2341>
>>>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <https://github.com/apache/incubator-dubbo/issues/2919>
>>>>
>>>> Jun
>>>>
>>>>
>>>
>>> --
>>>
>>> Best Regard!
>>> cvitory
>>
>
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and
implementations.
Posted by jun liu <ke...@gmail.com>.
> Dubbo OPS is about to release the first version, it supports service
> governance features in Dubbo2.7, including tag route, application scope
> rules, metadata report, etc. I've deployed a demo here:
> http://47.91.207.147/#/service <http://47.91.207.147/#/service>.
Great!
I have tried and encountered some problems when adding and updating governance rules yesterday, I will report Github issues later.
Jun
> On Dec 21, 2018, at 3:08 PM, Minxuan Zhuang <z8...@gmail.com> wrote:
>
> Dubbo OPS is about to release the first version, it supports service
> governance features in Dubbo2.7, including tag route, application scope
> rules, metadata report, etc. I've deployed a demo here:
> http://47.91.207.147/#/service <http://47.91.207.147/#/service>.
> the code locates here:
> https://github.com/apache/incubator-dubbo-ops/tree/metadata <https://github.com/apache/incubator-dubbo-ops/tree/metadata>, and I'll merge
> it to develop branch later.
>
> On Fri, Dec 21, 2018 at 11:37 AM jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>> wrote:
>
>> Two more things to mention:
>>
>> 1. I am thinking of merge this dev-metadata branch back to the master.
>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
>> together consist of v2.7’s release candidates. While they are evolving at
>> the same time concurrently, conflicts keep happening. I have been kept
>> merging the master branch to dev-metadata to try to avoid conflicts to the
>> most extend during the development of dev-metadata. Now, since the changes
>> in dev-metadata are stable enough, at least it won’t be a block for the
>> development in master (which is also the biggest concern why we created
>> this new branch), I think it’s time for us to merge the changes back and
>> work on the unified master branch.
>>
>> 2. Is there any plan for the release of OPS? Most of the new features
>> introduced in v2.7 are service governance related abilities and most users
>> have get used to using Dubbo OPS to do interoperability with their Dubbo
>> services. Thus I think it would be great if an OPS version supporting these
>> features can be released at the same time as v2.7 or slightly after it .
>> @Minxuan @Majinkai, I know you guys are working on OPS project, any news
>> to update?
>>
>> Jun
>>
>>> On Dec 21, 2018, at 10:35 AM, jun liu <ke...@gmail.com> wrote:
>>>
>>>> 1. Prioritization of centralized configuration
>>>
>>> Now, the centralized configuration or externalized configuration is
>> implemented to has the highest priority by default. For flexible concerns,
>> a switch is designed and opened to users so that they can override the
>> default value, for example, you can use the following JVM property to give
>> centralized configuration a lower priority than the local one:
>> dubbo.configCenter.highestPriority=false.
>>>
>>>> 2. The logic of the route is more complicated, and the compatibility
>> with
>>>> the original low version is guaranteed.
>>>
>>> When saying of complexity, I guess you mainly refer to the routing
>> module, because this module is one of the most evident parts that has
>> changed in this version and is also newly introduced. Its main purpose is
>> to improve the performance of the runtime. After all, there will be some
>> performance loss when routing is executed for address filtering every time
>> an RPC is executed.
>>> However, I agree we should be really careful about this cache part since
>> it works as an crucial path on the RPC wire. Some possible drawbacks I can
>> come up with it now are: excessive resource usage, priority guarantee of
>> routers in chain, etc. I think we can discuss more about the technical
>> details of this part, give it more test and then decide whether to release
>> it this time or wait until it’s mature enough.
>>>
>>>> 3.Tag routing has been modified, how is the compatibility with the
>> original?
>>>
>>> It has full backward compatibility with the original implementation with
>> only the supporting of of DynamicConfiguration added.
>>>
>>>> 4. How does the Environment clear responsibility? It is best to have an
>>>> independent description.
>>>
>>> Sorry, I don’t understand this one. Basically, you can think Environment
>> as the counterpart of that in Spring. I agree we should add a document
>> describing the design purpose and how to use it.
>>>
>>> Jun
>>>
>>>> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com <ma...@gmail.com> <mailto:
>> shenglicao2@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>> All of this features are the biggest concert in the community.
>>>> I have some questions：
>>>> 1.中心化配置的优先级
>>>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>>>> 3.Tag路由改造了，和原来的兼容性怎么样？
>>>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>>>> ----------
>>>> 1. Prioritization of centralized configuration
>>>> 2. The logic of the route is more complicated, and the compatibility
>> with
>>>> the original low version is guaranteed.
>>>> 3.Tag routing has been modified, how is the compatibility with the
>> original?
>>>> 4. How does the Environment clear responsibility? It is best to have an
>>>> independent description.
>>>>
>>>>
>>>> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com> <mailto:ken.lj.hz@gmail.com <ma...@gmail.com>>>
>> 于2018年12月7日周五 下午8:11写道：
>>>>
>>>>> Hi, All
>>>>>
>>>>> I’ve just posted some blogs[4] on Github issues relating to the design
>>>>> principles and implementations of V2.7.0, the content are based
>> mainly on
>>>>> my own understanding of the 2.7.0 codebase (hosted on branch
>>>>> dev-metadata[1]) and the previous discussions[2][3].
>>>>>
>>>>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
>>>>> metadata refactoring, I am happy to see that v2.7.0 is on a right
>> direction
>>>>> to meet community requirements and keeps evolving. The main changes or
>>>>> features already included in v2.7.0 branch are:
>>>>>
>>>>> * Config Center: Zookeeper, Apollo, Nacos
>>>>> * Externalized Configuration
>>>>> * Service governance enhancement: dynamic configuration & routing rule
>>>>> * Repackage to 'org.apache.dubbo'
>>>>> * Java 8 support
>>>>> * Async programming support
>>>>>
>>>>> Most of the features above have been mentioned or discussed on the
>> mailing
>>>>> list or Github issues days or months ago. But during the design and
>> coding
>>>>> process, more details come up that need to be further discussed and
>>>>> decided. The design principles and implementations on v2.7.0 branch
>> now are
>>>>> far from the the final decision, they may be not the best choice or
>> even
>>>>> turn to be unreasonable, so you can think them as a prototype
>>>>> implementation provided for your reference. Now, we need to know your
>>>>> opinions on v2.7.0, please help to review the designs and codes,
>> whenever
>>>>> you have better ideas or suggestions, please don’t hesitate to let the
>>>>> community know.
>>>>>
>>>>> FYI: If you want to know more implementation details and try to read
>> the
>>>>> codes or commits directly, you may find it hard to follow, because
>> there’re
>>>>> too much file changes in there. So I would suggest you read the
>> summaries I
>>>>> wrote in the blogs first and then dive into the code related to the
>> part
>>>>> you interest one by one.
>>>>>
>>>>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <https://github.com/apache/incubator-dubbo/tree/dev-metadata> <
>> https://github.com/apache/incubator-dubbo/tree/dev-metadata <https://github.com/apache/incubator-dubbo/tree/dev-metadata>>
>>>>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <https://github.com/apache/incubator-dubbo/issues/2030> <
>> https://github.com/apache/incubator-dubbo/issues/2030 <https://github.com/apache/incubator-dubbo/issues/2030>>
>>>>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <https://github.com/apache/incubator-dubbo/issues/2341> <
>> https://github.com/apache/incubator-dubbo/issues/2341 <https://github.com/apache/incubator-dubbo/issues/2341>>
>>>>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <https://github.com/apache/incubator-dubbo/issues/2919> <
>> https://github.com/apache/incubator-dubbo/issues/2919 <https://github.com/apache/incubator-dubbo/issues/2919>>
>>>>>
>>>>> Jun
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> Best Regard!
>>>> cvitory
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.
Posted by Minxuan Zhuang <z8...@gmail.com>.
Dubbo OPS is about to release the first version, it supports service
governance features in Dubbo2.7, including tag route, application scope
rules, metadata report, etc. I've deployed a demo here:
http://47.91.207.147/#/service.
the code locates here:
https://github.com/apache/incubator-dubbo-ops/tree/metadata, and I'll merge
it to develop branch later.
On Fri, Dec 21, 2018 at 11:37 AM jun liu <ke...@gmail.com> wrote:
> Two more things to mention:
>
> 1. I am thinking of merge this dev-metadata branch back to the master.
> Both these two branches have the same version 2.7.0-SNAPSHOT and they
> together consist of v2.7’s release candidates. While they are evolving at
> the same time concurrently, conflicts keep happening. I have been kept
> merging the master branch to dev-metadata to try to avoid conflicts to the
> most extend during the development of dev-metadata. Now, since the changes
> in dev-metadata are stable enough, at least it won’t be a block for the
> development in master (which is also the biggest concern why we created
> this new branch), I think it’s time for us to merge the changes back and
> work on the unified master branch.
>
> 2. Is there any plan for the release of OPS? Most of the new features
> introduced in v2.7 are service governance related abilities and most users
> have get used to using Dubbo OPS to do interoperability with their Dubbo
> services. Thus I think it would be great if an OPS version supporting these
> features can be released at the same time as v2.7 or slightly after it .
> @Minxuan @Majinkai, I know you guys are working on OPS project, any news
> to update?
>
> Jun
>
> > On Dec 21, 2018, at 10:35 AM, jun liu <ke...@gmail.com> wrote:
> >
> >> 1. Prioritization of centralized configuration
> >
> > Now, the centralized configuration or externalized configuration is
> implemented to has the highest priority by default. For flexible concerns,
> a switch is designed and opened to users so that they can override the
> default value, for example, you can use the following JVM property to give
> centralized configuration a lower priority than the local one:
> dubbo.configCenter.highestPriority=false.
> >
> >> 2. The logic of the route is more complicated, and the compatibility
> with
> >> the original low version is guaranteed.
> >
> > When saying of complexity, I guess you mainly refer to the routing
> module, because this module is one of the most evident parts that has
> changed in this version and is also newly introduced. Its main purpose is
> to improve the performance of the runtime. After all, there will be some
> performance loss when routing is executed for address filtering every time
> an RPC is executed.
> > However, I agree we should be really careful about this cache part since
> it works as an crucial path on the RPC wire. Some possible drawbacks I can
> come up with it now are: excessive resource usage, priority guarantee of
> routers in chain, etc. I think we can discuss more about the technical
> details of this part, give it more test and then decide whether to release
> it this time or wait until it’s mature enough.
> >
> >> 3.Tag routing has been modified, how is the compatibility with the
> original?
> >
> > It has full backward compatibility with the original implementation with
> only the supporting of of DynamicConfiguration added.
> >
> >> 4. How does the Environment clear responsibility? It is best to have an
> >> independent description.
> >
> > Sorry, I don’t understand this one. Basically, you can think Environment
> as the counterpart of that in Spring. I agree we should add a document
> describing the design purpose and how to use it.
> >
> > Jun
> >
> >> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com <mailto:
> shenglicao2@gmail.com>> wrote:
> >>
> >> All of this features are the biggest concert in the community.
> >> I have some questions：
> >> 1.中心化配置的优先级
> >> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
> >> 3.Tag路由改造了，和原来的兼容性怎么样？
> >> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
> >> ----------
> >> 1. Prioritization of centralized configuration
> >> 2. The logic of the route is more complicated, and the compatibility
> with
> >> the original low version is guaranteed.
> >> 3.Tag routing has been modified, how is the compatibility with the
> original?
> >> 4. How does the Environment clear responsibility? It is best to have an
> >> independent description.
> >>
> >>
> >> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>>
> 于2018年12月7日周五 下午8:11写道：
> >>
> >>> Hi, All
> >>>
> >>> I’ve just posted some blogs[4] on Github issues relating to the design
> >>> principles and implementations of V2.7.0, the content are based
> mainly on
> >>> my own understanding of the 2.7.0 codebase (hosted on branch
> >>> dev-metadata[1]) and the previous discussions[2][3].
> >>>
> >>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
> >>> metadata refactoring, I am happy to see that v2.7.0 is on a right
> direction
> >>> to meet community requirements and keeps evolving. The main changes or
> >>> features already included in v2.7.0 branch are:
> >>>
> >>> * Config Center: Zookeeper, Apollo, Nacos
> >>> * Externalized Configuration
> >>> * Service governance enhancement: dynamic configuration & routing rule
> >>> * Repackage to 'org.apache.dubbo'
> >>> * Java 8 support
> >>> * Async programming support
> >>>
> >>> Most of the features above have been mentioned or discussed on the
> mailing
> >>> list or Github issues days or months ago. But during the design and
> coding
> >>> process, more details come up that need to be further discussed and
> >>> decided. The design principles and implementations on v2.7.0 branch
> now are
> >>> far from the the final decision, they may be not the best choice or
> even
> >>> turn to be unreasonable, so you can think them as a prototype
> >>> implementation provided for your reference. Now, we need to know your
> >>> opinions on v2.7.0, please help to review the designs and codes,
> whenever
> >>> you have better ideas or suggestions, please don’t hesitate to let the
> >>> community know.
> >>>
> >>> FYI: If you want to know more implementation details and try to read
> the
> >>> codes or commits directly, you may find it hard to follow, because
> there’re
> >>> too much file changes in there. So I would suggest you read the
> summaries I
> >>> wrote in the blogs first and then dive into the code related to the
> part
> >>> you interest one by one.
> >>>
> >>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <
> https://github.com/apache/incubator-dubbo/tree/dev-metadata>
> >>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <
> https://github.com/apache/incubator-dubbo/issues/2030>
> >>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <
> https://github.com/apache/incubator-dubbo/issues/2341>
> >>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <
> https://github.com/apache/incubator-dubbo/issues/2919>
> >>>
> >>> Jun
> >>>
> >>>
> >>
> >> --
> >>
> >> Best Regard!
> >> cvitory
> >
>
>
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and
implementations.
Posted by jun liu <ke...@gmail.com>.
Two more things to mention:
1. I am thinking of merge this dev-metadata branch back to the master. Both these two branches have the same version 2.7.0-SNAPSHOT and they together consist of v2.7’s release candidates. While they are evolving at the same time concurrently, conflicts keep happening. I have been kept merging the master branch to dev-metadata to try to avoid conflicts to the most extend during the development of dev-metadata. Now, since the changes in dev-metadata are stable enough, at least it won’t be a block for the development in master (which is also the biggest concern why we created this new branch), I think it’s time for us to merge the changes back and work on the unified master branch.
2. Is there any plan for the release of OPS? Most of the new features introduced in v2.7 are service governance related abilities and most users have get used to using Dubbo OPS to do interoperability with their Dubbo services. Thus I think it would be great if an OPS version supporting these features can be released at the same time as v2.7 or slightly after it .
@Minxuan @Majinkai, I know you guys are working on OPS project, any news to update?
Jun
> On Dec 21, 2018, at 10:35 AM, jun liu <ke...@gmail.com> wrote:
>
>> 1. Prioritization of centralized configuration
>
> Now, the centralized configuration or externalized configuration is implemented to has the highest priority by default. For flexible concerns, a switch is designed and opened to users so that they can override the default value, for example, you can use the following JVM property to give centralized configuration a lower priority than the local one: dubbo.configCenter.highestPriority=false.
>
>> 2. The logic of the route is more complicated, and the compatibility with
>> the original low version is guaranteed.
>
> When saying of complexity, I guess you mainly refer to the routing module, because this module is one of the most evident parts that has changed in this version and is also newly introduced. Its main purpose is to improve the performance of the runtime. After all, there will be some performance loss when routing is executed for address filtering every time an RPC is executed.
> However, I agree we should be really careful about this cache part since it works as an crucial path on the RPC wire. Some possible drawbacks I can come up with it now are: excessive resource usage, priority guarantee of routers in chain, etc. I think we can discuss more about the technical details of this part, give it more test and then decide whether to release it this time or wait until it’s mature enough.
>
>> 3.Tag routing has been modified, how is the compatibility with the original?
>
> It has full backward compatibility with the original implementation with only the supporting of of DynamicConfiguration added.
>
>> 4. How does the Environment clear responsibility? It is best to have an
>> independent description.
>
> Sorry, I don’t understand this one. Basically, you can think Environment as the counterpart of that in Spring. I agree we should add a document describing the design purpose and how to use it.
>
> Jun
>
>> On Dec 14, 2018, at 12:26 PM, victory <shenglicao2@gmail.com <ma...@gmail.com>> wrote:
>>
>> All of this features are the biggest concert in the community.
>> I have some questions：
>> 1.中心化配置的优先级
>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>> 3.Tag路由改造了，和原来的兼容性怎么样？
>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>> ----------
>> 1. Prioritization of centralized configuration
>> 2. The logic of the route is more complicated, and the compatibility with
>> the original low version is guaranteed.
>> 3.Tag routing has been modified, how is the compatibility with the original?
>> 4. How does the Environment clear responsibility? It is best to have an
>> independent description.
>>
>>
>> jun liu <ken.lj.hz@gmail.com <ma...@gmail.com>> 于2018年12月7日周五 下午8:11写道：
>>
>>> Hi, All
>>>
>>> I’ve just posted some blogs[4] on Github issues relating to the design
>>> principles and implementations of V2.7.0, the content are based mainly on
>>> my own understanding of the 2.7.0 codebase (hosted on branch
>>> dev-metadata[1]) and the previous discussions[2][3].
>>>
>>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
>>> metadata refactoring, I am happy to see that v2.7.0 is on a right direction
>>> to meet community requirements and keeps evolving. The main changes or
>>> features already included in v2.7.0 branch are:
>>>
>>> * Config Center: Zookeeper, Apollo, Nacos
>>> * Externalized Configuration
>>> * Service governance enhancement: dynamic configuration & routing rule
>>> * Repackage to 'org.apache.dubbo'
>>> * Java 8 support
>>> * Async programming support
>>>
>>> Most of the features above have been mentioned or discussed on the mailing
>>> list or Github issues days or months ago. But during the design and coding
>>> process, more details come up that need to be further discussed and
>>> decided. The design principles and implementations on v2.7.0 branch now are
>>> far from the the final decision, they may be not the best choice or even
>>> turn to be unreasonable, so you can think them as a prototype
>>> implementation provided for your reference. Now, we need to know your
>>> opinions on v2.7.0, please help to review the designs and codes, whenever
>>> you have better ideas or suggestions, please don’t hesitate to let the
>>> community know.
>>>
>>> FYI: If you want to know more implementation details and try to read the
>>> codes or commits directly, you may find it hard to follow, because there’re
>>> too much file changes in there. So I would suggest you read the summaries I
>>> wrote in the blogs first and then dive into the code related to the part
>>> you interest one by one.
>>>
>>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata <https://github.com/apache/incubator-dubbo/tree/dev-metadata>
>>> 2. https://github.com/apache/incubator-dubbo/issues/2030 <https://github.com/apache/incubator-dubbo/issues/2030>
>>> 3. https://github.com/apache/incubator-dubbo/issues/2341 <https://github.com/apache/incubator-dubbo/issues/2341>
>>> 4. https://github.com/apache/incubator-dubbo/issues/2919 <https://github.com/apache/incubator-dubbo/issues/2919>
>>>
>>> Jun
>>>
>>>
>>
>> --
>>
>> Best Regard!
>> cvitory
>
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and
implementations.
Posted by jun liu <ke...@gmail.com>.
> 1. Prioritization of centralized configuration
Now, the centralized configuration or externalized configuration is implemented to has the highest priority by default. For flexible concerns, a switch is designed and opened to users so that they can override the default value, for example, you can use the following JVM property to give centralized configuration a lower priority than the local one: dubbo.configCenter.highestPriority=false.
> 2. The logic of the route is more complicated, and the compatibility with
> the original low version is guaranteed.
When saying of complexity, I guess you mainly refer to the routing module, because this module is one of the most evident parts that has changed in this version and is also newly introduced. Its main purpose is to improve the performance of the runtime. After all, there will be some performance loss when routing is executed for address filtering every time an RPC is executed.
However, I agree we should be really careful about this cache part since it works as an crucial path on the RPC wire. Some possible drawbacks I can come up with it now are: excessive resource usage, priority guarantee of routers in chain, etc. I think we can discuss more about the technical details of this part, give it more test and then decide whether to release it this time or wait until it’s mature enough.
> 3.Tag routing has been modified, how is the compatibility with the original?
It has full backward compatibility with the original implementation with only the supporting of of DynamicConfiguration added.
> 4. How does the Environment clear responsibility? It is best to have an
> independent description.
Sorry, I don’t understand this one. Basically, you can think Environment as the counterpart of that in Spring. I agree we should add a document describing the design purpose and how to use it.
Jun
> On Dec 14, 2018, at 12:26 PM, victory <sh...@gmail.com> wrote:
>
> All of this features are the biggest concert in the community.
> I have some questions：
> 1.中心化配置的优先级
> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
> 3.Tag路由改造了，和原来的兼容性怎么样？
> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
> ----------
> 1. Prioritization of centralized configuration
> 2. The logic of the route is more complicated, and the compatibility with
> the original low version is guaranteed.
> 3.Tag routing has been modified, how is the compatibility with the original?
> 4. How does the Environment clear responsibility? It is best to have an
> independent description.
>
>
> jun liu <ke...@gmail.com> 于2018年12月7日周五 下午8:11写道：
>
>> Hi, All
>>
>> I’ve just posted some blogs[4] on Github issues relating to the design
>> principles and implementations of V2.7.0, the content are based mainly on
>> my own understanding of the 2.7.0 codebase (hosted on branch
>> dev-metadata[1]) and the previous discussions[2][3].
>>
>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
>> metadata refactoring, I am happy to see that v2.7.0 is on a right direction
>> to meet community requirements and keeps evolving. The main changes or
>> features already included in v2.7.0 branch are:
>>
>> * Config Center: Zookeeper, Apollo, Nacos
>> * Externalized Configuration
>> * Service governance enhancement: dynamic configuration & routing rule
>> * Repackage to 'org.apache.dubbo'
>> * Java 8 support
>> * Async programming support
>>
>> Most of the features above have been mentioned or discussed on the mailing
>> list or Github issues days or months ago. But during the design and coding
>> process, more details come up that need to be further discussed and
>> decided. The design principles and implementations on v2.7.0 branch now are
>> far from the the final decision, they may be not the best choice or even
>> turn to be unreasonable, so you can think them as a prototype
>> implementation provided for your reference. Now, we need to know your
>> opinions on v2.7.0, please help to review the designs and codes, whenever
>> you have better ideas or suggestions, please don’t hesitate to let the
>> community know.
>>
>> FYI: If you want to know more implementation details and try to read the
>> codes or commits directly, you may find it hard to follow, because there’re
>> too much file changes in there. So I would suggest you read the summaries I
>> wrote in the blogs first and then dive into the code related to the part
>> you interest one by one.
>>
>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata
>> 2. https://github.com/apache/incubator-dubbo/issues/2030
>> 3. https://github.com/apache/incubator-dubbo/issues/2341
>> 4. https://github.com/apache/incubator-dubbo/issues/2919
>>
>> Jun
>>
>>
>
> --
>
> Best Regard!
> cvitory
Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.
Posted by victory <sh...@gmail.com>.
All of this features are the biggest concert in the community.
I have some questions：
1.中心化配置的优先级
2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
3.Tag路由改造了，和原来的兼容性怎么样？
4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
----------
1. Prioritization of centralized configuration
2. The logic of the route is more complicated, and the compatibility with
the original low version is guaranteed.
3.Tag routing has been modified, how is the compatibility with the original?
4. How does the Environment clear responsibility? It is best to have an
independent description.
jun liu <ke...@gmail.com> 于2018年12月7日周五 下午8:11写道：
> Hi, All
>
> I’ve just posted some blogs[4] on Github issues relating to the design
> principles and implementations of V2.7.0, the content are based mainly on
> my own understanding of the 2.7.0 codebase (hosted on branch
> dev-metadata[1]) and the previous discussions[2][3].
>
> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
> metadata refactoring, I am happy to see that v2.7.0 is on a right direction
> to meet community requirements and keeps evolving. The main changes or
> features already included in v2.7.0 branch are:
>
> * Config Center: Zookeeper, Apollo, Nacos
> * Externalized Configuration
> * Service governance enhancement: dynamic configuration & routing rule
> * Repackage to 'org.apache.dubbo'
> * Java 8 support
> * Async programming support
>
> Most of the features above have been mentioned or discussed on the mailing
> list or Github issues days or months ago. But during the design and coding
> process, more details come up that need to be further discussed and
> decided. The design principles and implementations on v2.7.0 branch now are
> far from the the final decision, they may be not the best choice or even
> turn to be unreasonable, so you can think them as a prototype
> implementation provided for your reference. Now, we need to know your
> opinions on v2.7.0, please help to review the designs and codes, whenever
> you have better ideas or suggestions, please don’t hesitate to let the
> community know.
>
> FYI: If you want to know more implementation details and try to read the
> codes or commits directly, you may find it hard to follow, because there’re
> too much file changes in there. So I would suggest you read the summaries I
> wrote in the blogs first and then dive into the code related to the part
> you interest one by one.
>
> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata
> 2. https://github.com/apache/incubator-dubbo/issues/2030
> 3. https://github.com/apache/incubator-dubbo/issues/2341
> 4. https://github.com/apache/incubator-dubbo/issues/2919
>
> Jun
>
>
--
Best Regard!
cvitory