👨‍👨‍👦‍👦 🦌 💬 L'architecture client-serveur en images 🔕 🛁 ⚫️

Une image familière? Mais vous êtes constamment confronté à cette architecture - lorsque vous achetez un billet de cinéma en ligne, réservez un billet pour la mer ou prenez rendez-vous avec un médecin.

Sur l'architecture client-serveur, tous les sites et services Internet sont créés. Il est également utilisé par les programmes de bureau qui transmettent des données sur Internet. Par conséquent, les professionnels de l'informatique doivent comprendre de quoi il s'agit et comment cela fonctionne.

J'en parlerai dans l'article. Je vais vous expliquer sur les doigts, avec des exemples et des images amusantes =) Si vous aimez plus le format vidéo, vous pouvez regarder ma vidéo youtube sur le même sujet.

Contenu

Qu'est-ce que c'est et comment ça marche

Nous avons ici un certain Vasya qui a décidé d'acheter une voiture. Comme dans la publicité - rapide, puissant, beau! Elle se tient juste comme la queue d'un avion, Vasya n'a pas ce genre d'argent.

Bien sûr, Vasya peut déterrer pendant plusieurs années, puis acheter une voiture. Mais vous voulez ici et maintenant! Oui, et un véhicule est nécessaire ...

Et Vasya ne sait pas comment économiser - a reçu un salaire, a acheté le principal, payé le logement, c'est tout! Le reste peut être dépensé. Pour ces personnes, il existe des banques où vous pouvez venir prendre de l'argent à crédit.

Bien sûr, vous paierez trop cher et les rembourserez. L'intérêt est le cheval. Mais maintenant, vous pouvez déjà vous permettre d'acheter quelque chose de cher.

Vasya a pensé, estimé et dit:

- Oui, je le veux comme ça! Je peux payer 100 roubles de mon salaire à la banque, mais je ne peux pas l’économiser. Je vais le dépenser.

Par conséquent, Vasya va à la banque et dit:

- Je suis Vasily Ivanov, je veux un prêt de voiture pour 1000 roubles.

Le commis Katya doit vérifier ses antécédents de crédit. Soudain, il ne peut pas obtenir de prêt, a-t-il une mauvaise histoire? Peut-être qu'il a déjà marqué 10 crédits et pas un ne paie? Ou peut-être que c'est un terroriste du tout?! Il faut vérifier que les opérateurs ne connaissent pas par cœur les listes noires.

Katya a un programme spécial pour vérifier les données client. Ce programme peut être sur le Web ou sur le bureau:

Web - ouvert dans un navigateur comme google ou facebook
Bureau - sur un ordinateur, comme un mot ou une calculatrice

Peu importe que Katya regarde le navigateur ou simplement le programme. En tout cas, ce sera un client. Le client est votre application. Celui avec lequel notre opérateur travaille.

Katya anime le programme «Vasily Ivanov» et reçoit des informations sur le client - est-il sur les listes noires? Y avait-il des antécédents de crédit auparavant? Etc. Mais que se passe-t-il dans les abats de l'application?

Katya a entré les données sur le client. Mais lorsqu'elle a cliqué sur "vérifier", la cliente a envoyé une requête au serveur:

- Donnez-moi des informations sur Vasya Ivanov!

Le serveur a envoyé une requête à la base de données, base de données:

- Sélectionnez * parmi les clients où fio = 'Vasily Ivanov'. (Donnez-moi toutes les informations sur le nom «Vasily Ivanov»)

La base a répondu:

- Voici tout ce que j'ai trouvé.

Le serveur a renvoyé ces informations au client:

Et le client l'a déjà dessiné pour Katya:

Katya regarde:

- Oui, l'historique de crédit est bon.

Et il propose à Vasya:

- S'il vous plaît, si vous voulez prendre un prêt, nous sommes prêts à allouer 1000 roubles pour 12 ans à 80% par an. Arrangé?

Vasya est contente:

- Oui, tout me convient, donne-moi plus d'argent, et j'ai couru après la voiture!
Tout le monde est heureux, tout le monde est heureux.

