Ingénierie des Architectures Logicielles · fiche contrôleB. Vella (base N. Ferry, G. Rocher) · cours 1 à 7, hors SOAP/REST · exemples : notre projet e-santé

Définition : la compréhension partagée par les développeurs experts de la façon dont le système est découpé en composants et dont ils interagissent par des interfaces. Seuls les éléments structurants, compris de tous, en font partie.

Propriétés : répond aux besoins utilisateurs · peut suivre un style · n'est pas figée · influence l'organisation de l'équipe et inversement · décrit le travail à faire · facilite la communication, la réutilisation, le repérage de ce qui va varier.

Ces attributs sont liés et parfois contradictoires → architecture = compromis.

Pour un flux de données similaires (capteurs) : source (produit) → filtres (traitements) reliés par des canaux (souvent unidirectionnels) ; le pipeline orchestre le tout.

Risques : désordre, échec d'un traitement, perte, double traitement → quelles garanties veut-on ?

Apache Storm : topology (graphe complet), spout (source : Kafka, API, capteur), bolt (étape), grouping (partitionnement), stream (suite de tuples).

TP1 séismes USGS : QuakeSpout → CsvSplitBolt (shuffle) → FormatBolt (fields « place »). Même chose en Node-RED : inject → http → csv → function → worldmap.

