Desenvolva aplicativos confiáveis, escaláveis e autônomos com uma arquitetura orientada a eventos – IBM Developer

Desenvolva aplicativos confiáveis, escaláveis e autônomos com uma arquitetura orientada a eventos

Os aplicativos monolíticos tradicionais processam dados por meio de mensagens de API REST e SOAP. As arquiteturas modernas, como microsserviços, usam interfaces de API para vincular diversos serviços com base em contexto, requisitos funcionais e requisitos de negócios.

Anteriormente, os serviços usavam uma arquitetura orientada a serviços (SOA) do tipo SOAP XML-RPC. Os serviços tinham um acordo comum entre o serviço e o cliente para definir a estrutura de dados e os métodos de serviço. Essa arquitetura segue o modelo de desenvolvimento em cascata. Nele, você primeiro projeta e define os aplicativos e, em seguida, passa a implementá-los e testá-los. Essa arquitetura dificultava o trabalho dos desenvolvedores de aplicativos quando os requisitos mudavam, devido à forte integração entre o servidor e o cliente. Por essa razão, a arquitetura não se encaixou bem no novo mundo ágil.

Agora, os desenvolvedores usam uma arquitetura de REST com HTTP. Essa arquitetura mudou a maneira como o cliente e o serviço enviam e recebem os dados. O HTTP é um protocolo de transporte e um sistema de envio de mensagem, pois as cargas úteis de solicitações e respostas são mensagens. A arquitetura REST permite que os aplicativos de cliente e servidor usem as próprias tecnologias de arquitetura de objetos distribuídos (DOA), como Java, Node.js ou ASP.NET, o que as torna fracamente acopladas. A arquitetura REST transformou os serviços em serviços da web para a comunicação entre cliente e servidor, e em microsserviços para a comunicação de servidor para servidor. Por causa dessa arquitetura, muitas empresas criaram plataformas de gerenciamento de API, como o API Connect da IBM, que permitiram a integração de APIs sem interface com o usuário entre as arquiteturas de negócios empresariais.

Mas as APIs RESTful são a única solução para o desenvolvimento ágil moderno? Elas solucionam todos os problemas arquiteturais diante da rápida evolução tecnológica dos dias de hoje? Na verdade, não.

É fácil desenvolver microsserviços em diferentes plataformas. No entanto, quando você possui muitos aplicativos e cada aplicativo tem seu próprio conjunto de microsserviços, como APIs REST, fica difícil padronizar os fluxos de trabalho e gerenciá-los. Além disso, quando você faz o upgrade das suas plataformas para tecnologias emergentes melhores e mais modernas, é difícil migrar todos os aplicativos para dar suporte a novas tecnologias usando APIs REST. Há um enorme custo envolvido na implementação de uma nova solução de arquitetura para que um aplicativo mude completamente para uma plataforma de tecnologia mais nova.

Estes são alguns dos principais desafios com as APIs RESTful: como podemos padronizar o fluxo de trabalho de negócios e como podemos mudar as plataformas para tecnologias mais novas usando o desenvolvimento ágil sem interromper o fluxo de trabalho existente e com o mínimo de alterações? Neste artigo, explicarei como podemos lidar com esses problemas e reduzir o custo de suporte e manutenção de sistemas herdados, bem como o custo da migração para arquiteturas e sistemas melhores.

Padronização do fluxo de trabalho

Os padrões do setor continuam mudando, pois a tecnologia global continua evoluindo. Por isso, as soluções empresariais não precisam ser recriadas desde o princípio. Para acompanhar o ritmo de seus concorrentes, você provavelmente está integrando tecnologias de terceiros ou software open-source disponíveis em mercados de nuvem nas suas soluções.

À medida que adota as tecnologias mais modernas na sua arquitetura empresarial atual, os aplicativos herdados ficarão obsoletos. Essas atualizações podem envolver várias mudanças em sistemas integrados. A possibilidade de fazer essas mudanças com o mínimo de esforço e sem interromper o fluxo de trabalho atual depende de como o sistema inteiro é arquitetado. No caso de microsserviços com APIs REST, você terá muito trabalho redundante.

Uma solução arquitetural é adotar a arquitetura orientada a eventos. Os eventos fornecem maior confiabilidade e escalabilidade. Além disso, tornam os componentes autônomos. Inicialmente, os eventos são usados principalmente para notificações de transmissão. Mas que tal usar fluxos de eventos em vez de APIs REST no design do fluxo de trabalho?

Os aplicativos podem assinar os tópicos e manipular os eventos de forma eficiente, contanto que o fluxo de trabalho tenha a configuração de design a seguir:

  • Os tópicos corretos
  • Um modelo de evento padronizado
  • Manipuladores de eventos padronizados

