Skip to content

Service Discovery

The ITsynch Suite is composed of multiple Services. These services vary in type:

  1. Utilities Services: scheduling, emailing, etc.
  2. Feature oriented services: Domains, Positions, etc.
  3. Application's APIs services: AIMS API, iInspector API
  4. Third Party services: from other vendors which we access through an API of some kind.

Each of these services may be scaled independently, hence, multiple instances of the same service may be available for consumption by clients at the same time.

A Client consist of any application, service, front/backend, etc that is trying to communicate with a Service.

Service Discovery is a way for any client to discover the address of a service which is needed for the client to perform it's business logic.

The Address of a Service is composed of a DNS name and Port. The DNS name may be an IPv4 or IPv6 instead.

When performing a discovery request, the client will query the Service Registry in order to resolve the address of a service by it's name or unique identifier. The Service Registry is a service in charge of keeping track of each service and where it can be found.

Discovery Process

The Suite utilizes what's known as Client Side Discovery In practice, this means that when a client needs to communicate with a service, the client will query the Service Registry in order to find the address of the desired service.

The client will then choose an Address from the list of possible addresses for a service; this process is known as load balancing.

The Service Discovery implementation supports multiple Registry providers for different scenarios, like cloud vs on-premises. However, a single provider may be used at a time.

Protocol agnostic

Note that Service Discovery per se is not specific to HTTP or other protocols. The process discovers "services", meaning Network Address or hostname/port combinations. That's it.

Hence, when declaring services you never provide the protocol. The service's client library is responsible of knowing the nuances for communicating with the service, including the URI protocol.

On-premises implementation

When deploying on premises, we assume certain things:

  1. It's a mostly static environment. Mostly meaning that hosts are pet servers No dynamic scaling.
  2. They're usually alive and keep the same Address/port combination.
  3. Services are not moved from host to host, they stay at the same host at all times.
  4. They're usually single-instance. Only critical services are scaled.

With this assumptions, we can estimate that we won't have more than 3 to 5 hosts for an on-premise deployment (per ship, in the case of the cruise industry). Hence, using a configuration file per host may be a valid approach.

The Suite's ServiceDiscoveryModule has a default provider, which can read services from .NET's IConfiguration. This combined with the host.config.json file can be used for declaring the address of services for all applications hosted on the same host in a single place. To read more about this, read section.

Cloud-native implementation

For cloud, we still don't have an implementation. However, chances are we will use either Consul or Eureka. In that case, only a new provider implementation is needed.

For implementation details, make sure you read the .NET Service Discovery Module and Angular's Service Discovery Module