Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DISCUSS] Introduce TagRouter, a new route feature. #2341

Closed
lexburner opened this issue Aug 23, 2018 · 4 comments
Closed

[DISCUSS] Introduce TagRouter, a new route feature. #2341

lexburner opened this issue Aug 23, 2018 · 4 comments

Comments

@lexburner
Copy link
Contributor

lexburner commented Aug 23, 2018

Hi, community.
This issue is related to this pull request. A simple and incomplete TagRouter implementation has been merged into dubbo v2.7.0-snapshot.In this issue,i will introduce what problem did it solve,while 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 tag
Tag will affect the default route behavior.

Some pain points in the past

Some pain points

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

isolation by 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

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

  1. 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)
  2. 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).
  3. 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.
  4. On the basis of 3. what is default value of foreTag TRUE or FALSE.

more suggestions are welcome to make.

@kimmking
Copy link
Member

We should discuss issues in mail list.

@diecui1202
Copy link

Since the feature has been merged to master, I'll close this issue.

@bdq460
Copy link

bdq460 commented Oct 29, 2018

Have been supported in version 2.6.4?

@WildWolfBang
Copy link

WildWolfBang commented Jan 27, 2021

Currently, only hardcoding is supported to set requestTag. Note that RpcContext is thread-bound, elegantly using the TagRouter feature, it is recommended to set the request tag via a servlet filter (in the web environment) or a custom Dubbo SPI filter.
RpcContext.getContext().setAttachment(Constants.REQUEST_TAG_KEY,"red");

Hi @lexburner,the Dubbo execute order is routers-->filters, so I wonder how the tag works via a filter without hardcoding when first call a provider.

The method org.apache.dubbo.rpc.cluster.router.tag.TagRouter#filterUsingStaticTag say tag can get from invocation or url. Should we configrate tag in <dubbo:reference /> by parameters?
private <T> List<Invoker<T>> filterUsingStaticTag(List<Invoker<T>> invokers, URL url, Invocation invocation) { List<Invoker<T>> result = invokers; // Dynamic param String tag = StringUtils.isEmpty(invocation.getAttachment(Constants.TAG_KEY)) ? url.getParameter(Constants.TAG_KEY) : invocation.getAttachment(Constants.TAG_KEY);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants