CODEWITHSUNDEEP
thrift
marrock
marrock

Reputation: 301

Routing service with Thrift

I have two thrift services:

service S1 {
  A f1(1: R1)
  B f2(1: R2)
}

service S2 {
  C f3(1: R3)
  D f4(1: R4)
}

Now I want to create another Thrift service which has a route method. The method takes the service, function and arguments as input and calls the appropriate function for appropriate client. PseudoCode:

RouterService {
  G route(service, function, [arguments]);
}

Thus the return value of this method would be generic and will depend on the function passed as argument.

Is it possible to do build such a service via Thrift?

Upvotes: 0

Views: 417

Answers (1)

JensG
JensG

Reputation: 13411

Essentialy you will need to build an intermediate service which translates one call into another. This part of the code must be written manually, however it will be a very straightforward and simple piece of code. My recommendation here would be to find (or write) some other code generator that can be utilized to implement that merely boring part of the task for you, instead of writing it manually.

As a proposal, the IDL could look like so:

// router service args structure
union RouterArgs {
  1: R1 r1_args
  2: R2 r2_args
  3: R3 r3_args
  4: R4 r4_args
}

// router service result structure
union RouterResult {
  1: A f1_result
  2: B f2_result
  3: C f3_result
  4: D f4_result
}

enum SvcAndFunc {
  S1_A,
  S1_B,
  S2_C,
  S2_D
}


service RouterService {
  RouterResult route(1 : SvcAndFunc sf, 2: RouterArgs args);
}

A second proposal could involve a router who does not know anything about the args and result data:

service RouterService {
  binary route(1 : string svc, 2: string func, 3: binary args);
}

In that latter case, both args and result are serialized Thrift structures that only depend on the svc and func parameters. By serializing them into a byte buffer (or a JSON string) the routed commands could be made completely transparent to the router. But that flexibility comes at the cost of two additional serialization and deserialization steps per call.

It could also be wort looking at the multiplex protocol which allows to serve multiple services over only one transport/protocol endpoint.

Generally speaking (and especially independently of Thrift), with any translation service approach you always add another conversion layer which will not make the whole thing faster. It will very likely be not so much the translation part itself, but the latencies added due to the two-step call. Nevertheless, and depending on the project priorities, this could be a suitable approach.

Upvotes: 1

Related Questions