Event Driven Architectures

https://medium.com/@cleber.z

Event Driven Architectures:

O que são, onde vivem e como se reproduzem

2016 - Cléber Zavadniak

Cléber Zavadniak

• Trabalhando com programação desde 2004;
  • C (microcontoladores) e C++ (simulação de hardware);
  • PHP (sites e sistemas);
  • Linux (sysadmin);
  • Linux (migração de aplicações HP-UX);
  • Python (comunicação com hardware, sistemas web);
• Ciência da Computação na UFPR (não concluído);
• Atualmente trabalhando na Olist.

https://medium.com/@cleber.z

Grandes Contribuições com Projetos de Software Livre

Crossbar/txaio

django-rest-swagger

Vamos construir um sistema?

Perfeito!

Agora escale para atender 1M reqs/s

Problemas

• Subsistemas desnecessários escalados!
  • Sign in, moderação e vários outros;
    • Consomem recursos;
    • Estão presentes (exposição a bugs).
• Acesso ao banco de dados extremamente concorrente;
• Integradores com marketplaces fora de controle.

Por que

nossa primeira solução dificilmente é escalável?

História

Mainframes e tempo compartilhado

• Antigamente, apenas um programa era executado;
  • Antigamente = muito antes dos "PCs";
  • Organizações pagavam por tempo;
  • Muito tempo gasto em operações de I/O;
    • (Memória secundária sempre foi um gargalo...)
• Solução: time shared operating systems;
  • Exemplo: Multics;
• Time shared = concorrência!

Qual programa está sendo executado nesse momento?

"Unix"

Qual programa está sendo executado nesse momento?

Vários processos, mesmo com uma CPU de apenas 1 núcleo.

Concorrência

• Como no mundo das empresas ou dos esportes;
• Vários "players" concorrendo por recursos limitados;
• Não implica em paralelismo.

Lei de Moore

• Concorrência é okay quando os recursos estão sempre aumentando.
• Gordon Earle Moore:
  • Co-fundador da Intel e da Fairchild Semiconductor;
• A "lei" que fala sobre "18 meses" é do David House, e é sobre o desempenho dos chips/CPUs;
• Resultado: programadores preguiçosos:
  • "Ano que vem meu programa será rápido";
  • Desleixo em relação ao uso do hardware;
  • Ignorância e desinteresse sobre paradigmas alternativos de programação.

"O número de transistores em um circuito integrado denso dobra aproximadamente a cada dois anos"

Solução:

Paralelismo

Concorrência

• Intel 486 rodando Linux;
• N threads em 1 CPU;

Paralelismo

• 2 Intel 486 rodando DOS 2.0;
• N > 1 processos em M > 1 cores;

Paralelismo no design

Fato 2:

Orientação a Objetos é péssima para lidar com paralelismo.

• Memória compartilhada (objetos);
• Efeitos colaterais;
• Locks constantes;

(E o mesmo se aplica para outros paradigmas mais comuns.)

Fato 1:

Orientação a Objetos é um paradigma muito intuitivo.

Orientação a objetos

• Pega de surpresa pela necessidade de paralelismo;
• Por isso parece não-natural a junção dos conceitos!
• A concorrência por recursos da máquina transformou-se em concorrência por objetos em memória.

• Thread 1: João entra no carro, que contém 0 pessoas;
• Thread 2: José entra no carro, que contém 0 pessoas;
• João e José estão no carro, que contém 1 pessoa.

Exemplo

Objeto: Carro

Atores: João e José

• João quer entrar no carro;
• Alguém está agarrado na porta? Não.
• João agarra a porta com olhar mortal.
• João entra no carro.
• João solta a porta.
• Agora José pode tentar entrar no carro.

Técnicas alternativas de programação

• Futures;
• Actor model;
• Parallel functional;
• Continuations;
• E outras...

Problemas

• Complexidade:
  • Vários fluxos de informação em um "programa" só;
  • Seres humanos tendem a entender melhor o estilo "receita de bolo";
  • Conseguir gente que entenda desses paradigmas.
• Concorrência:
  • Objetos compartilhados e efeitos colaterais: locks!

Ciclo de vida de um software

• Concepção
• Projeto
• Implementação
• Testes
• Homologação
• Entrega

Problemas de softwares muito grandes

• Ciclos muito longos;
• Alterações constantes;
• Regressões em potencial;
• Homologação constantemente se desfazendo.

Alternativas

Event Driven Architectures

Unindo o intuitivo ao intuitivo

Componentes

