Os serviços devem conversar diretamente entre si em uma arquitetura de microsserviço?

Eu tenho vários serviços da web que formam um aplicativo da web. Os clientes podem acessar esses serviços por meio de chamadas das APIs REST.

Esses serviços devem poder conversar diretamente entre si? Em caso afirmativo, isso não os unirá, o que contraria o conceito de microsserviços?

O cliente deve chamá-los diretamente um após o outro para obter os dados necessários para carregar uma página da Web no cliente?

Ou devo ter outra camada em cima dos meus serviços, que lida com uma solicitação do cliente, busca os dados para essa solicitação e os envia de volta ao cliente?

Se você deseja que seus serviços sejam exibidos nesta imagem, então sim: não é como se você não pudesse fazê-lo, mas na maioria das vezes isso terá consequências ruins. A comunicação através do REST não dissociará significativamente seus serviços. Quando alguma interface de serviço é alterada, todos os serviços dependentes provavelmente precisam ser alterados e reimplantados. Além disso, durante a reimplantação do serviço, você precisará desativar todos os serviços dependentes, o que não é considerado um bom design para os padrões de alta disponibilidade.

No final, você terá um aplicativo de microsserviços mais lento do que o aplicativo monolito alternativo, mas com quase todos os mesmos problemas!

Eu tenho que discordar de @Robert Harvey

Na prática, no entanto, um ou mais dos seus microsserviços (talvez todos eles) conversarão com algum armazenamento de dados central como um banco de dados SQL.

O banco de dados de integração é antipadrão bem conhecido

Uma solução muito melhor é usar o padrão de publicação-assinatura para tornar a comunicação entre seus serviços assíncrona:

Por favor, dê uma olhada na maneira do CQRS / ES de implementar esse método de comunicação. Greg Young e outros caras oferecem vários vídeos interessantes sobre o assunto. Basta pesquisar no Google a palavra-chave "CQRS / ES". Nessa abordagem, cada serviço se tornará publicador e assinante ao mesmo tempo, permitindo que os serviços sejam muito menos acoplados.

Aqui está uma boa série de artigos sobre microsserviços que esclarecem a controvérsia em torno do tópico. Explicação muito detalhada com boas ilustrações.

Você terá muitas idéias muito boas lendo o que Udi Dahan tem a dizer sobre SOA .

Um serviço é a autoridade técnica para um recurso comercial específico. Qualquer dado ou regra deve pertencer a apenas um serviço.

O que isso significa é que, mesmo quando os serviços estão publicando e se inscrevendo nos eventos um do outro, sempre sabemos qual é a fonte autorizada da verdade para cada dado e regra.

Além disso, ao analisar os serviços sob as lentes dos recursos de negócios, o que vemos é que muitas interfaces de usuário apresentam informações pertencentes a diferentes recursos - o preço de um produto, ao lado de estar em estoque ou não. Para cumprirmos a definição de serviços acima, isso nos leva a entender que essas interfaces de usuário são realmente um mashup - com cada serviço tendo o fragmento da interface do usuário lidando com seus dados específicos.

Especificamente em relação à composição da interface do usuário, o artigo de Mauro Servienti sobre a composição da interface do usuário é um bom ponto de partida. Veja também o vídeo de Udi, disponível aqui .

Esses serviços devem poder conversar diretamente entre si? Em caso afirmativo, isso não os unirá, o que contraria o conceito de microsserviços?

Se dois serviços trocarem mensagens entre si, você obterá um acoplamento. A resposta principal é que eles associam à API do outro serviço - o contrato que o serviço promete manter estável, mesmo quando seus internos estão mudando.

Além disso, técnicas como a descoberta de serviços podem facilitar a dependência de um provedor de serviços específico, e os intermediários de mensagens podem dissociar os produtores e os consumidores (eles ainda precisam entender as mensagens uns dos outros e como interagir com a API do intermediário de mensagens - não há mágica )

Depende do que você quer dizer com "diretamente".

É perfeitamente bom, de acordo com a arquitetura dos microsserviços, ter microsserviços que invocam outros microsserviços, seja no seu próprio servidor ou mesmo em servidores externos, por meio de alguma interface como REST.

