CODEWITHSUNDEEP
architecturemicroservices
Forbsey1
Forbsey1

Reputation: 155

Best Practices for Microservices discovery without Hard Coding?

This is a question that's been annoying me for a while, how does one write a series of microservices that run on on various machines at different locations without the need to hard code each services individual location?

Like say for instance I had service A which does some form of validation of a json message. Service A runs on box 1,3,5 and more instances can be brought up as demand grows.

Now say I have service B which looks to call upon service A, how would I communicate to service B where my service A resides?

Possible Solutions I've considered:

I'm quite new to this architectural style so I'm hoping I've not missed something very simple?

Upvotes: 4

Views: 1685

Answers (2)

Michael
Michael

Reputation: 701

Use a service registry and look up the location of other services at run time. Here are some of the typical technologies used for this (there are others out there).

The service registry must exist in a known location. This location should always be a configurable property in your microservice. Never hard coded! For improved flexibility, it's pretty typical to access the registry endpoint byway of a DNS. So, your service looks for https://registry-1 instead of a specific IP address, which might change.

Depending on the communication mechanism you want in your system, a message queue will help your services communicate, but it will not help with discovery. In this approach you would still use a DNS and configurable properties to tell each microservice the location of the message queue. Individual services would then publish and subscribe messages to the queue. Microservices would never be aware of other services (no discovery) and all communication would be through messages in the queue.

Sam Newman's book on microservices goes into greater detail on these approaches and covers other areas of concern you are likely interested in.

Upvotes: 4

Andrey Chausenko
Andrey Chausenko

Reputation: 897

Generally speaking, there are 2 approaches to implementing service discovery:

  1. with reverse-proxy / api-gateway. This approach provides faster update propagation. When your service is deployed / redeployed / undeployed all changes can be immediately handled by reverse-proxy, so its configuration always reflects the state of your microservices. However, there is a performance impact - all requests, including internal should go through reverse-proxy component. More details on this approach https://memz.co/api-gateway-microservices-docker-node-js/
  2. with DNS. This approach provides slower updates, as every component (essentially, every http client used to call discoverable components) needs to revalidate its DNS cache, which may take some time (it can be configured with TTL of corresponding DNS entry). Additionally, it assumes that every http client implementation will respect that TTL value. As a first approximation, we can assume that TTL can be set as low as 60 seconds, and so, it will take no longer than that for configuration changes to take effect. More details on this approach https://memz.co/service-discovery-microservices-skydns-docker/

Upvotes: 2

Related Questions