Sistemas reativos têm me fascinado e preciso compartilhar desse encanto com o mundo. Sistemas reativos estão no top (única circunstância em que me permito usar a palavra top) do mercado, geralmente encontrados na boa companhia de termos como: microservices, event-oriented-systems, event-driven, pushed-based-application e incontáveis outros similares. Muito embora não sejam a mesma coisa, bombam na indústria de desenvolvimento.
Agora que eu falei de relatividade, é um excelente nome para virar buzz word na computação, não acham? Sistemas relativos. Uau! Tem tudo pra ser top.
Manifesto Reativo
Uma galera à toa, percebendo pontos comuns no desenvolvimento reativo, resolveu criar o manifesto reativo. No manifesto, lemos algo parecido com: a reatividade é sobre a passagem de mensagens assíncronas. Permitindo o desacoplamento temporal — agora acho que tem a ver com a teoria da relatividade geral de Einsten, hein? — entre sistemas promovendo a responsividade em falhas e sob extremas demandas.
Não é que a perspectiva reativa é um modo mais prático de desenvolvimento. É que as soluções proativas não encaixam no panorama atual.
A verdade é que os requisitos mudaram. É necessário ser responsivo. As exigências se tornaram mais rigorosas, as requisições se multiplicaram, assim como fizeram os trocentos milhões de dados que transitam nelas. Natural que a arquitetura sistemas mude. As práticas que adotávamos há alguns anos já não são suficientes para dar ao usuário uma boa experiência.
Sistemas Reativos proporcionam flexibilidade, desacoplamento e escalabilidade, como consequência, tornam-se mais fáceis de desenvolver e manter.
A reatividade é um conjunto de princípios e práticas para a criação de sistemas coesos. No coração da reatividade está a composição de grandes sistemas por meio de pequenos serviços e das propriedades reativas de cada um deles de forma que essas propriedades se apliquem em todos os níveis de abstração e escalas, tornando-os combináveis.
Propriedades Reativas
O manifesto reativo identifica quatro propriedades. Discorro sobre elas logo abaixo:
Responsividade
Os sistemas encontrados hoje devem poder ser executados por todo tipo de máquinas, potentes ou não, numerosas ou não, geograficamente próximas ou não.
Ao mesmo tempo, as expectativas dos usuários se tornam mais difíceis de serem satisfeitas por que o ser humano é bicho ruim e está sempre pleiteando mais. Para ser capaz de entregar sistemas que usuários e corporações possam depender e confiar, os sistemas devem ser responsivos, dado que não há relevância na resposta se ela não estiver disponível quando for solicitada.
Fundamentalmente, não há diferença em não receber resposta e receber a resposta em um tempo não aceitável. Para alcançar isso, nós devemos garantir que a responsividade deve ser atingida mesmo sob falhas e sob demandas dinâmicas e extremas de requisições.
Resiliência
De acordo com algum site qualquer:
Resiliência é a capacidade de voltar ao seu estado natural, principalmente após alguma situação crítica e fora do comum.
Quando o assunto é a reatividade, a resiliência é além da responsividade sob falhas. Não é sobre uma degradação harmoniosa, é sobre ser capaz de se recuperar graciosamente a partir da falha: a auto-cura, tipo o Wolverine.
Isso requer isolação e retenção da falha para evitar contaminação dos vizinhos, o que pode acarretar em catastróficas falhas em cascata.
A chave para alcançar sistemas auto-curáveis é permitir que as falhas sejam: contidas, traduzidas como mensagens, enviadas para componentes supervisores e gerenciadas por um contexto seguro externo.
Ser message-driven é crucial, se distanciando de componentes fortemente acoplados com cadeias de chamadas profundamente aninhadas. A ideia é desacoplar o gerenciamento das falhas da cadeia de chamada, liberando o cliente da responsabilidade de tratar as falhas do servidor.
Elasticidade
Elasticidade é a responsividade sob demandas extremas. O sistema deve ser capaz de ser escalável, seja adicionando/removendo núcleos em uma única máquina ou adicionando/removendo máquinas. O intuito é atender demandas variáveis proporcionalmente alocando ou desalocando recursos.
Quando se trata de computação em nuvem é fundamental alocar somente o necessário. Isso permite a eficiência de recursos, economizando quando os custos são pagos por uso.
Sistemas precisam ser adaptativos, ou seja, sem intervenção humana e sem reconfiguração manual: devem permitir: auto-escala, replicação de estado e comportamento, balanceamento de carga e atualizações.
Orientados às mensagens assíncronas
Para alcançar o santo graal da arquitetura reativa, não há outra alternativa, é necessário fazer uso de mensagens assíncronas. Assim, estabelecem-se fronteiras bem definidas entre os componentes, garantindo baixo acoplamento, isolamento, e transparência na localização.
Mensagens assíncronas fornecem meios para delegar o tratamento de erros através das próprias mensagens.
Devem ser orientados às mensagens para, explicitamente, modelar as filas do sistema e gerenciar a cadência das mensagens quando necessário. Além disso, permite gerenciamento de demanda, escalabilidade e controle de fluxo, promovendo a elasticidade.
A comunicação deve ser assíncrona para fornecer ao cliente a opção de fazer outro trabalho ao invés de ficar bloqueado esperando pela disponibilidade do recurso.
Isso pode ser atingido por meio de uma notificação quando o recurso estiver disponível ou a operação for finalizada. Além de outros motivos, permite também que destinatários consumam os recursos somente quando ativos, evitando desgaste do sistema.
Para sintetizar, deve permitir que você escute uma boa música e lave a louça enquanto aguarda a resposta do crush no whatsapp sem precisar ficar plantado com a orelha no celular.
Apesar de nada recente, os sistemas reativos podem ser rastreados desde as décadas de 70 e 80, pré-história computacional, apenas há 5-10 anos a indústria da tecnologia tem repensado sobre as “melhores práticas” para desenvolvimento de sistemas corporativos.
Isso significa aplicar o conhecimento dos princípios reativos no mundo de hoje: atolado de internet das coisas, um nevoeiro danado na computação e processadores multi magaivers.
Os dados precisam estar disponíveis em todas circunstâncias, servindo aos usuários e às máquinas, em tudo que é fuso-horário, continuamente e em tempo quase real.
As arquiteturas, técnicas e ferramentas tradicionais (neste post, apresento uma ferramenta alternativa: enqueuer), se provaram não responsivas, não escaláveis e não disponíveis. Muitas companhias estão se movimentando em direção dos princípios reativos como resposta, visando fornecer uma enorme quantidade de dados rapidamente de uma forma preditiva, elástica e resiliente.
Pessoalmente, percebo uma clara representação da reatividade na maneira que os sistemas trocam mensagens. Há uma inversão na perspectiva convencional de permutação de informação. Costumo traçar um paralelo entre a reatividade como padrão de projeto Observer e o princípio Tell-Don’t-Ask, mas aplicada em nível de abstração mais alta do que a orientação a objetos.
A ideia é aplicar a reatividade em boa parte das trocas de mensagens em todos os níveis de abstração.
Não existe bala de prata
Para finalizar, o desenvolvimento de sistemas reativos não é a melhor solução para sistemas distribuídos, tampouco a pior. É uma abordagem diferente e que não é possível ser aplicada em todos os sistemas, pois depende de operações que fogem o seu controle.
Certa vez, meu colega Martin Fowler (Tintin, como ele gosta de ser chamado), disse algo interessante ao falar sobre distribuição:
Primeira regra dos objetos distribuídos: não distribua.
Acredito que possamos dizer justamente o contrário no contexto da reatividade. Então, como diria eu mesmo, perante mim mesmo e com o poder investido em mim, afirmo:
Reative sempre que der.
Comunicação de Sistemas
O ideal é tentar minimizar a comunicação entre os sistemas internos da arquitetura reativa. Quanto menor for a quantidade de mensagens transitando entre eles, melhor, porque a autonomia e o isolamento entre os serviços são promovidos.
Inevitavelmente, será necessário integrá-los de alguma forma, portanto, é fundamental estudar como ocorre essa comunicação: