Pontos chave:
- A interação entre os componentes diretamente entre si pode levar a um comportamento inesperado que é difícil para desenvolvedores, operadores e analistas de negócios entenderem.
- Para garantir a sustentabilidade do seu negócio, você precisa ver todas as interações que surgem no sistema.
- : , -; , ; , ; (process mining), ; , .
- , , , .
Em 2018, conheci um arquiteto de uma grande empresa de internet. Ele me disse que eles seguem todas as diretrizes corretas e dividem a funcionalidade em pequenos pedaços dentro de diferentes áreas, embora não chamem esse estilo de arquitetura de "microsserviços". Em seguida, conversamos sobre como esses serviços interagem entre si para dar suporte à lógica de negócios que transcende os limites do serviço, porque é aqui que a teoria é colocada em prática. Ele disse que seus serviços interagem por meio de eventos publicados no ônibus - essa abordagem é chamada de " coreografia " (falarei sobre isso com mais detalhes abaixo). A empresa considera isso ideal em termos de redução da coesão. Mas eles enfrentaram um problema: é difícil entender o que está acontecendo no sistema e é ainda mais difícil mudá-lo. " Esta não é a dança coreografada que você vê em apresentações de microsserviços, é um pogo jumping incontrolável! "
Isso está de acordo com o que outros clientes me disseram, como Josh Wolfe da Credit Sense ," o sistema que estamos substituindo usa coreografia ponto a ponto complexa que requer várias bases de código para entender ".
Vamos entender essa situação usando um exemplo simplificado. Digamos que você esteja criando um aplicativo de atendimento de pedidos. Você decidiu usar uma arquitetura orientada a eventos e escolheu, digamos, Apache Kafka como o barramento de eventos. Quando alguém faz um pedido, o serviço de checkout gera um evento que é recolhido pelo serviço de pagamento. Este serviço de pagamento recebe dinheiro e gera um evento que é recolhido pelo serviço de estoque.
Fluxo coreografado de eventos.
A vantagem dessa abordagem é que você pode facilmente adicionar novos componentes ao sistema. Digamos que você queira criar um serviço de notificação que envie emails para seus clientes. Você pode simplesmente adicionar um novo serviço e inscrever-se nos eventos apropriados sem tocar no resto do sistema. E agora você pode gerenciar de forma centralizada suas configurações de interação e a complexidade das notificações que atendem aos requisitos do GDPR (regulamento de proteção de dados da UE).
Esse estilo de arquitetura é chamado de coreografia porque não há necessidade de um orquestrador para dizer aos outros componentes o que fazer. Aqui, cada componente gera eventos aos quais outros componentes podem responder. Supõe-se que esse estilo reduza o acoplamento entre os componentes e torne mais fácil projetar e modificar o sistema, como acontece com nosso esquema de serviço de notificação.
Perda de transparência no fluxo de eventos
Quero me concentrar na pergunta que surge com mais frequência quando participo de discussões dessa arquitetura: "Como evitar a perda de transparência (e provavelmente de controle) do fluxo de eventos?" Em um estudo , Camunda (onde trabalho) perguntou sobre o uso de microsserviços. 92% dos entrevistados pelo menos os consideraram e 64% já os usaram de uma forma ou de outra. Isso não é mais um exagero. Mas naquele estudo, também perguntamos sobre as dificuldades e recebemos uma confirmação clara de nossas preocupações: na maioria das vezes, fomos informados sobre a perda de transparência de ponta a ponta dos processos de negócios que envolvem vários serviços.
Lembra das arquiteturas baseadas em vários gatilhos de banco de dados? Arquiteturas nas quais você nunca sabe exatamente o que acontecerá em resposta a alguma ação, e por que isso acontecerá? Às vezes, sou lembrado disso pelas dificuldades associadas a microsserviços reativos, embora essa comparação seja claramente inadequada.
Garantindo transparência
O que pode ser feito em tal situação? As abordagens a seguir irão ajudá-lo a recuperar a transparência, mas cada uma tem seus próprios méritos e deméritos:
- Rastreamento distribuído (como Zipkin ou Jaeger).
- Data lagos ou ferramentas analíticas (como Elastic).
- Controle e análise de mineração de processo (por exemplo, ProM).
- Rastreamento usando automação de fluxo de tarefas (como Camunda).
Observe que todas essas abordagens envolvem observar um sistema em execução e examinar os fluxos de dados nele. Não conheço nenhuma ferramenta de análise estática que possa extrair informações úteis.
Rastreamento distribuído
Essa abordagem monitora a pilha de chamadas entre diferentes sistemas e serviços. Para isso, são usados identificadores exclusivos, geralmente adicionados a determinados cabeçalhos (por exemplo, em HTTP ou cabeçalhos de mensagens). Se todos em seu sistema entendem ou pelo menos retransmitem esses cabeçalhos, você pode rastrear a troca de solicitações entre serviços.
Normalmente, o rastreio distribuído é usado para entender como os pedidos estão fluindo no sistema, para descobrir onde há falhas e para investigar as causas da degradação do desempenho. As vantagens da abordagem incluem a maturidade do kit de ferramentas e o ecossistema que o acompanha. Portanto, será relativamente fácil para você começar a usar o rastreio distribuído, mesmo que normalmente precise (talvez agressivamente) instruir seus aplicativos ou contêineres.
Então, por que não usar essa abordagem para entender como os processos de negócios geram eventos? Geralmente, há dois motivos para isso:
- . , , . . , -.
- . , , 90 % . Three Pillars with Zero Answers — towards a New Scorecard for Observability. .
Portanto, por si só, o rastreamento dificilmente é adequado para nós. Seria lógico recorrer a uma abordagem semelhante, mas levando em consideração nossa tarefa específica. Isso geralmente significa coletar não vestígios, mas eventos importantes de negócios ou temáticos, que você já pode ter encontrado. Freqüentemente, a solução se resume a criar um serviço que escuta todos os eventos e os armazena no banco de dados, o que pode aumentar a carga do sistema. Hoje, muitas pessoas usam o Elastic para isso.
É um mecanismo poderoso e relativamente fácil de implementar. E já foi implementado pela maioria de nossos clientes voltados para eventos. O principal obstáculo à implementação geralmente passa a ser a questão de quem, em uma grande organização, gerenciará tal ferramenta, porque certamente ela precisa ser gerenciada centralmente. Será fácil para você criar sua própria interface de usuário para trabalhar com este mecanismo, permitindo que você encontre rapidamente informações relevantes para certas consultas.
Um exemplo de interface de monitoramento de eventos .
As desvantagens incluem a falta de gráficos que facilitam o trabalho com a lista de eventos. Mas você pode adicioná-los à infraestrutura, por exemplo, projetando eventos em um renderizador como o BPMN. Estruturas pequenas como bpmn.io permitem adicionar informações a diagramas exibidos como páginas HTML simples ( exemplo ) que podem ser empacotadas no plug-in Kibana.
Este modelo não pode ser executado com nenhum módulo de gerenciamento de processos de negócios, é apenas um diagrama utilizado para visualizar os eventos registrados. Deste ponto de vista, você tem uma certa liberdade na escolha dos detalhes da tela. E se você estiver especialmente interessado na imagem completa, pode criar modelos que mostram eventos de diferentes microsserviços em um diagrama. Um diagrama como este não o impedirá de fazer alterações em serviços individuais, portanto a flexibilidade de sua empresa não será afetada. Mas existe o risco de que os diagramas se tornem obsoletos em comparação com o estado atual do sistema operacional.
Ferramentas de mineração de processo
Na abordagem anterior, você teria que modelar explicitamente o diagrama a ser usado para renderização. Mas se não podemos saber com antecedência a natureza do fluxo de eventos, devemos primeiro investigá-lo.
Isso pode ser feito usando ferramentas de monitoramento e análise de processos. Eles podem criar e exibir graficamente um diagrama completo, geralmente permitindo que você explore os detalhes, especialmente relacionados a gargalos do sistema ou otimizações potenciais.
Parece a solução perfeita para o nosso problema. Infelizmente, essas ferramentas são usadas com mais frequência para investigar processos em arquiteturas legadas, então elas se concentram na análise de logs e funcionam mediocremente com fluxos de eventos ao vivo. Outra desvantagem é que eles são ferramentas puramente científicas que são difíceis de usar (por exemplo, ProM) ou muito pesadas (por exemplo, Celonis). Na minha experiência, é impraticável usar esses tipos de ferramentas em empreendimentos de microsserviço típicos.
Em qualquer caso, a exploração de processos e análise de dados trazem possibilidades interessantes para fornecer visibilidade em fluxos de eventos e processos de negócios. Esperançosamente, em breve haverá uma tecnologia com funcionalidade semelhante, mas mais leve, mais amigável ao desenvolvedor e mais fácil de implementar.
Rastreamento com automação de fluxo de tarefas
Outra abordagem interessante é modelar fluxos de tarefas e, em seguida, implantá-los e executá-los por meio do módulo de controle. Este modelo é especial no sentido de que apenas rastreia eventos e não faz nada ativamente. Ou seja, não gerencia nada - apenas registra. Falei sobre isso no Kafka Summit San Francisco 2018 , usando o Apache Kafka e o módulo de fluxo de trabalho de código aberto Zeebe para demonstração .
Esta oportunidade é especialmente interessante. Muitas são as inovações no campo dos módulos de controle, resultando em ferramentas compactas, fáceis de desenvolver e altamente escaláveis. Escrevi sobre isso em Eventos, fluxos e serviços de longa duração: uma abordagem moderna para automação de fluxo de trabalho . As desvantagens óbvias incluem a necessidade de modelagem preliminar do fluxo de tarefas. Mas por outro lado, este modelo pode ser executado usando o módulo de controle de processo, ao contrário do monitoramento de eventos. Basicamente, você inicia instâncias de processo para eventos de entrada ou mapeia eventos para uma instância. Também permite verificar se a realidade corresponde ao seu modelo.
Além disso, essa abordagem permite que você aproveite toda a cadeia de ferramentas fornecida pela plataforma de automação do fluxo de tarefas. Você pode ver o estado real do sistema, rastrear SLAs, detectar falhas de instâncias de processo ou realizar uma análise completa dos dados históricos de auditoria.
Um exemplo de monitoramento de um fluxo de tarefa.
Quando testei essa abordagem com nossos clientes, foi fácil de configurar. Acabamos de montar um componente genérico que recebe eventos do barramento e o combinamos com o módulo de controle de fluxo de tarefas. Se o evento não pudesse ser reconciliado, usamos uma pequena tabela de decisão para determinar se ele poderia ser ignorado ou se o evento levaria a um incidente que teria que ser investigado posteriormente. Também aprimoramos os módulos de controle de fluxo de tarefas usados em microsserviços para executar a lógica de negócios para que gerem certos eventos (por exemplo, uma instância de processo é iniciada, concluída ou concluiu algum estágio) que farão parte do quadro geral.
Tudo isso é semelhante ao monitoramento de eventos, mas com ênfase nos processos de negócios. Ao contrário do rastreamento, a abordagem captura todos os eventos de negócios e exibe o quadro geral em diferentes formatos adequados para diferentes partes interessadas.
Business Outlook
A disponibilidade de processos de negócios para monitoramento permite que você entenda o contexto. Você pode ver por uma instância específica como, quando e em que estado terminou. Isso significa que você pode entender qual caminho esse processo não seguiu (e outros costumam segui-lo) e quais eventos ou dados levaram a certas decisões. Você também pode entender o que pode acontecer em um futuro próximo. Outros tipos de monitoramento não permitem isso. Embora não seja comum hoje em dia discutir a questão da consistência entre negócios e TI, é imperativo que os não especialistas também sejam capazes de entender os processos de negócios e como os eventos fluem por meio de microsserviços diferentes.
Do rastreamento ao gerenciamento
O rastreamento de processos é uma ótima ferramenta para fornecer monitoramento operacional, relatórios, KPIs e transparência; todos esses são fatores importantes para manter a flexibilidade da empresa. Mas, em projetos atuais, o rastreamento é apenas a primeira etapa em direção a um gerenciamento e orquestração mais profundos em seu ecossistema de microsserviços.
Por exemplo, você pode começar monitorando os tempos limite de ponta a ponta. Quando ocorre um tempo limite, uma ação é executada automaticamente. No exemplo abaixo, após 14 dias notificaremos o cliente sobre o atraso, mas ainda iremos aguardar. E após 21 dias cancelaremos o pedido.
Curiosamente, enviar uma equipe para cancelar um pedido aqui é uma orquestração que costuma ser discutida de maneira controversa.
Orquestração
Costumo ouvir que a orquestração deve ser evitada porque leva à coerência ou perturba a autonomia de microsserviços individuais e, é claro, pode ser mal implementada. Mas também é possível implementar a orquestração de uma forma que seja consistente com os princípios de microsserviços e agregue grande valor comercial. Falei sobre isso em detalhes no InfoQ New York 2018 .
Para mim, orquestração significa que um serviço pode dizer a outro para fazer algo. E isso é tudo. Esta não é uma conexão próxima, mas um tipo diferente de conexão. Vamos lembrar nosso exemplo com um pedido. Pode ser aconselhável que a caixa registradora gere um pedido e o coloque no ônibus do evento sem saber quem o processará. O serviço de pedidos seleciona o evento sobre o pedido que apareceu. O destinatário fica sabendo do evento e decide fazer algo a respeito. Ou seja, a coesão está presente do lado do receptor.
Com o pagamento, a situação é diferente, pois é bastante estranho que o serviço de pagamento saiba para que o pagamento foi recebido. Mas ele precisará desse conhecimento para reagir aos eventos certos, como fazer ou fazer um pedido. Significa também que o serviço terá que ser alterado toda vez que você desejar receber pagamentos por novos produtos ou serviços. Em muitos projetos, essa conexão desagradável é contornada pela geração dos eventos de pagamento necessários, mas esses não são eventos, já que o remetente deseja que alguém faça algo a respeito. Esta é uma equipe! O serviço de pedidos comanda o serviço de pagamento para receber dinheiro. Nesse caso, o remetente sabe qual comando enviar e o faz, ou seja, a coesão está presente do lado do remetente.
Para que toda interação entre dois serviços seja eficaz, isso implica um certo grau de acoplamento. Mas dependendo da tarefa específica, pode ser aconselhável implementar conectividade em um dos lados.
O serviço de pedidos pode até ser responsável pela orquestração e outros serviços, acompanhando as etapas de atendimento do pedido. Discuti os benefícios dessa abordagem em detalhes na palestra acima. O truque é que uma boa arquitetura requer um equilíbrio entre orquestração e coreografia, o que nem sempre é fácil de fazer.
No entanto, neste artigo, eu queria me concentrar na transparência. E há uma vantagem óbvia na orquestração usando o módulo de fluxo de tarefas: um modelo não é apenas um código para o orquestrador executar, ele pode ser usado para fornecer transparência de fluxo.
Conclusão
É muito importante garantir a transparência dos processos do seu negócio, independentemente de sua implementação. Considerei diferentes abordagens e, em projetos reais, tudo geralmente se resume a algum tipo de monitoramento de eventos usando ferramentas como o Elastic, ou ao rastreamento de processos usando módulos de controle. Em parte, a escolha pode depender do caso específico e das funções das pessoas envolvidas. Por exemplo, um analista de negócios precisa entender os dados coletados de todas as instâncias de processo com o grau de detalhe necessário, enquanto um oficial de operações precisa analisar um processo específico em vários graus de detalhe e, provavelmente, adquirir ferramentas para resolver rapidamente incidentes no nível do sistema.
Se o seu projeto depende muito da coreografia, o rastreamento do processo pode levar você a adicionar orquestração. E eu acho que esta é uma etapa muito importante para manter o controle de longo prazo sobre seus processos de negócios. Caso contrário, você pode “fazer um sistema orientado a eventos cuidadosamente desacoplado, sem perceber que perderá transparência à medida que o número de eventos e processos aumentar e, assim, garantir a você mesmo problemas nos próximos anos”, como disse Martin Fowler . Se você estiver trabalhando em um sistema completamente novo, encontre um equilíbrio entre orquestração e coreografia desde o início.
No entanto, independentemente das especificações da implementação do sistema, certifique-se de fornecer à empresa uma exibição compreensível dos processos de negócios implementados usando serviços de interação.