O
O
Optimus2017-07-18 20:13:46
Software design
Optimus, 2017-07-18 20:13:46

How to interact with a microservice architecture?

The question is how to minimize speed losses if there are a lot of microservices in the project? By what protocols can they interact at all?
For example, take PHP, there are websockets, then a CURL wrapper on websockets, well, guzzle, etc. we do not take - these are already libraries. So, if you use the curl http protocol, then there are 130-200 requests per minute, depending on the response speed of the server that we are requesting, but even if it responds quickly, there is still overhead for establishing a connection, etc. pieces.
How can you increase the number of requests by tens and hundreds of times? Another protocol, lower level communication?
Considering the PHP scripting language, the entire script will not complete there while the request-response goes, with a large number this whole thing will devour a lot of memory and there will be a complete hat ...

Answer the question

In order to leave comments, you need to log in

1 answer(s)
L
laxikodeje, 2017-07-18
Pyan @marrk2

I would generally recommend the protobuf protocol for microservices.
or gRPC.
they themselves already know how to work correctly on top of lower-level protocols.
I think there are already ready-made binding libraries for PHP.
and for sure they implement the technology of "connection pools", which allows you not to break the connection for quite a long time.
UDP can also be considered as the fastest alternative. If you have a reliable connection between services and short messages - I think this will be extremely efficient and without complex programming.
similarly, websockets should be efficient.
but, with a connection pool.
but this all assumes that your PHP microservice is running and not restarted for quite a long time (hours, or at least minutes and tens of minutes). otherwise, all optimizations are meaningless
, there are 2 modes for running PHP scripts.
the one that is used for small shitty websites - there the script is really restarted on request.
and long-term operation of the script. one script handles many requests without restarting.
if you are unable to make the second option, which is actually well suited for a quick implementation, then
consider the option with external MQ servers in relation to your PHP scripts, which will work constantly and do not depend on restarting PHP.
some kind of RabbitMQ, etc.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question