{"id":5073,"date":"2022-07-07T15:09:06","date_gmt":"2022-07-07T18:09:06","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=5073"},"modified":"2024-01-11T18:01:04","modified_gmt":"2024-01-11T21:01:04","slug":"fundamentos-para-arquiteturas-baseadas-em-eventos-eda-capitulo-8-v-1-02","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda-capitulo-8-v-1-02\/","title":{"rendered":"Fundamentos para arquiteturas baseadas em eventos (EDA) \/ Cap\u00edtulo 8 v 1.02"},"content":{"rendered":"Em um mundo cada vez mais conectado, onde produtos e sistemas t\u00eam cada vez mais sensores e poder de processamento, com modelos de neg\u00f3cios cada vez mais adaptados ao comportamento individual, ganha mais relev\u00e2ncia a capacidade de reconhecer, assimilar e reagir adequadamente a ocorr\u00eancia de eventos de diversas naturezas.\n
\n

A tecnologia da informa\u00e7\u00e3o est\u00e1 revolucionando os produtos. Antes compostos apenas por pe\u00e7as mec\u00e2nicas e el\u00e9tricas, os produtos se tornaram sistemas complexos que combinam hardware, sensores, armazenamento de dados, microprocessadores, software e conectividade de in\u00fameras maneiras. (Porter e Heppelmann)<\/em><\/p>\n

Sob a perspectiva de sistemas computacionais um evento \u00e9 um registro de algo que j\u00e1 aconteceu.<\/strong> Uma venda realizada, uma entrega efetuada, um pagamento efetivado, etc.<\/p>\n

O aumento exponencial na quantidade de sensores e na conectividade tem feito “explodir” a quantidade e \u00a0granularidade de eventos identificados em sistemas computacionais que precisam ser assimilados e tratados.<\/strong> Carros modernos, por exemplo, al\u00e9m de todos os sensores que monitoram o comportamento de seus componentes, tamb\u00e9m registram o comportamento dos condutores, identificam outros carros e as condi\u00e7\u00f5es da pista. Neles, o software embarcado toma decis\u00f5es “inteligentes” em tempo real e, eventualmente, conecta-se a outros software na “nuvem”, para realiza\u00e7\u00e3o de a\u00e7\u00f5es consolidadas.<\/p>\n

A demanda por formas eficientes de lidar com eventos tamb\u00e9m \u00e9 marcante em opera\u00e7\u00f5es com cart\u00f5es de cr\u00e9dito e sistemas de vota\u00e7\u00e3o, detectando fraudes; em sistemas de atendimento, qualificando o processo; em sistemas de vendas, habilitando\u00a0up-selling\u00a0<\/em>e\u00a0cross-selling,\u00a0<\/em>apenas para citar mais alguns exemplos.<\/p>\n

Sistemas modernos precisam reconhecer, assimilar e tratar eventos de maneira eficiente e eficaz e essa realidade fez surgir uma s\u00e9rie de padr\u00f5es e pr\u00e1ticas arquiteturais.<\/strong> As arquiteturas que utilizam esses padr\u00f5es e pr\u00e1ticas s\u00e3o identificadas como event-driven architectures<\/em>\u00a0(EDAs). Elas se destacam por serem\u00a0escal\u00e1veis, adapt\u00e1veis, responsivas e, geralmente, perform\u00e1ticas.<\/p>\n

\r\n

Diferen\u00e7a entre responsividade e performance<\/p>\r\n<\/p>\n

Frequentemente, h\u00e1 confus\u00e3o entre responsividade e performance.<\/p>\n

A responsividade<\/strong>\u00a0\u00e9 um atributo de qualidade que tem rela\u00e7\u00e3o com o tempo que um usu\u00e1rio ou sistema cliente tem de esperar para, ap\u00f3s iniciar alguma opera\u00e7\u00e3o, poder iniciar outra.<\/p>\n

A performance<\/strong>, tamb\u00e9m um atributo de qualidade, tem rela\u00e7\u00e3o com o tempo total demandado por um sistema computacional para processar uma opera\u00e7\u00e3o completamente.<\/p>\n

Assim, um sistema pode ser responsivo sem ser perform\u00e1tico.<\/p>\n

<\/div>\n

Aplica\u00e7\u00f5es desenvolvidas com arquiteturas event-driven<\/em> s\u00e3o compostas por componentes desacoplados para produ\u00e7\u00e3o e tratamento de eventos, sempre de maneira ass\u00edncrona.<\/strong><\/p>\nO desacoplamento dos componentes de arquiteturas event-driven\u00a0<\/em>facilita a defini\u00e7\u00e3o de\u00a0ownership,\u00a0<\/em>reduzindo riscos de difus\u00e3o de responsabilidade, e se destacam pelo\u00a0evolvability<\/em>. Entretanto, \u00e9 ineg\u00e1vel a complexidade frente a pr\u00e1ticas e padr\u00f5es ortodoxos.\n

Request-driven<\/em> versus Event-driven<\/em><\/h2>\n

Os benef\u00edcios gerados por arquiteturas\u00a0event-driven\u00a0<\/em>chamam a aten\u00e7\u00e3o mesmo em cen\u00e1rios onde lidar com eventos n\u00e3o \u00e9 necessidade prim\u00e1ria.<\/strong><\/p>\n

A maioria das aplica\u00e7\u00f5es LoB (Line-of-business<\/i>), por exemplo, operam, tradicionalmente, em modelo\u00a0request-driven.\u00a0<\/i><\/strong>Ou seja, onde requisi\u00e7\u00f5es s\u00e3o realizadas atrav\u00e9s de interfaces com usu\u00e1rios, suportadas por APIs, encaminhadas para\u00a0handlers\u00a0<\/em>que, por sua vez, fazem consultas ou atualiza\u00e7\u00f5es em bases de dados, normalmente de forma s\u00edncrona. Esse modelo \u00e9 plenamente alinhado com a realidade do dom\u00ednio e geralmente apropriado. Entretanto, apresenta desafios bem conhecidos para suportar o aumento da escala sem comprometer a efici\u00eancia.<\/p>\n

Os benef\u00edcios de arquiteturas\u00a0event-driven\u00a0<\/em>t\u00eam levado times de tecnologia e de neg\u00f3cios a adaptar seus modelos de opera\u00e7\u00e3o para que sejam compat\u00edveis com elas, visando melhorar a responsividade e resili\u00eancia de\u00a0seus sistemas.<\/strong> O varejo online, por exemplo, vem “desacoplando” processos de venda, segregando eventos em “pedido realizado”, “pagamento efetivado”, “produto separado”, etc.<\/p>\n

\r\n

EDA e Domain-driven design<\/p>\r\n<\/p>\n

A elabora\u00e7\u00e3o de arquiteturas\u00a0event-driven\u00a0<\/em>tem sido facilitada pelo uso de\u00a0Domain-driven Design<\/em>.<\/p>\n

A identifica\u00e7\u00e3o de contextos delimitados, com suas respectivas responsabilidades, faz emergir naturalmente os “eventos de dom\u00ednio”, utilizados sobretudo para a comunica\u00e7\u00e3o entre contextos diversos, de maneira alinhada as demandas do neg\u00f3cio.<\/p>\n

Ali\u00e1s, uma das t\u00e9cnicas mais populares para “descoberta” do dom\u00ednio \u00e9 centrada em eventos: event storming.<\/em><\/p>\n

<\/div>\n

Outro ponto interessante relacionado \u00e0 arquiteturas event-driven<\/em>, frente a arquiteturas request-driven,<\/em>\u00a0\u00e9 a amplia\u00e7\u00e3o da resili\u00eancia em fun\u00e7\u00e3o da possibilidade de tratar mensagens mal-formadas ou poison pills,\u00a0<\/em>sem comprometer o fluxo transacional. Afinal, mensagens “problem\u00e1ticas” voltam para a fila, para retentativas, e, eventualmente, podem ser encaminhadas para filas de mensagens com problemas.<\/p>\n\u00c9 recomend\u00e1vel adotar arquiteturas event-driven, em substitui\u00e7\u00e3o a request-driven<\/em>, em cen\u00e1rios que demandem responsividade (varejo online, por exemplo) e resili\u00eancia, com alta complexidade e dinamismo nas intera\u00e7\u00f5es. Entretanto, o aumento da complexidade n\u00e3o ter\u00e1 suficiente compensa\u00e7\u00e3o para opera\u00e7\u00f5es \u00a0mais simples e obrigatoriamente s\u00edncronas.\n

\n

Dois tipos de EDA<\/h2>\n

De forma abstrata, podemos classificar arquiteturas\u00a0event-driven\u00a0<\/i>em expl\u00edcitas e impl\u00edcitas.<\/strong><\/p>\n

Arquiteturas event-driven<\/em>\u00a0s\u00e3o expl\u00edcitas quando os componentes que produzem eventos “conhecem” todos os componentes que os consomem. Nesses cen\u00e1rios, n\u00e3o \u00e9 incomum que os componentes produtores acionem os consumidores\u00a0<\/em>diretamente, com c\u00f3digo. Evidentemente, tal abordagem aumenta o acoplamento.<\/p>\n

Em implementa\u00e7\u00f5es EDA impl\u00edcitas, n\u00e3o h\u00e1 qualquer “conex\u00e3o fixa” entre produtores e consumidores de eventos. Assim, componentes consumidores precisam especificar, de alguma forma, os tipos de eventos em que est\u00e3o interessados. Os produtores “publicam” os eventos aos consumidores atrav\u00e9s de algum mecanismo de “assinatura”, exercendo menor controle.<\/p>\nDos dois tipos de EDA, a abordagem impl\u00edcita \u00e9, evidentemente, mais poderosa, entretanto, incrementalmente mais complexa, pois, na medida em que os sistemas crescem, \u00e9 mais desafiador monitorar e avaliar resultados.\n

Duas topologias fundamentais<\/h2>\n

H\u00e1 duas topologias fundamentais para implementa\u00e7\u00e3o de arquiteturas event-driven<\/em>. A primeira delas \u00e9 baseada na ideia de mediadores ativos e orquestra\u00e7\u00e3o. A segunda, \u00e9 baseada na utiliza\u00e7\u00e3o de intermediadores (brokers<\/em>) e coreografia.<\/strong><\/p>\nImplementa\u00e7\u00f5es event-driven<\/em> que utilizam mediadores ativos e orquestra\u00e7\u00e3o s\u00e3o mais apropriadas para cen\u00e1rios onde o tratamento de eventos precise ser gerenciado, com forte controle sobre falhas e sobre o andamento. Por outro lado, implementa\u00e7\u00f5es com brokers<\/em> e coreografia s\u00e3o mais apropriadas para estruturas din\u00e2micas, fire-and-forget<\/em>.\n

\n

Ambas as abordagens assumem que um “evento inicial” ser\u00e1 capturado pelo sistema iniciando processamento.<\/p>\n

Usando mediadores ativos e orquestra\u00e7\u00e3o<\/h4>\n

A principal caracter\u00edstica de uma arquitetura event-driven com mediadores ativos e orquestra\u00e7\u00e3o \u00e9 a presen\u00e7a de um componente orquestrador (o mediador ativo) que gerencia e controla o fluxo de atividades, acionando componentes processadores, de maneira organizada, em tempos apropriados.<\/strong><\/p>\n

Nessa topologia, expl\u00edcita, um “evento inicial” \u00e9 submetido a uma fila que \u00e9 “escutada” pelo componente mediador. Este componente, por sua vez, “sabe” quais procedimentos que devem ser executados para “tratar” o evento e em que sequ\u00eancia. Por isso, aciona “executores”, notificando-os com eventos atrav\u00e9s de canais de eventos point-to-point<\/em>.\u00a0Toda vez que um componente executor conclui seu trabalho, geralmente notifica o componente mediador.<\/p>\n

\"\"<\/p>\n

Os componentes executores comunicam-se apenas com o componente mediador, nunca com outros componentes executores. Enquanto isso,\u00a0os componentes mediadores s\u00e3o a “fonte da verdade” com rela\u00e7\u00e3o ao est\u00e1gio de execu\u00e7\u00e3o de um fluxo para tratamento de um evento.<\/p>\n

De maneira concreta, quando o mediador exerce fun\u00e7\u00e3o ativa, direcionado o workflow<\/em>, muitas vezes comunica-se enviando comandos para os diversos processadores.<\/p>\n

\"\"<\/p>\n

Geralmente, aplica\u00e7\u00f5es com arquiteturas event-driven<\/em> desenvolvidas nessa abordagem t\u00eam diversos componentes mediadores, algumas vezes, agrupados processos correlatos, outras vezes, ponderando estrat\u00e9gias para atender atributos de qualidade como disponibilidade, elasticidade e performance.<\/p>\n

Mediadores podem ser implementados em c\u00f3digo puro ou utilizando tecnologias como Apache Camel<\/a> e Mule ESB<\/a> ou Apache ODE<\/a>. H\u00e1 tamb\u00e9m quem defenda a utiliza\u00e7\u00e3o de ferramentas BPM (e BPA).<\/p>\n

Usando brokers e coreografia<\/h4>\n

Diferente da abordagem utilizando mediadores e orquestra\u00e7\u00e3o, a utiliza\u00e7\u00e3o de brokers<\/em> e coreografia se destaca pela inexist\u00eancia de um componente central, respons\u00e1vel pelo sequenciamento dos trabalhos.<\/strong><\/p>\n

Nessa topologia, impl\u00edcita, componentes executores s\u00e3o acionados de maneira encadeada, onde um componente executor encaminha um evento para um message broker (como RabbitMQ<\/a> ou outras implementa\u00e7\u00f5es AMQP<\/a>), sempre que conclui seu trabalho, acionando outro(s) componente(s) executor(es), e assim sucessivamente, at\u00e9 que todo o processamento necess\u00e1rio aconte\u00e7a.<\/p>\n

\"\"<\/p>\nA estrat\u00e9gia de cada componente executor ao encaminhar eventos \u00e9 do tipo fire-and-forget<\/em> e \u00e9 muito importante que todo processamento executado seja notificado, com eventos, ao sistema, ampliando chances de extensibilidade ao custo de desperd\u00edcio de recursos computacionais (com eventos que n\u00e3o s\u00e3o “escutados” por ningu\u00e9m).\n

\n
\r\n

Fire-and-forget<\/p>\r\n<\/p>\n

Fire-and-forget\u00a0<\/em>\u00e9 um padr\u00e3o de mensageria onde o produtor envia uma mensagem para um consumidor sem esperar resposta.\u00a0Trata-se da\u00a0forma\u00a0mais simples de troca de mensagens. <\/strong><\/p>\n

Fire-and-Forget<\/em>\u00a0destaca-se pelo baix\u00edssimo acoplamento, afinal o produtor n\u00e3o precisa saber nada sobre seus consumidores, incluindo quantos existem ou o que eles fazem com a mensagem.\u00a0Esse tipo de intera\u00e7\u00e3o sem estado resulta em sistemas de mensagens altamente escal\u00e1veis.<\/p>\n

A simplicidade e o baixo acoplamento, entretanto, tem seu pre\u00e7o: o tratamento de erros n\u00e3o \u00e9 poss\u00edvel porque n\u00e3o h\u00e1 feedback<\/em> sobre a “entrega” das mensagens. Assim, implementa\u00e7\u00f5es Fire-and-Forget<\/em> devem utilizar mecanismos mais robustos de “entrega” ou aceitarem que algumas mensagens possam ser perdidas. Al\u00e9m disso, \u00e9 importante ter consci\u00eancia de que um consumidor ter\u00e1 pouco a fazer caso a mensagem recebida esteja mal-formada ou com dados inv\u00e1lidos.<\/div>\n

Tr\u00eas padr\u00f5es de processamento<\/h2>\n

Componentes executores assumem, basicamente, tr\u00eas padr\u00f5es de comportamento:<\/p>\n

    \n
  1. processamento simples;<\/li>\n
  2. processamento de streams;\u00a0<\/em><\/li>\n
  3. processamento de eventos complexos (complex event processing<\/em> – CEP).<\/li>\n<\/ol>\n
    \n

    Enquanto o padr\u00e3o de processamento simples ocorre tanto arquiteturas orquestradas e coreografadas, processamento de streams <\/em>e de eventos complexos costumam ser implementadas apenas em topologias coreografadas.<\/p>\n

    O detalhamento desses padr\u00f5es de execu\u00e7\u00e3o est\u00e3o al\u00e9m do escopo desse livro. Ali\u00e1s, h\u00e1 obras inteiras dedicadas ao tema.<\/p>\n

    Processamento simples<\/h4>\n

    Componentes executores que operam adotando processamento simples, “escutam” um determinado tipo de mensagem e executam, para cada ocorr\u00eancia, algum trabalho. Trata-se do padr\u00e3o mais f\u00e1cil de implementar e, provavelmente, mais comum.<\/p>\n

    Processamento de streams<\/em><\/h4>\n

    Componentes executores que operam adotando processamento de streams<\/em>, podem “escutar” diversas ocorr\u00eancias de eventos mas s\u00f3 executam algum processamento quando algum crit\u00e9rio \u00e9 atendido. Estes executores operam agregando, analisando e processando\u00a0streams\u00a0<\/em>de eventos.<\/p>\n

    Considere, por exemplo, um componente executor recebendo todas as transa\u00e7\u00f5es de um determinado cart\u00e3o de cr\u00e9dito. Caso duas transa\u00e7\u00f5es presenciais (dois eventos) sejam executadas em localidades afastadas a uma dist\u00e2ncia maior do que aquela que poderia ser percorrida no intervalo de tempo entre as ocorr\u00eancias, este\u00a0executor\u00a0<\/em>poderia gerar um evento (agrega\u00e7\u00e3o) indicando possibilidade de fraude.<\/p>\n

    Processamento de eventos complexos (CEP)<\/h4>\n

    Componentes executores que operam adotando processamento de eventos complexos, identificam eventos significativos (como oportunidades ou amea\u00e7as) a partir de eventos menos expressivos, oriundos de dois ou mais streams<\/em>.<\/p>\n

    Sagas<\/h2>\n

    Em aplica\u00e7\u00f5es monol\u00edticas, geralmente, temos um frontend<\/em> conectando a um \u00fanico servi\u00e7o que, por sua vez, se conecta a apenas um banco de dados que serve como a \u201cgrande fonte da verdade\u201d.\u00a0Por mais complexas que sejam as opera\u00e7\u00f5es, podemos usar, quase sempre o recurso de transa\u00e7\u00f5es do banco de dados para garantir a preserva\u00e7\u00e3o da consist\u00eancia.<\/p>\n

    \"\"<\/p>\n

    Imaginemos, entretanto, que n\u00e3o seja poss\u00edvel estabelecer uma \u201cfonte \u00fanica de verdade\u201d ou, ainda, que a arquitetura da aplica\u00e7\u00e3o utilize mais que um banco de dados (conforme contexto delimitado).\u00a0 Vamos considerar, por exemplo, o desenvolvimento de um servi\u00e7o para apoiar a compra de produtos associados a viagens. Nesse contexto, desejar\u00edamos ajudar nossos clientes na aquisi\u00e7\u00e3o de bilhetes a\u00e9reos, no aluguel de carros e na reservas em hot\u00e9is.<\/p>\n

    \"\"<\/p>\n

    No “mundo perfeito”, sempre que um cliente resolvesse viajar, poder\u00edamos disparar a compra do bilhete a\u00e9reo, a reserva do hotel e do carro de forma paralela. Nosso trabalho seria apenas consolidar as confirma\u00e7\u00f5es em nosso \u201cbanco de dados\u201d para poder fornecer ao cliente as informa\u00e7\u00f5es de cada servi\u00e7o contratado. Mas, o que aconteceria se:<\/p>\n