Como aumentar os elementos da API da arquitetura orientada a eventos

Como aumentar os elementos da API da arquitetura orientada a eventos

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Muitas organizações em transformação digital estão sob pressão para conectar seus aplicativos, dados e dispositivos – na maioria das vezes, o caminho para o sucesso é mudar para uma estratégia de integração baseada em API.

APIs desempenham uma função específica dentro de uma abordagem liderada por API – desbloquear dados de sistemas, compor dados em processos ou entregar uma experiência. Se toda a organização se comprometer com essa abordagem, todos na empresa têm autonomia para acessar seus melhores recursos na entrega de aplicativos e projetos por meio de descoberta, autoatendimento e reutilização.

No entanto, de acordo com o Gartner, cerca de 50% das APIs gerenciadas darão suporte à TI orientada a eventos até 2020. APIs orientadas a eventos farão parte de uma combinação de tecnologia que ajudará uma organização a obter uma vantagem competitiva com integração em tempo real. Por esse motivo, as organizações – não apenas no início da definição de sua estratégia de integração – regularmente nos fazem duas perguntas comuns:

  • Devemos alavancar uma arquitetura baseada em eventos ou abordagem baseada em API?
  • Existe um híbrido entre conectividade baseada em eventos e conectividade baseada em API?

Nesta postagem do blog, discutiremos as diferenças entre eventos e APIs, discutiremos as diferenças entre uma arquitetura orientada a eventos e a conectividade orientada por API, como elas podem trabalhar juntas e como isso beneficiará seus negócios.

Eventos x APIs

Eventos e APIs podem ser comparados e contrastados ao longo das seguintes dimensões:

  • Programático: Ambos são abordagens de comunicação principalmente programáticas por natureza, ou seja, destinadas à comunicação entre os componentes do aplicativo.
  • Significado: Um evento descreve uma mudança de estado que ocorreu em um componente do aplicativo que atua como o produtor do evento, enquanto uma API é uma interface programática para um serviço fornecido pelo componente do aplicativo que expõe essa API.
  • Natureza dinâmica: Um evento descreve algo que já aconteceu, enquanto uma API descreve uma ação que será executada assim que a chamada da API for recebida.
  • Natureza estática: Eventos que denotam mudanças de estado do mesmo tipo do mesmo tipo de evento. Isso é o equivalente da API e, especificamente, do modelo de dados da API usado na especificação da API.
  • Granularidade: Um tipo de evento é normalmente para uma mudança de estado bem definida, enquanto uma chamada de API pode expor muitos recursos e oferecer suporte a muitos métodos HTTP por recurso. Portanto, uma API é mais semelhante a um grupo de tipos de eventos do que a um único tipo de evento.
  • Sincronicidade: As chamadas de API são, por definição, síncronas, consistindo em solicitação e resposta síncrona, embora o processamento acionado por uma chamada de API possa ser executado de forma assíncrona. Portanto, se o cliente da API e a implementação da API não estiverem disponíveis durante a chamada da API, haverá falha. Em contraste, os eventos são trocados de forma assíncrona – portanto, o produtor do evento e o consumidor são desacoplados no tempo.
  • Caminho de comunicação: Uma chamada de API é de um cliente de API para uma implementação de API, e o cliente de API aborda especificamente a implementação de API. Os eventos são enviados por um produtor de eventos a um destino (fila, tópico, troca de mensagens – dependendo do paradigma do sistema de mensagens) e são recebidos pelos consumidores de eventos desse destino. Sem que o produtor e o consumidor sejam um ao outro. Além disso, pode haver mais de um consumidor para cada evento.
  • Corretor: A troca de eventos requer um agente de mensagens, como Anypoint MQ, Kafka, ActiveMQ ou RabbitMQ – apenas para citar alguns. Eles atuam como proprietários de destinos, enquanto as chamadas de API, no mínimo, requerem apenas cliente de API e implementação de API.
  • Contrato: O contrato para uma API é sua especificação de API – de preferência, uma definição de RAML. O contrato para um evento é a combinação de destino e tipo de evento (dados) e pode ser descrito por uma definição AsyncAPI.
