Arquiteturas síncronas em sistemas distribuídos modernos, introdução.
Olá amigos! Pretendo trazer aqui alguns artigos para falar sobre modelos de arquitetura. Vou me concentrar em falar mais no aspecto 'macro' das opções, sendo elas as arquiteturas síncronas e as arquiteturas assíncronas. Pretendo discursar sobre alguns padrões entre um artigo e outro para não soar repetitivo e tentar trazer um conteúdo bacana. Neste primeiro capítulo eu pretendo falar um pouco sobre o modelo de arquitetura síncrona e abrir um pouco a 'caixa de pandora'. Vamos lá?
Introdução
É comum vivermos hoje em um mundo extremamente digitalizado, onde tempo, literalmente, é dinheiro. A tecnologia da informação tem evoluído cada vez mais para nos proporcionar "velocidade", e, pense só, há mais ou menos 20 anos atrás, usávamos internet discada, e pasmem, com velocidades de 9, 14, 28, e 56 kbps! Comparando com o que temos hoje, nem as redes mais primitivas de celular trafegam nesta velocidade (redes GPRS, a famosa banda 2,5G, tem uma taxa de transmissão de 160 kbps), portanto, podemos perceber que, conforme as telecomunicações evoluíram, mais nos importamos com a velocidade da entrega de conteúdo que nos é fornecido.
"Blá, blá, blá…papo cringe", é o que alguns mais jovens diriam, "Isso não é mais uma preocupação nos dias de hoje…o que importa é a experiência do usuário!", imaginem que, boa parte de uma experiência de usuário não é só a clareza e objetividade que uma interface fornece na condução de uma jornada, mas também a sua velocidade, a diferença é que velocidade é um quesito inerente a tudo o que fazemos hoje, e, portanto, já não é levado tanto em consideração como requisito.
Falei, falei e falei e ainda não comecei o papo sobre arquiteturas síncronas, por quê? Acho que é importante definir o contexto antes de falarmos de comunicação inter-processos, pois velocidade vai ser o maior fator decisivo ao optar por um modelo ou outro. (Isso não significa que complexidade, manutenabilidade e outros fatores não sejam importantes, mas, no final do dia, velocidade é muito importante para o negócio e para a jornada do cliente).
Uma definição…
Arquitetura síncrona é um conjunto de técnicas e requisitos que unimos para atender a um objetivo específico de inter-comunicação de aplicações dado um intervalo de tempo(segundo a minha visão, existem definições melhores e mais acadêmicas, mas aqui é para ter um conteúdo mais simplificado). Na arquitetura síncrona, os processos se conversam com interfaces desenhadas especificamente para cada um dos relacionamentos, como mostrado na figura abaixo:
O processo "A" se comunica com o processo "B" através de uma interface definida utilizando um método de requisição apropriado, isto é, o processo "A" executa uma (ou mais) regra(s) de negócio e, para dar sequência ao processo, gera informações que serão requisitadas pelo processo "B" para dar continuidade na jornada, para isso, o processo "A" serializa uma "mensagem" (muitas vezes chamada de payload) em um padrão pré-especificado (XML, REST, gRPC, etc) e abre um canal de comunicação com o processo "B" para transmitir essa "mensagem" serializada.
"Tá, tudo bem, até ai nada de diferente em nenhum modelo de arquitetura de sistemas distribuídos, isso não é síncrono!". Sim, ainda não entrei na especificidade do tema, mas isso é o básico do básico do conceito. A questão chave de tudo o que exemplifiquei acima vem com a adição de um componente muito importante: a dimensão tempo.
Request/Response não tem nada de novo no dia-a-dia, e pode ser utilizado em arquiteturas assíncronas também, então, onde está o "pulo do gato" aqui? Bom, a principal diferença é que em uma arquitetura síncrona, a disponibilidade (tempo de funcionamento de um processo) é um critério extremamente importante, pois a partir do momento que 'eu' requisito a continuidade da jornada, os processos que estão encadeados, devem, primariamente, estar disponíveis, caso contrário não será possível seguir com a jornada daquele cliente, ou seja, se, por qualquer motivo, um dos processos na cadeia esteja indisponível, significa que aquela jornada não poderá ser completada em sua totalidade, podendo gerar potenciais perdas para o negócio.
Quando o processo "A" requisitar ao processo "B" a continuidade da jornada, o processo "B" deverá indicar que irá continuar com essa jornada ou indicar erro para o processo requisitante para que esse possa fornecer rapidamente um feedback para o usuário ou cliente daquela jornada que há algo de errado com os dados fornecidos ou com o processo em si. Essa velocidade de feedback entre a comunicação entre um processo e outro dentro de uma jornada é o que define (de forma bem primitiva) uma arquitetura síncrona.
No fim, o encadeamento de processos tem um prazo para ser executado, o prazo pode ser de milissegundos, segundos, minutos…depende muito dos processos de negócio que estão sendo executados. Normalmente operações de escrita consomem mais tempo do que operações de leitura, portanto, se você tem um processo de negócio que registra muito mais do que consulta, você (provavelmente) têm uma jornada mais lenta. Isso não significa que a regra se aplica a tudo, há especificidades a serem tratadas que fogem um pouco do escopo do que estou tentando trazer aqui.
Cada “prazo” citado aqui (entenda-se pelo famoso SLA) é criado para aquele processo, dado que há um objetivo a ser atendido (SLO) pelo processo, necessitamos gerar métricas ([SLI] médias, quartis, dispersão de amostras) que irão alimentar (ou realimentar) um controlador deste processo.
Para exemplificarmos de maneira mais clara, gosto de pensar de acordo com o processo ilustrado abaixo:
Na jornada acima, podemos perceber que há um processo orquestrando os demais processos ativos, este orquestrador delega ordens aos demais processos para conduzir a jornada, e isso pode ser feito de maneira sequencial (o orquestrador espera tudo ser executado para devolver uma 'resposta final' para o cliente) ou de maneira concorrente (onde o orquestrador delega as atividades para os demais processos de uma única vez).
Resumo da ópera
Dependendo das escolhas que tomamos acima, podemos criar controles para evitarmos a interrupção da jornada utilizando técnicas de retry, circuit-breaker ou desenhando relações interprocessos com baixo 'acoplamento'. Percebam que aqui eu não vou entrar no mérito destas técnicas, ficará para o próximo capítulo. Mas a ideia central sobre o tema é tentar pousar o conceito de uma forma mais didática, e, entendendo tudo o que foi dito acima (ou ao menos grande parte), fica mais fácil para entrarmos em discussões mais técnicas e com mais detalhes.
Nesta figura acima, é importante ressaltar que eu não mencionei as relações entre os processos, mas, seguindo a lógica natural de construção de jornadas síncronas, quaisquer elementos que sejam indisponibilizados, a jornada será interrompida, e, consequentemente, todos os processos serão descontinuados, notificando rapidamente o ponto de contato (i.e: o cliente, neste caso).
Fica fácil de entendermos quando especificamos as interfaces para modelos bem definidos, como o REST, por exemplo. Uma requisição inter-processos (ou entre microsserviços) obtém uma resposta imediata através de uma ação ditada por um verbo (um GET, por exemplo). Nesta situação, o orquestrador delega ações para cada uma das cadeias de processos, POSTs, GETs, PATCHs e etc…Caso haja falha, o serviço requisitante obtém uma resposta quase que imediata, seja 4xx ou 5xx e é essa velocidade de feedback que indica (primariamente) que um processo é síncrono.
Mais para frente, quando falarmos de assincronismo, iremos perceber que a mensagem serializada fica disponível por um período (pré-definido) em um barramento externo a aplicação para que, quando a aplicação volte a ficar disponível, ela consuma a mensagem deste barramento, sequenciando a jornada.
Encerramento
Como diria o He-man: Por hoje é só, amigos! Nos próximos artigos, iremos entrar em maiores detalhes da arquitetura síncrona, tentando explorar mais coisas com maior profundidade, cobrir o tema de sincronismo dá um trabalhão, rs.
Feedbacks sobre o artigo são muito bem vindos!
LinkedIn: https://www.linkedin.com/in/renato-rosa-guimar%C3%A3es-6158a25a/
Muito obrigado!
