-1

Consider this scenario: I have N>2 software components (microservices) that can communicate through two different communication protocols depending on how they are deployed. In other words, I have two deployment scenarios:

  1. The components are to be deployed on the same machine. In this case I don't know if it makes sense to use HTTP to communicate these two components, if I think about performance. I understand that there are more efficient ways to communicate two processes on the same machine using java, such as sockets, RMI, RPC ...

  2. The components are to be deployed on N different machines. In this case, it seems to me that it makes sense for me to use HTTP to communicate these components.

In short, what I want to do is to be able to configure the communication protocol depending on the way I perform the deployment: On a single machine, for example, use RMI, but when I deploy on two machines, use HTTP.

Does anyone know how I can do this using Spring Boot?

Many Thanks!

AlejoDev
  • 4,345
  • 9
  • 36
  • 67
  • do your two components can communicate with each other use different protocol?if you have implemented your just need to tell components deploy mode through for example use environment variable – TongChen Nov 30 '20 at 06:52
  • @TongChen Yes. The question would be how development is affected within a component, when you have the possibility of using two ways of communicating and how is that done with spring Boot – AlejoDev Nov 30 '20 at 12:02
  • spring profile may helpful. – TongChen Dec 01 '20 at 01:11

2 Answers2

1

Fundamental building block of protocols like RMI or HTTP is socket communication. If you are not looking for the comfort of HTTP or RMI, and priority is performance, pure socket communication is your choice.

This will raise other concerns like, deployment difficulties. You should know IP address of both nodes in advance.

Another option, is to go for unix -domain socket for within server communication. For that you have to depend on JunixSocket.

If you want to go another route, check all inter process communication options.

EDIT

As you said in comment "It is simply no longer a question of two components but of many". In that scenario, each component should be a micro-service And should be capable to interact with each other. If that is the choice most scalable protocol are REST/RPC both are using HTTP protocol under the hood. REST is ideal solution for an API to be developed against a data source using CRUD operations. RPC is more lean towards action oriented API. You can find more details to identify the difference in between REST and RPC here.

Steephen
  • 14,645
  • 7
  • 40
  • 47
  • Thank you very much for your reply and the information you provide. I have updated the question because the scenario is not only client server, any of the components can be client or server. The additional question is whether the cost benefit of HTTP vs a more specialized protocol on the same machine has significant differences – AlejoDev Nov 30 '20 at 12:07
  • Ideally you should not modify your question, that will invalidate the answer I have written already. Best practice is to update your question by additional details at bottom of your question with a subheading `EDIT`. I read your question again, but I could not differentiate your new edit at this point. – Steephen Nov 30 '20 at 17:33
  • Thank you very much for your recommendations. It is simply no longer a question of two components but of many. Where any of them can function as a client or as a server depending on the business logic that each component handles. For example, one that specializes only in authentication and another in scheduling visits, etc. – AlejoDev Nov 30 '20 at 17:44
0

How I understand this is... if the components (producer and consumer) are deployed on the same host then use an optimized protocol and if on different hosts then use HTTP(s) Firstly, there must be a serious driver to go down this route. I take it the driver here is performance. You would like to offer faster performance on local deployment and compartively compromised speeds on distributed deployments. BTW, given that we are in a distributed deployment world (or atleast where we are headed) HTTP will be what will survive. Custom protocols are discouraged.

Anyways... I would say your producer application should be in a self healing / discovery mode. On start-up (or periodically) it could check the health of the "optimized" end-point and decide whether it the optimized receiver is around. The receiver would need to stand behind a load-balancer. If the receiver is not up then go towards HTTP(S) and setup this instance accordingly at runtime.

For the consumer, it would need to keep both the gates (HTTP and optimized) open. It should be ready to handle requests from either channel.

In SpringBoot you can have a healthCheck implmented and switch the emitter on/off depending on the health of optimized end-point. If both end-points are unhealthy then surely the producer cannot emit anything. Apart from this the rest is just normal dependency-injection.

A G
  • 297
  • 1
  • 7
  • Thanks for your reply. I have updated the question because the scenario is not only client server, any of the components can be client or server – AlejoDev Nov 30 '20 at 12:04