# service discovery pattern

https://www.youtube.com/watch?v=v4u7m2Im7ng&ab_channel=ADev%27Story

###### tags: `monolith-like`,`registry`


when local to micro service, the communication might be problem: how to find the right ip of target services in cloud-based system. (all service might shutdown and up)

### DNS

record the ip to different internet domain


*　simple/coupling

---

### client side service discovery

https://microservices.io/patterns/client-side-discovery.html

client side ask router then send the request

pros:
* Fewer moving parts and network hops compared to Server-side Discovery

cons:
* need to implement client-side service discovery logic for each programming language/framework used by your application
* couples the client to the Service Registry



---
### server side service discovery

https://microservices.io/patterns/server-side-discovery.html

client side send the req to server side(router/server), the router/load balancer distribute the request by router table

pros:
* Some cloud environments provide this functionality
* **decoupling btw service and registry**: the client code is simpler since it does not have to deal with discovery. Instead, a client simply makes a request to the router

cons:
* Unless it’s part of the cloud environment, the router must is another system component that must be installed and configured. It will also need to be replicated for availability and capacity.
* The router must support the necessary communication protocols (e.g HTTP, gRPC, Thrift, etc) unless it is TCP-based router
* **More network hops**: are required than when using Client Side Discovery

A/B dont have direct connect.



### registation

* self registration
* third-party registration

#### self registration

https://microservices.io/patterns/self-registration.html

* registration by each service itself to registry
* **A service instance is responsible for registering itself** with the service registry. On startup the service instance registers itself (host and IP address) with the service registry and makes itself available for discovery. The client must typically periodically renew its registration so that the registry knows it is still alive. On shutdown, the service instance unregisters itself from the service registry.

pros:
* handle granuous service state by service can distinguish it own status and register/unregister itself

cons:
* Couples the service to the Service Registry
* You must implement service registration logic in each programming language/framework that you use to write your services
* unable to handle full request(cannot handle request stautus): A service instance that is **running yet unable to handle requests** will often lack the self-awareness to unregister itself from the service registry


#### third-party registration ex. k8s orchestration

https://microservices.io/patterns/3rd-party-registration.html

registrar(3rd-party) observe service up then register, if service down then remove it from registry.

pros:
* less complex (handle by 3rd): The service code is less complex than when using the Self Registration pattern
* the registrar can perform health checks on a service instance and register/unregister the instance based the health check

cons:
* the granularity control by 3rd: The 3rd party registrar might only have superficial knowledge of the state of the service instance, e.g. RUNNING or NOT RUNNING and so might not know whether it can handle requests. However, as mentioned above some registrars such as Netflix Prana perform a health check in order to determine the availability of the service instance.
* Unless the registrar is part of the infrastructure it’s another component that must be installed, configured and maintained. Also, since it’s a critical system component it needs to be highly available.