Docker-compose x Microsserviços

Olá Camilo.
Pergunta interessante e até um pouco complexa.
Vou tentar lhe explicar rapidamente.
Normalmente, em projetos com microsserviços, existe um docker-compose principal na raiz do projeto, que orquestra todos os containers dos diferentes microsserviços.
Cada microsserviço pode ter seu próprio Dockerfile, descrevendo como construir sua imagem, mas o docker-compose principal é o responsável por juntar tudo, definindo como cada serviço se conecta e se comunica.
Em alguns casos, quando os microsserviços são mantidos em repositórios separados, cada um pode ter seu próprio docker-compose apenas para facilitar o desenvolvimento isolado.
Ainda assim, quando é preciso rodar o sistema completo, cria-se um docker-compose central (geralmente em um repositório de orquestração) que referencia as imagens de todos os microsserviços.
Então, o comum é um único docker-compose para o conjunto, e não um para cada serviço dentro de um mesmo ambiente.
Espero que esta resposta lhe ajude a entender.
Caso queira saber mais pergunte ai.
Bons estudos.

Entendi, mas ainda tenho algumas dúvidas:

Então nesse questão de uma arquitetura de microsserviços, o docker-compose será implementado apenas na raiz do projeto.
Na pasta do desktop, ele irá aparecer como da mesma forma que aparece o REDME? Só na questão da visualização nas pastas mesmo.

Outra dúvida é em relação ao service registry e o api gateway: Como é feito a parte do docker neles? É da mesma forma?

Nessa questão dos microsserviços, a comunicação entre eles acontece natualmente, da mesma forma que é feita na implementação dos microsserviços, ou precisa configurar algo no dockfile?

E ai Camilo.
Vamos por partes:

1. Onde o docker-compose fica dentro do projeto

Em uma arquitetura de microsserviços, é comum existir um docker-compose principal na raiz do projeto — ou no repositório responsável por orquestrar tudo.
Na sua máquina, ele aparece como qualquer outro arquivo, exatamente como um README.md aparece quando você abre a pasta do projeto.
Exemplo de estrutura:

meu-projeto/
 ├─ docker-compose.yml   ← arquivo principal de orquestração
 ├─ servico-a/
 │   └─ Dockerfile
 ├─ servico-b/
 │   └─ Dockerfile
 └─ servico-c/
     └─ Dockerfile

Nada de especial: é só um arquivo YAML na raiz.

2. Como funciona com o Service Registry e o API Gateway

O Service Registry (como Eureka, Consul etc.) e o API Gateway (como Spring Cloud Gateway, Kong, Traefik) também entram no docker-compose, como qualquer outro serviço.
Ou seja, no docker-compose.yml você adiciona algo como:

services:
  service-registry:
    build: ./service-registry
    ports:
      - "8761:8761"

  api-gateway:
    build: ./api-gateway
    ports:
      - "8080:8080"
    depends_on:
      - service-registry

  servico-a:
    build: ./servico-a

  servico-b:
    build: ./servico-b

Cada um desses componentes terá:

• seu Dockerfile, que explica como construir a imagem;
• e uma entrada no docker-compose, que diz como ele se conecta aos demais.

Não tem diferença no uso do Docker para eles são apenas mais serviços dentro da mesma orquestração.

3. A comunicação entre os microsserviços dentro do Docker

Aqui é um ponto MUITO importante:

A comunicação NÃO acontece automaticamente.

Mas você não configura isso no Dockerfile, e sim no docker-compose.
O Dockerfile só serve para construir a imagem, não para networking.
Quando você coloca todos os serviços no mesmo docker-compose.yml, eles automaticamente entram na mesma rede interna do Docker, e podem se comunicar pelo nome do serviço.
Exemplo:
Se no docker-compose você define:

services:
  servico-a:
  servico-b:

Dentro dos microsserviços (código fonte), o serviço A pode chamar B assim:

http://servico-b:8080/alguma-rota

Esse nome (servico-b) é resolvido pela própria rede interna criada pelo docker-compose.
Ou seja:

• Não precisa configurar rede no Dockerfile;
• A comunicação acontece porque o docker-compose cria uma rede comum;
• Você só usa o nome do serviço como "host".

Resumo :

• O docker-compose.yml normalmente fica na raiz do projeto (como aparece o README).
• API Gateway e Service Registry são adicionados ao docker-compose da mesma forma que qualquer outro serviço.
• A comunicação entre os microsserviços é configurada pelo docker-compose, não pelos Dockerfiles.
• Dentro da rede do docker-compose, cada serviço acessa os outros usando o nome definido no arquivo YAML.

Pergunte qualquer coisa.
Bons estudos.