Os aplicativos baseados na Web vieram há muito tempo desde que costumávamos servir conteúdo HTML estático de servidores. Hoje em dia, os aplicativos são muito mais complexos e usam múltiplas estruturas, data centers e tecnologias. Nos últimos dois anos, vimos dois conceitos dominarem o mercado de TI:

 

movendo nossos aplicativos para a nuvem;

 

implantação de uma arquitetura de microsserviços;

 

Essas ideias moldaram a forma como projetamos e construímos softwares. De certa forma, não estamos mais construindo aplicações; em vez disso, estamos construindo plataformas. Os aplicativos não compartilham mais o mesmo espaço computacional. Em vez disso, eles têm que se comunicar uns com os outros através de protocolos de comunicação leves, como APIs REST ou chamadas RPC. Esse modelo possibilitou a criação de alguns softwares incríveis como Facebook, Netflix, Uber e tantos outros.

Neste artigo, discutiremos alguns dos problemas que impulsionam a inovação no desenvolvimento da web moderna. Em seguida, mergulharemos no básico da arquitetura orientada a eventos (EDA), que tenta resolver esses problemas pensando na arquitetura back-end de uma maneira nova.

 

Os problemas enfrentados pela teia moderna

 

Cada tecnologia tem que lidar com os desafios que os aplicativos sempre on, multi-usuário e assíncronsos enfrentam hoje:

 

Disponibilidade

 

Em vez de um aplicativo, agora temos muitas, dezenas talvez até centenas de serviços vinculados, e cada um deles tem que estar pronto para fazer seu trabalho 24 horas por dia, 7 dias por semana. Como podemos fazer isso? Na maioria das vezes, o serviço é dimensionado horizontalmente para várias instâncias, às vezes em vários data centers, tornando-o altamente disponível. Todas as solicitações que entrarem neste serviço específico serão encaminhadas uniformemente em todas as instâncias. Algumas ferramentas de implantação oferecem recursos de auto-recuperação, portanto, se uma instância cair, criará outra instância para tomar seu lugar.

 

Escalabilidade

 

A escalabilidade tem muito em comum com a disponibilidade. A disponibilidade é para garantir que haja pelo menos uma instância do serviço em funcionamento, pronta para atender às solicitações recebidas. A escalabilidade, por outro lado, é focada no desempenho. Se um aplicativo estiver sobrecarregado, então podemos criar novas instâncias desse aplicativo para acomodar o aumento do número de solicitações. Mas escalar aplicativos não é livre de desafios, especialmente se lidarmos com aplicações imponentes.

 

Única fonte de verdade

 

Antes dos microsserviços, este trabalho era simples. Todos os dados residiam em um único lugar, tipicamente algum tipo de banco de dados relacional. Mas quando vários serviços compartilham um banco de dados, você pode criar problemas como dependências entre equipes sobre mudanças de esquema ou problemas de desempenho. Um padrão comum para resolver esse problema é usar um banco de dados por serviço. Uma fonte distribuída de verdade realmente ajuda a manter a arquitetura limpa, mas agora temos que lidar com transações distribuídas e a complexidade de manter vários bancos de dados.

 

Síncrono

 

Em um cenário típico de solicitação-resposta, o cliente aguarda a resposta do servidor; bloqueia todas as suas atividades até receber uma resposta ou o tempo limite expirar. Se pegarmos esse comportamento e colocá-lo em uma arquitetura de microsserviços usando chamadas acorrentadas em todo o sistema, podemos facilmente acabar com o que eu chamo de “Inferno de Microserviços”. Tudo começa com uma chamada de serviço, vamos chamá-lo de serviço A. Mas então, o serviço A precisa chamar o serviço B, e a diversão continua. O problema com esse comportamento é que se um serviço tem recursos bloqueados (por exemplo: um segmento está pendurado), os tempos limite agora são exponenciais. Se permitirmos um tempo limite de 500 ms por serviço e houver cinco chamadas de serviço na cadeia, então o primeiro serviço precisaria ter um intervalo de 2500 ms (2,5 segundos), enquanto o último serviço precisaria ter um tempo limite de 500 ms.

 

 

Introdução da arquitetura orientada a eventos

 

A arquitetura orientada a eventos (EDA)é um paradigma de arquitetura de software que promove a produção, detecção, consumo e reação a eventos.

 

-Wikipédia

 

Nos aplicativos clássicos de três níveis, o núcleo do nosso sistema era a base de dados. No EDA, o foco é deslocado para os eventos e como eles estão fluindo através do sistema. Essa mudança nos permitiu mudar completamente a forma como projetamos aplicativos que abordam os problemas mencionados acima.

Antes de realmente ver como o EDA faz isso, vamos ver o que exatamente é um evento. Um evento é uma ação que desencadeia uma notificação ou algum tipo de mudança no estado do aplicativo. Uma luz foi acesa(notificação),o termostato desligou o sistema de aquecimento(notificação),um usuário alterou seu endereço(mudança de estado)ou um de seus amigos mudou seu número de telefone(mudança de estado). Todos esses são eventos, mas isso não significa que devemos adicioná-los a uma solução orientada a eventos. Para que um evento seja adicionado, ele deve ser relevante para o negócio. Um usuário que faz um novo pedido é um evento relevante para esse negócio específico, mas ele/ela comer pizza no almoço não é.

Quais eventos são relevantes para um negócio pode ser óbvio quando você pensa sobre eles, mas alguns deles pode