Lambda architecture : un système réel combine plusieurs styles. Ex. une couche batch (recalcul exact sur tout l'historique), une couche speed (stream, résultat approché immédiat), une couche serving qui fusionne.

Couches fonctionnelles : présentation · métier · persistance · base. Chaque couche peut englober plusieurs composants, forme une abstraction, ne parle qu'à ses voisines.

Fermée : accès aux seules couches adjacentes · ouverte : la couche peut être contournée. Transverses (sécurité, monitoring) : présentes dans plusieurs couches.

Sinkhole anti-pattern : des couches qui ne font que relayer la requête.

Tier = unité de déploiement séparée, avec du réseau entre tiers · layer = séparation logique. Chaque tier est serveur pour celui du dessus, client pour celui du dessous.

Dans un pipeline, l'émetteur doit connaître le canal, la suite du traitement, et chaque nouvelle équipe intéressée → couplage fort et dépendance organisationnelle.

En EDA, le producteur annonce qu'il s'est passé quelque chose (événement) ; les intéressés s'abonnent et réagissent (Publisher-Subscriber). Composants qui ne se connaissent pas (space decoupling) et n'ont pas à être présents en même temps (time decoupling).

Ordre : stocker les messages (FIFO, LIFO, FEFO ; par id, clé, partition) · plusieurs consommateurs en parallèle cassent l'ordre global → partitionner : ordre garanti dans une partition.

Auto ACK (défaut, dès réception) : prouve la réception, pas le traitement. Client ACK (manuel, après traitement) : permet de distinguer les erreurs.

Selon l'erreur : retry immédiat · retry avec délai · nombre max · Dead Letter Queue · émettre un événement d'erreur.

Crash entre l'update DB et l'envoi de l'événement : base d'abord → événement jamais envoyé ; événement d'abord → la base ne le reflète pas. Incohérent dans les deux cas.

Solution : écrire la donnée métier et la ligne d'outbox dans la même transaction ; un relay lit l'outbox et publie. L'enregistrement est atomique ; le relay peut crasher entre l'envoi et le marquage → at least once.

Léger (un id) : petit, mais le consommateur rappelle un service → couplage. Lourd (Event-Carried State Transfer) : autonome, mais données dupliquées, possiblement obsolètes.

Sémantique : {"temperature": 39,5} ne dit ni l'unité, ni ponctuel ou moyen, ni brut ou arrondi → celsiusTemperature ou champ unit.

Métadonnées : type, id, partition ou corrélation, date, version (la donnée n'est pas une métadonnée).

Évolution : 15 consommateurs de name dans 6 équipes → versionner ne suffit pas, préférer les changements backward-compatible (ajouter un champ, ne pas en renommer).

MQTT : pub/sub léger pour l'IoT et les objets peu puissants. Topics hiérarchiques pays/region/cp/maison/solarEnergy. Wildcards : + un niveau (france/paca/+/house42/solarEnergy), # tous les niveaux, en fin (france/paca/#). Gère la QoS : 0 at most once, 1 at least once, 2 exactly once.

TP2 Mosquitto local (2.x : listener 1883 + allow_anonymous), Node-RED, monitoring CPU/mémoire multi-machines avec alarmes.

Monolithe = application déployée d'un bloc (pas « tout dans un fichier »). Avec des frontières internes propres : monolithe modulaire.

Limites quand : un module change chaque semaine et un autre une fois par an (on redéploie tout) · un seul module est chargé (on duplique tout).

Micro-service : application déployable indépendamment, autonome (réseau), avec une capacité métier cohérente (pas forcément 1 pour 1 avec le DDD).

Principes : responsabilité métier unique (pas forcément « micro ») · domaine délimité (bounded context) · couplage faible obligatoire, sinon distributed monolith · contrat d'API versionné.

Avantages : passage à l'échelle et ressources par service · résilience (une panne isolée, redémarrage seul) · équipes et technos indépendantes, seule contrainte le contrat.

Coût : un appel de fonction (réussit ou lève une erreur) devient un appel réseau qui peut réussir, échouer, ne jamais répondre, réussir très lentement, réussir mais perdre la réponse, être traité plusieurs fois. On échange de la complexité interne contre de la complexité distribuée.

Données : base commune = gros couplage · base par service = transactions multi-domaines difficiles → SAGA (chorégraphie ou orchestration, avec actions de compensation) → cohérence éventuelle.

1. Transitoire ? Retenter : 429, 5xx sauf 500 et 520 (503, 504). Inutile : 4xx sauf 429, 500, 520, crash.

2. Timeout (par appel et par flow, calé sur les délais normaux) · trop court : un appel lent devient un faux échec et un retry qui surcharge · trop long : threads, sockets, connexions bloqués.

3. Retry si le service est idempotent (idempotency-key dans la requête) · surcharge probable : exponential backoff + jitter (aléa, évite les vagues synchronisées) · savoir s'arrêter : retry limit (par requête), retry budget (par service et par unité de temps).

4. Circuit breaker si la panne est avérée (retenter gaspille) :

Décision sur : taux d'échecs, taux d'appels lents, fenêtre glissante, nombre minimal d'appels. Ouvert : protège le service malade et économise le client (fail fast). Semi-ouvert : reprise contrôlée, pas 50 000 clients d'un coup. Ciblé, jusqu'à un breaker par opération.

Monitoring : grandeurs choisies à surveiller · observabilité : capacité à comprendre l'état du système à partir de ses données. Trois signaux :

Logs (événement discret) : centralisés, requêtables (format fixe), rattachables à un flow (id propagé). Piège : trop en faire (un rapport d'étudiant : 3,45 To/an gagnés sur 10 logs).

Métriques (agrégées dans le temps) : compteur (croît, on lit son taux), gauge (instantané), histogramme (distribution). Requêtes : RED = Rate, Errors, Duration ; + Saturation = 4 golden signals de Google. La moyenne cache la tail latency (regarder p99).

Traces : parcours d'une requête, faites de spans (début, durée, statut, opération), liées par context propagation (traceId, spanId, parentId).

Service mesh : retries, timeouts, sécurité, réseau, observabilité ne sont pas du métier et on ne veut pas les recoder dans chaque service → couche d'infrastructure dédiée.

Data plane (sidecar) : un proxy par service qui accepte, route, répartit, mesure, chiffre, retente. Control plane : la configuration qu'il applique (routes, certificats, retry et timeout, load balancing, contrôle d'accès).

Boîtes et flèches pour commencer ; UML est un standard mais pas obligatoire (autres approches : OASIS, C4).

C4 = zooms successifs sur le même système. Les vues architecturales montrent des aspects différents : logique (sous-systèmes groupés), déploiement (infra, dépendances), implémentation (composants et responsabilités), runtime, sécurité.

Titre (la décision) · Contexte (problème, besoins, contraintes, date) · Options envisagées · Décision et pourquoi · Conséquences (avantages, inconvénients, risques) · Statut : Proposed, Accepted, Deprecated, Superseded.

Bonnes pratiques : court et clair · pas pour chaque micro-décision · écrit au moment de la décision · garder les alternatives rejetées · versionné.

Exemple projet. ADR : Kafka derrière MQTT. Contexte : objets peu puissants, plusieurs consommateurs internes, rejouer un flux, ordre par patient. Options : MQTT seul, RabbitMQ, Kafka. Décision : MQTT pour les objets (léger, QoS, Last Will), Kafka en interne (partitions par patient, rétention, consumer groups). Conséquences : + rejouable, scalable par partition ; − un bridge et un broker de plus à opérer. Statut : Accepted (RabbitMQ abandonné).

Migrer = remplacer une techno par une autre · moderniser = améliorer l'adéquation du système à ses besoins et contraintes (pas forcément tout réécrire : retirer une dépendance, isoler un module).

Quand ? Pas l'âge (vieux = équipe formée, CI rodée, besoins satisfaits). Quand il y a inadéquation entre capacités et besoins actuels ou futurs : dépendances non maintenues, maintenance hors de prix, compétences rares. Une migration coûte cher, on ne la fait pas pour rien.

Architecture archeology : on veut le système as-built, pas as-designed (la requête SQL directe non documentée d'il y a 7 ans). Analyse métier (spec, experts), statique (code, dépendances, requêtes DB, CI/CD, tests), dynamique (logs, traces, trafic).

Par blocs : 1 partir des problèmes, pas des solutions (« pas de micro-services » n'est pas un problème ; « l'équipe ne peut pas déployer seule » en est un) · 2 hotspots : dette × forte activité (historique git, incidents, change coupling) · 3 facteur limitant · 4 prioriser coût, gain, risque, cost of delay.

Strangler Fig : façade devant l'existant, qui bascule fonction par fonction vers le nouveau système (évite le big bang : pas de retour client, risque de régression, bascule).

API : Expand-Migrate-Contract (v1 et v2 en parallèle, délai annoncé, puis retrait de v1) · tests provider-driven (l'implémentation respecte le contrat) et consumer-driven (les besoins des consommateurs restent servis), valables aussi en EDA.

Déploiement : rolling (instances remplacées peu à peu) · canary (5, 20, 50, 100 % du trafic) · dark launch derrière un feature flag + shadow traffic (parallel run, on compare). Prix : plus d'instances, de coûts, de monitoring ; rollback pas toujours possible.

Hazard : ce qui est dangereux par nature · threats (causes) · barrières préventives · top event (perte de contrôle) · barrières de mitigation · conséquences · escalation factors : pourquoi une barrière lâcherait (on peut leur ajouter des contrôles).

Cours (porte) : perte réseau de la caméra → barrière : reconnaissance faciale locale (escalade : crash du logiciel local) → top event : contrôle d'accès indisponible → mitigation : clé physique → le propriétaire entre quand même.