Microservice Architecture at Meducation

Transcript

1. Microservices Architecture at Meducation By Malcolm Landon
3. Monorail
5. Monorail Architecture
6. Problems • Dependency Hell • Tight Coupling • Messy • Complex • Hard to Understand • Hard to Maintain • Buggy
7. How did we scale? • Pub/Sub • Micro Service Architecture – “independently deployable services”
8. Pub/Sub • Faye • Storm • AWS – SNS/SQS
9. Propono https://github.com/meducation/propono
10. Publisher SNS Topic SQS Queue Subscriber SQS Queue Subscriber SQS Queue Subscriber /user /user/email_service /user/badge_service /user/dashboard_service Pub/Sub Using SQS/SNS
11. Propono Glues Everything Together
12. Glue when Publishing Publisher SNS Topic /user Propono.publish(“user”,msg)
13. Glue when Subscribing SNS Topic SQS Queue Subscriber /user /user/email_service Propono.listen_to_queue(“user”) do |msg| #process message... end
14. Microservices • Email • File Conversion • Indexing • Scheduled Tasks • More.... Nearly 20
15. Pub/Sub Architecture
16. Messages • Small • Minimal information • e.g. Propono.publish( “user_topic”, {action: “created”, id: 30660} )
17. Internal “System API”
18. Problem: Visibility of Failure • Monitoring of Website • How do you know when daemons fail? • How do you recover after a failure?
19. SQS Queue Subscriber SQS Queue user/email_service user/email_service_fail Fail Queue
20. Replay Fail Queue SQS Queue Subscriber SQS Queue user/email_service user/email_service_fail
21. AWS Cloudwatch • Alert on Failed Queue > 0 • Alert on Main Queue > n
22. Problem: Multiple Delivery • From Amazon • From Us!
23. AWS SQS FAQ “SQS is engineered to provide “at least once” delivery of all messages in its queues. Although most of the time each message will be delivered to your application exactly once, you should design your system so that processing a message more than once does not create any errors or inconsistencies.”
24. Idempotent Services
25. Don't Send Same Email Twice! Mailchimps API Daemon 1 Email Service user_topic AWS Simple DB key: /user/new_user/30660
26. Solution • Not 100% guaranteed • Window of opportunity for failure greatly reduced
27. Problem: Daemon Standardisation • Continuously improving daemon • Early daemons fall behind
28. Larva http://github.com/meducation/larva “Larva is a Ruby daemon builder based on top of the Propono pub/sub library and the Filum logging library. It is the foundation for daemons in Meducation's infrastructure.”
29. Larva • Standardise how daemons worked • Create new daemons very quickly – From scratch to live in less than a day
30. What did we achieve? • Separation of Concern • Loose Coupling • Scalability • Add/Remove Functionality Quickly • Speed of Iteration
31. Image Attribution • “Monorail Monday” by Joe Penniston – https://www.flickr.com/photos/expressmonorail/5548294525/ • “Glue Goo” by Sam Catch – https://www.flickr.com/photos/samcatchesides/3326878608
32. Questions?