How the microservice components of Server VRT communicates with each other?

Vahana Runtime (VRT)
1

I was wondering how the microservice components of Server VRT communicates with each other?

What kind of microservice architecture pattern do we follow?

@Vikas_Dhillon @naks @shivang.garg @naveen.gupta

2

VRT microservices communicate with each other using the Service Discovery design pattern, which involves a central discovery server. Here’s how two microservices, let’s call them Service A and Service B, communicate with each other using this pattern:

  1. Service Registration:
  • When Service A and Service B start up, they register themselves with the Service Discovery Server. During registration, each service provides information such as its hostname, port, and any metadata that helps identify the service.
  1. Heartbeating:
  • Both Service A and Service B regularly send heartbeats or health checks to the Service Discovery Server. This serves two purposes:
    • It helps the server keep track of which services are currently running and healthy.
    • It allows the server to detect when a service becomes unhealthy or goes offline.
  1. Service Lookup:
  • When Service A wants to communicate with Service B, it queries the Service Discovery Server for the location of Service B. This query is typically done by specifying the service name or a unique identifier associated with Service B.
  1. Response from Discovery Server:
  • The Service Discovery Server responds to the query from Service A with information about the location of Service B. This information can include the hostname, port, and potentially other metadata.
  1. Communication:
  • Service A uses the information provided by the Service Discovery Server to send requests directly to Service B. It may use the hostname and port to create an HTTP or gRPC request or use other appropriate communication protocols.
  1. Dynamic Updates:
  • If Service B becomes unhealthy or is taken offline for maintenance, the Service Discovery Server can detect this through failed heartbeats or health checks. It then removes the unhealthy instance of Service B from its list of available services.
  • When a new instance of Service B comes online, it registers itself with the Service Discovery Server, making it available for discovery and communication.
  1. Load Balancing:
  • The Service Discovery Server may also provide load balancing capabilities. If multiple instances of Service B are available, the Service Discovery Server can distribute incoming requests from Service A among these instances to ensure high availability and scalability.
  1. Security:
  • Access control and security considerations are crucial. Service A may need to authenticate itself with Service B, and the communication between the services should be secured. These security measures can be implemented at the service level or with the help of additional components like API Gateways.
5 Likes