• Aplicações;
• Eventos;
• Nuvem de Eventos / Roteador.

Evento

Mudança significativa de estado

Eventos ajudam na "Reatividade":

• Usuário clicou em determinado botão;
• Determinado objeto foi criado;
• Sensor 001 mudou de 0 para 1;
• Pressão do ar no pneu ficou abaixo do ideal;
• Deu a hora de acordar;
• O chefe apareceu de repente atrás de você!

Eventos, não serviços

• Representados por mensagens (reificação);
• Fire and forget;
• Mensagens representam eventos, não instruções.

Orientação a eventos

• Boa vizinhança: broadcast any action;
• Ignora-se os recipientes das mensagens;
• Publicação imediata:
  • No mesmo instante em que os eventos ocorrem;
  • Não se espera o recipiente processar a mensagem anterior;

Tópicos

• Mensagens são classificadas em tópicos;
• Aplicações assinam (subscrevem) tópicos;
• Exemplos:
  • "product.created"
  • "user.updated"
  • "order.received"
• Toda mensagem (/evento) tem um tópico.

user.created

{

 "id": 1,

 "name": "Cléber Zavadniak",

 "email": "example@example.com",

 "birth_date": "1986-03-28",

 "city": "Curitiba",

 "state": "PR"

}

Nuvem de Eventos

• Gerencia conexões e subscrições;
• Roteia as mensagens.

Roteamento

Várias aplicações conectadas

• Baixíssimo acoplamento;
  • Sem "mais um nível de indireção".
• Regras de interação muito simples.

Repare nos IPCs

• IPC = inter process communication system;
• Não importa a quantidade de aplicações:
  • Apenas 2 por aplicação, em geral:
    • Banco de dados;
    • Roteador.
• O próprio banco de dados pode tornar-se uma aplicação.

Cópia de dados

• Aplicações não requisitam dados umas às outras;
• Mantém-se uma cópia local dos dados que precisam;
  • E ouvem na Nuvem as atualizações.

• ID
• Name
• E-mail
• Password hash
• Birth date
• Address

Users

• ID
• Name
• Address

Fulfillment

Ciclos de vida curtos

• Aplicações são menores;
• Homologações duram mais;
• Re-implementações afetam áreas menores do sistema;
• Versões antigas e novas da mesma aplicação podem conviver juntas
  • Contanto que o contrato não mude.

Exemplo: Histórico

• Users não grava histórico de alterações;
  • Mas precisa gravar!
• Eu poderia mexer no código de Users (argh!)
  • Quebrar a homologação;
  • Expor o sistema ao risco de mal funcionamento.
• Ou poderia criar outra aplicação, à parte
  • Que assine os tópicos nos quais Users publica;
  • E mantenha seu próprio histórico, separadamente.

Escopos de responsabilidade menores

• Cada aplicação tem um escopo bem delimitado.
• Múltiplos times de programadores;
• Múltiplas linguagens de programação;
• Múltiplos paradigmas.

Desvantagens da arquitetura

• Pouca validação em tempo de build;
• Orquestração pode ser complexa;
• Depuração pode ser "tricky":
  • Pequenos typos nos nomes dos tópicos;
  • Serviços com dificuldade de ouvir ou gerar eventos;
  • Configurações conflitantes;
    • E espalhadas por diversas máquinas.

Na vida real

Crossbar

(crossbar.io)

Só eventos ou só serviços?

• Sempre acabamos precisando de alguma requisição a serviço;
  • Por exemplo: ações síncronas em software;
  • Ativação de dispositivos físicos;
  • Crossbar provê:
    • Roteamento de RPCs por nome;
    • E round-robin dispatching de RPCs.

RPC roteado

• Só preciso saber do nome do RPC;
• A requisição é enviada ao Roteador (dealer);
• Não me interessa quem vai responder.

Multi-linguagem, multi-arquitetura

Crossbar: Arquitetura completa

• Conexão sobre SSL (ou não);
• Provê REST bridging;
• Autenticação
  • Sem tráfego de credenciais on the wire;
• Autorização
  • Estática (configuração) ou dinâmica;
• Orquestração
  • Workers nativos (ou não)
• Servidor HTML estático
  • Porque você só precisa do autobahn.js
  • Ótima combinação: React.js e autobahn.js

Crossbar/WAMP: Problemas

• Perda de mensagens
  • Estamos trabalhando nisso...
• Overflow de mensagens;
• Python 2 (Usa muito twisted);
• Falta de solução provisionada.

Fim

• https://medium.com/@cleber.z
• https://olist.com
• http://crossbar.io