Katya ne sait même pas de quelle manière les données du programme l'ont fait lorsqu'elle y a conduit le nom complet de son client. Mais vous et moi devons découvrir de quel type de chemin il s'agit. Et pourquoi toutes ces difficultés? Pourquoi une telle structure? Pourquoi y a-t-il un client, pourquoi y a-t-il un serveur?

Pourquoi ai-je besoin d'un client

Ici, tout est simple: l'utilisateur travaille avec le client. Il est nécessaire de transformer les octets du code du programme en une image belle et claire. L'utilisateur n'est pas programmeur, il ne comprend pas le langage de programmation ou sql. Il comprend les moules et les boutons. Nous les attirons chez le client.

Pourquoi avons-nous besoin d'un serveur

Il est plus puissant, il

peut y avoir de nombreux clients. Dans l'exemple avec la banque, nous pouvons avoir 10 agences dans 10 villes de Russie, et chaque agence a 10 agents opérationnels. Mille Katek, et chacun a un ordinateur séparé.

Mais nous voulons que l'application fonctionne rapidement. Pour qu'il ne soit pas stupide et ne gèle pas, déroutant l'opérateur et faisant patienter le client. La voiture en a donc besoin d'une puissante. Mais si l'ordinateur de chaque opérateur est rendu puissant, vous devrez investir beaucoup d'argent!

Par conséquent, nous transférons toute la logique de base au serveur. Et maintenant, nous le faisons puissant! Et les machines clientes peuvent être bon marché, car elles n'ont qu'une logique dans le style de «demander des informations et de les rendre magnifiquement».

Pas de duplication de code

Si nous n'avions que des ordinateurs clients, chacun d'eux aurait le même code de traitement logique, la base de données entière, tous les répertoires terroristes et ainsi de suite. Mais comme le serveur et la base de données sont placés dans des liens séparés, beaucoup d'espace est libéré de la machine cliente ... Et du code.

Pas besoin de dupliquer le code, car toute la logique principale est prise sur un serveur plus puissant.

C'est plus sûr:

sur le serveur et dans la base de données sont stockées des informations inaccessibles à un simple opérateur. Il:

Données client
Informations sur ses finances
Listes noires des banques
...

Pourquoi montrer ces informations à tout le monde et à tout le monde? L'opératrice ne voit que son interface. J'ai conduit un nom complet - j'ai obtenu une réponse, un prêt ou non. Tout. Elle n'a besoin de rien d'autre.

Il y a des commis qui sont prêts à fusionner les informations client pour denyushki. Il y a des gens malhonnêtes qui sont prêts à regarder accidentellement par-dessus leurs épaules. Ou peut-être que le client lui-même est une telle personne. Imaginez, Vasya bouscule la fragile Katya, s'assoit devant son ordinateur et transfère des millions sur son compte jusqu'à ce qu'il soit immobilisé par des gardes.

Pourquoi avons-nous besoin d'une base

Quel est le rapport avec la base de données? Ici, nous avons notre serveur, même s'il stocke toutes les informations. Cela arrive, parfois la base de données n'est tout simplement pas nécessaire et nous avons toujours une architecture client-serveur à deux niveaux.

Dans ce cas, le serveur stocke toutes les données en mémoire. Mais seulement si le serveur tombe en panne, ou redémarre simplement, toutes les informations seront perdues. Tout ce qui était en mémoire est effacé lorsque le système est éteint.

DB (base de données) - un produit logiciel distinct qui vous permet de:

Récupérer rapidement des informations
enregistrer des informations même lors du redémarrage du système.

Autrement dit, si le réseau disparaît soudainement, la base se fige, la machine avec la base redémarre ou quelque chose d'autre se produit, nos modifications ne seront pas perdues. C'est ce qu'on appelle la persistance. Il est réalisé grâce à des transactions qui annulent en cas de problème. Mais dans cet article, nous ne nous pencherons pas sur ce sujet))

Oui, il peut ne pas y avoir de base. Mais quand c'est le cas, nous sommes confiants dans la sécurité des données et pouvons facilement les rechercher.

Avantages de l'architecture

Nous résumons les avantages de l'architecture:

