PHP Symfony MicroServices Migration @MeeticTech

1 344 vues

Publié le

Feedback on Meetic journey to migrate from a monolithic PHP application to a MicroServices architecture using PHP & Symfony. First presented at Symfony Live Paris 2017 in March 2017 by Etienne Broutin, Software Architect @MeeticTech

Publié dans : Ingénierie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 344
Sur SlideShare
0
Issues des intégrations
0
Intégrations
50
Actions
Partages
0
Téléchargements
20
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

PHP Symfony MicroServices Migration @MeeticTech

  1. 1. Symfony Micro-services @Meetic
  2. 2. Who am I ? Joined Meetic in 2014 Interested by their volumes, functionnal richness and experience Etienne Broutin Software Architect
  3. 3. Started in 2001 • Active in 15 countries • Dating leader in Europe • Millions of Monthly Active Users • 150 people in IT teams
  4. 4. Back again
  5. 5. 2013 Reasons for refactoring plan Unmaintainable code Duplicates Untestable Need elders validation Unable to monitor Continue on failure policy Based on global log volume
  6. 6. 2013 Initial project Webservices Backoffices Mobile Web WAP Desktop Cronjobs … Exposition Layer Private webservices
  7. 7. Started So cute in the beginning !
  8. 8. But new issues Duplicated business logic Merge conflicts Longer tests (40min) Refactorings started to become more and more difficult
  9. 9. We were building a new monolith ! Only 15% of business features Only 10 developers, target 40
  10. 10. Micro-service pros • Simpler design phase • Manage refactoring impacts • Faster feedbacks by software factory • Faster deployments • Real ownership by developers, easier upgrades
  11. 11. Micro-service cons • Implementation of interfaces • Response time • CPU and network usage • Time to setup a new application • Can also become hard to understand
  12. 12. New stack Exposition Layer Event bus Consumers Micro-services BackOffices Webservices
  13. 13. 2 years later.... Micro-service design Dependencies Team Production
  14. 14. Micro-service design
  15. 15. How to split ? Functionnal splitting Built around a concept Pictures Right
  16. 16. What size ? 25 micro-services 9 avg route count 7k avg NLOC 4 avg relationnal tables to understand a micro-service 1 to 2 days
  17. 17. Testability Build in 3minSimpler functionnal tests
  18. 18. Modelization POST /photos/{accountId} GET /photos/{accountId}/{photoId} PUT /photos/{accountId}/{photoId} DELETE /photos/{accountId}/{photoId} POST /boost/{boostId}/increment REST approach Commands
  19. 19. Data isolation Strong and difficult choice But • brings scalability • brings visibility • data consistency • enables caching • manage data migration
  20. 20. Limits of data isolation Build a denormalized database OLTP Reactive (event bus) Batch processing BI
  21. 21. How to deal with dependencies ?
  22. 22. Product team has a new idea...
  23. 23. In practice 2/3 of our micro-services do not depend on another micro-service took several refactorings for that
  24. 24. Defining perimeter is the key Messages Authentication nickname business model account status Photo Announce Moderation Photo + Moderation Announce + Moderation
  25. 25. Event bus to manage dependency Event bus Consumer Consumer Profile Mailing Optin
  26. 26. get photos Pattern 1 : Pull data - performance - reusability does have a photo itself ?can see photos ? + hides complexity for clients + fast change of business rules Exposition Layer Rights Photo
  27. 27. Pattern 2 : Push data from client + mutualize data fetching - harder to change if multiple clients send message Exposition Layer Rights Message conversation already started ? can start a new conversation ?
  28. 28. Pattern 3 : Store data Event bus read message Exposition Layer Message get visible messages Blacklist + performance + reusable - long to implement blacklist added hide messages
  29. 29. Other tips Batch calls GET /photos/{accountId}/14,15,21 Parallelize calls using Guzzle promise
  30. 30. Working together
  31. 31. Context Several independent agile teams No strong synchronization Continuous deployment 15 deployments per day
  32. 32. How do you manage compatibility ? No versioning • used internally • less maintenance • interface backward compatible
  33. 33. Automated environment Scripts with docker compose
  34. 34. Can I use any framework ? Any langage ? Any database ?
  35. 35. Common interface • REST + JSON • Naming conventions • Security • Common build • Common deployment chain
  36. 36. Don’t waste time : need a common basis Micro-services chassis • Security • Logging • HTTP Interface • DB & cache components
  37. 37. Share knowledge with non-tech teams Talkative names Visibility for project management profile will be updated soon changes on message are ready thanks
  38. 38. Documentation Inventory <<< Call graph generated from Elastic Search GET /profile/{accountId} Profile Exposition Layer Right Backoffice 4% 85% 11%
  39. 39. Ownership More initiatives More refactorings More upgrades More monitoring
  40. 40. Production
  41. 41. Hosting concerns It will overload the network ! It will take time to configure ! We will need much more servers !
  42. 42. Figures 1B calls / day 25ms response time 100 servers Who calls micro-services ? Exposition LayerEvent Bus Micro-services
  43. 43. Networking • Every Micro-services deployed on each server • Affinity for inter micro-service call Have not experienced need for : • Service isolation • Network constraints
  44. 44. 8 ms Symfony boostrap overhead limited by application size 17 ms 25ms Cost : 25%
  45. 45. Monitoring Alerting Elastic Search + Logstash + Kibana • Easy to locate errors • Performance analysis Monitoring route for every dependency GET /profile/{accountId} 11ms 100% POST /profile/ 42ms 99.992% ... P P
  46. 46. Design for failure Objective 99.999% Internally : analyse logs Externally : implement fallback behavior Exposition Layer 99.9% 98.3% 99.2% Reliability < 97.4%
  47. 47. Conclusion
  48. 48. Re-usability Re-used micro-services from acquisition fusion Used for several products
  49. 49. Huge opportunity for Data Best Database for each Scalability
  50. 50. Feedback on that choice For Meetic, this architecture was a good choice : • Symfony helps standardization • Can scale teams • Clear implementation of all features • Answer business needs
  51. 51. Any questions?

×