Aprender esses 5 padrões de microservice o tornará um melhor engenheiro

Para muitos engenheiros, entrar em microservices pode ser difícil, porque é difícil decidir onde as linhas devem ser desenhadas. Para mim, 99% dos serviços se enquadram em uma das cinco categorias, e dividir as responsabilidades desta forma permite que você pense em como engenharia de recursos por meio de serviços de encanamento, como você faria em scripts de shell do Unix.

Vamos falar um pouco sobre o que todos os microservices têm em comum. Eric Evans, pai do Domain Driven Design, os define como os seguintes: “[serviços] que podem consumir e produzir mensagens” ( https://www.youtube.com/watch?v=yPvef9R3k-M )

Com isso em mente, para cada padrão de serviço, falarei sobre os tipos de mensagens que são produzidas ou consumidas.

Essas mensagens novamente, podem ser subdivididas em duas categorias: Eventos e Comandos.

Antes de começar, porém, e porque o contexto é importante, eu ouvi pela primeira vez estes padrões Microservice de Matt Walters , o criador da biblioteca servicebus . O Servicebus é uma adaptação do nó de uma biblioteca popular .Net chamada NServiceBus, que foi criada e popularizada por Udi Dahan.

O Servicebus permite que você escreva facilmente comandos de send e listen , e publish e subscribe eventos usando AMQP como um idioma universal, com cargas úteis JSON. Isso significa que outras linguagens de programação podem facilmente implementar as mesmas interfaces e poder participar perfeitamente em um sistema composto por partes escritas em muitos idiomas.

Se você é um desenvolvedor Go, ou Python, quem gostaria de contribuir com essa causa, envie-me uma mensagem!

E, além disso, os 5 padrões de microserviços.

1. Model Services

Se MVC vem à mente, então você está no bom caminho com esse tipo de serviço. Os modelos de serviços são onde seus modelos devem viver. Os limites normalmente são feitos no nível Agregado ou Entidade, dependendo da complexidade do domínio.

Os serviços modelo consomem mensagens sobre coisas relevantes em seu contexto. Por exemplo, se você tivesse um Serviço de Inventário, algumas mensagens de comando que seriam relevantes para consumir seria inventory.product.create ou inventory.product.increaseStock . Em resposta, você quer produzir algumas mensagens de Evento para que o resto do sistema possa estar ciente de como o modelo está mudando e responder a essas mudanças. As mensagens de eventos produzidas neste exemplo seriam inventory.product.created e inventory.product.stockLevelIncreased .

2. Serviços Denormalizer

Os denormalizadores são exatamente o que os bancos de dados relacionais estão fazendo, exceto para um sistema distribuído. Eles estão juntando múltiplas fontes normalizadas de entrada em uma estrutura de dados legível que um cliente pode consumir.

Por exemplo, imagine que você tenha um aplicativo de comércio eletrônico. Quando os níveis de estoque aumentam ou diminuem, ou, tornam-se disponíveis em seu inventário, sua aplicação deve saber sobre isso.

Isso significa que, com um serviço de desmineralização, você está se inscrevendo nos eventos que estão sendo emitidos pelo serviço modelo acima e se você estiver usando o MongoDb, usando algo como mangusto para persistir esses dados em uma estrutura perfeita para esse aplicativo específico para consumir.

Imagine se você é engenheiro de aplicativos que estão usando algo como Meteor com MongoDB – eles apenas obtiveram inventário em tempo real de um sistema externo sem ter que escrever uma linha de código. Isso também funciona muito bem com o RethinkDB emparelhado com inscrições do GraphQL!

Se você tem uma equipe que precisa de dados no trabalho Kafka para Big Data, basta adicionar um serviço de desmantelar Kafka.

3. Serviços de gateway

Os serviços de gateway podem ser usados ??de forma muito semelhante a Denormalizers. Em vez de se conectar a um banco de dados, no entanto, é uma conexão a uma API.

Eu estava recentemente trabalhando com um mecanismo de recomendação, chamado LiftIgniter, com o qual nosso inventário precisava ser sincronizado. O serviço subscreve inventory.product.updated e inventory.product.added eventos, e simplesmente lança os dados formatados para os pontos finais apropriados.

Posteriormente, adicionou-se um serviço adicional que escutou os mesmos eventos e criando um serviço Magento Gateway, conseguimos manter uma loja de comércio eletrônico atualizada com os níveis de estoque em constante mudança também!

4. Serviços de Ingestor

Tudo o que falamos até agora é trabalhar com dados que se propagam através do sistema ou criados em serviços modelo. No entanto, é um requisito frequente para obter dados externos no sistema. Conceitualmente, os dados de uma fonte externa precisam ser ingeridos no idioma universal, o resto do sistema fala. Este é o trabalho de um serviço de ingestão.

Os serviços de Ingestor geralmente apenas produzem mensagens. Esses serviços geralmente envolvem quer receber uma API POST sobre HTTP, ou executar um trabalho CRON e raspar em um intervalo. Os dados obtidos ou recebidos são então publicados no sistema usando o idioma universal (AMQP w / JSON).

5. Adaptador de Serviços

Um serviço de adaptador é um caso de uso mais raro, mas vale a pena mencionar. Semelhante a um serviço Gateway, um Adaptador consome mensagens, então usa esses dados para invocar uma biblioteca no sistema. Um exemplo disso pode ser usando uma ferramenta de manipulação gráfica como ImageMagick. ImageMagick é uma ferramenta poderosa, mas não tem ligações Node.js. Um serviço de adaptador resolve isso executando um processo filho e, em seguida, produzindo mensagens com os resultados, no idioma universal do sistema.

Serviços API

ATUALIZAÇÃO: 12 de janeiro de 2018
Um dia depois de publicar este artigo, percebi que eles poderiam ser uma confusão sobre o encaixe da API. Então eu decidi adicionar esta seção e explicar o meu raciocínio. Eles são definitivamente microservices, mas eles não são realmente novos e não estavam na minha lista de coisas novas para ensinar.

Os serviços API devem ser mantidos leves. Se você está construindo um monte de lógica de negócios em uma API, então você está construindo um monólito. É um pouco melhor do que a combinação de um aplicativo e um servidor que costumávamos ver com arquiteturas “n-tier”, mas eventualmente leva à infame “Big Ball of Mud” ou “Spaghetti Code” também.

Para realizar isso, use o “Serviço de Denormalizer” de cima para projetar uma visão eficiente da consulta dos dados no (s) banco (s) de dados que a API lê. Isso cria um fluxo unidirecional de dados ou, como eu ouvi primeiro de Matt, um “Sistema Unidirecional”.

Sistemas Unidireccionais

O uso desses padrões acima permite que você trabalhe com eventos imutáveis ??em um fluxo de trabalho unidirecional. Se você estiver no desenvolvimento de aplicativos, você não tem dúvidas sobre como o Redux mudou o jogo para gerenciamento de estado. Ter uma loja com estado que escorre a árvore do componente permite que você racifique facilmente sobre como as ações afetam o estado porque são fatos simples e imutáveis ??que ocorrem em uma localização centralizada.

Se você seguir os padrões acima, você estará usando o que às vezes é mais complicado chamado Segmento de Responsabilidade de Consulta de Comando, ou CQRS. Os comandos são consumidos por Model Services e são produzidos eventos que são consumidos por Denormalizer ou Gateway Services, que atualizam os modelos Read. As consultas são então feitas contra o modelo Read.

Como você está usando mensagens imutáveis, isso faz do Event Sourcing o padrão perfeito para a construção de seus serviços Modelos. Outra criação de Matt Walters vale a pena conferir, é um micro-framework chamado [sourced] ( https://github.com/mateodelnorte/sourced ) que funciona perfeitamente em harmonia com o servicebus, para adicionar facilmente recursos de Sourcing de eventos para consumir os eventos do seu serviço , e persisti-los em um banco de dados.

Conclusão

Finalmente, vale a pena mencionar que, com simplicidade de serviços, alguma complexidade é necessariamente movida para a arquitetura. Espero ter fornecido uma maneira de criar mentalmente sistemas de microserviços na sua cabeça com alguns blocos genéricos de lego.

Se você não leu meu outro artigo, ” The 10 Puzzle Pieces of a Effective Microservice Architecture ” leu isso também! Abrange os componentes que fazem uma arquitetura de microserviço.

Se você quiser ignorar a parte em que você passa meses aprendendo a configurar tudo isso sozinho, eu estou preparando um curso na web que irá mostrar como sistematei o processo e codifiquei o sistema, para que você possa estar em funcionamento e eficiente com o Microservices no tempo mais rápido possível! Inscreva-se agora para ter acesso antes de todos! Visite Microservice Driven para obter informações!

Obrigado por ler! Se você me acompanhar e me dar 50 aplausos, isso realmente me ajudaria a alcançar mais pessoas! Clique e #HODL o botão de clap abaixo;)

Para obter informações sobre consultoria, envie-me uma mensagem no LinkedIn .

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *