Como um grande sistema REST funciona

897 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
897
No SlideShare
0
A partir de incorporações
0
Número de incorporações
8
Ações
Compartilhamentos
0
Downloads
10
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Como um grande sistema REST funciona

  1. 1. Como um grandesistema REST funciona
  2. 2. David Robertdavidrobert@gmail.comtwitter: while42github: davidrobert
  3. 3. AMBIENTE
  4. 4. gráficadistribuidoraeducação
  5. 5. Playboy VejaQuatro RodasSuper InteressantePlacar
  6. 6. “organizações que projetam sistemas sãorestritas a produzir projetos que são cópiasdas estruturas de comunicação dessasorganizações”Lei de Conwayhttp://www.melconway.com/Home/Conways_Law.html
  7. 7. CMS’s existem desde os anos 90.Por que reiventamos a roda?
  8. 8. Porque temosalta diversidadederequisitosnegóciospessoasorçamentosprioridadesculturas{
  9. 9. boaarquiteturanecessidadesatendidascustoaceitável= + *ßßquão bem o seu clientesabe pedir o que quer :-PMTRHMTRHmean time torecovery happiness
  10. 10. diretoria digitalPlayboyVejaQuatro Rodas
  11. 11. RAIO X
  12. 12. 16 sites em produção
  13. 13. +/- 60 desenvolvedores13 arquitetos de software6 Gerentes de Projeto4 Gerentes de Produto1 Advocate da Plataforma
  14. 14. • MongoDB• MySQL• Hbase• HDFS• PostgreSQL• memcached• redis• ruby• java• javascript• rails• sinatra• goliath• node.js• play• jetty• tokamak• cachebag• HTTPMonkeylinguagens storage frameworks outros• Solr• Hadoop• RabbitMQ• Varnish• New Relichttps://github.com/abril
  15. 15. infraestrutura Alexandria + sites• 91 VMs para ambientes dev, qa, stage• AMC (Abril Mídia Cloud): private cloud (Xen/Open Stack)• ou VMWare• ~100 VMs + 20 físicas para produção• Data center próprio, AWS, Heroku• Total aproximado: 220 máquinas
  16. 16. +15 milhões de pageviews(de jan até fev de 2013)
  17. 17. HTTP
  18. 18. 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
  19. 19. serviço• 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
  20. 20. data-entry• entrada da Redação• aplicação web• ~ 1 para cada domínio• “API explorer”
  21. 21. sitetools• admin do site• manipulação das áreas e templates• agiliza criação de produtos• a fronteira com o usuário• opcional
  22. 22. HTTPdomínioserviçodata-entry sitetools
  23. 23. system of systems
  24. 24. REST
  25. 25. Por que escolhemos REST?• Protocolo de transferência amplamenteutilizado• Escalabilidade• Performance alta• Alta disponibilidade• Permitir evolução sem parar o sistema• Permitir evolução sem quebrar os clientes• Segurança
  26. 26. Por que escolhemos REST?• HTTP• Escalabilidade• Performance alta• Alta disponibilidade• Permitir evolução sem parar o sistema• Permitir evolução sem quebrar os clientes• Segurança
  27. 27. Por que escolhemos REST?• HTTP• Web Caches• Performance alta• Alta disponibilidade• Permitir evolução sem parar o sistema• Permitir evolução sem quebrar os clientes• Segurança
  28. 28. Por que escolhemos REST?• HTTP• Web Caches• Web Proxies (localização geografica)• Alta disponibilidade• Permitir evolução sem parar o sistema• Permitir evolução sem quebrar os clientes• Segurança
  29. 29. Por que escolhemos REST?• HTTP• Web Caches• Web Proxies (localização geografica)• Load Balancers “comoditizados”• Permitir evolução sem parar o sistema• Permitir evolução sem quebrar os clientes• Segurança
  30. 30. Por que escolhemos REST?• HTTP• Web Caches• Web Proxies (localização geografica)• Load Balancers “comoditizados”• Load Balancers• Permitir evolução sem quebrar os clientes• Segurança
  31. 31. Por que escolhemos REST?• HTTP• Web Caches• Web Proxies (localização geografica)• Load Balancers “comoditizados”• Load Balancers• HTML, JSON, XML• Segurança
  32. 32. Por que escolhemos REST?• HTTP• Web Caches• Web Proxies (localização geografica)• Load Balancers “comoditizados”• Load Balancers• HTML, JSON, XML• HTTPS / TLS
  33. 33. REST= +LCODC$SSPorque...Uo_O
  34. 34. REST= +LCODC$SSPorque...ULayered-Code on Demand-Client-Cache-Stateless-Server
  35. 35. REST= +LCODC$SS UClient-Server• Separação de responsabilidades• Escalabilidade (simplificação)• Evolução independentehttp://byterot.blogspot.co.uk/2012/06/what-i-think-coupling-is.html
  36. 36. REST= +LCODC$SS UClient-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
  37. 37. REST= +LCODC$SS U• Visibilidade• Escalabilidade(recursos alocados)• Confiabilidade• Performance de redeStateless
  38. 38. Stateless no Alexandria• HATEOAS implementado nas APIs• cookies nas operações destrutivasREST= +LCODC$SS U
  39. 39. REST= +LCODC$SS U• Eficiência• Escalabilidade• Performancepercebida pelo usuário• ConfiabilidadeCache
  40. 40. 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 cacheREST= +ULCODC$SS
  41. 41. REST= +LCODC$SS U• Encapsula complexidade• Evolvabilidade• Simplicidade• Performance percebidapelo usuárioLayered System
  42. 42. • 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 legadoREST= +ULCODC$SSLayered System no Alexandria
  43. 43. REST= +LCODC$SS U• Extensibilidade• Simplificação do client• VisibilidadeCode-on-demand
  44. 44. • widgets dos data-entries• no futuro, o console também será instanciado assim• é um elemento importante do REST que foi esquecidopor um tempo pela nossa arquiteturaREST= +ULCODC$SSCode-on-demand no Alexandria
  45. 45. REST= +LCODC$SS U• Simplificação pela generalidade• Visibilidade• Desacoplamento• Evolvabilidade• Performance percebidapelo usuário• Restrita a dados comgranularidade largaUniform interface
  46. 46. REST=niform interface no Alexandria+LCODC$SSU
  47. 47. Uresource identificationURIuniversal resource identifier
  48. 48. Uresource identification/:tipo_recurso/:id
  49. 49. Uresource identificationhttp://editorial.api.abril.com.br/materia/dicashttp://editorial.api.abril.com.br/materia/ac23657fghttp://bebe.abril.com.br/materia/ac23657fg
  50. 50. Uresources
  51. 51. Uresources{"tipo_recurso" : "materia","link" : [{"href" :"http://editorial.api.abril.com.br/materia/4f0dea5a1e13694","rel" : "self","type" : "application/json"},{"href" : "http://editorial.api.abril.com.br/materias","rel" : "materias","type" : "application/json"}],"id" : "http://editorial.api.abril.com.br/materia/4f0dea5a1e13694","slug" : "o-quintal-da-realeza","marca" : "viajeaqui","status" : "disponivel","descricao_conteudo" : "O quintal da realeza","fonte" : "viajeaqui",(continua)
  52. 52. UrepresentationsJSON
  53. 53. Urepresentationse um tiquinho assim de XMLou melhor,de application/opensearchdescription+xml
  54. 54. Urepresentations<?xml version="1.0" encoding="UTF-8"?><OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"xmlns:grafo="http://socialcore.api.abril.com.br/grafo/busca"><ShortName>Buscar relacionamentos</ShortName><Description>Busca de relacionamentos no grafo</Description><Url type="application/json"template="http://socialcore.api.abril.com.br/grafo/busca?usuario={grafo:usuario?}&amp;tipo={grafo:tipo}"/><Query role="example"title="Exemplo de valores dos parâmetros"grafo:usuario="id do usuario"grafo:tipo="segue |seguido_por " /></OpenSearchDescription>
  55. 55. UhypermediaExercício: criar uma atividade deum usuário no site.Você só sabe o entrypoint:http://socialcore.api.abril.com.br
  56. 56. UhypermediaPOST http://socialcore.api.abril.com.br/Accept: application/json
  57. 57. UhypermediaPOST???
  58. 58. UhypermediaHTTP/1.1 405 Method Not AllowedAllow: GET
  59. 59. UhypermediaGET http://socialcore.api.abril.com.br/Accept: application/json
  60. 60. UhypermediaHTTP/1.1 200 OKContent-Type: application/json; charset=utf-8{"titulo": "socialcore","link": [{"href": "http://socialcore.api.abril.com.br/","rel": "self","type": "application/json"},{"href": "http://socialcore.api.abril.com.br/atividade","rel": "atividade","type": "application/json"},{"href": "http://socialcore.api.abril.com.br/grafo","rel": "grafo","type": "application/json"}]}
  61. 61. UhypermediaGET http://socialcore.api.abril.com.br/atividadeAccept: application/json
  62. 62. UhypermediaHTTP/1.1 200 OKContent-Type: application/json; charset=utf-8{"titulo": "Entry Point de Atividades","link": [{"href": "http://socialcore.api.abril.com.br/atividade/template","rel": "template","type": "application/json"},{"href":"http://socialcore.api.abril.com.br/atividade/busca/descritor","rel": "search","type": "application/opensearchdescription+xml"},{"href":"http://socialcore.api.abril.com.br/atividade/stat/descritor","rel": "stat","type": "application/opensearchdescription+xml"}]}
  63. 63. UhypermediaGET http://socialcore.api.abril.com.br/atividade/templateAccept: application/json
  64. 64. UhypermediaHTTP/1.1 200 OKContent-Type: application/json;charset=utf-8{"atividade": {"app": "","created_at": "","usuario": "","tipo": "","objeto": {"tipo": ""},"resultado": {"tipo": ""}},(continua)
  65. 65. Uhypermedia"link": [{"href": "http://socialcore.api.abril.com.br/atividade","rel": "atividade","type": "application/json"},{"href":"http://socialcore.api.abril.com.br/atividade/busca/descritor","rel": "search","type": "application/opensearchdescription+xml"},{"href":"http://socialcore.api.abril.com.br/atividade/stat/descritor","rel": "stat","type": "application/opensearchdescription+xml"}]}
  66. 66. UhypermediaPOST http://socialcore.api.abril.com.br/atividadeAccept: application/jsonContent-Type: application/json; charset=utf-8Authentication: Basic 37rnx9w87rjdw87gri{"atividade": {"app": "http://aapg.api.abril.com.br/produtos/1","created_at": 1325086429,"tipo": "comentar","objeto": {"descricao": "Titulo da materia","id":"http://veja.abril.com.br/noticia/economia/confianca-da","tipo": "materia"},"resultado": {"corpo": "otima materia","id":"http://veja.abril.com.br/noticia/economia/confianca-da/comments/1","tipo": "comentario"}
  67. 67. UhypermediaHTTP/1.1 422 Unprocessable EntityContent-Type: application/json; charset=utf-8{"tipo_recurso":"erro","atividade":{"usuario":"",},"erros":[{"atributo":"usuario","mensagem":["é obrigatório"]}]}
  68. 68. UhypermediaPOST http://socialcore.api.abril.com.br/atividadeAccept: application/jsonContent-Type: application/json; charset=utf-8Authentication: Basic 37rnx9w87rjdw87gri{"atividade": {"app": "http://aapg.api.abril.com.br/produtos/1","created_at": 1325086429,"usuario": "http://aapg.api.abril.com.br/usuarios/2","tipo": "comentar","objeto": {"descricao": "Titulo da materia","id":"http://veja.abril.com.br/noticia/economia/confianca-da","tipo": "materia"},"resultado": {"corpo": "otima materia","id":"http://veja.abril.com.br/noticia/economia/confianca-da/comments/1","tipo": "comentario"
  69. 69. UhypermediaHTTP/1.1 201 CreatedContent-Type: application/json; charset=utf-8Location: http://socialcore.api.abril.com.br/atividade/0922307o/
  70. 70. Uapplication protocolHTTPstatus codesrepresentation metadataresource metadatacontrol data
  71. 71. Lições aprendidas
  72. 72. pontos importantes em performanceclientorigin server• performance dosconnectors• non-blockingHTTP clients• cache local• middlewarearchitecture• libs padronizadas• short stacks• evented servers• libs padronizadas• good TTL strategy• middlewarearchitecture• caches• HTTP plumbing
  73. 73. • 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 temsuas desvantagens• medir/monitorar o desempenho é importantíssimo
  74. 74. Assumimos que nossa arquitetura está válida.
  75. 75. necessidadesatendidascustoaceitável+ * ßMTRHmas...
  76. 76. e quando REST nãofor suficiente?
  77. 77. não use REST
  78. 78. Os responsáveis
  79. 79. PERGUNTAS ?
  80. 80. engineering.abril.com.brdigital.abril.com.brObrigado!David Robert

×