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.

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. CoreVis 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
CoreVis 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. Futuropró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