Leia Também  8 modelos anuais fáceis de planejamento e orçamento de marketing I Smart Insights

Agora que entendemos as diferenças entre eventos e APIs, podemos começar a comparar a arquitetura orientada a eventos e a conectividade orientada por API.

Arquitetura baseada em eventos vs. conectividade baseada em API

A MuleSoft define a conectividade baseada em API através da lente de uma abordagem em três camadas. Essas três camadas são compostas por APIs de experiência, APIs de processo e APIs de sistema.

Embora os eventos de troca de componentes de aplicativo possam ser organizados de forma semelhante – isso não é uma parte inerente de uma arquitetura orientada a eventos.

A conectividade baseada em API restringe os padrões de comunicação de acordo com as três camadas (essencialmente de cima para baixo), enquanto os eventos de troca de componentes do aplicativo não precisam aderir às mesmas restrições de padrão de comunicação.

Implementações de API geralmente têm dependências estáticas bem definidas em outras APIs ou sistemas back-end. Embora relacionamentos semelhantes possam se materializar em uma arquitetura orientada a eventos em tempo de execução, não há dependências estáticas entre os componentes do aplicativo trocando eventos. Em vez disso, esses componentes de aplicativo dependem apenas dos tipos de eventos trocados, dos destinos e do intermediário de mensagens que hospeda esses destinos. Além disso, os consumidores de eventos podem mudar dinamicamente a qualquer momento, reconfigurando dinamicamente o gráfico de relacionamento dos componentes do aplicativo em uma arquitetura orientada a eventos, sem que os produtores de eventos tomem conhecimento dessa mudança.

Uma arquitetura orientada a eventos requer um agente de mensagens como um componente adicional da arquitetura de tecnologia, com todos os componentes do aplicativo que trocam eventos tendo que concordar com o mesmo agente de mensagens.

Leia Também  Comece sua jornada na nuvem no Cloud Summit
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

A conectividade baseada em API (e em redes de aplicativos específicos) é definida pelos ativos centrados em API publicados para consumo de autoatendimento. O equivalente para uma arquitetura orientada a eventos giraria em torno de destinos e tipos de eventos.

Uma arquitetura orientada a eventos e conectividade orientada por API podem trabalhar juntas?

Vamos examinar alguns cenários que geram a necessidade de elementos da arquitetura orientada a eventos.

  • Integração com aplicativos SaaS modernos: Eles dependem muito de abordagens de uma arquitetura orientada a eventos para garantir alta disponibilidade e escalabilidade (por exemplo, arquitetura orientada a eventos na plataforma Salesforce Customer 360).
  • Internet das Coisas: O enorme volume de eventos transmitidos de dispositivos precisa estar acessível em tempo real e em escala, o que torna as APIs de solicitação-resposta síncronas pouco razoáveis.
  • Tolerância a falhas: um sistema está ouvindo notificações quando transações ou pedidos em um sistema de comércio eletrônico foram cancelados ou falharam.
  • Evite a votação: Processando notificações (por exemplo, um pedido foi atualizado), decida que ação tomar e direcione a resposta apropriada para um sistema de back-end em vez de pesquisar constantemente as alterações.
  • Sistemas legados: Eles precisam processar as notificações, mas apresentam problemas de confiabilidade.

Em nosso exemplo a seguir, teremos um aplicativo móvel que permite aos clientes criar, alterar e visualizar seus dados e pedidos de clientes.

Jornada do usuário 1: cancelamento de um pedido

Na camada de experiência, temos uma API móvel ouvindo notificações relevantes quando nosso cliente está interagindo com nosso aplicativo móvel por meio de Webhooks, publicar-assinar ou um mecanismo semelhante – como cancelar um pedido. Nesse cenário, a API móvel valida e transforma a mensagem usando DataWeave, antes de publicá-la na fila relevante – neste caso, a fila de pedidos. Essa fila pode ser implementada como Anypoint MQ, Kafka, ActiveMQ, RabbitMQ ou qualquer outro intermediário de mensagem.

