qu'est-ce que la «dégradation gracieuse»?

J'entends beaucoup parler de ce terme de "dégradation gracieuse".

Par exemple ,

 "An application server should gracefully degrage when it is under heavy load "

  "Graceful degradation of user interfaces.... "

Le terme me semble abstrait. Un exemple concret de ce que cela signifie?

Voici quelques exemples:

• Si vous manquez de ressources (poignées, sockets, mémoire, espace disque), vous ne plantez pas, mais vous continuez à servir autant d'utilisateurs que vous le pouvez avec vos ressources disponibles. Quelque chose qui ne se dégrade pas gracieusement peut simplement cesser de fonctionner lorsqu'il est sorti de l'enveloppe de conception.
• Sous des charges plus lourdes que ce que vous avez conçu pour les utilisateurs, la réponse sera plus lente que celle pour laquelle vous avez conçu. Sans dégradation gracieuse, le fait que le système cesse de fonctionner une fois les exigences dépassées peut être acceptable.
• Conditions d'erreur, telles qu'une défaillance du lecteur de disque, une défaillance dans un cœur de processeur, une défaillance de la mémoire. Un système conçu pour se dégrader gracieusement peut continuer à fonctionner dans un mode réduit (par exemple sans être en mesure d'accéder aux données sur le disque défectueux mais toujours de fournir des données à partir du disque qui n'a pas échoué) tandis qu'un autre plantera simplement.

Les applications qui ont un mode «dégradé» offrent généralement l'accès à un ensemble limité de fonctionnalités en raison d'un problème interne ou externe. Par exemple, imaginez que votre application se connecte à deux sources de données différentes. Si l'un d'entre eux échoue, il pourrait toujours être possible de continuer à fonctionner, mais de désactiver toutes les fonctionnalités visuelles (ou / et backend) liées à la ressource non disponible.

Exemple concret: votre application dispose de deux sources de données, dans l'une d'entre elles vous stockez des personnes, dans l'autre vous stockez des comptes. Même si la base de données des comptes échoue, si l'application a un mode dégradé, vous devriez toujours pouvoir créer de nouvelles personnes, sans interagir avec leurs comptes.

En ce qui concerne l'interface utilisateur, cela signifie généralement que vous indiquez clairement à l'utilisateur que certaines fonctionnalités sont désactivées et que vous affichez un message d'avertissement afin qu'il ne soit pas laissé de côté pour expliquer pourquoi quelque chose n'est pas disponible.

En outre, il existe une entrée Wikipédia relative aux systèmes tolérants aux pannes .

Avec l'avancement de la technologie, nous avons toujours des changements qui se transforment en une application qui, à tout moment, peut ne pas être prise en charge par tous les publics cibles. Dans de tels scénarios, nous rencontrons une dégradation Graceful qui émule que nous construisons pour le meilleur disponible, mais nous avons également une sécurité intégrée pour ceux qui n'ont pas mis à niveau ou leur système peut ne pas prendre en charge.

Un exemple majeur est la <img>balise qui a l' altattribut qui est utile dans les cas où les images sont bloquées ou désactivées, maintenant celles-ci donnent un contexte significatif pour les images (bien sûr seulement si nous spécifions).

Eh bien, un autre exemple auquel je peux penser est celui des feuilles de style en cas d'erreur ou d'indisponibilité, le navigateur fournit une version générique qui lui est propre pour afficher / afficher la page.

Maintenant, comme vous l'avez mentionné, vous devez soigneusement définir un plan comme ce qui doit être fait si vos hits dépassent le seuil, vous désactivez certaines fonctionnalités ou suspendez certains services qui ne sont pas critiques et vous donnez une pause. Tout cela vous aidera à mettre en place une dégradation gracieuse afin que l'utilisateur sache en raison des x choses que le serveur pourrait prendre un certain temps pour répondre ou le service x serait indisponible pendant environ une heure

Cela signifie que les entrées et l'état dépassant les limites de conception, les sorties restent aussi raisonnables et fiables que possible.

S'il s'agit d'un serveur conçu pour gérer 100 connexions simultanées, il ne tombe pas en panne ou ne commence pas à renvoyer des résultats fous à 101 ou même 150 connexions - il ralentit ou peut-être abandonne quelques connexions, mais continue principalement de fonctionner. S'il s'agit d'une base de données conçue pour gérer 1 milliard d'enregistrements, elle ne ralentit pas soudainement à un état inutilisable à 1,01 milliard.

Si vous n'avez pas de système graphique (comme aucun serveur X11 en cours d'exécution), votre programme devrait au moins fournir une CLI, comme ncurses.

vi a un mode stupide dans lequel il se comporte comme ex, si le terminal a trop peu de fonctionnalités.

Lors de la création d'applications Web, une dégradation gracieuse entre en jeu lorsque votre site s'appuie sur JavaScript ou Flash ou sur des techniques similaires que l'utilisateur n'a pas ou désactivées.

Ensuite, vous devez toujours fournir certaines fonctionnalités de base avec HTML uniquement ou au moins un message expliquant pourquoi le site ne fonctionne pas comme prévu.