Architecture d'une application full API
orientée micro service
Présentation
• Yves HeitzDevOps Klubup
• Xavier Gorse / @xgorse CTO & Co-fondateur KlubupFondateur Elao
Qu’est ce qu’un micro service ?
http://martinfowler.com/articles/microservices.html
Qu’est ce qu’un micro service ?
http://martinfowler.com/articles/microservices.html
Klubup
• Connecter les @personnes et les #passions autour de la notion du Klub
• On est membre d’un Klub
• On partage dans un Klub
• On sponsorise un Klub
Klubup
• Liste des services
ServicesKlub SF2 Mysql
Search Silex SOLR
Pics Silex -
Register NodeJS Redis
Provider NodeJS -
Metrics GO Logentries
Notification PHP Iron.io Firebase
ApplicationsFront Backbone
iOS ObjectiveC
Android Java
Mirador SF2
Twitter streaming MeteorJS
GraphManager MeteorJS
Pourquoi ?
• Appli monolithique de 60 Bundles
• Mobile
• Application full Javascript
• Optimisation des dev Back/Front
Bon candidat à un service
• Scope fonctionnel délimité
• Datastore spécifique
• Bootstrap d’un nouveau fonctionnel
• Nouvelle techno
Mauvais candidat à un service
• Data existante
• Transactionnel
• Nano service
• Nouvelle techno
Quelle techno pour mon service ?
• Compétences
• Productivité
• Performance
• Evolution de techno
Communication
• HTTP : Universel
• API REST JSON : Universel, Simple
• Consommation directe
• Consommation encapsulée via un service
Gestion d’erreurs
• Accepter
• Criticité
• Front
• Back
Sécurité
• OAuth2 pour les applications
• OAuth2, Hawk et réseau privé pour les services
• OAuth2 pas adapté entre les services
• HTTPS
Transactionnel
• Pas de gestion de transaction cross services
• Seulement au sein d'un service
• Accepter l’erreur pour éviter les transactions
Monitoring / Reporting
• Basé sur les log avec Logentries
• RequestId pour regrouper les logs
• UserAgent des applications et des services
Monitoring / Reporting
• Basé sur les log avec Logentries
• RequestId pour regroupé les logs
• UserAgent des applications et des services
Scalabilité
• Isolation
• Horizontalement / Verticalement
• Séparation API Lecture / Ecriture
• Concurrency des workers
• Humaine : 1 team / 1 service
Performance
• Rendre la main le plus vite possible au front
• Difficulté de la parallélisation en PHP
• Limiter les rebonds entre les services
• Latence HTTP
• Traitement asynchrone
Asynchrone
• Iron.io SAAS : IronMQ & IronWorker
• Callback HTTP
• Messaging avec workers
• Généralisation des messages sur toutes les API
Iron.io
Cache
• Pas de cache au niveau applicatif
• Séparation /public/* et /private/*
• Public : Cache HTTP via Varnish
• Private : pas de cache pour l’instant
Infra
• Provisionning avec Chef OpsCode
• VM via OpenVz
• Autonomie des deploy Applications/Services
• Impact nouveau service / nouvelle techno
Conclusion
• Composant
• Orienté métier
• Approche produit
• Décentralisation
• Infrastructure automatisée
• Gestion des erreurs
Conclusion
• Couplage : Applications, Services, Infra
• Bootstrap rapide
• Industrialisation et refactoring douloureux
• Ouverture du code
• Setup et debug compliqués
Next Step ?
• Baptême du feu à la charge
• Rationalisation
• Industrialisation
• Docker
Merci
Recrute sur ParisRecrute sur Lyon