Upload
xavier-gorse
View
9.827
Download
4
Embed Size (px)
DESCRIPTION
A travers un retour d'expérience sur le projet Klubup.com, nous explorerons une architecture applicative est basée sur les Micro Service, avec des API REST exploitées par les applications web principales (Symfony/BackboneJS), par les applications mobiles ( iOS et Android), mais aussi des petites applications métier basé sur d'autres techno comme Silex, Meteor ou NodeJS. Nous aussi aborderons la problématique d'authentification (Oauth), la gestion asynchrone via la solution Iron.io, mais aussi la partie infra avec la virtualisation, le provisionning avec Chef et la gestion des logs avec Logentries.
Citation preview
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