Un serveur puissant coûte moins cher que plus de 100 machines clientes puissantes - si nous voulons que l'application ne ralentisse pas, nous avons besoin d'une bonne machine. Vous en aurez un. Ou quelques-uns, si la charge est importante, mais nettement inférieure au nombre de clients.
— , « » « , 100 ».
— . , .

Un lien est

tombé - tout le monde se repose. Si le serveur est tombé ou que la base est tombée, c'est-à-dire qu'un lien s'est détérioré - tout, tout le monde est dans la stupeur, tout le monde se repose. Des centaines, des milliers, voire des millions de clients, le cas échéant, personne ne peut travailler. Tous les officiers d'opération regardent tristement la fenêtre «Désolé, quelque chose s'est mal passé» et haussent les mains devant le client.

C'est pourquoi dans les logiciels critiques, l'architecture est compliquée et même dupliquée. Une banque avec des milliers de scrutateurs ne peut pas se permettre un temps d'arrêt. Par conséquent, ils utilisent un cluster de serveurs - l'un est tombé, le reste fonctionne.

Comment alors le client comprend-il où lui envoyer la demande?

Un équilibreur est placé devant les serveurs et le client y envoie une demande. Peu importe le nombre de serveurs placés dans le cluster, le client n'est pas intéressé. Il a une URL - l'adresse de l'équilibreur.

Et maintenant, le client reçoit une demande:

- Donnez-moi toutes les informations sur Vasya Ivanov.

L'équilibreur dit:

- Les gars, une nouvelle demande! Qui est moins chargé?

Premier serveur:

- J'ai 5 demandes dans la file d'attente.

Deuxièmement:

- Et j'en ai 2. L'

équilibreur envoie une demande au deuxième serveur.

Un tel schéma est utilisé pour une application très chargée - lorsqu'il y a tellement de demandes qu'un serveur ne peut tout simplement pas y faire face.

Facebook, amazon, google - des millions d'utilisateurs y vont. Un serveur ne peut pas les gérer. Par conséquent, ils mettent un cluster et l'équilibreur partage la charge entre eux. Et dans ce cas, dans le cluster, il peut ne pas y avoir 2 serveurs, mais 10, 15, tant que nous en avons besoin, nous en définissons autant.

Ce faisant, nous pouvons équilibrer la base de données de la même manière. Nous pouvons avoir plusieurs copies des bases de données sur une variété de machines, et l'équilibreur envoie des demandes à l'une ou à l'autre.

Ce schéma est appelé redondance d'UC - lorsque plusieurs serveurs fonctionnent en parallèle et que l'équilibreur répartit la charge entre eux.

Il peut également y avoir un système de réserve à froid - lorsque notre deuxième serveur est une sauvegarde «au cas où». Toutes les requêtes vont au premier serveur, le second reste.

Mais si quelque chose arrive au premier serveur et qu'il meurt, l'équilibreur redirigera la charge vers le deuxième serveur:

à ce stade, les administrateurs auront le temps de traiter le problème sur le serveur 1.

Le schéma de réserve à froid est utilisé lorsqu'un serveur est capable de supporter la charge et de donner une bonne vitesse. Mais l'application est critique pour l'entreprise et simplement inacceptable.

Cela peut être simple non seulement parce que quelque chose de grave s'est produit. Il y a également une mise à jour régulière de l'application. Les deux schémas de sauvegarde vous permettent de mettre à niveau sans douleur. S'il y a deux serveurs dans le cluster, la mise à jour ressemblera à ceci:

