Pontos Principais
- A comunicação peer-to-peer entre os componentes pode levar a um comportamento emergente, o que é um desafio para os desenvolvedores, operadores e analistas de negócios compreenderem.
- Precisa-se ter a certeza de uma visão geral de toda a comunicação anterior, posterior e atual para atender a uma capacidade de negócios.
- As soluções que fornecem uma visão geral variam a partir do rastreamento distribuído, o que geralmente deixa de lado a perspectiva de negócios; data lakes, que exigem algum esforço para sintonizar o que é necessário saber; rastreamento de processos, onde tem que se modelar um fluxo de trabalho para o rastreamento; processo de mineração, que pode descobrir o fluxo de trabalho; todo o caminho até a orquestração, que vem com a visibilidade embutida.
- Neste artigo, discutimos que é preciso equilibrar a orquestração e a coreografia em uma arquitetura de microservice para poder entender, gerenciar e alterar o sistema.
Há algum tempo, conheci um arquiteto de uma grande organização de comércio eletrônico. Ele me disse que eles fazem as coisas certas e dividem sua funcionalidade em partes menores ao longo dos limites (boundaries) de domínio, mesmo que não chamem esse estilo arquitetônico de "microservices". Em seguida, falamos sobre como esses serviços colaboram para realizar a lógica de negócios que ultrapassa os limites de serviço, já que é normalmente onde a as coisas ficam complicadas. Ele me disse que seus serviços interagem por meio de eventos publicados em um barramento, que é normalmente conhecido como "coreografia" (esse conceito será explicado em maior detalhe). Eles consideraram isso ideal em termos de desacoplamento. Mas o problema que enfrentam é que fica difícil entender o que está acontecendo e ainda mais difícil mudar alguma coisa. "Isto não é como as danças coreografadas que se vê nos slides de algumas palestras sobre microservices; isso está mais para uma platéia pulando em um show de rock!"
Isso corresponde ao que outros clientes me dizem, por exemplo Josh Wulf, da Credit Sense, disse que "o sistema que estamos substituindo usa uma complexa coreografia peer-to-peer que requer raciocínio através de múltiplas bases de código para entender".
Foto por Pedobear19 disponível sob CC BY-SA 4.0
Vamos investigar isso mais à fundo usando um exemplo simplificado. Suponha que se crie um aplicativo de preenchimento de pedidos. Escolhe-se implementar o sistema usando uma arquitetura orientada a eventos que usa, por exemplo, o Apache Kafka como um barramento de eventos. Sempre que alguém faz um pedido, um evento é disparado do serviço de checkout e recolhido por um serviço de pagamento. Este serviço de pagamento agora coleta dinheiro e dispara um evento que é captado por um serviço de inventário.
Fluxo de evento coreografado
A vantagem desta maneira de trabalhar é que pode-se incluir facilmente novos componentes no sistema. Suponha que se queira criar um serviço de notificação para enviar e-mails para seu cliente; pode-se simplesmente adicionar um novo serviço e assinar eventos relevantes, sem tocar em nenhum dos outros serviços. Em seguida pode-se gerenciar as configurações de comunicação e lidar com toda a complexidade das notificações de clientes compatíveis com GDPR nesse local central.
Esse estilo arquitetônico é chamado de coreografia, já que não é necessário um orquestrador que informe aos outros o que fazer. Em contraste, cada componente emite eventos e outros podem ser reativos a eles. Esse estilo assume que há redução do acoplamento entre os componentes e os sistemas, tornando-se mais fácil de desenvolver e mudar, o que é verdade para o serviço de notificação de esboço.
Perda de visão do fluxo de eventos
Neste artigo, vamos nos concentrar na pergunta mais frequente dessa arquitetura: Como evitamos perder de vista (e provavelmente controlar) o fluxo de eventos? Em uma pesquisa recente, Camunda (a empresa em que trabalho) perguntou sobre a adoção de microservices. 92% de todos os entrevistados ao menos consideram utilizar microservices, e 64% já utilizam microservices de alguma forma. É mais do que apenas exagero. Mas nessa pesquisa também perguntamos sobre os desafios e encontramos uma clara confirmação desse risco; A principal resposta foi a falta de visibilidade dos processos de negócios de ponta a ponta que abrangem vários serviços.
Quem se lembra das arquiteturas baseadas em gatilhos de banco de dados? Arquiteturas onde nunca se sabia exatamente o que aconteceria se alguma coisa mudasse - e espere - por que isso aconteceu? Desafios com microservices reativos às vezes me lembram um pouco disso, mesmo que essa comparação seja claramente equivocada.
Estabelecendo Visibilidade
Mas o que podemos fazer sobre isso? As abordagens a seguir podem nos ajudar a recuperar a visibilidade, mas cada um tem diferentes vantagens e desvantagens:
- Rastreamento distribuído (por exemplo, Zipkin ou Jaeger)
- Data Lakes ou ferramentas analíticas (por exemplo, Elastic)
- Mineração de processo (por exemplo, ProM)
- Acompanhamento usando automação de fluxo de trabalho (por exemplo, Camunda)
Esteja ciente de que todas as abordagens observam um sistema em execução e inspecionam as instâncias que passam por ele. Não conheço nenhuma ferramenta de análise estática que forneça informações úteis.
Rastreamento Distribuído
O rastreamento distribuído deseja rastrear pilhas de chamadas em diferentes sistemas e serviços. Isso é feito criando ids de rastreio exclusivos que são geralmente adicionados a determinados cabeçalhos genericamente (por exemplo, cabeçalhos HTTP ou de mensagens). Se todos no nosso universo entenderem ou, pelo menos, encaminharem esses cabeçalhos, podemos deixar um rastro enquanto uma solicitação é realizada por diferentes serviços.
Geralmente, o rastreamento distribuído é usado para entender como as solicitações fluem pelo sistema, identificar falhas ou investigar a raiz dos gargalos de desempenho. A ponto principal sobre o rastreamento distribuído é que existem ferramentas consolidadas no mercado com um ecossistema vivo ao redor. Por isso, é relativamente fácil começar, mesmo que se tenha que instrumentalizar (potencialmente de forma invasiva) seus aplicativos ou contêineres.
Então, por que não usar esta ferramenta para realmente entender como os processos de negócios emergem por meio de eventos que fluem pelo nosso sistema? Bem, basicamente duas razões tornam difícil a aplicação do rastreamento distribuído para este caso de uso:
- Os rastros são difíceis de entender para não-engenheiros. Meus experimentos pessoais com o objetivo de mostrar os rastros para pessoas não técnicas falharam miseravelmente. Era muito melhor investir algum tempo para redesenhar a mesma informação com caixas e setas. E mesmo que todas as informações sobre chamadas e mensagens de método sejam totalmente úteis para entender os comportamentos de comunicação, elas são muito refinadas para entender a essência dos processos de negócios entre serviços.
- Para gerenciar a massa avassaladora de dados refinados, o rastreamento distribuído usa a chamada amostragem. Isso significa que apenas uma pequena parte de todas as solicitações é coletada. Normalmente, mais de 90% das solicitações nunca são registradas. Uma boa ideia disso são os Três Pilares com Respostas Zero - em direção a um Novo Placar para o Monitoramento. Então nunca terá uma visão completa do que está acontecendo.
Data Lakes ou ferramentas analíticas
O rastreamento, feito de maneira heterodoxa, talvez não seja o caminho a ser seguido. O próximo passo lógico é fazer algo comparável, mas sob medida para o problema em questão. Isso basicamente significa não coletar rastreamentos, mas sim coletar eventos de negócios ou de domínios significativos que possa ter sido contornado de alguma maneira. Isso geralmente se resume a criar um serviço para ouvir todos os eventos e armazená-los em um armazenamento de dados que pode levar algum carregamento. Atualmente, muitos de nossos clientes usam o Elastic para essa finalidade.
Este é um mecanismo poderoso que é relativamente fácil de construir. A maioria dos clientes que trabalham de maneira orientada a eventos já têm essa configuração. A maior barreira para a introdução é muitas vezes a questão de quem irá operar tal ferramenta dentro de uma grande organização, pois ela definitivamente precisa ser gerenciada por alguma instalação centralizada. Também é fácil criar suas próprias interfaces de usuário dentro desta solução, para encontrar informações relevantes para determinadas perguntas com facilidade.
Exemplo de interface do monitor de eventos
Uma desvantagem é a falta de gráficos para fazer sentido de uma lista de eventos. Mas isso pode ser construído nessa infraestrutura, por exemplo, projetando eventos em alguma visualização como o BPMN.
Estruturas leves como o bpmn.io permitem que se adicione informações a esse diagrama em páginas HTML simples (um exemplo pode ser encontrado aqui) que também pode ser empacotado em um plug-in do Kibana.
Este modelo não é executado por algum mecanismo de workflow; é um diagrama usado para visualizar os eventos capturados de uma maneira diferente. Nesse sentido, também se tem alguma liberdade quanto à granularidade que mostrará, e também é correto ter modelos que mostrem eventos de diferentes microservices em um diagrama, pois é nisso que se está especialmente interessado: o quadro geral. A boa notícia é que esse diagrama não impede que se implemente alterações em serviços individuais, de forma que não atrapalhe a agilidade em sua organização, mas a desvantagem é que isso apresenta o risco de os diagramas se tornarem desatualizados, quando comparado com o estado atual dos serviços do sistema operacional em produção.
Ferramentas de Mineração de Processos
Na abordagem acima, deve-se modelar explicitamente o diagrama usado para visualização, mas se a natureza do fluxo de eventos não for conhecida antecipadamente, precisará ser descoberta primeiro.
Essa descoberta de processo pode ser feita por ferramentas de mineração de processo. Elas podem derivar o plano geral e mostrar isso graficamente, muitas vezes até mesmo permitindo a obtenção de muitos dados detalhados, especialmente em torno de gargalos ou oportunidades de otimização.
Isso soa como um ajuste perfeito para o nosso problema. Infelizmente, as ferramentas são usadas com mais frequência para descobrir fluxos de processos em arquiteturas legadas, de modo que elas se concentram na análise de arquivos de log e não são realmente boas em ingerir fluxos de eventos ao vivo. Outro problema com essas ferramentas é que elas são muito científicas e difíceis de usar (como o ProM) - ou muito pesadas (como o Celonis). Portanto, em nossa experiência, muitas vezes é impraticável introduzir essas ferramentas em esforços típicos de microservices.
No entanto, a descoberta de processos e a mineração adicionam recursos interessantes ao mix, a fim de obter visibilidade dos fluxos de eventos e processos de negócios. Espero que em breve surja uma tecnologia que ofereça funcionalidade comparável, mas leve, fácil de usar e fácil de ser adotada.
Acompanhamento por meio da automação de fluxo de trabalho
Outra abordagem interessante é modelar o fluxo de trabalho (workflow), mas depois implementá-lo e executá-lo em um fluxo de trablho real. O modelo de fluxo de trabalho é especial em um sentido, pois apenas rastreia os eventos e não faz nada além disso. Por isso, não orienta nada - simplesmente grava. Falei sobre isso no Kafka Summit San Francisco 2018, e a gravação inclui uma demonstração ao vivo usando o Apache Kafka e o mecanismo de fluxo de trabalho de código aberto Zeebe.
Essa opção é especialmente interessante, pois há muita inovação no mercado de mecanismos de fluxo de trabalho, o que resulta no surgimento de ferramentas leves, fáceis de usar e altamente escaláveis. Eu escrevi sobre isso em Eventos, fluxos e serviços de longa duração: uma abordagem moderna para automação de fluxo de trabalho. A desvantagem óbvia é que se deve modelar o fluxo de trabalho antecipadamente. Mas, em contraste com o monitoramento de eventos, esse modelo é executado em um mecanismo de fluxo de trabalho - na verdade, inicia-se instâncias de fluxo de trabalho para eventos de entrada ou correlaciona eventos a essa instância de fluxo de trabalho. Isso também permite verificações de conformidade - a realidade se encaixa no modelo?
Essa abordagem permite que se aproveite toda a cadeia de ferramentas das plataformas de automação de fluxo de trabalho, o que permite ver o que está acontecendo atualmente, monitorar SLAs e detectar instâncias paralisadas ou fazer uma análise detalhada dos dados de histórico de auditoria.
Exemplo de monitoramento de fluxo de trabalho (da camunda.com)
Quando validei essa abordagem com os clientes, foi fácil configurar. Nós apenas tivemos que construir um componente genérico captando eventos do barramento e correlacioná-lo ao mecanismo de fluxo de trabalho. Sempre que um evento não pudesse ser correlacionado, usamos uma pequena tabela de decisão para decidir se ele poderia ser ignorado ou produziria um incidente para ser verificado mais tarde. Também instrumentamos mecanismos de fluxo de trabalho usados em microservices para executar a lógica de negócios para gerar determinados eventos (por exemplo, instância de fluxo de trabalho iniciada, finalizada ou marcada como concluída) a serem usados na imagem geral.
Esse acompanhamento de fluxo de trabalho é um pouco parecido com o monitoramento de eventos, mas com um foco de processo de negócios. Ao contrário do rastreamento, ele pode registrar 100% dos seus eventos de negócios e fornecer uma visão adequada para os vários interessados.
A perspectiva do negócio
Uma grande vantagem de ter o processo de negócios disponível no monitoramento é que se entende o contexto. Para uma determinada instância, sempre pode-se ver como e por que ela acabou no estado atual, o que permite que entender qual caminho não foi executado (mas outras instâncias geralmente o fazem) e quais eventos ou dados levam a determinadas decisões. Também pode-se ter uma ideia do que pode acontecer no futuro próximo. Isso é algo que se sente falta em outras formas de monitoramento. E mesmo que não seja comum discutir o alinhamento entre negócios e TI, é absolutamente necessário que os não-engenheiros também entendam os processos de negócios e como os eventos fluem através de vários microservices.
Uma jornada do rastreamento ao gerenciamento
O rastreamento de processos é bom, pois isso proporciona monitoramento, relatórios, KPIs e visibilidade operacionais como um importante pilar para manter a agilidade. Mas, nos projetos atuais, essa abordagem de rastreamento é, na verdade, apenas o primeiro passo em uma jornada em direção a mais gerenciamento e orquestração em seu panorama de microservices.
Um exemplo simples pode ser começar a monitorar os tempos limite do seu processo de ponta a ponta. Sempre que esse tempo limite é atingido, alguma ação é executada automaticamente. No exemplo a seguir, informamos o cliente sobre um atraso após 14 dias - mas ainda continuamos aguardando. Após 21 dias desistimos e cancelamos o pedido.
Um aspecto interessante na imagem acima é o envio da ordem de comando de cancelamento. Isso é orquestração - e isso às vezes é discutido de maneira controversa.
Orquestração
Muitas vezes ouço que a orquestração deve ser evitada com o argumento de que ela introduz o acoplamento ou viola a autonomia de microservices únicos. E é claro que é verdade que a orquestração pode ser mal feita, mas também pode ser feita de uma maneira que se alinhe aos princípios de microservices, ao mesmo tempo em que agrega muito valor ao negócio. No QCon New York 2018 falei especificamente sobre esse equívoco.
Em sua essência, a orquestração para mim significa que um serviço pode ordenar que outro faça alguma coisa. É isso. Isso não é um acoplamento mais forte, é apenas acoplado de maneira diferente. Veja o exemplo do pedido. Pode ser uma boa ideia que o serviço de checkout apenas emita um evento de encomenda, mas não saiba quem o processa. O serviço de pedidos ouve o pedido realizado. O receptor sabe sobre o evento e decide fazer algo a respeito; o acoplamento está no lado da recepção.
É diferente com o pagamento, porque não seria natural que o serviço de pagamento saiba para que serve o pagamento. Mas seria necessário que o conhecimento para reagir aos eventos certos, como ordem colocada ou ordem criada. Isso também significa que ele precisa ser alterado sempre que se quiser receber pagamentos por novos produtos ou serviços. Muitos projetos trabalham em torno desse acoplamento desfavorável, emitindo eventos de pagamento requerido, mas isso não são eventos, pois o remetente deseja que outra pessoa faça alguma coisa. Isto é um comando! O serviço de pedidos comanda o pagamento para recuperar dinheiro. Nesse caso, o remetente sabe sobre o comando para enviar e decide usá-lo; o acoplamento está no lado de envio.
Cada comunicação entre dois serviços envolve algum grau de acoplamento para ser eficaz, mas dependendo do problema em questão, pode ser mais apropriado implementar o acoplamento dentro de um deles ao invés de outro.
O serviço de pedidos pode até ser responsável por orquestrar mais serviços e acompanhar a sequência de etapas no cumprimento de pedidos. Discuti as vantagens na conversa acima mencionada em detalhes. A parte complicada é que uma boa arquitetura precisa equilibrar a orquestração e a coreografia, o que nem sempre é fácil de fazer.
Mas para este artigo gostaríamos de focar na visibilidade. E há uma vantagem óbvia da orquestração usando um mecanismo de fluxo de trabalho; o modelo não é apenas o código para executar a orquestração, ele também pode ser usado diretamente para a visibilidade do fluxo.
Resumo
É essencial obter visibilidade dos processos de negócios, independentemente da maneira como são implementados. Foram discutidas várias possibilidades e, na maioria das situações do mundo real, isso geralmente se resume a algum monitoramento de eventos usando ferramentas do tipo Elastic ou rastreamento de processo usando mecanismos de fluxo de trabalho. Isso pode depender um pouco do contexto e da função envolvida, portanto, os analistas de negócios precisam entender os dados coletados de todas as instâncias na granularidade correta, enquanto as pessoas de operações precisam examinar uma instância específica com granularidade variável e provavelmente desejarão ter ferramentas para resolver rapidamente o problema de incidentes de alto nível.
Se você tem um modelo bem coreografado, o rastreamento de processos pode levá-lo a uma jornada rumo a mais orquestração, o que eu acho que é um passo muito importante para manter o controle de seus processos de negócios a longo prazo. Caso contrário, pode-se "criar sistemas realmente desacoplados com a notificação de eventos, sem perceber que está perdendo o fluxo em grande escala e, assim, enfrentar problemas nos próximos anos", como diz Martin Fowler. Se está trabalhando em um sistema mais novos, deve-se encontrar um bom equilíbrio para orquestração e coreografia desde o início.
No entanto, independentemente dos detalhes de implementação do seu sistema, verifique se tem uma visão favorável aos seus processos de negócios implementados pelos serviços de colaboração.
Sobre o autor
Bernd Ruecker é co-fundador e tecnologista da Camunda. Anteriormente, ele ajudou a automatizar fluxos de trabalho centrais altamente escaláveis em empresas globais, incluindo a T-Mobile, a Lufthansa e o Zalando. Ele está atualmente focado em novos paradigmas de automação de fluxo de trabalho que se encaixam em arquiteturas modernas em torno de sistemas distribuídos, microservices, design orientado a domínio, arquitetura orientada a eventos e sistemas reativos.