SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
Como um verdadeiro sistema REST funciona: arquitetura e performance na Abril
A palestra irá compartilhar a experiência e lições aprendidas no desenvolvimento da plataforma de publicação da Abril, um sistema distribuído com vários nós independentes que se comunicam usando REST e hypermidia. Também introduziremos alguns conceitos avançados de HTTP que podem fazer com que sistemas REST executem com melhor performance, evitando os problemas comuns de se manter uma plataforma em larga escala, com uma grande diversidade de usuários.
Director Software Engineering at Rocket Internet SE
A palestra irá compartilhar a experiência e lições aprendidas no desenvolvimento da plataforma de publicação da Abril, um sistema distribuído com vários nós independentes que se comunicam usando REST e hypermidia. Também introduziremos alguns conceitos avançados de HTTP que podem fazer com que sistemas REST executem com melhor performance, evitando os problemas comuns de se manter uma plataforma em larga escala, com uma grande diversidade de usuários.
16.
boa
arquitetura =
custo
aceitável + necessidades
atendidas
* ß
MTRH
ß quão bem o seu cliente
sabe pedir o que quer :-P MTRH mean time to
recovery happiness
21.
“organizações que projetam sistemas são restritas a
produzir projetos que são cópias das estruturas de
comunicação dessas organizações”
Lei de Conway
http://www.melconway.com/Home/Conways_Law.html
29.
domínio
• acesso e manipulação de recursos
• implementa regras de negócio
• servidor HTTP + base de dados
• infra “isolada”
• ~ 8 domínios
• ex: editorial (matérias, galerias, etc), anotações
(comentários), estabelecimentos, mídia, pessoas
30.
• consumo e manipulação de recursos
• servidor HTTP + (opcional base de dados)
• infra “isolada”
• ~ 12 serviços
• ex: console, socialcore, search, Abril ID, abr.io, etc
serviço
31.
data-entry
• entrada da Redação
• aplicação web
• ~ 1 para cada domínio
• “API explorer”
32.
• admin do site sitetools
• manipulação das áreas e templates
• agiliza criação de produtos
• a fronteira com o usuário
• opcional
38.
REST = LCODC$SS + U
Client-Server
• Separação de responsabilidades
• Escalabilidade (simplificação)
• Evolução independente
http://byterot.blogspot.co.uk/2012/06/what-i-think-coupling-is.html
39.
REST = LCODC$SS + U
Client-Server no Alexandria
• Separação de responsabilidades
• entre domínios e sites
• entre domínios e data entries
• entre domínios e serviços
• Escalabilidade
• funcionalidade implementada nos clients
• domínios só lidam com recursos (simplicidade)
• Evolução independente
• em certos pontos da arquitetura não há
• falta retro-compatibilidade
40.
REST = LCODC$SS + U
Stateless
• Visibilidade
• Escalabilidade • Performance de rede
(recursos alocados)
• Confiabilidade
41.
REST = LCODC$SS + U
Stateless no Alexandria
• HATEOAS implementado nas APIs
• cookies nas operações destrutivas
42.
REST = LCODC$SS + U
Cache
• Eficiência • Confiabilidade
• Escalabilidade
• Performance
percebida pelo usuário
43.
REST = LCODC$SS + U
Cache no Alexandria
• Built-in no protocolo HTTP
• shared-caches instanciados entre alguns nós
• pesquisa sobre caches locais
• nem todos os nós implementam estratégia de cache
• purge de recursos diretamente no cache
44.
REST = LCODC$SS + U
Layered System
• Encapsula complexidade • Performance
• Evolvabilidade percebida pelo usuário
• Simplicidade
45.
REST = LCODC$SS + U
Layered System no Alexandria
• shared-caches
• gateways para expor API para a Web
• balanceadores de carga
• encapsulamento de autenticação corporativa
• encapsulamento de legado
• permite evolução incremental do legado
46.
REST = LCODC$SS + U
Code-on-demand
• Extensibilidade • Visibilidade
• Simplificação do client
47.
REST = LCODC$SS + U
Code-on-demand no Alexandria
• widgets dos data-entries
• no futuro, o console também será instanciado assim
• é um elemento importante do REST que foi esquecido
por um tempo pela nossa arquitetura
48.
REST = LCODC$SS + U
Uniform interface
• Simplificação pela generalidade • Performance
• Visibilidade percebida pelo usuário
• Desacoplamento • Restrita a dados com
• Evolvabilidade granularidade larga
49.
REST = LCODC$SS +
Uniform interface no Alexandria
50.
U resource identification
URI
universal resource identifier
88.
• Lei de Postel
• Seja conservador no que faz, seja liberal no que você aceita dos outros
• REST é uma arquitetura de longo prazo
• Defenda com todas as suas forças:
• seus metadados (recursos)
• sua interface
• Documentação é essencial
• Independência de desenvolvimento dos nós tem
suas desvantagens
• medir/monitorar o desempenho é importantíssimo