Meetup microservice
•Télécharger en tant que PPTX, PDF•
0 j'aime•367 vues
This is a presentation on a feedback on the architecture microservices impletation at TraxAir Music Technologies. It held at the meetup microservices paris
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (10)
Similaire à Meetup microservice
Similaire à Meetup microservice (20)
Dernier
Dernier (8)
Meetup microservice
- 2. Sommaire • Introduction • Du développement à la production • Le bilan
- 3. Sommaire • Introduction • Du développement à la production • Le bilan
- 4. Introduction • Qu’est ce que l’architecture Microservices ? • Le contexte
- 5. Architecture Microservices Transformation Lean de l’architecture
- 6. Architecture Microservices Petit Autonome Fait une chose et le fait bien Vision Business
- 7. Architecture Microservices Code sous contrôle Interface simple Interface expressive
- 8. Architecture Microservices Couplage faible Groupe de microservices
- 9. Architecture Microservices Sandbox Pas de technologie en particulier
- 12. Pourquoi les microservices Module à taille humaine
- 14. Modélisation d’un microservice Image de base La configuration L’application Composants Le script de démarrage Paramètres de démarrage
- 15. Le contexte
- 16. Le livre
- 17. Sommaire • Introduction • Du développement à la production • Le bilan
- 18. Le développement Github Flow Création de la branche (feature, hotfix …)
- 19. Le développement Github Flow Commits (développements)
- 20. Le développement Github Flow Ouverture de la pull request (Release candidate)
- 21. Le développement Github Flow Revue du code & discution
- 22. Le développement Github Flow Déploiement de la release
- 23. Le développement Github Flow Merge de la release
- 24. Github Flow Comment est utilisé github chez traxair
- 26. Le développement
- 29. Devbox Ficher compose Service_X: image: registry.com/Service_X ports: - "443:443" volumes: - Service_X/app:/app - Service_X/Service_X.env:/Service_X.env command: dev
- 33. Continuous Integration Qu’est ce qui doit être testé ? Relation d’ordre topologique sur composants connexes du graphe orienté acyclique
- 34. Continuous Integration Les tests Environnement isolé et propre • Test unitaire • Service • End to end Temps moyen d’un test 1 minute
- 35. Continuous Integration Les tests Emulation d’un microservice (stub)
- 36. Continuous Integration Le build Temps moyen d’un build • Librairie : 1 minute • Microservice : 10 minutes • Image de base : 20 minutes
- 38. Continuous Integration Code Review Qualité de code
- 41. Tutum
- 42. Gestion de la configuration
- 43. Différents types de microservices
- 44. Réseau
- 45. Production Le monitoring • Datadog, monitoring as a service • ELK, centralisation des logs et traitement
- 46. Sommaire • Introduction • Du développement à la production • Le bilan
- 47. Le bilan Les microservices, c'est bien, mais c'est difficile à mettre en place (et ça nous a ralenti).
Notes de l'éditeur
- ce meetup restera assez ouvert, il y aura : des REX sessions de discutions sur différents.
- Le terme lean (« svelte ») sert à qualifier une théorie de gestion de la production qui se concentre sur la « gestion sans gaspillage » ou encore gestion « au plus juste »4. Le lean trouve ses sources au Japon dans le système de production de Toyota ou L'école de philosophie du lean est marquée par la recherche de la performance (en matière de productivité, de qualité, de délais, et enfin de coûts)
- la granuarité du service est celle d’une fonctionnalité élémentaire, au sens métier du terme. (ex: métier interne identifier de la musique, du coup on a un microservice d’identification de musique)
- Puisque Microservice petit => le code est plus facilement gardé sous contrôle Plus facile de prendre en compte tout les cas (success + error) Les interface définisse un contrat Son interface doit être suffisamment simple et expressive pour quiconque souhaitant l’utiliser. (ex swager)
- Dans la mesure du possible, les services doivent être faiblement couplés entre eux. Il y a aura forcément des groupes de microservices et ces groupes doivent ne avoir le moins possible et doivent être le plus séparé (moins de microservices en commun)
- Microservices sandboxé => un service dispose de son propre contexte d’exécution => ce qui facilite sa mise à jour. pas de technologique a utiliser en particulier à la base (langage, framework) ni même l’architecture applicative mais il y a quand même des pattern qui apparaissent Ex: nodejs pour le backend des site web et python pour le reste les services doivent être inter-opérables
- Un microservice doit pouvoir être : Construit Testé Déployé de manière totalement isolée des autres services
- Sous estimation des moins Complexité Architecture monolithique (-) : Quand la quantité de code augmente, le code devient de plus en plus complexe Plus le projet évolue, plus il y a des interactions entre les différentes briques Multiplication des effet de bord (ex: site intranet, les mails étaient bloqués, car ajout de code sans connaitre l’ensemble du projet) Microservices (+): Contraindre la taille limite, mettre en place les cas particulier => permet d’avoir tout en tête Les interface sont mieux gérées
- Scalabilité Monolithique -: Améliorer la scalabilité d’un système peut demander de modifier des éléments important Plus le projet est gros plus l’intervention est risquées et couteuses Risque: Le système est très difficile à faire évoluer voir impossible. Micro +: Plus facile à scaler, plus ciblé
- Input output Boite noir Configuration environnement Connecter les interfaces
- Parce que c’était cool Anticipation sur les besoin de scalabilité Module à taille humaine (forcer ) Raison de performance mais discuttable
- Site à rajouter
- Swagger se veut être un standard de description d’api Pour créer un microservice rest avec swagger Fichier yaml 400 lignes +- Serverside fonction write read db Bootstrapé: Test côté serveur quasiment rien à écrire (moins de 5 lignes) Libraire client Crée une lib de test (custom tool) Code côté serveur généré sauf db Lien avec l’api gateway, peut exposer ce microservice en ayant le choix d’exposer les entrypoint (droit au get mais pas au post), caché ou pas des attribut
- Génération d’un microservices / librairie via template Génération de code OK Gestion action pre/post Pb : manque l’enregistration dans la ci, deploiement, repository d’artifact …
- Graphe avec un sens (A dépend de B) sans cycle (impossible d’avoir A -> B -> C -> A) Composant connexes, possibilité d’avoir des groupes indépendant (A -> B, C) Relation topologique c’est pour pouvoir définir l’ordre d’execution afin de savoir quel artifact est le premier, permet de classer Il y a des librairies et des microservices. Les librairies créent du doublage. Ex: Lib décodeer de l’audio crée du couplage Lib Mettre des fichier sur des buckets Obliger de gérer les ordres dans lesquels ça tournent Les microservices dépendent de container de base Il y a un couplage au niveau docker
- End to end on test que les happy
- Grâce à swagger on peut générer des test de façon automatique, on peut directement tester des lien entre les microservices au niveau des test unitaires http-pretty (lib) catch les requetes hhtp et renvoient une réponse avec les données attendu Réduire le nombre de test end-to-end Après un test on build l’artefact
- Tout les test et builds sont parallélisés nombre de lib : 40 Nombre de microservice : rest: 12, message queue: 20
- 50k lignes de code Complexité moyenne par ligne 10/100 La plupart du code est testé à plus 80 %
- Screenshot Pas de vu big computer (explication du big computer) Tutum permet d’avoir un parc de serveur
- Lorsqu’un conteneur démarre en mode production, il va interroger : Etcd Recupérer des clef valeur Les mettre en variable d’envrionnement
- Rest haproxy pour la gestion des ports tcp Message queue pas de réelle gestion mise à part avoir l’adresse de la message queue
- Mobify http requests are hard (blog) Lors d’une communication via le réseau par exemple HTTP, beaucoup de choses peuvent mal de passer comme : Timeout de la requete Le serveur a planté Un cable a été sectionné L’api a une limitation du nombre de requete DNS / mauvais contenu / … Le but est de prévoir comment éviter un maximum c’est erreur Comment gérer ce genre de problème: Avoir un système qui log l’erreur afin de la comprendre Un système de retry qui s’étale sur le temps Tcp keep alive a activé dans les lib et service Fonctionnalité optionnelle qui se repose sur un système d’envoie de paquets réseau afin d’éviter que le lien soit cassé Retry pour certains services
- C’est un des obstacle conséquent mais on peut se débrouiller quand il n’y pas beaucoup de microservices
- Penser que tout fonctionne sans problème voir design for faillure : http://blog.octo.com/design-for-failure/ Qu’est ce qu’on a fait qui n’était pas bien: Trop de microservices au début Trop micro On a pas eu le temps de faire le montoring On a du faire une ci robuste plus rapidement Ce qu’on recommande Partir du monolithique puis découper petit à petit (baby step) Commencer à mettre en place tout les concepts parlés précédemment Mise en place d’automatisation Faire des microservices force à avoir un esprit plus continuous delivery car plus de déploiement. Force à avoir des best practices rapidement. On a fait des erreurs mais on reste content de ce qu’on a fait et ça a finit par marcher malgrès des difficultés.