Rediriger toute la charge vers le serveur 2
Arrêter le serveur 1
Mise à jour du serveur 1
Nous le lançons et dirigeons toute la charge dessus
Arrêter le serveur 2
Le mettre à jour
Nous lançons
Répartissez à nouveau la charge (s'il s'agit d'une réserve chaude)

Autrement dit, l'application ne s'arrête pas du tout!

Ainsi, les plans de redondance nous aident à éliminer le problème «1 lien est tombé - tout le monde se repose». Le client ne saura jamais qu'un ou plusieurs serveurs du cluster sont morts, tout a fonctionné pour lui et cela fonctionne.

L'équipement de

serveur coûteux coûte cher. Là, vous ne pouvez pas mettre un SSD ordinaire pour un ordinateur personnel. Pourquoi? Étant donné que les exigences matérielles pour les serveurs sont complètement différentes pour le matériel +, il existe une prise en charge de fonctions spécifiques:

- Le disque dur a un firmware de contrôleur spécial, optimisé pour le fonctionnement du disque en RAID, ce n'est pas nécessaire à la maison.

- Le SSD a la présence d'un groupe de condensateurs qui stockent l'énergie en cas de panne de courant, de sorte qu'il y ait suffisamment de temps pour jeter les données du cache DDR dans la mémoire non volatile et que les données ne se cassent pas.

SSD - un disque à fonctionnement rapide, HDD - normal. RAID - lorsque nous avons connecté N disques ensemble et que le cache DDR est RAM

De plus, les solutions serveur ont généralement une garantie beaucoup plus longue: 5 ans, pas un an.

Pour le prix, ils diffèrent de 2 fois. Par exemple, SSD:

pour un gigaoctet à la maison coûte 16,53r
pour un concert d'entreprise de serveur coûte 32 roubles

Chiffres pour décembre 2019. C'est sinon du fer de marque à prendre, mais du fabricant.

Cela ne semble pas très différent, non? Mais le fait est que pour une maison, 1 To est suffisant pour les yeux - et tout ira dans les photos, les films et un tas d'applications ... Et pour une base de données, parfois 10 To sera petit. Et si vous créez un cluster, nous multiplions le coût par 2, sinon plus. Par conséquent, la différence de prix semble énorme, mais une fois convertie en gigaoctets, une petite sort.

N'oubliez pas qu'à la maison, il vous suffit de conserver vos photos, et même celles-ci sont généralement dans le cloud. Et sur le serveur, il y a une fonctionnalité essentielle à l'entreprise qui consomme beaucoup de ressources et qui doit être dupliquée au cas où «le premier meurt soudainement».

Besoin d'embaucher un administrateur systèmeツ

Nous devons engager un administrateur système qui surveillera tous nos serveurs d'applications et bases de données. Ajoutez son salaire au coût de l'équipement!

Que tester

Pour comprendre quoi tester, vous devez comprendre ce à quoi une personne a affaire.

L'utilisateur travaille avec un client. Cela peut être une application Web ou de bureau, pas le but. L'opératrice Kate a reçu un lieu de travail, ils ont montré quel programme exécuter et comment travailler avec. Elle ne connaît pas la disponibilité des serveurs et des bases de données, elle ne travaille qu'avec le client.

Par conséquent, le testeur vérifie d'abord le client! Parce que le serveur peut parfaitement fonctionner, vous pouvez même écrire des tests au niveau de l'API et ils seront tous verts, et il semble que tout le monde soit blessé! Et l'utilisateur téléchargera le rapport et verra l'erreur. Oh.

Le serveur est en cours d'exécution, une erreur s'est produite sur le client. Et ne vous souciez pas des centaines d'autotests «verts». L'utilisateur a toujours une erreur. Et notre tâche est de regarder de son point de vue.

Cependant, si vous avez accès au serveur d'applications et à sa base de données - cela vaut également la peine de les vérifier! Nous pouvons donc voir le "futur bug". Par exemple:

Nous avons enregistré la carte de produit - le système la dessine et dit que tout va bien. Tout va bien pour le client!
Nous avons vérifié la base de données - et là une partie des champs est restée vide, le développeur a incorrectement indiqué le nom du champ dans la base de données. Et l'information a été perdue.

Ce que l'utilisateur voit maintenant dans le client n'est qu'un cache, "ce que j'ai entré est ce que j'affiche". Si vous ne vérifiez pas la base de données, un tel problème peut même ne pas s'ouvrir immédiatement. L'utilisateur ouvre la fiche produit - certains champs ne sont pas remplis:

- Eh bien, probablement ils n'ont pas été remplis.

Et ils étaient remplis! Juste économiser de façon tortueuse. Par conséquent, si nous n'avons qu'une boîte noire, nous devons vérifier: "Les données sont-elles vraiment enregistrées?" Enregistré? Ouvrez la carte dans une nouvelle fenêtre ou appelez les informations via la méthode API.

Si vous avez accès à la base de données - vérifiez simplement que tout va bien. Si vous avez accès aux journaux du serveur, recherchez-les pour les erreurs.

En plus des utilisateurs ordinaires, il y a des gens méchants qui essaient de s'en tenir à notre application et volent de l'argent / des données. Ils n'utilisent pas de client ou de serveur - ils n'y ont pas accès. Ils essaient d'intercepter les données du client vers le serveur ou du serveur vers la base de données.

Eh bien, si de mauvaises personnes peuvent le faire, le testeur doit également pouvoir le faire! Parce que le testeur fournit des informations sur notre produit.

Le testeur examine les vulnérabilités et dit ensuite à l'équipe:

- Les gars, alors j'ai vérifié, nous avons tel ou tel trou potentiel. Voyons si nous devons les fermer d'une manière ou d'une autre.

Ce n'est pas le fait qu'ils vont régler le problème. Peut-être que vous avez une application non critique - les données ne fuiront pas, vous ne stockez pas d'argent. Ensuite, plus personne ne s'en souciera, car les tests de sécurité coûtent cher, il y a peu de spécialistes.

Mais certaines vérifications de base comme les injections SQL ou les attaques XSS méritent d'être explorées et vérifiées sur votre application. Au moins pour comprendre leur criticité. Après tout, si l'attaque brise le client - eh bien, laissez-le être Pinocchio. Et si l'attaque met le serveur, ce n'est pas très bon. Et il faut au moins savoir de quoi il s'agit.

Total

Le client est le programme avec lequel l'utilisateur travaille. Il ne sait pas si c'est tout le programme sur son ordinateur, ou quelque part un serveur avec une base ou même un RAID entier se cache derrière. Il fonctionne dans un navigateur ou avec une application de bureau. Et tout ce qu'il doit savoir, c'est où piquer.

Le client n'a pas besoin de beaucoup de mémoire, d'espace disque et d'autres ressources. Par conséquent, les emplois sont relativement bon marché. Et c'est exactement ce dont nous avons besoin, surtout si nous devons acheter du matériel pour des milliers d'agents d'exploitation de banque.

Serveur - un ordinateur sur lequel l'application elle-même est stockée. Tout le code, toute la logique, tous les matériaux supplémentaires et livres de référence. Par exemple, le répertoire d'adresses FIAS ou le répertoire des entités juridiques du registre des entités juridiques - ils occupent également une place, à la fois par eux-mêmes et dans la mémoire de l'application.

Parfois, ils disent «serveur d'applications» et «serveur de base de données». C'est normal, car en fait le serveur n'est qu'une machine, un ordinateur. Et la base de données et le serveur d'applications sont généralement stockés sur différentes machines, pour des raisons de sécurité. Dans ce cas, s'ils disent "serveur d'application" - nous parlons du deuxième lien de notre schéma.

Les applications sont très différentes. Il y a beaucoup de ressources, ils ont besoin de beaucoup de mémoire et d'espace disque. Il existe des "poumons" qui peuvent être déployés même sur un ordinateur personnel.

DB (base de données) - entrepôt de données. Ici, vous pouvez facilement rechercher des informations + être sûr qu'elles resteront, même si quelque chose se casse dans l'application.

La quantité d'espace nécessaire pour la base de données dépend de la quantité de données. Il y a d'énormes bases dans les banques, où 1 To sera peu. Et il y en a de très petits que vous pouvez installer sur votre machine. Par exemple,XAMPP peut être fourni. Et il est peu probable que vous y entassiez autant de données que vous n'aurez pas de place pour elles.

Il peut ne pas y avoir de base séparée, alors la structure deviendra à deux niveaux: client-serveur. Et c'est tout!

Le régime est conditionnel, dans la vie réelle, nous aurons au moins plus de clients. Et si l'application est lourdement chargée, alors il y aura plusieurs serveurs et plusieurs bases de données:

PS - cherchez des articles plus utiles dans mon blog sous la balise "utile"

L'architecture client-serveur en images