Para adotar facilmente as novas tecnologias, é possível assinar os tópicos de interesse e desenvolver protótipos ou criar produtos mínimos viáveis (MVPs). Em seguida, os aplicativos podem trabalhar imediatamente em dados de produção, sem scripts de migração planejados ou sem envolver diversas equipes.

O exemplo a seguir mostra como podemos padronizar o fluxo de trabalho e experimentar novas tecnologias. A Figura 1 mostra a arquitetura das APIs RESTful, enquanto a Figura 2 mostra a arquitetura orientada a eventos.

A Figura 1 mostra três componentes: Componente A, Componente B, Componente C, sendo que o Componente C tem um fluxo de trabalho configurado por meio de APIs RESTful. Os três componentes usam APIs para compartilhar dados entre eles. Agora, queremos desenvolver um protótipo de uma nova tecnologia e criar um componente que substitua o Componente B, o qual chamaremos de B1. Como podemos fazer mudanças mínimas no fluxo de trabalho para adotar o Componente B1?

Figura 1

Arquitetura de API RESTful

O esforço envolvido na adoção de B1 envolve o entendimento das APIs do Componente B e a integração com os Componentes A e C. Essa arquitetura de APIs RESTful mostra o nível de acoplamento dos componentes e a flexibilidade limitada, já que todos os três componentes devem ser atualizados para suportar o novo componente B1.

A Figura 2 mostra o mesmo exemplo, mas usando uma arquitetura orientada a eventos. Se todos os componentes assinarem tópicos e enviarem mensagens com um modelo de dados padrão, será mais fácil adotar novas tecnologias sem afetar o fluxo de trabalho.

Figura 2

Arquitetura orientada a eventos

O Componente B1 recém-adotado não precisa entender o Componente A e o Componente C, desde que entenda os tópicos na fila de eventos e os tipos de eventos que estão sendo enviados. Essa arquitetura torna todos os componentes fracamente acoplados e permite que novos componentes sejam adotados sem afetar o fluxo de trabalho.

Os fluxos de eventos ajudam a desenvolver soluções flexíveis de arquitetura de fluxo de trabalho

Em geral, um fluxo de trabalho terá um conjunto de tarefas que precisam ser executadas em sequência. Os fluxos de trabalho podem se tornar complicados quando temos tarefas assíncronas. Para simplificar, diremos que as tarefas são alinhadas para que tenham um único resultado entregue a sistemas de renderização. Dividiremos o fluxo de trabalho, portanto, em um pipeline síncrono ou assíncrono que tenha tarefas. A maioria das tarefas síncronas é desenvolvida com filas de mensagens, enquanto as tarefas assíncronas são realizadas com fluxos de eventos.

Após a conclusão de cada tarefa, é possível implementar uma análise automatizada ou manual que acabará fornecendo o resultado para a próxima tarefa e a próxima análise. Em um mundo ágil, os requisitos continuam mudando. As tarefas precisam ser módulos autônomos e, se possível, precisam ser transformadas em um aplicativo autônomo que somente atenda ao requisito de negócios para a tarefa em questão. Essa arquitetura de fluxo de trabalho torna o sistema muito mais flexível para poder incluir, remover ou reordenar tarefas. Trata-se de uma arquitetura de microsserviços com barramento de serviços empresariais.

É possível obter essa arquitetura orientada a eventos usando um produto como o IBM Event Streams, o qual pode fornecer aplicativos autônomos que são independentes e fáceis de integrar uns com os outros. Com o IBM Event Streams, o aplicativo pode ser definido com base em modelos de dados e assinaturas de tópicos de interesse. O IBM Event Streams é uma plataforma de transmissão de eventos, desenvolvida no Apache Kafka open-source, que ajuda a criar aplicativos inteligentes que possam reagir a eventos à medida que acontecem. Ele proporciona confiabilidade e escalabilidade. Além disso, torna os aplicativos autônomos, como mostrado no exemplo abaixo.

Vamos considerar um exemplo de plataforma de publicação de conteúdo na nuvem, em que o conteúdo é publicado por meio de um fluxo de trabalho simplificado. Temos uma plataforma de integração que analisará e publicará o conteúdo. Também temos uma plataforma de globalização que terá análises para o conteúdo traduzido e publicado em um país. Consulte a Figura 3 para ver esse fluxo de trabalho.

Figura 3

Fluxo de trabalho da plataforma de publicação de conteúdo na nuvem

Esse fluxo de trabalho pode ser implementado com APIs ou microsserviços. A Figura 4 contém um diagrama de arquitetura que descreve as interações entre as plataformas por meio de APIs.

Figura 4

Arquitetura que mostra as interações entre as plataformas por meio de APIs

Se a plataforma de integração for um aplicativo próprio desenvolvido com estruturas de front-end e plataformas no lado do servidor, e se quisermos migrar tudo para ferramentas do fornecedor de CMS, talvez seja necessário que a plataforma de integração, a plataforma de globalização e o catálogo forneçam muitas informações a respeito das APIs de microsserviço. As três plataformas exigirão a criação de novas APIs para dar suporte a um novo fluxo de trabalho, replicando o fluxo de trabalho existente com um novo CMS. Essa arquitetura exigiria a coordenação de diversas equipes para entender as APIs necessárias envolvidas no fluxo de trabalho.

