Service Discovery - Porque sua arquitetura precisa disso?
Tags: programming, architecture, microservices, sre
Published: 2023-08-06 04:45:11

Salveee pessoal!!

Bora trocar uma ideia sobre Arquitetura de Microservices? Porque não há momento para compreender como criar um microservice com qualidade e boa arquitetura.

## What's Service Discovery?

### Real case

**OBS.: Eu poderia aqui dar um exemplo de um sistema monolitico que está sendo migrado para microservice, mas aqui vai outro exemplo tão bom quanto do benefício do Service Discovery.**

Imagine que você está lidando com um arquitetura complexa de microservices e precisar realizar uma migração de ambiente desligando o seu antigo servidor do ambiente legado para o novo. Seus clientes realizam requests para você através de um dominio configurado em um DNS Server que resolve e entrega para seus clientes o ambiente legado e para realizar a migração você precisa notificar todos da mudança. Como realizar essa migração sem necessitar de que todos realizem uma atualização?

Você poderia responder:
- Modifique a sua entrada DNS para entregar para seus clientes o endereço do novo ambiente.
- OK! Vou precisar realizar isso para todos os microservices que irei migrar para o novo ambiente?
- Sim, infelizmente.
- Isso não é escalável e sempre que precisar realizar qualquer mudança no ambiente dos nossos microservices precisaremos realizar uma mudança no nosso DNS Server.

Arquiteturas Cloud Native necessitam de táticas onde esse tipo de complexidade seja abstraida. Para isso o Service Discovery nos entrega uma forma dinamica de viabilizar e detectar mudanças em nosso sistema.

O Service Discovery nos ajuda a conhecer onde cada instâncias de um microservice está localizado. Dessa forma, o Service Discovery atua como um registry em que o endereço de todas as nossas instâncias possam ser facilmente consultadas. Assim, nossos clientes precisam apenas consultar nossa ferramenta de Service Discovery para encontrar nosso microservice.

### How does Service Discovery works?

Podemos dividir o Service Discovery em duas partes principais: Register e Discovery. No diagrama abaixo podemos ver em um forma simples como isso funciona na prática:

![service-discovery](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ufx1hun82rcnr7pdghli.png)

O **Service A** está realizando uma consulta no servidor chamado de **Service Registry** com o intuito de conhecer onde está o **Service B**.

1. A localização do Service B é enviado para o Service Registry (um database contendo as localizações de todas as instâncias disponíveis do microservice);
2. O Service A solicita ao Service Registry pela localização do Service B;
3. A localização do Service B é buscada pela Service Registry em seu database interno e retornada ao Service A;
4. O Service A pode agora realizar a request diretamente ao Service B.

## Service Discovery Implementations

### Client-Side Service Discovery

Nessa implementação o nosso Service A é responsável por solicitar ao Service Registry as instâncias do microservice de destino e responsável por realizar o load balancing usando um algoritmo próprio para escolher uma instância para receber a request.

A implementação a seguir mostra o que descrevemos:

![client-side-discovery](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cxg3v34ywearvmdgtlqa.png)

No client-side com a responsabilidade de realizar o load balancing é um fardo e uma vantagem. A vantagem é que evitamos um hop na comunicação pois teriamos que adicionar um load balancer dedicado e um fardo já que o client terá que implementar um algoritmo de load balance. Além sem mencionar que o Service A está muito acoplado ao Service Registry e que nessa implementação a lógica de Discovery precisará ser implementada por todos os clients.

### Server-Side Service Discovery

Uma alternativa a abordagem de Client-Side Discovery é o Server-Side Discovery, que usa um intermediário que atua como um Load Balancer. O client realiza a request para o microservice via load balancer que é responsável por pesquisar no Service Registry e encaminhar cada request para um instância disponível do microservice.

A implementação a seguir mostra o que descrevemos:

![server-side-discovery](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qhv6lbeyr89ykrjiadev.png)

Aqui temos um Load Balancer dedicado fazendo o trabalho de balanceamento. Criando um nível de abstração acabamos deixando o trabalho do client mais simples pois ele não precisa de uma implementação própria de: balanceamento e consulta no Service Registry.

## Service Registration Options

### Self-Registration

Nessa abordagem, a instância do microservice é responsável por registrar-se e desregistrar-se do Service Registry.

A implementação a seguir mostra o que descrevemos:

![service-self-registration](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ho3jvamtvgow6p22x05e.jpg)

Como vantagem essa abordagem não necessita de outros componentes em seus sistema como intermediários. Contudo, cria um acoplamento e dependência com o Service Registry, que significa que necessitamos implementar uma forma de registrar e desregistrar nossa instância.

### Third-party Registration

Nesse modelo de registro, outro componente do sistema é responsável por conhecer e registrar nossas instâncias do microservices. Quando detecta uma nova instância ou uma instância com problema informa o Service Registry que adiciona ou remove respectivamente a instância do seu database.

A implementação a seguir mostra o que descrevemos:

![service-third-party-registration](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/27cyiqsyxfjzcaqrm3jy.jpg)

Uma das principais vantagens desse modelo é o desacoplamento do Service Registry como não há a necessidade de implementar uma lógica de registro. Como desvantagem, esse componente se torna altamente critico para seu sistema sendo responsável por detectar qualquer mudança em seus microservices. Por ser critico é necessário ser altamente disponível e confiável.

## Conclusion

Este artigo tem como objetivo mostrar que em arquiteturas Cloud Native de microservices necessitamos de implementações e padrões de arquitetura para nos ajudar a remover a complexidade de realizar mudanças em nossos sistemas. Service Discovery nos ajuda a realizar o registro, desregistro e consulta da localização de nossos microservices.