Thanks kirito for making a new big feature at first time. The key point is with current implement, an invocation with a tag can't return all invokers in TagRouter.
So I suggest here: Add a forceTag flag(TAG_FORCE_KEY = "tag.force"), default value is false. 1. When it's true, TagRouter strickly match invokers' tag. - An invocation with "black" tag only match invokers with "black" tag. - An invocation with empty tag only match invokers withempty tag. - An invocation match no invokers will return no invokers. 2. When it's false(default), TagRouter match invokers' tag by the most invokers strategy. - An invocation with "black" tag match invokers with "black" tag. If no invokers with "black" tag, return all invokers. - An invocation with empty tag will match all invokers. - An invocation match no invokers will return all invokers. Then we can cover all condition for using TagRouter. And I pull request my codes with all tests here, we can review and complete it now: https://github.com/apache/incubator-dubbo/pull/2343 在 2018-08-24 01:58:01，"徐靖峰" <kirito....@foxmail.com> 写道： >Hi, community. This mail is related to this issue.A simple and incomplete >TagRouter has merged into dubbo v2.7.0-snapshot，in this mail，i will introduce >what problem did it solve. At the end of the letter, i want to refer to your >opinion and proposal, decide the final behavior of TagRouter . > >What is TagRouter > >TagRouter is a new implement of Router interface, other exsiting Router : >ConditionRouter, ScriptRouter, FileRouter. > >It makes any request can carry a request.tag and any service belong to a >certain tagTag will affect the default route behavior. > >Some pain points in the past > > > >fact1: some applications changed at the same time in different branch,like >A,B,C.fact2: some applications didn't change ,but deploy repeatedly，like >D,E.fact3: if a new feature need to be tested, all 5 application need to be >deployed.fact4: isolation by feature is not friendly to parallel development. > >Benefited from tag > > > >we consider the RED，YELLOW，BLUE as tagged service , the grey block as origin >service or normal service. > >The benefit we have is that we have reduced a lot of overhead about >application deployment. Only changed applications need deploy incrementally . > >A vivid example > > > >Usage > >consumer >RpcContext.getContext().setAttachment("request.tag","red"); >I suggest you can use filter or SPI to set this attachment, notice that >RpcContext is bound to Thread. > >provider >@Bean >public ApplicationConfig applicationConfig() { > ApplicationConfig applicationConfig = new ApplicationConfig(); > applicationConfig.setName("provider-book"); > // instruct tag router > Map<String,String> parameters = new HashMap<>(); > parameters.put(Constants.ROUTER_KEY, "tag"); > applicationConfig.setParameters(parameters); > return applicationConfig; >} >Need more discussion > > >If a tag request can not find any application of the same tag，should it use >other application of different tag (NOTICE : different tag is not the default >application with grey block) > > > >If a normal request can not find normal application，should it use any tag >application?(in my opinion，normal request should not reach the tag >application，also the current version). > > > >A forceTag flag can be considered to decided the behavior of downgrade. >forceTag=true means all tag requests must strictly match the application's >tag；forceTag=false means tag requests will prefer the application of the same >tag，if there is no corresponding application， downgrade to other >application，ignore the tag. > > > >On the basis of 3. what is default value of foreTag TRUE or FALSE. > > >more suggestions are welcome to make.
