Architectures microservices

• Les architectures Monolithiques
o Définition
o Limites
• Les architectures Microservices
o Définition
o Patterns de migration
o Patterns de découpage
o Différentes topologies
o Pattern SAGA
o CQRS / Event Sourcing
o Cross cutting concerns
o Devops & Infra
o Bénéfices
o Challenges à relever

Transcript

1. Architectures microservices Romain Schlick @r_schlick Riadh Mnasri @riadhmnasri 23/01/2019
2. A Propos de nous Romain Schlick @r_schlick • Dev Java 12 ans • Scrum Master • Intéressé par: TDD, DDD, qualité, NoSql, JS, Agilité Riadh Mnasri @riadhmnasri • Dev Java Kotlin • Intéressé par le clean code, functional Programming, TDD, ATDD, BDD, DDD
3. Monolithes vs Microservices Monolithe Microservices No silver bullet
4. Il était une fois … un Monolithe magnifique
5. Monolithe: Définition Tomcat • Une seule unité d'exécution • Composants fortement couplés • Cadence de release long: > 3 mois • Equipe assez grande > 10 pers Browser MySQL Database WAR / EAR Store Front UI Catalog Service Inventory Service Shipping Service
6. Monolithes: Problèmes
7. Collaboration difficile Quand l’application grossit … plusieurs équipes se marchent sur les pieds
8. Testabilité lente et douloureuse
9. Déploiement long et risqué
10. Innovation rendue difficile
11. Difficilement scalable Titre de la présentation - Date
12. Monolithe: Peut être une bonne solution • Approche Monolithe First • Solution parfois la plus adaptée: • équipe reste petite • time to market • clean code • livraison rapide
13. Architecture microservices: Définition
14. Architecture microservices: Exemple
15. Patterns de migration: Big Bang • Très long à développer • L’existant bouge en même temps • Plus compliqué et risqué !
16. Patterns de migration: Strangler Pattern REQUEST ROUTER Micro- Service shipping WEB API WEB API GLUE CODE GLUE CODE Old HTTP requests New HTTP requests HTTP request
17. Comment découper les microservices ?
18. Découper par département métier • Décomposer en sous-domaines • Un bon point de départ • … mais assez limitant et peu créer des dépendances
19. Découper par objectif (verbe d’action) • Chaque domaine a un objectif • Faire des interviews avec tous les acteurs (définir des patates) • Exemple: Shipping, Billing, Recommandation, Navigation, Searching
20. Découper selon une contrainte technique forte • Haute volumétrie vs faible volumétrie (BD NoSQL/Relationelle) • Focus Lecture vs Ecriture (CQRS) • Calcul rapide vs exact (finance de marché)
21. Découper par Bounded context (DDD) • Ubiquitous langage • Bounded Context • Aggregate root • Repository • Domain Service
22. Découper par Bounded Context
23. Event Storming Pratique très intéressante pour identifier les contextes bornées
24. Différents patterns d’architecture Exemples : Comment gérer la communication entre les MS ? Comment accéder aux données distribuées ? Comment assurer la robustesse ? Pattern = Solution réutilisable répondant à une problématique
25. 1 DB by Service / public API / synchronous communications Customer Service Domain Store API Gateway (sécurité, routing, query multi-services) REST API REST API Order Service Domain Store REST API Browser CreateCustomer() findCustomer() CreateOrder() findOrder() findOrdersForCustomer() findRecentCustomers() Mobile App Store Front UI HTML REST REST Load balancing Circuit breaking Service discovery « Back-end for front end »
26. 1 DB by service / Async messaging / commands & events Customer Service Domain Store Aggregator Service REST API REST API Order Service Domain Store REST API Mobile App findCustomer() findOrder() findOrdersForCustomer() findRecentCustomers() View Store Message Broker Customer created event Credit reserved event Order created event Order canceled event Subscribe to events reserveCredit command createOrder command
27. CQRS pattern: Command Query Responsability Segregation • Séparation des composants d’écriture (« command») et de lecture (« query ») • Solution alternative au CRUD • Write: Opérations sur un modèle métier (DDD) • Query: Vision aggrégée des objets mis à jour via des events • Query: Eventual consistency Permet: • Solution pour requêter des données cross-services • Meilleure isolation des responsabilités • Différentes technologies • Writing DB != Reading DB
28. Message broker CQRS pattern: Schéma Customer Order History Service SQL DB Commands channel Events channel createCustomer reserveCredit createOrder cancelOrder REST API Customer Geo Loc Service MONGO DB REST API QUERIES COMMANDS Customer Service SQL DB Order Service SQL DB Order created Order canceled Customer created Credit reserved Subscribe to events Query store Query store Domain Store Domain Store
29. Collaboration entre microservices • Comment peuvent collaborer les microservices ? • Comment implémenter une transaction distribuée ? • Comment maintenir la cohérence des données distribuées ? Titre de la présentation - Date Transaction distribuée 2PC à proscrire Solution = SAGA PATTERN
30. SAGA pattern: Séquence de transactions locales CreateOrder() SAGA Order Service Local transaction createOrder() Order State = PENDING Customer Service Local transaction reserveCredit() Customer Order Service Local transaction approveOrder() Order State = APPROVED
31. SAGA: Transactions compensatrices CreateOrder() SAGA Order Service Local transaction createOrder() Order State = PENDING Customer Service Local transaction reserveCredit() Customer Order Service Local transaction cancelOrder() Order State = CANCELLED InsuffisantCredit !!!!
32. Message Broker SAGA: Events Choregraphy pattern • Prise de décision distribuée • Coordination basée sur des messages « events » • Chaque service va écouter les évènements et faire avancer le workflow Order events channel Customer events channel Customer Service Order Service Order created Credit reserved OR Credit Limit Exceeded Order State Total Customer creditLimit creditReservations reserveCredit() create() Approve() / reject() Listen Order events Listen customer events
33. Message Broker SAGA: Command / Reply Orchestration pattern • Prise de décision centralisée par un Orchestrateur • Coordination basée sur des messages « command » et « reply » • Objet persistant qui traque l’état de la SAGA et invoque les MS Customer command channel Saga reply channel Customer Service Order Service ReserveCredit Credit Reserved Orchestrator
34. Comment assurer l’atomicité du changement d’état en base et l’envoi de l’event associé ? Titre de la présentation - Date
35. Event sourcing pattern • Approche « Event driven » • Persister les objets métiers comme une séquence d’évènements • Objet métier = State change event • Rejouer les events pour re-recréer une image de l’objet • Event Store: Data Store + Message broker • Se marie bien avec CQRS Permet: • Changement d’état en base et envoi de l’event atomique • Historisation complète • Audit log + Rejouer les events
36. Event store Event sourcing pattern: Schéma Entity Id Entity Type Event Id Event type Date Event Data 101 Order 901 OrderCreated … … 101 Order 902 OrderApproved … … 101 Order 903 OrderShipped … … Event table Order state Apply(event) Order Persister l’objet comme une séquence d’events Rejouer les events pour obtenir une image de l’objet
37. Comment déployer les microservices ? • Approche Devops: • Intégration continue • Déploiement continue • Infrastructure: • Déployés dans des containers (ex: Docker) • Gestionnaire de containers (ex: Kubernetes) • Cloud privé (ex: Openshift) vs Cloud Public (GCP, AWS, Azure) • Services Mesh (ex: Istio): sécurité, load balancing, routing • Serverless
38. Serverless: C’est quoi ? • FaaS (function as a service) • « Custom code that’s run in ephemeral container in the cloud » • Cloud providers: AWS Lambda, GCP Functions, MS Functions • Les instances sont crées à la demande et détruire après le traitement • Dépend fortement de services cloud tiers • Approche events
39. Serverless: Bénéfices et limites Bénéfices • Auto scaling • Payer à la demande • Peu d’infra à gérer • Event driven • Sécurité Limites • Vendor lock-in • Taille et durée de runtime limité • Débuggage en local parfois difficile
40. Serverless: Exemple
41. Cross cutting concerns Load balacing Circuit breaking Health check Configuration Logging Service discovery Métriques Proxy / Gateway Ex: Ribbon, Apache, Nginx, HAProxy Ex: Hystrix Ex: Spring Boot Actuator Ex: Spring Cloud Config Ex: ELK, Logstash, Splunk Ex: Consul, Eureka Ex: Spring Boot Actuator Ex: Zuul, Spring Cloud Gateway Tracing Ex: Spring Cloud Sleuth, Zipkin, OpenTracing Messaging Ex: Spring Cloud Stream Nombreuses Initiatives: Netflix OSS, Spring Cloud, Eclipse MicroProfile
42. Bénéfices d’une architecture microservices • Indépendance – Faiblement couplé • Travailler en équipes petites, feature teams • Scalabilité • Maintenabilité • Testabilité • Plus facilement déployable • Facilite l’innovation et l’expérimentation
43. Challenges à relever Complexité: • Processus distribués • Données distribuées • Tolérances aux pannes • Déploiements • Monitoring • Nombreux cross cutting concerns • Nanoservices anti-pattern Pré-requis importants • Approche Devops impérative • Provisionning automatique
44. MERCI !
45. Références • https://microservices.io • https://www.slideshare.net/chris.e.richardson/mucon-not-just-events-developing-asynchronous- microservices • https://www.slideshare.net/chris.e.richardson/code-freeze-2018-there-is-no-such-thing-as-a-microservice • https://microservices.io/microservices/news/2018/11/07/microservices-kong-2018.html • Livre « Domain-driven Design » par Eric Evans • Livre « Building Microservices » par Sam Newman • Livre « Enterprise Java Microservices » par Kenn Finningan • Livre « Microservices pattern » par Chris Richardson • Hexagonal at Scale, with DDD and microservices! (Cyrille Martraire) https://www.youtube.com/watch?v=xZOO_CksS-E • Magazine Programmez! – décembre 2018 • https://www.martinfowler.com/bliki/StranglerApplication.html • https://github.com/kbastani/event-sourcing-microservices-example • https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/ • https://fr.slideshare.net/nikgraf/introduction-to-serverless • https://martinfowler.com/bliki/CQRS.html • https://www.codeproject.com/Articles/339725/Domain-Driven-Design-Clear-Your-Concepts-Before-Yo