Arquitetura de Mensagens Assíncronas - MeliDevConf 2013 - SP

MercadoLivre Developers Conference

Arquitetura de mensagens assíncrona.

Gerente de Desenvolvimento

MercadoLivre Developers Conference Arquitetura de mensagens assíncrona.

AGENDA➔ Diferença entre sites e plataformas

➔ Organização de recursos

➔ Arquitetura de mensagens

➔ Consistência eventual

➔ Lições aprendidas

➔ Perguntas


Lembramos a diferença de um site e uma plataforma


WebSite

Frontend

Platform API

Mobile Device

DB

Third-party


Os recursos da nossa API estão agrupados lógicamente em departamentos

Cada departamento é independente dos outros, isto significa:● Escolha livre de tecnologia● Deploys independentes● Minimizar dependência


Externamente a API é como uma coisa só, mas está toda dividida em departamentos.


Items

/items/items/MLBX/descriptions/items/MLBX/relist

Categories

/categories/MLXXX

Questions

/questions/

MercadoLivre API RestFul

Ok, mas como fazemos quando dois ou mais departamentos dividem dados.



Um departamento tem uma cópia original e propaga as mudanças aos outros, por exemplo, o recurso de items realiza operações básicas (CRUD) e propaga os eventos ao motor de busca para que indexe as publicações.


/items (GET, PUT, POST, DELETE )

MercadoLivre - API ResFul

/sites/MLB/search?q=ipod

Web Servers

Cache

SQL DatabaseSearch Engine

Web Servers

events


O serviço de fila permite propagar uma mensagem por meio de um feed e a guarda até que alguém a consuma.


Queue Service

items

searchqueue

moderationqueue

items-feed

moderation

search


Como chegam as mensagens?


Dado que as mensagens são assíncronas, elas podem chegar desordenadas e como não se persiste em um único lugar, podem chegar repetidas.

Então as mensagens:● Podem chegar repetidas● Podem chegar desordenadas

A solução é que a ação realizada depois de receber uma mensagem seja idempotente.


Qual o conteúdo das mensagens?



Utilizamos 2 tipos de mensagens


Apenas o ID do recurso modificado

Vantagem- Mensagem pequena

Desvantagem- GET para obter os dados

Toda a entidade com id de versão

Vantagem- Não necessita um GET ao recurso

Desvantagem- A mensagem é mais pesada


Um poucos mais de teoria


Não forçar uma consistência nos ajuda a obter

● Latência baixa● Alta disponibilidade e tolerância a falhas● Facilidade para escalar

Devido a nossa plataforma estar altamente distribuída e utilizar mensagens assíncronas, existe uma consistência eventual.



E para que podemos utilizar esta arquitetura?


Diferenças entre o hábito de guardar dados em uma tabela e processar depois X utilizar uma fila de mensagens.


Jobs

QueueServices

Workers

Workers

ID Status Work Date

1 Pending ..... 12/31

2 Pending ..... 12/31

3 Done .... 12/31

4 Done ..... 12/31


O que aprendemos no caminho


Trabalhe offline

● Minimizar o trabalho para responder cada request.● Tudo o que pode ser feito offline, não faça online.

Guardar informações redundantes

● Se os dados têm múltiplas formas de apresentação, guarde todas elas.● O espaço em disco e memória é mais barato que fazer o usuário esperar.

Cachear tudo

● Informação da base de dados.● Guardar dados pré-carregados.


Perguntas?

Pablo Moretti@elsantob

Arquitetura de Mensagens Assíncronas - MeliDevConf 2013 - SP

Technology

Transcript of Arquitetura de Mensagens Assíncronas - MeliDevConf 2013 - SP