微服务架构中的HTTP vs Thrift

Question

I'm have just start learning about micro-services and I have a question that I cannot answer myself. (and I'm also a Java based developer)

I have a situation like this:

1. I have service A (an API service) that call Thrift services (Named T1) for get data.

2. Then I have a service B that can use data response from A, parse these data and then generate some new data, finally, return it to client.

The question is: Which I should use? B call API from A and parse (for example JSON data) with HttpClient/ AsyncHttpClient with connection pool or B direct call T1 and repeat what A do?

IMHO, I think Thrift (with connection pooling too) is faster than HTTP call? Am I right?

I see a lot of services that use HTTP for internal like Elastic search, Neo4j, Eureka Netflix, etc ...

So, which one should I use? And why HTTP is so popular for internal use instead of RPC like Thrift, ProtoBuf, ...?

Sorry for my bad english. Thank you in advance.

Answer 1

HTTP and JSON or XML are generally used because they're platform and language independent. The HTTP API allows for a ReSTful architecture, which has proven to be a scalable model for developing distributed systems.

Historically, RPC-based approaches to distributed systems have shown a number of weak points:

• often they're language dependent. Thrift and Protobuf are more interoperable but they're still dependent on fairly specific 3rd party libraries. In comparison, there are many implementations of HTTP clients and XML or JSON data bindings / processors.

• by tying together the client and server upgrades can become difficult - the client often must be upgraded at the same time as the server. In a truly distributed network this can be impossible.

• RPC is often not a great metaphor in a distributed system. By abstracting the network to an implementation concern they often encourage low-level 'chatty' interfaces which either involve too much network traffic or are not resilient to unreliable networks.

• binary transfer formats are more difficult to analyse / debug when something goes wrong.

For these kinds of reasons people tend to choose Rest-with-HTTP-based APIs over proprietary RPC APIs.