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

Grandes Contribuições com Projetos de Software Livre

Crossbar/txaio

django-rest-swagger

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.

Olist

Antes

Depois

Nosso escritório

Programadores podem trabalhar remotamente!

Acesse:

http://olist.com

http://olist.recruiterbox.com

Vamos construir um sistema?

Vamos!

(Conheça: http://plantuml.com)

Perfeito!

Agora escale para atender 1M reqs/s

"Pronto, escalei!"

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"

Problema:

A "lei" pode ser válida, mas não comercialmente

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

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.

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.

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!

Várias aplicações conectadas

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

Baixo acoplamento

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.

Responsabilidades "trocadas"

  • Em SOA: instruções / requisições;
  • Em EDA: apenas eventos.

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.

Orquestração

  • Sistema de gerenciamento de configuração;
  • Validações:
    • Subscrições em tópicos inexistentes;
    • Referências circulares de eventos.

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.

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

Fim

  • cleber.blog.br
  • olist.com
  • crossbar.io
Made with Slides.com