• se caractérise un microservice • définir la taille et le périmètre d’un microservice • évaluer les risques d’une telle architecture • développer et surveiller un micro service avec Spring Boot • l’enregistrer dans Zookeeper à l’aide de Curator • le déployer avec Ansible • utiliser la stack Netflix pour le rendre plus robuste avec Hystrix • le tester avec WireMock
• Chez Ippon depuis 2013 • Code en Java depuis 2000… • Microservices addict • @stephlag Olivier Revial • Développeur • Chez Ippon depuis 2013 • Code en Java depuis le berceau • @PommeDouze
de recherche d’un site de e- commerce (mais confidentiel) • Création d’une architecture de microservices pour alimenter, interroger et monitorer les composants du moteur de recherche • Projet multi plateformes et multilingue (multi tenants) • Démarrage en début d’année, déploiement toujours en cours
Hétérogénéité des langages – Multiplication des frameworks – Diversité des solutions de stockage SQL & NoSQL • Évolution des patterns d’architecture – Stateless Services – API Web (REST / HTTP) - voir conférence de David Martin (Ippon) – HATEAOS – CQRS – Asynchronisme (“Relax”)
à la demande – Sujet à des pannes et/ou des latences – En remplacement ou en relais de l’infra “historique” • Containerization - Docker – Génération de containers – Déploiement sur toutes les plate-formes du même livrable – Isolation des ressources • Provisioning - Mesos, Kubernetes – Auto provisionning de ressources en fonction des besoins – Voir la conférence suivante sur Kubernetes...
en Mars 2012 à Krakow intitulée Micro-services - Java the Unix Way “This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.”
monolithique déploie toutes ses fonctionnalités dans un seul ensemble… Une architecture de microservices isole chaque fonctionnalité dans un service dédié... … et assure la scalabilité en distribuant ces services sur les serveurs, répliquant si nécessaire. … et assure la scalabilité en répliquant cet ensemble sur plusieurs serveurs.
Java embedded jetty, tomcat, undertow – Facile à tester (HttpUnit, WireMock), rapide à lancer • Packagé comme un jar exécutable • Installable comme un simple service Linux • Déployable de façon autonome et en continu • Utilise la source de données qui lui convient (sa propre base?) • Doit pouvoir fournir les informations sur son état (monitoring) • Communication via HTTP
limitée – généralement un business case (domain driven design) – “Small enough to fit in your head” James Lewis again… – assez petits pour être jetables (réécriture plutôt que maintenance) et donc faciles à remplacer – dérogations à la règle DRY (Don’t Repeat Yourself) • Il peut y avoir du code commun mais utilisé en tant que librairie embarquée – Pas de microservice de persistence! – Pas de code “métier” dans les librairies
• Organiser les équipes pour se conformer à la “loi de Conway” – microservices = microteams • Besoin d’une usine logicielle fiable et complète – Tests automatisés et qualité de code à assurer • Complexité supplémentaire de déploiement et de surveillance • Construction d’API compatibles (versionning) • Tolérance aux pannes
exécutable avec container web embarqué • Fournit un ensemble de “starters” permettant d’utiliser les fonctionnalités issues du framework Spring • Permet de surcharger la configuration par défaut selon les besoins • Pas de configuration XML, pas de génération de code • Auto reload des classes (avec l’IDE) • Démarrage rapide facilitant le développement • Une boîte à outils pour créer des microservices
en production (objectif DevOps) – health - permet de savoir si une instance est up – info - infos générales de l’application – metrics - nombre d’appels, performance du dernier appel – mappings - urls accessibles – beans - les infos du container Spring – env - toutes les variables d’environnement – shutdown - désactivé par défaut (!) – ...
par SolrCloud et installé sur nos serveurs • Système léger et robuste si bien installé • Éprouvé par l’utilisation intensive de SolrCloud • Fournit des solutions pour la programmation distribuée • Utilisation via Apache Curator (initialement projet Netflix)
avec SolrCloud) • Utiliser la classe ServiceProvider pour récupérer des instances de services. • Bien conserver les erreurs pour ne pas router les appels vers des instances de services KO • Zookeeper est un système CP, c’est donc un point faible de l’architecture. • Nécessite une surveillance (Exhibitor mais qui a besoin… d’un autre Zookeeper) • Nous allons utiliser nos propres instances de ZK pour les services (isolation des responsabilités)
• Pour démarrer en Json • Versionning des services • Pour assurer la compatibilité des services, la portabilité – Protobuf – Thrift • Pour plus d’infos suivre la conférence suivante de David Bruant “JSON c'est nul. Parlons de binaire et protocol buffer”
stephlag
pfn
odashi
.png){kind=avatar}
codatum
occhi
puhitaku
rfdnxbro
kaminashi
masakiokuda
riyaamemiya
teamlab
ishikawa_satoru
nttcom
eileencodes
mayunak
codingconduct
eitanlees
caitiem20
techseoconnect
rasagy
sabderemane
andyhume
thirion
greggifford
marktimemedia