Agora vamos considerar o mesmo fluxo de trabalho, mas usando uma arquitetura orientada a eventos e um produto como o IBM Event Streams.

Figura 5

Fluxo de trabalho padronizado com tópicos e eventos

Se padronizarmos o fluxo de trabalho com tópicos e eventos bem definidos do IBM Event Streams, como mostrado na Figura 5, o fluxo de trabalho se tornará padrão e as novas plataformas, como o novo CMS, poderão facilmente assinar filas de eventos para começar a participar do fluxo de trabalho sem interrupções. Essa arquitetura também requer alterações mínimas nos componentes integrantes. A arquitetura de fila de eventos facilita bastante a migração para a inclusão de novas plataformas.

As vantagens da arquitetura orientada a eventos em relação às APIs RESTful e aos microsserviços

Ao implementar uma arquitetura orientada a eventos em vez de APIs RESTful, é possível obter estas vantagens:

  • Confiabilidade
  • Escalabilidade
  • Autonomia

Confiabilidade

Plataformas de transmissão de eventos, como o IBM Event Streams, fornecem filas de dados persistentes para o envio de mensagens. Isso tornará os componentes tolerantes a falhas em caso de indisponibilidade. O IBM Event Streams fornece persistência de dados por cerca de sete dias, ao contrário de outras soluções de transmissão de eventos.

As arquiteturas orientadas a eventos são mais confiáveis porque é possível transmitir mensagens para vários componentes. A Figura 6 mostra uma arquitetura de API à esquerda comparada com uma arquitetura orientada a eventos à direta:

  • No caso das APIs, se um componente perder um evento, o Componente 1 deverá fazer várias novas tentativas e evitar o envio do mesmo evento várias vezes a todos os outros. Essa arquitetura o torna fortemente acoplado.
  • Usando uma plataforma de transmissão de eventos como o IBM Event Streams, podemos garantir que os componentes recebam os eventos com menos sobrecarga. Assim, os fluxos de eventos são mais confiáveis.
Figura 6

Confiabilidade: arquitetura de API à esquerda; arquitetura orientada a eventos à direita

Escalabilidade

É possível escalar qualquer número de instâncias do aplicativo assinando um único tópico. O IBM Event Streams permite que os aplicativos agrupem um conjunto de instâncias para consumir o evento uma vez ou criem vários grupos para que diversos componentes do aplicativo consumam o mesmo evento.

As arquiteturas orientadas a eventos são escaláveis de modo que é possível implementar novas plataformas de tecnologia sem interromper o fluxo de trabalho. A Figura 7 mostra uma arquitetura de API à esquerda comparada com uma arquitetura orientada a eventos à direita:

  • No caso de APIs, existem muitas dependências entre os componentes.
  • No caso de filas de eventos, um produto como o IBM Event Streams fornecerá escalabilidade ao permitir que a nova plataforma de tecnologia registre o serviço e comece a consumir mensagens sem interromper nenhum processo do fluxo de trabalho.
Figura 7

Confiabilidade: arquitetura de API à esquerda; arquitetura orientada a eventos à direita

Autonomia

As filas de eventos removem as dependências entre os componentes e simplificam significativamente a integração de aplicativos desacoplados.

As arquiteturas orientadas a eventos são autônomas porque é possível descontinuar as APIs que vários componentes usam. A Figura 8 mostra uma arquitetura de API à esquerda comparada com uma arquitetura orientada a eventos à direita:

  • No caso de APIs, é difícil descontinuá-las porque é necessário identificar todos os componentes que estão usando a API e, em seguida, notificá-los para descontinuar a API.
  • No caso de filas de eventos, não é necessário identificar os componentes. O Componente C pode parar o envio de mensagens e cancelar a assinatura do tópico a partir do qual ele envia mensagens.
Figura 8

Autonomia: arquitetura de API à esquerda; arquitetura orientada a eventos à direita

Conclusão

Uma arquitetura orientada a eventos é uma arquitetura muito eficiente que ajuda a padronizar os fluxos de trabalho. Uma arquitetura orientada a eventos tem maior flexibilidade e permite facilmente adotar e criar protótipos de novas plataformas de tecnologia sem grandes mudanças na arquitetura geral ou em componentes individuais dos seus aplicativos. Essa flexibilidade, por sua vez, reduzirá o custo e o tempo envolvidos na migração para novas plataformas de tecnologia.

Quais são os próximos passos? Saiba mais sobre as vantagens de uma arquitetura orientada a eventos e as considerações arquiteturais para sistemas baseados em microsserviços orientados a eventos.