Forwarding Thrift service requests across servers running on different machines -

i have ubuntu server running on mac , have thrift servers running on both ubuntu , mac. services each thrift server offers different.

the limitation need expose mac thrift server ip , port clients.

is there way can forward requests coming clients ubuntu server mac thrift server? or matter possible have other broker can have forwarding based on service being requested for?

sure. @ least 3 approaches come mind. depends on how api designed , whether or not able change it.

approach 1: naive approach

handy if can't or won't change api. each request handler function forwardes data another, otherwise similar service shares same thrift idl definitions. same responses. trivial implement, maybe less efficient, because messages need decoded , encoded on proxy, requires have proxy up-to-date , being aware of old versions of api.

approach 2: more generic

to avoid implementing each , every api function on proxy stupid data shuffling, when api going evolve on time, 1 put requests , responses universal wrapper union, so, leaving on single api call als easy implement on proxy:

union allrequests {   1: foorequest foo   2: barrequest bar   // more needed }   union allresponses {   1: fooresponse foo   2: barresponse bar   // more needed }  service fowarding {     allresponses  handlerequest( 1: allrequests request) } 

messages still need decoded , encoded on proxy, plus same considerations re idl versioning apply. additionally, data format quite formal, in fact not bad thing. if @ day want switch mq system, or if plan record/playback service calls using thrift serialization, way go anyway.

approach 3: nested serialization

the payload message can serialized blob, sent proxy server, forwards final destination.

service fowarding {     binary  handlerequest( 1: binary request) } 

the single benefit here is, proxy not need know what's in binary data. transparent him. means, proxy not need know idl used serialize these data. last not least, allows add meta data binary data, if needed optimize routing and/or processing:

struct binaryrequest {   1: binary data   2: string preferredroute } 

the price pay double serialization overhead.