Redu Walled Garden

Apresentará as motivações e lições aprendidas na criação de uma aplicação de larga escala orientada a serviços. Entenda como fatores como performance, estilos de comunicação e produtividade da equipe relacionam-se à estruturação de uma aplicação.

Transcript

1. Walled Garden Redu
2. Apresentações
3. Guilherme Cavalcanti github.com/guiocavalcanti Tiago Ferreira github.com/fltiago
5. Plataforma de educação a distância construída em uma estrutura de rede social redu.com.br
6. Walled Garden
7. Monolítica Serviços Redu Analytics Core App Store
8. Serviços • Resposabilidades bem definidas • API REST • Privados • On going process • “Desmembrar” serviços Analytics Core App Store
9. Vantagens • Evolução indepentente • Liberdade de tecnologia • Menos overhead de comunicação entre pessoas Analytics Core App Store
10. Core Vis Apps Walled Garden
11. Untied github.com/redu/untied
12. Acoplamento entre serviços • Comunicação “um para muitos” • Identidade de serviços
13. Acoplamento entre serviços Core Vis Apps N ...
14. spaghetti Service
15. Disponibilidade e tolerância • Como lidar com não disponibilidade do serviço? • Estratégia de retry no cliente • Em casos de falhas de HTTP
16. Disponibilidade e tolerância Core Vis N ... x
17. Message Bus
18. Ideia • Canal de comunicação transversal entre todos os serviços • Propagação de representações do domain model (RESTishy)
19. The real Walled Garden Core Vis Apps Message Bus
20. Messaging that just works
21. Upsides • Tolerância a falhas (dos consumers) • O trabalho do publisher termina ao enviar a mensagem para o exchanger • Garantia de entrega
22. Untied Publisher github.com/redu/untied
23. Doorkeeper class  DoorkeeperWithRepresenter    include  Untied::Doorkeeper    def  initialize        watch  User,  :after_create,  represent_with:  UserRepresenter        watch  Course,  :after_create,  represent_with:  CourseRepresenter    end end
24. Features • ActiveRecord lifecycle • Propaga representações, não domain models • Multiplos adapters (Bunny & AMQP)
25. Untied Consumer github.com/redu/untied
26. Observer class  Builder  <  Untied::Consumer::Observer    observe  :user,  from:  "social-­‐network"      def  build(attrs)        LeanUser.new(attrs)    end    alias_method  :after_create,  :build end • Lifecycle • Configuração • Framework agnostic
27. “Daemonizable” $  ruby  consumerd.rb  start $  ruby  consumerd.rb  status untiedc:  running  [pid  52324] $  ruby  consumerd.rb  stop untiedc:  trying  to  stop  process  with  pid  52324.. untiedc:  process  with  pid  52324  successfully  sto worker  =  Untied::Consumer::Worker.new worker.daemonize(pids_dir:  pids_dir,  log_dir:   • gem “deamons” • Monit, god, etc
28. Untied Plugins github.com/redu/untied-consumer-sync
29. Padrões comuns • Untied Consumer Sync • Abstraí o padrão de replicar entidades através de vários serviços
30. Como? Untied::Consumer::Sync.configure  do  |config|    config.model_data  =  "mappings.yml" end User:  #  Payload's  type    attributes:  #  Needed  attributes        -­‐  id        -­‐  login        -­‐  first_name        -­‐  last_name    mappings:        id:  core_id  #  Maps  payload's  id  key  to  model'    name:  LeanUser  #  Model  name • Configuração • Definição de atributos • Definição de mapeamentos • ActiveRecord • Mongoid
31. Vis
32. Objetivos • Garantia de entrega • Assíncrono e escalável • Fail-safe • Independente de Framework
33. Big Picture Core Vis mongoDB HTTP
34. Solução • MongoDB • Dados não estruturados • Possibilidade de guardar estrutura de dados complexas • Mais facilmente escalável • Boa biblioteca de consulta
35. Solução • Aplicação isolada (fail-safe) • Interação através de uma API REST • em-http-request (requisições assíncronas e paralelas)
36. Implementação inicial • Cliente da API (VisClient) bem simples • Uso do em-http-request para envio de requisições de forma assíncrona e paralela • Falhas logadas em arquivos • Uso extensivo de Observers
37. Requisições • Assíncronas • Logs em arquivos def  send_async_info(params,  url)    if  EM.reactor_running?        do_request(params,  url,  true)    else        ...    end end   def  do_request(params,  url,  self_reactor)    http  =  EM::HttpRequest.new(url).post({:body  =>  params.to_json  })      http.callback  do        ...        rescue              log.error  "log  goes  here..."        end        EM.stop  unless  self_reactor    end      http.errback    do        ...        rescue            log.error  "log  goes  here..."        end        EM.stop  unless  self_reactor    end end
38. Requisições • Paralelas • Logs em arquivos def  send_multi_request    ...    em  do        multi  =  EventMachine::MultiRequest.new                enrollments.each_with_index  do  |enroll,  idx|            multi.add  idx,  EM::HttpRequest.new(url).post({                :body  =>  enroll.to_json  })        end          multi.callback  do            multi.responses[:errback].each  do  |err|                logger.error  "logs  goes  here..."            end              EM.stop  unless  @running        end    end end
39. Parâmetros • Preenchidos manualmente • Acesso a múltiplos modelos def  fill_enroll_params(enrollment_id,  type)    ...    if  enrollment        course  =  enrollment.subject.space.course        params  =  {            :user_id  =>  enrollment.user_id,            :type  =>  type,            :lecture_id  =>  nil,            :subject_id  =>  enrollment.subject_id,            :space_id  =>  enrollment.subject.space.id,            :course_id  =>  course.id,            ...            :created_at  =>  enrollment.created_at,            :updated_at  =>  enrollment.updated_at        }    else        nil    end end
40. Lições aprendidas
41. Lições Aprendidas • Não havia interface única para envio das notificações, ou seja, código espalhado e de difícil manutenção • O em-http-request é construído em cima do EventMachine • Logar em arquivos com propósito de recuperar falhas é uma bola de neve
42. Lições Aprendidas • Lidar com requisições paralelas é difícil • Pouco workers do nginx para muitas requisições paralelas • Difícil depuração
43. Atualmente
44. Atualmente • Delayed Job lida com falhas e reenvios de uma forma atômica • VisClient responsável por criar Jobs e construir os parâmetros • Simples depuração e detecção de falhas • Uso de representers github.com/apotonick/roar
45. New vis client • Envio de requisições (Faraday) • Lógica de criação de jobs • Lógica de parametrização def  self.notify_delayed(resource,  type,  args)    elements  =  args.respond_to?(:map)  ?  args  :  [args]    notifier_builder  =  NotifierBuilder.new(resource,                                            type,  elements)    notifier_builder.build end
46. Representer module  Vis    module  EnrollmentVisRepresenter        include  Roar::Representer::JSON          property  :user_id        property  :subject_id        property  :space_id        property  :course_id        property  :created_at        property  :updated_at          def  space_id            self.subject.space.id        end          def  course_id            self.subject.space.course.id        end    end end
47. Futuro próximo
48. Futuro • Vis vai se tornar provedora de Relatórios e Visualizações • não haverá API de consulta • relatórios e visualizações estarão em Vis, front-end incluso • inclusão será feita através de iframe
49. Referências • https://github.com/redu/permit • https://github.com/redu/untied • https://github.com/redu/untied- consumer-sync