Integração de Sistemas usando tecnologias open source

1,060 views

Published on

Palestra ministrada no primeiro

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,060
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
10
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Integração de Sistemas usando tecnologias open source

    1. 1. INTEGRAÇÃO DE SISTEMAS CASE: GLOBO.COM Utilizando software livre @pac_man Hack ‘n Rio 2011
    2. 2. QUEM SOU EU?• Tiago Peczenyj (@pac_man)• Desenvolvedor da globo.com• Distribuição de Videos/Webmedia• Apaixonado por Open Source• Blog pacman.blog.br
    3. 3. OPEN SOURCE NA GLOBO.COM• php, perl, python (Django, Tornado), ruby (Rails, Sinatra),• apache, nginx, mysql, memcached, jQuery, CentOS...• ffmpeg, mencoder, ImageMagick
    4. 4. INTEGRAÇÃO DE SISTEMAS• File Transfer• Shared Database• Remote Procedure Invocation• Messaging
    5. 5. CASE: PUBLICAÇÃO VIDEOS• Eisque eu preciso pegar um video bruto e publicar na internet...
    6. 6. PUBLICAÇÃO DE VIDEOS• E(f) - encodar o video no(s) formato(s) especificos•M - inserir meta-dados do video no(s) sistema(s)•D - disponibilizar video adequadamente
    7. 7. RESUMO• E(f) -> M -> D
    8. 8. THUMBNAILS?• E(f) -> T -> M -> D
    9. 9. DISPONIBILIZAR: FTP E SINALIZAR QUE ESTA OK• E(f) -> T -> M -> F -> S
    10. 10. DEFINIR OS FORMATOS• D-> E(f) -> T -> M -> F -> S
    11. 11. E TAMBÉM• Publicar em um tempo X (SLA)• Resistir à catástrofes (rede, banco, disco)• Utilizar bem meus recursos
    12. 12. COMOFAS/• Com um sistema apenas posso fazer tudo isso.•N vídeos, N instâncias do sistema simultaneamente.• Monolítico
    13. 13. MAS E O SLA?• Se tiver que produzir varios formatos, vou demorar se esperar um formato ficar pronto para produzir o próximo
    14. 14. RESISTIR À CATÁSTROFE• Sealguma das etapas falhar, precisarei seguir alguma protocolo de acordo com a natureza da falha.• Seprecisar retentar enquanto a falha persiste (ex: rede) pode ficar complexo o tratamento disso.• Devo evitar estados inconsistentes e voltar a funcionar OK
    15. 15. UTILIZAÇÃO DE RECURSOS• Linguagens interpretadas podem apresentar GIL• Maquinas atuais possuem CPU com varios cores• Precisoainda de redundância para garantir alta disponibilidade, meus gastos podem facilmente sair o dobro do esperado.• Cores de CPU ociosas são prejuizo
    16. 16. SOLUÇÃO• Perl• FFmpeg• PHP• MySQL
    17. 17. CONCEITOS
    18. 18. PROCESSOS• Possoter varios processos na mesma maquina trabalhando de forma cooperativa• A “morte” deum desses processos deve produzir uma resposta adequada (alarmar, reiniciar o processo por exemplo)• Monitoria dos processos é essencial (Watchdog, Monit, etc)
    19. 19. FILESYSTEM• Emintegração de sistemas as vezes precisamos realizar operações atômicas (ex: um mesmo video não pode ser encodado varias vezes).• Mover um arquivo entre diretórios É uma operação atômica.• Tudo no mundo *nix é arquivo...•2 + 2...
    20. 20. HTTP• HyperText Transfer Protocol• Define 4 métodos: GET, POST, PUT, DELETE (HEAD, etc)• Mensagem possui Header e Body• Codigos de retorno bem compreendidos (200, 404, 500, 302)• Trata de transferir recursos
    21. 21. REST• Representational State Transfer• Posso utilizar caracteristicas do HTTP para representar e transferir recursos entre sistemas• Facilita a integração pois praticamente tudo acessa a WEB• Equivalência entre métodos HTTP e CRUD
    22. 22. REST (2)• PUT -> Create• GET -> Retrieve• POST -> Update• DELETE -> Delete
    23. 23. REST (FIM)• Possotrafegar a representação (em XML, JSON, YAML...) entre aplicações diferentes.• Respeitando as regras e os verbos HTTP posso fazer muita coisa (no mínimo CRUD).• Tolerância a erros: problemas temporários basta tentar novamente apos X segundos, problemas irreversíveis devem ser vistos imediatamente.
    24. 24. VIDEO (REST)• Possui meta-dados, identificador e estado• Uma API REST (PHP) centraliza a maquina de estados• Video (dado) é armazenado em banco, arquivo no filesystem• Basta operar sobre o arquivo e alterar o estado na API
    25. 25. CARTAS NA MESA• Posso dividir as etapas em deamons independentes, que se comunicam transferindo o arquivo de video entre diretorios.• Consistencia é feita pela comunicação com a API• API fornece formatos de video• Cumprir todas as etapas torna o video apto a ser consumido
    26. 26. FLUXO UNICO•D -> E(f) -> T -> M -> F -> S (teorico)•D <- E(f) -> T -> M -> F -> S (pratico)
    27. 27. MAS O QUE FAZ A API?• Outros sistemas integram com a API• Um fluxo pode ser interrompido• Posso saber o que esta acontecendo• Centraliza regras de negócio
    28. 28. DEAMON TIPICO• Trabalha com conceito de diretorios• Indir é a entrada de videos• Workdir é onde o deamon trabalha• Outdir é a saída de videos• Se o outdir de um deamon for o Indir de outro... ?
    29. 29. REDUNDANCIA DE DEAMONS?• Operação move é atomica• Cada processo deve ter o seu Workdir• Varios procesos de uma mesma etapa tem o mesmo Indir• Quem chegar primeiro leva.• Reporta tudo a API REST (LWP)
    30. 30. use LWP::UserAgent;my $ua = LWP::UserAgent−>new;my $req = HTTP::Request−>new( GET => "http://api.xxx.com/video/$id" );my $res = $ua−>request($req);if ($res−>is_success) { process $res−>content;} else { error $res−>status_line ;}
    31. 31. <?php# http://www.slimframework.comrequire "Slim/Slim.php";$app = new Slim();$app->get(/video/:id, function($id) use ($app) { $service = new VideoService(); if ( !$service->exists($id) ) { $app->notFound(); } else { $app->render(video.tpl, $service->retrieve($id)); } });?>
    32. 32. E O SLA• Arquitetura garante paralelismo de atividades demoradas• Limita-se o tempo de encoding (via SIGALARM)• Dimensiona-se a infraestrutura para suportar uma média de videos• SLA é estatística
    33. 33. RESISTENCIA A DESASTRES• Separandoos deamons cada um fica com codigo minimo e reusando modulos (CPAN) evitamos (os nossos) bugs• Perda de rede não trava o encoding, são processos separados• Perda de banco local não trava o fluxo, depois o sistema é atualizado desde que haja cache de dados (http!)• Redundância natural, perder um processo não trava tudo• Recuperação simples: basta mover de volta o arquivo
    34. 34. OUTROS DETALHES• Meta Dados são publicados usando SOAP::Lite (ugh)• Thumbs são tranferidos usando base64 dentro do SOAP• Thumbs gerados pelo FFmpeg e ImageMagick• 5% dos videos são descartados por falta de qualidade• Transferencia hoje é SFTP
    35. 35. PERGUNTAS?

    ×