Crossbar

O que é

Crossbar: o que é

Uma plataforma de comunicação open source para aplicações distribuídas e microsserviços

• Autenticação/Autorização
• Pub/Sub
• RPC
• Orquestração
• "Bridges" para vários outros protocolos

Arquitetura Típica

• Router/Dealer
• É o único que precisa ser conhecido previamente
• Suporta clustering/HA

Protocolo: WAMP

• Web Application Messaging Protocol
• Serialização: JSON / msgpack
  • Mas é completamente transparente.
  • "No fio" o envio é num formato próprio, muito leve, razoavelmente similar a MQTT.
• WAMP != Crossbar
  • Há implementações de routers em várias outras linguagens.

Linguagens com suporte

• Todas.
• Exceto essa medonha, aí, que só você conhece.
• Interessantes:
  • autobahn (Python)
  • autobahn.js (JS)
  • vue-wamp (JS)
  • turnpike (Go)

Autenticação

• Várias opções disponíveis (protocolos)
• Estática ou dinâmica
  • Estática: autenticar o autenticador e algumas apps.
  • Dinâmica: autenticar usuários.
• Secure web socket (TLS | "wss://")
• Segredos não trafegam no fio
• Cada conexão é uma sessão
  • Que pode ser anônima ou autenticada.
• Trabalha com realms.

Sessão e autenticação

(Sessão anônima é opcional)

1. Conecta no roteador
2. Reino "anon"
3. Autenticação
4. Reino "frontend"

Realms

• Provém isolamento total (pub/sub)
• Influenciam autorização

Exemplos de reinos

• anon: completamente inseguro
• front: potencialmente maligno
• back: aplicações - seguro
• sys: geralmente logging

Realms e RPC

• As apps não são "especiais"
• A conexão delas também é uma sessão
• Cada conexão app->router pertence a um realm

Autorização

• Reino + User + Tópico + Ação
  • Reino: front
  • User: Zequinha
  • Tópico: user.created
  • Ação: PUBLISH
  • Permissão negada!
• Se precisar de algo mais granular, também pode-se identificar o "callee" no RPC.

Pub/Sub

• Tópico + Payload

  • org.33.device.42.activated

• Payload tem limite de tamanho
  • (Mas é bem grande)
• Mensagens são etéreas!
  • (Voláteis, diferente de um Kafka ou RabbitMQ)
  • Existe a opção de manter mensagens em memória
    • em número específico ou
    • baseado em tempo

Subscription

org.33.device.42.activated

• Match: org.33.device.42.activated
• Prefix: org.33.device
• Wildcard: org..device..activated

Publishing

• Um tópico por vez (não tem "matching")
• Fire-and-forget
  • Pub/sub != RPC

RPC

• Nenhuma comunicação direta entre componentes
  • (O que é muito bom)
• Router faz papel de "dealer"
• Protocolo permite respostas "paginadas" transparentes

RPC/Register

• Mesma notação de pontos dos tópicos

  • photos.upload(path) | photos.download()

• Permite usar várias estratégias:
  • 1-to-1 (só 1 app pode registrar por vez)
  • Fan out (bom para tarefas pesadas)
    • Random
    • Round robin
  • First (tenta 1 até cair)
  • Last (tenta sempre a versão mais recente)

RPC/round robin

• CALL: photo.analyze(data)
• photo_analyzer_01: RETURN
• CALL: photo.analyze(data)
• photo_analyzer_02: RETURN
• CALL: photo.analyze(data)
• photo_analyzer_03: RETURN
• CALL: photo.analyze(data)
• photo_analyzer_01: RETURN
• ...

Bridges

• MQTT
• HTTP

Misc

• Roda no Docker
• Suporta até ~200k conexões simultâneas