Event Driven Architectures
EDA:
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.
http://cleber.blog.br
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2629479/badge-linux.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2629507/badge-gentoo.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2629509/badge-python.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2629514/badge-vim.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2629515/zsh.png)
Grandes Contribuições com Projetos de Software Livre
Crossbar/txaio
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2629151/contrib-crossbar-txaio.png)
django-rest-swagger
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2629153/contrib-django-rest-swagger.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2624548/logo-olist-v-branco-slogan.png)
Olist
A Missão do Olist é acabar com qualquer barreira de distribuição enfrentada por micro, pequenos e médios negócios no Brasil e no Mundo.
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2631076/casas-bahia.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2618526/diagrama-integradores.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2618528/diagrama-olist.png)
Olist
Antes
Depois
Nosso escritório
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2629316/motox-factory.jpg)
Programadores podem trabalhar remotamente!
Acesse:
http://olist.com
http://olist.recruiterbox.com
Vamos construir um sistema?
Vamos!
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2624593/sistema-monolitico.png)
(Conheça: http://plantuml.com)
Perfeito!
Agora escale para atender 1M reqs/s
"Pronto, escalei!"
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2625204/sistema-monolitico-ampliado.png)
Problemas
- Subsistemas desnecessários escalados!
-
Sign in, moderação e vários outros;
- Consomem recursos;
- Estão presentes (exposição a bugs).
-
Sign in, moderação e vários outros;
- 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"
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2620717/ps-aux.png)
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"
Problema:
A "lei" pode ser válida, mas não comercialmente
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2625222/intel-and-moores-law.png)
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;
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2630771/intel-cores.jpg)
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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2625204/sistema-monolitico-ampliado.png)
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
Micro-serviços
- Cada aplicação pode ser uma boa e velha "receita de bolo";
- Os ciclos de vida podem ser muito menores;
- Complexidade sai do design e passa para a arquitetura.
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2625247/router.png)
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;
- Eventos costumam apresentar uma espécie de hierarquia.
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.
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2621542/cloud.png)
Roteamento
Application | Subscriptions | Generates |
---|---|---|
Sign In | sigin.received | |
Users | sigin.* | user.created user.updated user.removed |
Confirmation | user.created user.removed |
confirmation.email.sent |
Products |
product.created product.updated product.removed |
|
Moderation | product.* | moderation.approved moderation.reproved |
Action!
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2625499/events.png)
Várias aplicações conectadas
- Baixíssimo acoplamento;
- Sem "mais um nível de indireção".
- Regras de interação muito simples.
Baixo acoplamento
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2625367/eda.png)
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.
- Apenas 2 por aplicação, em geral:
- O próprio banco de dados pode tornar-se uma aplicação.
Responsabilidades "trocadas"
- Em SOA: instruções / requisições;
- Em EDA: apenas eventos.
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2630864/soa.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2630867/nao-soa.png)
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
- 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.
Orquestração
- Sistema de gerenciamento de configuração;
- Validações:
- Subscrições em tópicos inexistentes;
- Referências circulares de eventos.
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2630942/circular-reference.png)
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)
Multi-language Applications
EDA ou SOA?
-
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.
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2631004/wamp.jpg)
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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/511676/images/2621495/crossbar-components.png)
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
Fim
- cleber.blog.br
- olist.com
- crossbar.io
Event Driven Architectures
By Cléber Zavadniak
Event Driven Architectures
Event Driven Architectures: apresentação para a V JAI (Jornada da Atualização da Informática) da Unicuritiba, em 18 de maio de 2016.
- 455