O que não é bom é que um microsserviço invoque outro usando invocações diretas de método; isso tornaria ambos os microsserviços parte do mesmo monólito.

Esses serviços devem poder conversar diretamente entre si? Em caso afirmativo, isso não os unirá, o que contraria o conceito de microsserviços?

Acoplamento não é uma palavra ruim. Toda aplicação já possui um certo grau de acoplamento; os aplicativos que falam com seus microsserviços já estão acoplados aos microsserviços, caso contrário eles não funcionariam.

O que você realmente procura com microsserviços é o acoplamento solto ; você pode conseguir isso simplesmente fazendo com que um microsserviço interrogue o outro por meio de sua API pública ou usando um barramento de eventos.

Na prática, no entanto, um ou mais dos seus microsserviços (talvez todos) irão conversar com algum armazenamento de dados central, como um banco de dados SQL. Dependendo de como você deseja atingir seu objetivo, você pode simplesmente ter um microsserviço alterando os dados do banco de dados de alguma forma, que o outro microsserviço consultará para captar a alteração.

Parece que, ao falar sobre SOA e arquitetura em geral, as pessoas são pegas na semântica e no jargão. O que torna um serviço "micro"? Por fim, é um conjunto de características que, em qualquer "sistema de pontuação" que você estiver usando, claramente não torna o serviço "não micro". O que foi que o juiz da Suprema Corte disse sobre indecência? "Eu vou saber quando eu vir."

Tenho certeza de que algumas pessoas dirão que isso é uma não resposta, mas então elas estão perdendo o objetivo. As arquiteturas de microsserviço destinam-se a evitar vários problemas, entre eles a questão do "acoplamento rígido". Portanto, se você acabar criando um emaranhado de microsserviços que dependem de muitos detalhes finos um do outro, criou um acoplamento rígido que - seja usando um barramento de mensagens de pub / sub ou chamadas diretas - destrói sua capacidade de compor novas soluções a partir das peças, reconfigurar peças individuais sem derrubar todo o sistema, etc etc

O cliente deve chamá-los diretamente um após o outro para obter os dados necessários para carregar uma página da Web no cliente?

Depende; no entanto, sugiro fornecer recursos diretamente utilizáveis ​​ao cliente e ocultar (encapsular) os detalhes de como os resultados são reunidos (por exemplo, através de vários micro serviços).

Se houver muita lógica envolvida na combinação de resultados individuais de microsserviços pelo cliente, isso pode causar inadvertidamente alguma lógica de negócios que se infiltra no cliente. Também pode expor mais da sua arquitetura interna ao cliente do que você gostaria, dificultando a refatoração posterior dos microsserviços.

Portanto, com microsserviços, às vezes é útil ter um microsserviço de wrapper que forneça ao cliente um terminal com abstrações úteis e que execute uma coordenação de nível mais alto de outros microsserviços (talvez agora mais internos).

(Além disso, as viagens de ida e volta para o cliente provavelmente são mais caras do que dos microsserviços entre si.)

Se você observar a direção adotada pelo GraphQL, por exemplo, encontrará clientes emitindo consultas diretamente relevantes para um terminal, que pode ou não ser implementado como uma coleção de microsserviços. Como a arquitetura dos microsserviços fica oculta por trás do GraphQL, isso torna a arquitetura mais fácil de refatorar e também mais amigável para o cliente. Consulte, por exemplo, https://stackoverflow.com/a/38079681/471129 .

O principal objetivo dos microsserviços é tornar seu aplicativo fracamente acoplado. Portanto, os serviços não podem se chamar. Caso contrário, ele será amarrado. Mas o que faremos se tivermos dois serviços que precisam compartilhar dados? A resposta é Message Broker. Portanto, o serviço que obtém dados do cliente pode compartilhar os dados com o intermediário central de mensagens; então, os serviços precisam usar esses dados para consumi-los, transformá-los e colocá-los em seu próprio armazenamento de dados. Eu recomendo o Kafka porque você pode juntar dados de diferentes tópicos em tempo real com o Kafka Stream. PS. melhor separar seus microsserviços por recurso.