How to communicate two microservices with different ports?

 When two microservices need to communicate with each other but are running on different ports, there are a few approaches :

1. 1.Direct Communication: If the microservices are deployed on the same network or infrastructure, they can communicate directly using their network addresses. You can use HTTP or any other appropriate protocol for communication. In this approach, each microservice would need to know the network address (IP address or domain name) and the port of the other microservice.

2. Example:

3. Microservice A running on port 8080 wants to communicate with Microservice B running on port 9090. Microservice A can make an HTTP request to Microservice B using its network address and port:

4. HttpClient client = HttpClient.newHttpClient(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create("http://localhost:9090/api/resource")) .build(); HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());

5. 
   

6. 2.Service Discovery: Service discovery is a mechanism that allows microservices to locate and communicate with each other dynamically. Instead of hardcoding network addresses, you can utilize a service registry (e.g., Consul, Eureka, or ZooKeeper) that keeps track of available services and their network locations. Microservices can register themselves with the service registry upon startup and discover other services when needed. The service registry acts as a central point for service discovery, enabling communication between microservices regardless of their ports.

7. Example : Microservice A and Microservice B register themselves with a service registry (e.g., Consul). When Microservice A needs to communicate with Microservice B, it queries the service registry to discover the network address and port of Microservice B dynamically:

// Pseudo code for service discovery using Consul

String serviceUrl = consulClient.lookupServiceUrl("microservice-b");

// Use serviceUrl for communication

1. 
   

2. 3.API Gateway: An API gateway acts as an entry point for clients and can also help in communication between microservices. You can configure the API gateway to route requests to the appropriate microservice based on the request path or other criteria. This way, the microservices can run on different ports, but clients communicate with a single endpoint provided by the API gateway. The API gateway handles the routing and forwarding of requests to the appropriate microservice.

3. Example:

4. Microservice A and Microservice B run on different ports, but they are exposed through an API gateway running on port 8080. Clients make requests to the API gateway, which routes the requests to the appropriate microservice:

5. // Request from the client to the API gateway (running on port 8080) GET http://localhost:8080/microservice-a/api/resource

The API gateway handles the request and forwards it to Microservice A running on a different port.

1. 
   

2. 4.Message Queue/Message Broker: Another approach is to use a message queue or message broker system like Apache Kafka or RabbitMQ. Microservices can communicate by publishing messages to a specific topic or queue, and the receiving microservice can consume those messages from the queue. The message broker acts as an intermediary, decoupling the communication between microservices. Each microservice would need to connect to the message broker using its own port, and the broker takes care of routing messages between them.

3. Example :

4. Microservice A and Microservice B communicate through a message broker (e.g., Apache Kafka). Microservice A produces a message to a specific topic, and Microservice B consumes messages from that topic:

5. 
   

6. // Microservice A (producer) kafkaProducer.send(new ProducerRecord<>("my-topic", "message")); // Microservice B (consumer) ConsumerRecords<String, String> records = kafkaConsumer.poll(Duration.ofMillis(100)); for (ConsumerRecord<String, String> record : records) { // Process the received message }

7. 
   

The choice of approach depends on factors such as the complexity of your microservices architecture, scalability requirements, and specific use cases. Consider the characteristics of your system and select the most suitable approach for your scenario.