Patterns pour haute dispo et scalabilité d’une appli web – Partie VI

Utilisation des caches

Le cache est sans doute l’outil le mieux connu des développeurs et certainement le plus répandu. Il faut dire que l’efficacité est très grande et la mise en œuvre vraiment très simple. Il existe très peu de sites web qui se passent de cache et dans ce cas c’est probablement une erreur.

Mais avant de se lancer il y a tout de même un petit fond culturel utile à connaître:

• Définition d’un cache
• Mécanismes fondamentaux
• Pattern cache-aside
• Cache local, cache distribué
• Création de cache maison
• Redis
• Accélérateur web
• Quelques mauvaises pratiques

Patterns pour haute dispo et scalabilité d’une appli web – Partie V

Gérer les pannes matérielles

Le chapitre précédent nous a appris quelques stratégies adaptées au cas de pannes transitoires, c’est à dire qui vont se résoudre d’elles-même.

Mais il peut arriver que le problème soit plus sérieux ou en tout cas prenne beaucoup de temps à se résoudre, des heures plutôt que des minutes. Les stratégies de réitération, même avec un disjoncteur, n’est peut être pas la solution la plus adaptée.

 

Peut t’on protéger mieux l’application contre ce problème?

Je vais aborder deux solutions possibles:

1. la redondance matérielle
2. Le découplage des modules
3. Usages d’une queue

Patterns pour haute dispo et scalabilité d’une appli web – Partie IV

Maîtriser les pannes transitoires

Les applications modernes sont construites à partir d’un certain nombre de briques, de modules, plus ou moins indépendants et en interaction permanente.

La question que je vais aborder est celle de savoir ce qui se passe si un de ces modules a une défaillance. La défaillance peut venir du module lui-même ou bien de sa connectivité. Savoir ce qui se passe, mais surtout quelles stratégies peut t’on mettre en place pour limiter les impacts pour votre client en souplesse et si possible de façon transparente.

Les points abordés dans cet article:

• Erreurs transitoires ou permanentes
• Pattern de réitération (transient fault handling pattern)
• Pattern du disjoncteur (circuit breaker pattern)
• Mise en œuvre pratique
• Considérations pratiques

Patterns pour haute dispo et scalabilité d’une appli web – Partie III

L’architecture CQRS

Poursuivons avec l’architecture CQRS.

CQRS fait partie de ces patterns émergeants pas encore très connus, mais je crois promis à un certain avenir d’autant plus que souvent on le rencontre par hasard sans savoir qu’il y a une architecture!!!

Soyons tout de même clair, la littérature disponible n’est pas encore à la hauteur de ce qui existe pour les architectures traditionnelles. Beaucoup de questions sont encore débattues.

Je me garderai bien d’intervenir dans un débat où je ne me sens pas l’épaisseur suffisante, mais si j’ai réussi à vous faire comprendre de quoi on parle et l’intérêt de CQRS, le but est atteint!

Patterns pour haute dispo et scalabilité d’une appli web – Partie II

Exploiter l’asynchronisme

Un thread est occupé lorsqu’il exécute du code. Cela ne signifie pas qu’il soit réellement utilisé. Il peut être en attente pour une des raisons suivantes:

1. Le code effectue des manipulations de données en mémoire, il est en attente qu’une CPU devienne disponible.
   On parle de code lié à la CPU (CPU-bound)
2. Le code est en attente d’une requête vers un composant situé en dehors de son process, il est alors I/O bound.

Ces situations ne sont pas très favorables car si le thread ne travaille pas, il n’est pas pour autant disponible pour d’autres tâches.
Une meilleure situation serait de le recycler en attendant que la cause du blocage se résolve.

Les techniques d’asynchronismes permettent d’organiser ce recyclage. Toutefois, l’asynchronisme a un coût. De plus, dans la mesure où le nombre de CPU est tout de même très limité sur un serveur, la mise en oeuvre de code asynchrone est surtout pertinente pour du code I/O bound.

Patterns pour haute dispo et scalabilité d’une appli web – Partie I

Les bases

La scalabilité et la disponibilité d’un site web sont des critères d’importance pour en assurer le succès. Je pense que tous les développeurs un minimum expérimentés connaissent un certain nombre de bonnes pratiques. La plupart du temps elles ont été acquises expérimentalement.

Je voudrai montrer à travers cette série d’article qu’il existe des moyens plus organisés de monter en compétence rapidement sur ce sujet. Des patterns existent, une littérature importante est à notre disposition. Je vais essayer de vous en donner un aperçu pratique.

 

Cet article est un article d’introduction à la série. je vais y développer:

• Le vocabulaire
• Le cadre de cette présentation, les bases techniques
• Présentation du projet de démo

L’origine du système de noms de domaine

C’est la traduction d’un article que vous pouvez lire en VO ici:

https://blog.cdemi.io/origins-of-the-domain-name-system/

Je remercie l’auteur, Christopher Demicoli, de m’avoir autorisé à réaliser cette traduction. J’espère ne pas avoir fait trop d’erreurs!