Microsserviços para construção de livros descreve em detalhes os estilos mencionados por @RogerAlsing em sua resposta.
Na página 43 em Orquestração vs Coreografia, o livro diz:
Quando começamos a modelar lógicas cada vez mais complexas, precisamos lidar com o problema de gerenciar processos de negócios que se estendem além dos limites de serviços individuais. E com microsserviços, atingiremos esse limite mais cedo do que o habitual. [...] Quando se trata de realmente implementar esse fluxo, existem dois estilos de arquitetura que poderíamos seguir. Com a orquestração, contamos com um cérebro central para orientar e conduzir o processo, como o maestro de uma orquestra. Com a coreografia, informamos cada parte do sistema de seu trabalho e deixamos que ele elabore os detalhes, como dançarinos, todos descobrindo seu caminho e reagindo aos outros ao seu redor em um balé.
O livro passa a explicar os dois estilos. O estilo de orquestração corresponde mais à idéia SOA de serviços de orquestração / tarefa , enquanto o estilo de coreografia corresponde aos tubos burros e pontos de extremidade inteligentes mencionados no artigo de Martin Fowler.
Estilo de orquestração
Sob esse estilo, o livro acima menciona:
Vamos pensar em como seria uma solução de orquestração para esse fluxo. Aqui, provavelmente a coisa mais simples a fazer seria fazer com que nosso serviço ao cliente atue como o cérebro central. Na criação, ele conversa com o banco de pontos de fidelidade, serviço de e-mail e serviço postal, [...] por meio de uma série de chamadas de solicitação / resposta. O próprio serviço ao cliente pode rastrear onde um cliente está nesse processo. Ele pode verificar se a conta do cliente foi configurada ou se o email foi enviado ou a postagem foi entregue. Podemos pegar o fluxograma e [...] modelá-lo diretamente no código. Poderíamos até usar ferramentas que implementam isso para nós, talvez usando um mecanismo de regras apropriado. Existem ferramentas comerciais para esse fim, na forma de software de modelagem de processos de negócios. Supondo que usamos solicitação / resposta síncrona, poderíamos até saber se cada estágio funcionou [...] A desvantagem dessa abordagem de orquestração é que o serviço ao cliente pode se tornar uma autoridade governamental central demais. Pode se tornar o centro no meio de uma rede e um ponto central em que a lógica começa a viver. Eu já vi essa abordagem resultar em um pequeno número de serviços "divinos" inteligentes, dizendo aos serviços anêmicos baseados em CRUD o que fazer.
Nota: Suponho que, quando o autor menciona ferramentas, ele está se referindo a algo como BPM (por exemplo , Activity , Apache ODE , Camunda ). De fato, o site de padrões de fluxo de trabalho possui um conjunto impressionante de padrões para fazer esse tipo de orquestração e também oferece detalhes de avaliação de diferentes ferramentas de fornecedores que ajudam a implementá-lo dessa maneira. Eu não acho que o autor implique que seja necessário usar uma dessas ferramentas para implementar esse estilo de integração, embora outras estruturas leves de orquestração possam ser usadas, por exemplo, Spring Integration , Apache Camel ou Mule ESB
No entanto, outros livros que li sobre o microsserviços e, em geral, a maioria dos artigos encontrados na Web parecem desfavorecer essa abordagem da orquestração e, em vez disso, sugerem o uso da próxima.
Estilo coreográfico
No estilo coreográfico, o autor diz:
Com uma abordagem coreografada, poderíamos apenas fazer com que o serviço ao cliente emitisse um evento de maneira assíncrona, dizendo que o cliente foi criado. O serviço de e-mail, o serviço postal e o banco de pontos de fidelidade apenas assinam esses eventos e reagem de acordo [...] com essa abordagem. Se algum outro serviço precisou chegar à criação de um cliente, ele só precisa se inscrever nos eventos e fazer seu trabalho quando necessário. A desvantagem é que a visão explícita do processo de negócios que vemos no [fluxo de trabalho] agora é refletida apenas implicitamente em nosso sistema. Isso significa [...] que trabalho adicional é necessário para garantir que você possa monitorar e rastrear as coisas certas. aconteceu. Por exemplo, você saberia se o banco de pontos de fidelidade tinha um bug e, por algum motivo, não configurou a conta correta? Uma abordagem que eu gosto de lidar com isso é criar um sistema de monitoramento que corresponda explicitamente à exibição do processo de negócios no [fluxo de trabalho], mas depois rastreie o que cada um dos serviços faz como entidades independentes, permitindo que você veja exceções estranhas mapeadas no fluxo de processo mais explícito. O fluxograma não é a força motriz, mas apenas uma lente através da qual podemos ver como o sistema está se comportando. Em geral, eu descobri que os sistemas que tendem mais para a abordagem coreografada são mais fracamente acoplados e são mais flexíveis e propensos a mudanças. Você precisa fazer um trabalho extra para monitorar e rastrear os processos através dos limites do sistema. Eu achei as implementações mais fortemente orquestradas extremamente frágeis, com um custo de mudança mais alto. Com isso em mente, prefiro fortemente apontar para um sistema coreografado, em que cada serviço seja inteligente o suficiente para entender seu papel em toda a dança.
Nota: Até hoje ainda não tenho certeza se a coreografia é apenas outro nome para a arquitetura orientada a eventos (EDA), mas se a EDA é apenas uma maneira de fazer isso, quais são as outras maneiras? (Veja também O que você quer dizer com "Orientado a Eventos"? E Os significados da arquitetura orientada a eventos ). Além disso, parece que coisas como CQRS e EventSourcing ressoam muito com esse estilo arquitetônico, certo?
Agora, depois disso, vem a diversão. O livro Microsserviços não assume que os microsserviços serão implementados com o REST. De fato, na próxima seção do livro, eles passam a considerar as soluções baseadas em RPC e SOA e, finalmente, o REST. Um ponto importante aqui é que os microsserviços não implicam REST.
Então, e quanto a HATEOAS? (Hipermídia como o mecanismo do estado do aplicativo)
Agora, se queremos seguir a abordagem RESTful, não podemos ignorar o HATEOAS ou Roy Fielding ficará muito satisfeito em dizer em seu blog que nossa solução não é verdadeiramente REST. Veja a publicação no blog dele na API REST deve ser direcionada por hipertexto :
Estou ficando frustrado com o número de pessoas que chamam qualquer interface baseada em HTTP de API REST. O que precisa ser feito para tornar claro o estilo de arquitetura REST na noção de que o hipertexto é uma restrição? Em outras palavras, se o mecanismo do estado do aplicativo (e, portanto, a API) não estiver sendo conduzido por hipertexto, ele não poderá ser RESTful e não poderá ser uma API REST. Período. Existe algum manual quebrado em algum lugar que precise ser corrigido?
Portanto, como você pode ver, Fielding acha que sem o HATEOAS você não está realmente construindo aplicativos RESTful. Para Fielding, o HATEOAS é o caminho a seguir quando se trata de orquestrar serviços. Estou apenas aprendendo tudo isso, mas para mim, o HATEOAS não define claramente quem ou o que é a força motriz por trás dos links. Em uma interface do usuário que pode ser o usuário, mas nas interações computador a computador, suponho que isso precise ser feito por um serviço de nível superior.
Segundo o HATEOAS, o único link que o consumidor da API realmente precisa saber é o que inicia a comunicação com o servidor (por exemplo, POST / pedido). A partir deste momento, o REST conduzirá o fluxo, porque, na resposta desse terminal, o recurso retornado conterá os links para os próximos estados possíveis. O consumidor da API decide o link a seguir e move o aplicativo para o próximo estado.
Apesar de parecer legal, o cliente ainda precisa saber se o link deve ser POSTADO, COLOCADO, OBTIDO, PATCHADO etc. O cliente ainda precisa decidir qual carga útil deve passar. O cliente ainda precisa estar ciente do que fazer se isso falhar (tente novamente, compense, cancele etc.).
Eu sou bastante novo nisso tudo, mas para mim, da perspectiva do HATEOAs, esse cliente ou consumidor de API é um serviço de alto nível. Se pensarmos da perspectiva de um ser humano, você pode imaginar um usuário final em uma página da web, decidindo quais links seguir, mas ainda assim, o programador da página da web precisou decidir qual método usar para chamar os links, e qual carga útil passar. Portanto, no meu ponto de vista, em uma interação computador a computador, o computador assume o papel de usuário final. Mais uma vez, é isso que chamamos de serviço de orquestração.
Suponho que podemos usar o HATEOAS com orquestração ou coreografia.
O padrão de gateway da API
Outro padrão interessante é sugerido por Chris Richardson, que também propôs o que chamou de Padrão de Gateway de API .
Em uma arquitetura monolítica, os clientes do aplicativo, como navegadores da web e aplicativos nativos, fazem solicitações HTTP por meio de um balanceador de carga para uma das N instâncias idênticas do aplicativo. Mas em uma arquitetura de microsserviço, o monólito foi substituído por uma coleção de serviços. Consequentemente, uma questão chave que precisamos responder é com o que os clientes interagem?
Um cliente de aplicativo, como um aplicativo móvel nativo, pode fazer solicitações HTTP RESTful para os serviços [...] individuais Na superfície, isso pode parecer atraente. No entanto, é provável que haja uma incompatibilidade significativa na granularidade entre as APIs dos serviços individuais e os dados exigidos pelos clientes. Por exemplo, exibir uma página da web pode exigir chamadas para um grande número de serviços. Amazon.com, por exemplo,
descreve como algumas páginas requerem chamadas para mais de 100 serviços. Fazer muitas solicitações, mesmo em uma conexão de Internet de alta velocidade, sem falar em uma rede móvel de baixa largura de banda e latência mais alta, seria muito ineficiente e resultaria em uma experiência ruim para o usuário.
Uma abordagem muito melhor é que os clientes façam um pequeno número de solicitações por página, talvez apenas uma, na Internet, para um servidor front-end conhecido como gateway de API.
O gateway da API fica entre os clientes do aplicativo e os microsserviços. Ele fornece APIs personalizadas para o cliente. O gateway da API fornece uma API de granulação grossa para clientes móveis e uma API de granularidade mais fina para clientes de desktop que usam uma rede de alto desempenho. Neste exemplo, os clientes de desktop fazem várias solicitações para recuperar informações sobre um produto, enquanto um cliente móvel faz uma única solicitação.
O gateway da API lida com as solicitações recebidas, fazendo solicitações para um certo número de microsserviços na LAN de alto desempenho. A Netflix, por exemplo,
descreve
como cada solicitação atende, em média, seis serviços de back-end. Neste exemplo, solicitações de baixa granularidade de um cliente de desktop são simplesmente enviadas para o serviço correspondente, enquanto cada solicitação de baixa granularidade de um cliente móvel é tratada agregando os resultados da chamada de vários serviços.
O gateway da API não apenas otimiza a comunicação entre os clientes e o aplicativo, mas também encapsula os detalhes dos microsserviços. Isso permite que os microsserviços evoluam sem afetar os clientes. Por exemplo, dois microsserviços podem ser mesclados. Outro microsserviço pode ser particionado em dois ou mais serviços. Somente o gateway da API precisa ser atualizado para refletir essas alterações. Os clientes não são afetados.
Agora que examinamos como o gateway da API medeia entre o aplicativo e seus clientes, agora vamos ver como implementar a comunicação entre microsserviços.
Isso soa muito semelhante ao estilo de orquestração mencionado acima, apenas com uma intenção ligeiramente diferente; neste caso, parece ser tudo sobre desempenho e simplificação de interações.
.