Na camada de processo, um aplicativo Mule consome as mensagens da fila de pedidos. Este aplicativo Mule atua essencialmente como um manipulador de eventos e inspeciona o cabeçalho da mensagem e a carga útil para determinar o curso de ação relevante usando o escopo ‘roteador de escolha’.

O manipulador de eventos decidirá quais APIs de processo ou sistema invocar quando um pedido for cancelado, para que a mensagem do evento original seja transmitida aos sistemas back-end corretos. Neste exemplo, apenas o sistema back-end de pedidos precisa ser atualizado. Portanto, o aplicativo manipulador de eventos só invocará a API do sistema de pedidos, que expõe o terminal relevante para atualizar ou cancelar um pedido e passa a mensagem no formato necessário.

Jornada do usuário 2: atualização do perfil do cliente

Neste exemplo, onde nosso cliente atualiza dados pessoais em seu aplicativo móvel, estamos usando a mesma API de experiência. A API de experiência publicará a mensagem na fila – mas desta vez na fila de clientes. Assim como no exemplo anterior, nosso manipulador de eventos consumirá as mensagens da fila de nossos clientes e, com base no cabeçalho da mensagem e na carga útil, decidirá qual processo subjacente ou APIs de sistema invocar. Como agora estamos tentando atualizar os dados do cliente, o manipulador de eventos invoca a API de processo do cliente, que então chama as APIs do sistema subjacente para atualizar os dados no Salesforce e SAP.

Leia Também  Anypoint Platform Maio '20 versão

Jornada do usuário 3: obtendo detalhes do pedido

Em nosso último exemplo, nosso cliente chegou em casa e deseja obter detalhes sobre seus pedidos recentes. Semelhante aos outros exemplos, usamos uma API de experiência para lidar com a solicitação. Como nosso cliente está usando um aplicativo da web em vez do aplicativo móvel, agora usaremos a nova API de experiência do aplicativo da web.

Em vez de publicar a mensagem em uma fila, estamos seguindo a abordagem típica conduzida por API, em que a API de experiência chama as APIs de processo e as APIs de processo chamam as APIs do sistema. Nossa API de experiência de aplicativo da web pode não nos fornecer o ID do cliente específico do sistema de back-end de pedidos, que é necessário para obter todos os pedidos relacionados de um cliente. Por esse motivo, temos a API do processo de histórico de pedidos situada entre a camada de experiência e a camada do sistema. A API do processo de histórico de pedidos primeiro chamará a API do processo do cliente para descobrir o ID do cliente, ou seja: obter o ID do cliente fornecendo ao Salesforce e SAP o nome do cliente. Assim que a API de processo do cliente receber com sucesso o ID do cliente, ela então o passará para a API do histórico de pedidos para invocar a API do sistema de pedidos – fornecendo a ID do cliente necessária.

No caso de um dos sistemas backend não estar disponível ou incapaz de persistir nos dados, existem diferentes abordagens para lidar com o caminho infeliz. Por exemplo, colocar a mensagem de volta na fila para reprocessamento, mover a mensagem para a fila de devoluções, reconhecer a API de experiência sobre a mensagem de erro e como proceder ou simplesmente acionar qualquer outro processo manual ou automático.

Quais são os benefícios de combinar uma arquitetura orientada a eventos com conectividade orientada por API?

Com uma abordagem combinada, você pode reutilizar APIs de processo e sistema para casos de uso futuros sem ter que reescrever a lógica de transformação e a conectividade para sistemas de back-end. Além disso, você pode usar filas de mensagens para garantir perda zero de mensagens, aumentar a confiabilidade e a robustez de seus aplicativos de TI e adicionar outra ferramenta na caixa de ferramentas cobrindo as situações em que as APIs de solicitação-resposta síncronas podem não ser ideais.

Esta postagem usa conteúdo encontrado no curso Arquitetura da Plataforma Anypoint: Redes de Aplicativos. Se você quiser saber mais sobre como combinar com êxito a arquitetura orientada a eventos e a conectividade orientada por API, inscreva-se no curso.


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso