Microsserviço, registro de serviço, gateway de API e compartilhamento de dados

Na verdade, estou lendo vários artigos sobre arquitetura de microsserviços, mas parece que eles estão lidando com as coisas da maneira mais fácil possível, sem aprofundar as explicações.

Para explicar minhas perguntas, mostrarei minha pequena arquitetura real:

Então, aqui está o que eu quero usar. Antes de fazer qualquer coisa tecnicamente, preciso de mais informações teóricas.

Descrição do meu domínio

Tenho alguns clientes móveis e navegadores, capazes de se conectar a um aplicativo, obter as informações do usuário e consultar informações de cobrança sobre o que compraram.

Em um aplicativo monolítico, eu usaria esta arquitetura: - Camada de apresentação com Mobile / Angular-Ember - Camada de negócios com uma API REST com NGINX na frente disso - DAL com um banco de dados MySQL padrão - A escalabilidade seria aplicada apenas no eixo X

Eu quero usar uma arquitetura de microsserviço nesse caso, porque é "domínio escalável" e realmente flexível (e para aprender um pouco mais sobre isso, é claro).

No esquema, em cada serviço, há o único URL HTTP exposto pela API em questão.

Questões

uma/ No fluxo (1), "mobile" envia uma solicitação http emhttp: //myDomain.or/auth.

Na minha opinião, o APIGateway pode solicitar que um Registro de Serviço padrão (Eureka, ZooKeeper ou qualquer outra coisa) possa descobrir se um AuthSrv está acessível e pode recuperar seu endereço de rede. Em seguida, o ApiGateway pode solicitar o AuthSrv e responder ao servidor

Essa é uma boa maneira de fazê-lo funcionar? Não há problema de latência ao lidar com máquinas X para acessar dados?

b / O fluxo (2) consulta o registro de serviço. Como o registro de serviço pode entender que todas as solicitações em / auth, mesmo em filhos url como / auth / other (se ele foi exposto) estão relacionadas a esse serviço neste endereço ip: port?

c / O fluxo (3) está mostrando que o registro de serviço tem um AuthSrv disponível. O (3 bis) mostra o outro: nenhum AuthSrv está disponível. Em um pequeno aplicativo, podemos admitir que perdemos algum tempo de disponibilidade, mas em um grande sistema, onde centenas de serviços estão vinculados, como podemos lidar com a deficiência de serviço?

d / Em outra postagem, eu estava perguntando como armazenar uma informação de cobrança porque está relacionada a um usuário, de outro serviço e outro banco de dados.

Em uma arquitetura padrão, eu teria:

{
   billingInformations:{...},
   billingUser:ObjectId("userId")
}

Em uma arquitetura de microsserviço, alguém recomendou usar:

{
    billingInformations:{...},
    billingUser:"/user/12365" // URL corresponding the the user Resource in the other service
}

Essa é a melhor maneira de lidar com o "compartilhamento de dados de serviço" e não associar os serviços?

e / Quando devo preferir usar o protocolo AMQP em vez do protocolo HTTP neste caso específico?

Agradecemos antecipadamente