Service Registry and Discovery pattern

When you build applications and enable customers to find the details of the services when they need them, you can use service registry and discovery.

In this pattern, you will need a service registry to collect and keep all information about your service and metadata. The data will be server location, URLs, service interface, SLA, etc.

In high-level, service registries will serve the functions below. The highly available service registry will perform the request from the client to get the service information.

Example from Nginx

There are two types of service registry and discovery; client-side discovery and server-side discovery.

In client-side discovery, there are two steps to get the service information.

ref: https://www.researchgate.net/figure/Client-side-discovery-pattern_fig3_304582247

1. Discovery service information to ‘service registry’
2. Invoke the service

In server-side discovery, there is usually like-router-functional network devices, which can be router or load balancer. The load balancer is possibly configured to get the information from the service registry upon the client’s request.

1. Invoke service through the router
2. The router obtains the service information
3. The router invoke the service
4. The client will be responded from the router.

In practice, there are a lot of service discovery software in the industry.

• Docker hub.
• ZooKeeper.
• Hysterix.
• HashiCorp Consul.
• GRPC.
• Eureka.
• Apache Thrift.
• Traefik.
• Nginx

Service discovery in K8s: In Kubernetes, Kubernetes is using DNS names to discover the pods, and resolve the names to find the right pods by mapping with the data stored in ETCD; key-value storage.

But if you want more complex structure, you will need like service-mesh (Istio) or Consul (service registry).

Ref: https://www.magalix.com/blog/kubernetes-patterns-the-service-discovery-pattern. https://www.solo.io/blog/multi-cluster-service-discovery-in-kubernetes-and-service-mesh/#:~:text=A%20service%20mesh%20enables%20service,solve%20the%20multi%2Dnetwork%20problem.

Lastly, one question can be raised? Why not just use an API gateway?

There are differences between API gateway (management) and Service discovery (Service Mesh); service discovery and mesh are different, but in many cases, the service mesh provides discovery capability.

First of the purposes / main focuses are different between.

And apparently, service discovery serves more east-west traffic, rather than the traffic coming through from the client to direct to hit the server.

from: https://www.sensedia.com/post/sensedia-service-mesh-observability-and-security-for-microservices

Ref: https://www.cncf.io/blog/2020/03/06/the-difference-between-api-gateways-and-service-mesh/