Solution rapide en 10 minutes | Architecture du système de commerce électronique distribué à grande échelle

Cet article est un résumé technique de l'apprentissage de l'architecture de sites Web distribués à grande échelle. Une brève description de l'architecture d'un site Web distribué performant, hautement disponible, évolutif et extensible, ainsi qu'une référence architecturale sont données. Une partie de l'article consiste à lire des notes et une partie est un résumé de l'expérience personnelle, qui a une bonne valeur de référence pour l'architecture de sites Web distribués à grande échelle.

Technologie d'architecture de sites Web distribués à grande échelle

1 Caractéristiques des sites Web à grande échelle

• Beaucoup d'utilisateurs, large distribution
• Trafic important, concurrence élevée
  .
• Données massives, le service est hautement disponible
• L'environnement de sécurité est médiocre et vulnérable aux attaques réseau
• Fonctions multiples, développement plus rapide, versions fréquentes
• Développer progressivement de petit à grand
• Utilisateur- centré
• Service gratuit, expérience payante

2. Grands objectifs d'architecture de site Web

• Haute performance : offrir une expérience d'accès rapide.
• Haute disponibilité : Le service du site Internet est toujours accessible normalement.
• Évolutif : augmenter/diminuer, augmenter/diminuer la puissance de traitement via le matériel.
• Sécurité : fournit un accès sécurisé au site Web et le cryptage des données, un stockage sécurisé et d'autres stratégies.
• Extensibilité : ajoutez/supprimez facilement de nouvelles fonctions/modules.
• Agilité : sur demande, réponse rapide

3. Modèle d'architecture de grand site Web

• Layering : peut généralement être divisé en couche d'application et couche de service, données couche, couche de gestion et couche d'analyse ;
• segmentation : généralement divisée selon les caractéristiques métier/module/fonctionnelles, par exemple, la couche application est divisée en page d'accueil et centre utilisateur.
• Distribué : déployez des applications séparément (telles que plusieurs machines physiques) et travaillez ensemble via des appels à distance.
• Cluster : une application/un module/une fonction est déployé en plusieurs copies (telles que plusieurs machines physiques) pour fournir conjointement un accès externe via l'équilibrage de charge.
• Mise en cache : placez les données au plus près de l'application ou de l'utilisateur pour accélérer l'accès.
• Asynchrone : asynchrone les opérations synchrones. Le client envoie une demande sans attendre la réponse du serveur. Une fois le traitement terminé, le serveur utilise une notification ou une interrogation pour informer le demandeur. Désigne généralement : le mode requête-réponse-notification.
• Redondance : augmentez les répliques pour améliorer la disponibilité, la sécurité et les performances.
• Sécurité : avoir des solutions efficaces aux problèmes connus et établir des mécanismes de découverte et de défense pour les problèmes inconnus/potentiels.
• Automatisation : Utiliser des machines pour effectuer des tâches répétitives qui ne nécessitent pas d'intervention humaine via des outils.
• Agilité : Accepter activement les changements d'exigences et répondre rapidement aux besoins de développement commercial.

4. L'architecture haute performance

est centrée sur l'utilisateur et offre une expérience d'accès Web rapide. Les principaux paramètres sont un temps de réponse court, une grande capacité de traitement simultané, un débit élevé et des paramètres de performances stables.

Peut être divisé en optimisation frontale, optimisation de la couche d'application, optimisation de la couche de code et optimisation de la couche de stockage.

• Optimisation du front-end : la partie avant la logique métier du site Web ;
• Optimisation du navigateur : réduire le nombre de requêtes HTTP, utiliser le cache du navigateur, activer la compression, la position CSS JS, JS asynchrone, réduire la transmission des cookies ; accélération, proxy inverse ;
• Optimisation de la couche application : le serveur qui gère les activités du site Web. Utiliser le cache, l'asynchrone, le cluster
• Optimisation du code : architecture raisonnable, multi-threading, réutilisation des ressources (pool d'objets, pool de threads, etc.), bonne structure de données, réglage JVM, singleton, Cache, etc. ;
• Optimisation du stockage : cache, disque SSD, transmission fibre optique, lecture et écriture optimisées, redondance des disques, stockage distribué (HDFS), NoSQL, etc.

5. Architecture haute disponibilité

Les grands sites Web doivent être accessibles à tout moment et fournir des services externes normaux. En raison de la complexité, de la distribution, des serveurs bon marché, des bases de données open source, des systèmes d'exploitation et d'autres caractéristiques des grands sites Web, il est difficile de garantir une haute disponibilité, ce qui signifie que les pannes des sites Web sont inévitables.

Comment améliorer la convivialité est un problème qui doit être résolu de toute urgence. Tout d’abord, nous devons l’envisager du point de vue architectural et tenir compte de la disponibilité lors de la planification. Dans l'industrie, plusieurs neuf sont généralement utilisés pour représenter les indicateurs de disponibilité, comme quatre neuf (99,99), et la durée d'indisponibilité autorisée dans une année est de 53 minutes.

Différentes stratégies sont utilisées à différents niveaux. La sauvegarde redondante et le basculement sont généralement utilisés pour résoudre les problèmes de haute disponibilité.

• Couche Application : Généralement conçue pour être apatride, elle n'a aucun impact sur le serveur utilisé pour traiter chaque requête. Généralement, la technologie d'équilibrage de charge (qui doit résoudre le problème de synchronisation de session) est utilisée pour atteindre une haute disponibilité.
• Couche de service : équilibrage de charge, gestion hiérarchique, panne rapide (paramètre de timeout), appels asynchrones, dégradation de service, conception idempotente, etc.
• Couche de données : sauvegarde redondante (sauvegarde à froid, à chaud [synchrone, asynchrone], sauvegarde à chaud), failover (confirmation, transfert, restauration). La célèbre base théorique de la haute disponibilité des données est la théorie CAP (persistance, disponibilité, cohérence des données [forte cohérence, cohérence utilisateur, cohérence éventuelle])

6 Architecture évolutive

L'évolutivité fait référence sans changer la. Conception d'architecture originale, les capacités de traitement du système peuvent être augmentées ou diminuées en ajoutant/réduisant du matériel (serveurs).

• Couche d'application : divisez l'application verticalement ou horizontalement. Ensuite, équilibrez la charge par rapport à une seule fonction (DNS, HTTP [proxy inverse], IP, couche de liaison).
• Couche de service : similaire à la couche d'application ;
• Couche de données : sous-base de données, sous-table, NoSQL, etc. ; algorithme de hachage couramment utilisé ;

7. Architecture évolutive

peut facilement ajouter/supprimer des modules de fonction et offrir une bonne évolutivité au niveau du code/module.

• Modularisation et composantisation : cohésion élevée, faible couplage, réutilisabilité et évolutivité améliorées.
• Interface stable : Définissez une interface stable. Tant que l'interface reste inchangée, la structure interne peut changer "à volonté".
• Modèle de conception : appliquez des idées et des principes orientés objet, utilisez des modèles de conception pour concevoir au niveau du code.
• Message Queue : Un système modulaire qui interagit via des files d'attente de messages pour découpler les dépendances entre les modules.
• Services distribués : les modules publics sont orientés services pour permettre une utilisation par d'autres systèmes, améliorant ainsi la réutilisabilité et l'évolutivité.

8. Architecture de sécurité

Avoir des solutions efficaces aux problèmes connus et établir des mécanismes de découverte et de défense pour les problèmes inconnus/potentiels. Pour les problèmes de sécurité, nous devons d'abord améliorer la sensibilisation à la sécurité et établir un mécanisme de sécurité efficace pour garantir cela au niveau politique et organisationnel. Par exemple, les mots de passe des serveurs ne peuvent pas être divulgués, les mots de passe sont mis à jour mensuellement et ne peuvent pas être répétés trois fois par semaine. analyses de sécurité, etc. Renforcer la construction du système de sécurité de manière institutionnalisée. Dans le même temps, il convient de prêter attention à tous les aspects liés à la sécurité. Les questions de sécurité ne peuvent être ignorées, notamment la sécurité des infrastructures, la sécurité des systèmes applicatifs, la confidentialité et la sécurité des données, etc.

• Sécurité des infrastructures : achat de matériel, sécurité du système d'exploitation et de l'environnement réseau. En règle générale, utilisez les canaux formels pour acheter des produits de haute qualité, choisissez un système d'exploitation sûr, corrigez les vulnérabilités en temps opportun et installez un logiciel antivirus et des pare-feu. Protégez-vous contre les virus et les portes dérobées. Définissez des politiques de pare-feu, établissez des systèmes de défense DDOS, utilisez des systèmes de détection d'attaques et effectuez une isolation de sous-réseau.
• Sécurité du système d'application : pendant le développement du programme, utilisez les méthodes correctes pour résoudre les problèmes courants connus au niveau du code. Empêchez les attaques de script intersite (XSS), les attaques par injection, la falsification de requêtes intersite (CSRF), les messages d'erreur, les commentaires HTML, les téléchargements de fichiers, la traversée de chemin, etc. Vous pouvez également utiliser un pare-feu d'application Web (tel que ModSecurity) pour effectuer une analyse des vulnérabilités de sécurité et d'autres mesures visant à renforcer la sécurité au niveau des applications.
• Confidentialité et sécurité des données : sécurité du stockage (stockage dans un équipement fiable, sauvegarde en temps réel et programmée), sécurité de la conservation (conservation cryptée des informations importantes, sélection du personnel approprié pour la conservation et la détection complexes, etc.), sécurité de la transmission (prévention du vol et de la falsification des données)

Algorithmes de cryptage et de décryptage couramment utilisés (cryptage à hachage unique [MD5, SHA], cryptage symétrique [DES, 3DES, RC]), cryptage asymétrique [RSA], etc.

9. Agilité

La conception architecturale et la gestion de l'exploitation et de la maintenance du site Web doivent s'adapter aux changements et offrir une grande évolutivité et évolutivité. Faites face facilement au développement rapide des affaires, à l’augmentation soudaine de l’accès à fort trafic et à d’autres exigences.

En plus des éléments architecturaux introduits ci-dessus, il est également nécessaire d'introduire les idées de gestion agile et de développement agile. Unifiez les activités, les produits, la technologie, l’exploitation et la maintenance, adaptez-vous aux besoins et réagissez rapidement.

10. Exemples d'architecture à grande échelle

Ce qui précède utilise une architecture logique à sept couches, la première couche est la couche client, la deuxième couche est la couche d'optimisation frontale, la troisième La couche est la couche d'application, la quatrième couche est la couche de service et la cinquième couche est la couche de stockage de données, la sixième couche est la couche de stockage de Big Data et la septième couche est la couche de traitement du Big Data.

• Couche client : prend en charge le navigateur PC et l'application mobile. La différence est que l'application mobile est accessible directement via IP et un serveur proxy inverse.
• Couche frontale : utilisation de l'équilibrage de charge DNS, de l'accélération locale CDN et des services de proxy inverse ;
• Couche d'application : cluster d'applications de sites Web divisé verticalement en fonction des activités, telles que les applications de produits, les centres de membres, etc. ;
• Couche de service : fournit des services publics, tels que les services aux utilisateurs, les services de commande, les services de paiement, etc. ;
• Couche de données : prend en charge les clusters de bases de données relationnelles (prend en charge la séparation en lecture-écriture), les clusters NOSQL, le système de fichiers distribué clusters ; et cache distribué ;
• Couche de stockage de données volumineuses : prend en charge la collecte de données de journaux dans la couche application et la couche de service, la collecte de données structurées et semi-structurées dans les bases de données relationnelles et les bases de données NOSQL ; hors ligne via l'analyse des données Mapreduce ou l'analyse des données en temps réel Storm, et les données traitées sont stockées dans une base de données relationnelle. (En utilisation réelle, les données hors ligne et les données en temps réel seront classées et traitées selon les exigences de l'entreprise et stockées dans différentes bases de données pour être utilisées par la couche application ou la couche service).

L'évolution de l'architecture système des sites Web de commerce électronique à grande échelle

L'architecture système d'un site Web mature à grande échelle (comme Taobao, Tmall, Tencent, etc.) n'est pas conçue avec des performances élevées dès le début, une haute disponibilité, une évolutivité élevée et d'autres caractéristiques. Il a progressivement évolué et amélioré avec l'augmentation du nombre d'utilisateurs et l'expansion des fonctions commerciales. Dans ce processus, le modèle de développement, l'architecture technique et. les idées de conception ont également subi de grands changements. Même le personnel technique est passé de quelques personnes à un département ou même une ligne de produits. Ainsi, l'architecture système mature s'améliore progressivement avec l'expansion de l'entreprise, et cela ne se fait pas du jour au lendemain ; les systèmes avec des caractéristiques commerciales différentes auront leur propre objectif, comme Taobao, qui doit résoudre la recherche, la commande et le traitement des des informations massives sur les produits. Tencent, par exemple, doit gérer la transmission de messages en temps réel pour des centaines de millions d'utilisateurs ; Baidu doit gérer des demandes de recherche massives.

Ils ont tous leurs propres caractéristiques commerciales et l'architecture du système est également différente. Malgré cela, nous pouvons également trouver des technologies communes à ces différents contextes de sites Web. Ces technologies et méthodes sont largement utilisées dans l'architecture des systèmes de sites Web à grande échelle. Comprenons ces technologies et méthodes en introduisant le processus d'évolution des systèmes de sites Web à grande échelle. moyens.

L'architecture initiale du site Web

L'architecture initiale, les applications, les bases de données et les fichiers sont tous déployés sur un serveur, comme le montre l'image :

2. Séparation des applications, des données et des fichiers

Avec l'expansion de l'activité, un serveur ne peut plus répondre aux exigences de performances, de sorte que les applications, les bases de données et les fichiers sont déployés sur des serveurs distincts, et Configurez différents matériels en fonction de l'objectif du serveur pour obtenir les meilleurs résultats en termes de performances.

3. Utilisez la mise en cache pour améliorer les performances du site Web

Tout en optimisant les performances du matériel, elle optimise également les performances via les logiciels. Dans la plupart des systèmes de sites Web, la technologie de mise en cache est utilisée pour améliorer les performances du système. la mise en cache est principalement due à l'existence de données chaudes. La plupart des visites de sites Web suivent le principe 28 (c'est-à-dire que 80 % des demandes d'accès aboutissent sur 20 % des données), nous pouvons donc mettre en cache les données chaudes pour réduire l'accès à ces données. chemin pour améliorer l’expérience utilisateur.

Les moyens courants d'implémenter le cache sont le cache local et le cache distribué. Bien entendu, il existe également des CDN, des proxys inverses, etc., dont nous parlerons plus tard. Le cache local, comme son nom l'indique, met en cache les données localement sur le serveur d'applications. Il peut être stocké en mémoire ou dans des fichiers. OSCache est un composant de cache local couramment utilisé. La caractéristique du cache local est qu'il est rapide, mais comme l'espace local est limité, la quantité de données mises en cache est également limitée. La caractéristique du cache distribué est qu'il peut mettre en cache d'énormes quantités de données et qu'il est très facile à développer. Il est souvent utilisé dans les sites Web de portail et n'est pas aussi rapide que les caches distribués couramment utilisés sont Memcached et Redis.

4. Utilisez des clusters pour améliorer les performances du serveur d'applications

En tant qu'entrée du site Web, le serveur d'applications supportera un grand nombre de requêtes. Nous utilisons souvent des clusters de serveurs d'applications pour partager le nombre de requêtes. Un serveur d'équilibrage de charge est déployé devant le serveur d'applications pour planifier les demandes des utilisateurs et distribuer les demandes à plusieurs nœuds de serveur d'applications conformément à la politique de distribution.

Le matériel technologique d'équilibrage de charge couramment utilisé comprend F5, qui est relativement cher, et les logiciels incluent LVS, Nginx et HAProxy. LVS est un équilibrage de charge à quatre couches, qui sélectionne les serveurs internes en fonction de l'adresse et du port cibles. Nginx et HAProxy sont un équilibrage de charge à sept couches, qui peut sélectionner les serveurs internes en fonction du contenu du message. Par conséquent, le chemin de distribution LVS est meilleur que. Nginx et HAProxy, et les performances sont plus élevées. Nginx et HAProxy sont plus configurables et peuvent être utilisés pour la séparation dynamique et statique (choisissez un serveur de ressources statiques ou un serveur d'applications en fonction des caractéristiques du message de requête).

5. Séparation en lecture-écriture de la base de données et partitionnement de la base de données et des tables

Avec l'augmentation du nombre d'utilisateurs, la base de données est devenue le plus grand goulot d'étranglement. Les méthodes couramment utilisées pour améliorer les performances de la base de données sont la séparation en lecture-écriture et la base de données. et partitionnement de table Lecture et écriture Comme son nom l'indique, la séparation consiste à diviser la base de données en une base de données de lecture et une base de données d'écriture, et à réaliser la synchronisation des données via les fonctions primaires et secondaires. Le partitionnement de base de données et le partitionnement de table sont divisés en partitionnement horizontal et partitionnement vertical. Le partitionnement horizontal consiste à diviser une très grande table dans une base de données, telle qu'une table utilisateur. La segmentation verticale est basée sur différentes activités. Par exemple, les tableaux liés à l'activité des utilisateurs et à l'activité des produits sont placés dans différentes bases de données.

6. Utilisez le CDN et le proxy inverse pour améliorer les performances du site Web

Si nos serveurs sont déployés dans la salle informatique de Chengdu, l'accès sera plus rapide pour les utilisateurs du Sichuan, mais pour les utilisateurs de Pékin, l'accès sera plus rapide. est plus lent. Cela est dû au fait que le Sichuan et Pékin appartiennent respectivement à des régions développées différentes de China Telecom et de China Unicom. Les utilisateurs de Pékin doivent emprunter un chemin plus long via le routeur Internet pour accéder au serveur de Chengdu. Le chemin de retour est également le même. le temps de transmission des données est donc relativement long. Dans cette situation, CDN est souvent utilisé pour résoudre le problème. CDN met en cache le contenu des données dans la salle informatique de l'opérateur. Lorsque les utilisateurs accèdent aux données, ils obtiennent d'abord les données auprès de l'opérateur le plus proche, ce qui réduit considérablement le chemin d'accès au réseau. Les opérateurs CDN plus professionnels incluent Lanxun et Wangsu.

Le proxy inverse est déployé dans la salle informatique du site Web. Lorsque la demande de l'utilisateur arrive, il accède d'abord au serveur proxy inverse. Le serveur proxy inverse renvoie les données mises en cache à l'utilisateur. continuez à accéder au serveur d'applications pour l'obtenir, ce qui réduit le coût d'obtention des données. Les proxys inverses incluent Squid et Nginx.

7. Utiliser un système de fichiers distribué

Le nombre d'utilisateurs augmente de jour en jour, le volume d'activité devient de plus en plus important et de plus en plus de fichiers sont générés. Un seul serveur de fichiers ne peut pas. ne répond plus à la demande. À l'heure actuelle, il nécessite le support d'un système de fichiers distribué. Les systèmes de fichiers distribués couramment utilisés incluent GFS, HDFS et TFS.

8. Utilisez NoSQL et les moteurs de recherche

Pour l'interrogation et l'analyse de données massives, nous utilisons des bases de données NoSQL ainsi que des moteurs de recherche pour obtenir de meilleures performances. Toutes les données ne doivent pas nécessairement être placées dans des données relationnelles. Le NoSQL couramment utilisé inclut MongoDB, HBase et Redis, et les moteurs de recherche incluent Lucene, Solr et Elasticsearch.

9. Diviser le serveur d'applications en entreprise

À mesure que l'entreprise se développe, l'application devient très volumineuse. À ce stade, nous devons diviser l'application en entreprise. actualités, pages Web, images et autres services. Chaque application métier est responsable d’opérations commerciales relativement indépendantes. Les entreprises communiquent par messages ou partagent des bases de données.

10. Créer des services distribués

À l'heure actuelle, nous avons constaté que chaque application métier utilisera certains services métier de base, tels que les services utilisateur, les services de commande, les services de paiement et les services de sécurité. prennent en charge les éléments de base de chaque application métier. Nous extrayons ces services et utilisons le cadre de services distribués pour créer des services distribués. Le Dubbo d'Ali est un bon choix.

Une photo expliquant l'architecture d'un site e-commerce

Grand cas d'architecture de site e-commerce

1. E-commerce La raison du case

Il existe actuellement plusieurs grandes catégories de sites web distribués à grande échelle :

• Grands portails, tels que NetEase, Sina, etc.
• Sites Web SNS, tels que Xiaonei, Kaixin.com, etc.
• Sites Web de commerce électronique, tels que Alibaba, JD.com, Allez en ligne, Autohome, etc.

Les portails à grande échelle sont généralement des informations d'actualité, qui peuvent être optimisées à l'aide de CDN, de statique, etc. Kaixin.com et d'autres sites Web sont plus interactifs et peuvent introduire davantage de NoSQL, de mise en cache distribuée et utiliser des cadres de communication hautes performances, etc. Les sites Web de commerce électronique présentent les caractéristiques des deux catégories ci-dessus. Par exemple, les détails des produits peuvent utiliser le CDN et sont statiques. Ceux qui ont une grande interactivité doivent utiliser NoSQL et d'autres technologies. Par conséquent, nous utilisons les sites Web de commerce électronique comme argument d’analyse.

2. Besoins du site de commerce électronique

Besoins des clients :

• Établir un site Web de commerce électronique complet (B2C) où les utilisateurs peuvent acheter des marchandises en ligne, payer en ligne ou payer à la livraison ;
• Les utilisateurs peuvent communiquer avec le service client en ligne lors de l'achat ;
• Après avoir reçu les marchandises, les utilisateurs peuvent évaluer et évaluer les marchandises
• Actuellement, il existe un système d'achat, de vente et d'inventaire mature ; connecté au site Web ;
• J'espère soutenir le développement commercial dans 3 à 5 ans
• Il est prévu que le nombre d'utilisateurs atteigne 10 millions dans 3 à 5 ans ; , Double 12, Journée des hommes du 8 mars et autres activités
• Pour d'autres fonctions, veuillez vous référer aux sites Web tels que JD.com ou Gome Online.
• Les clients sont des clients. Ils ne vous diront pas ce qu'ils veulent, ils vous diront seulement ce qu'ils veulent. Nous devons souvent guider et explorer les besoins des clients. Heureusement, un site Web de référence clair est fourni. Par conséquent, l'étape suivante consiste à effectuer une grande quantité d'analyses, à combiner l'industrie et les sites Web de référence pour fournir des solutions aux clients.
  Matrice des fonctions des exigences
  L'approche traditionnelle de la gestion des exigences consiste à utiliser des diagrammes de cas d'utilisation ou des diagrammes de modules (listes d'exigences) pour décrire les exigences. Cela néglige souvent une exigence très importante (exigence non fonctionnelle), il est donc recommandé d'utiliser la matrice de fonctions des exigences pour décrire les exigences. La matrice de demande de ce site de commerce électronique est la suivante :

3. Architecture principale du site Web

Site Web général, l'approche initiale est de trois serveurs, un pour déployer l'application et un pour déployer la base de données, on déploie le système de fichiers NFS. C'est une approche relativement traditionnelle ces dernières années, j'ai vu un site Web avec plus de 100 000 membres, un portail vertical de conception de vêtements et de nombreuses photos. Un serveur est utilisé pour déployer des applications, des bases de données et du stockage d'images. Il y avait beaucoup de problèmes de performances. Comme indiqué ci-dessous :

Cependant, l'architecture actuelle des sites Web grand public a subi des changements bouleversants. Généralement, une approche cluster est utilisée pour la conception à haute disponibilité. Au moins, cela ressemble à ceci :

• Utilisez des clusters pour des serveurs d'applications redondants pour obtenir une haute disponibilité (un équipement d'équilibrage de charge peut être déployé avec l'application)
• Utilisez une base de données ; Mode de sauvegarde maître pour obtenir une sauvegarde des données et une haute disponibilité ;

4. Estimation de la capacité du système

Étapes d'estimation :

• Nombre d'utilisateurs enregistrés - Volume UV moyen quotidien - Volume PV quotidien - Montant quotidien de simultanéité ;
• Estimation maximale : 2 à 3 fois le montant normal
• Calculez la capacité du système en fonction du montant de simultanéité (concurrence, nombre de transactions) et de la capacité de stockage.

Selon les besoins des clients : le nombre d'utilisateurs atteindra 10 millions d'utilisateurs enregistrés d'ici 3 à 5 ans, et le nombre d'utilisateurs simultanés par seconde peut être estimé :

• L'UV quotidien est de 2 millions (28 principes)
• Cliquez pour voir 30 fois par jour
• Volume PV : 200*30=60 millions ; =4,8 heures, il y aura 60 millions
  0,8=48 millions (28 principes)
• Concurrence par minute : 4,8*60=288 minutes, 4800/288=167 000 visites par minute (environ égal à
) ;
• Concurrence par seconde : 167 000/60=2780 (environ égal à) ;
• En supposant que la période de pointe est trois fois la valeur normale, le nombre de concurrence par seconde peut atteindre 8340.
• 1 milliseconde = 1,3 visites
• Regrettez-vous de ne pas bien étudier les mathématiques ? ! (Je ne sais pas si le calcul ci-dessus est faux, haha~~) Estimation du serveur : (prenons le serveur Tomcat comme exemple) Selon un serveur Web, il prend en charge 300 calculs simultanés par seconde. Normalement, 10 serveurs sont nécessaires (environ l'équivalent) [la configuration par défaut de Tomcat est de 150], 30 serveurs sont nécessaires pendant les périodes de pointe : estimation de la capacité : principe 70/90 ; Le processeur du système est généralement maintenu à environ 70 % et atteint 90 % pendant les périodes de pointe. Il ne gaspille pas de ressources et est relativement stable. La mémoire et les E/S sont similaires. Les estimations ci-dessus sont fournies à titre de référence uniquement, car la configuration du serveur, la complexité de la logique métier, etc. ont toutes un impact. Ici, le CPU, le disque dur, le réseau, etc. ne sont plus évalués. 5. Analyse de l'architecture du site Web Selon l'estimation ci-dessus, il y a plusieurs problèmes :

Un grand nombre de serveurs doivent être déployés. Durant les périodes de pointe, 30 serveurs web peuvent être déployés. De plus, ces trente serveurs ne sont utilisés que lors de ventes flash et d'événements, ce qui représente beaucoup de gaspillage.

• Toutes les applications sont déployées sur le même serveur, et le couplage entre applications est sérieux. Des tranches verticales et horizontales sont nécessaires.
• Il existe des codes redondants dans un grand nombre d'applications
• La synchronisation des sessions serveur consomme beaucoup de mémoire et de bande passante réseau
• Les données doivent accéder fréquemment à la base de données, et la pression d'accès à la base de données est énorme.
• Les grands sites Web doivent généralement procéder à l'optimisation de l'architecture suivante (l'optimisation est quelque chose qui doit être pris en compte lors de la conception de l'architecture. Elle est généralement résolue au niveau de l'architecture/du code. Le réglage est principalement l'ajustement de paramètres simples, tels que Réglage JVM ; si le réglage implique un grand nombre de modifications de code ne sont pas du réglage, mais du refactoring) :
  • Business Split
  • Déploiement de cluster d'applications (déploiement distribué, déploiement de cluster et équilibrage de charge)
  • Cache multi-niveaux
  • Authentification unique (session distribuée)
  • Cluster de base de données ( Lire et séparation d'écriture, sous-base de données et sous-table)
  • Serviceisation
  • File d'attente des messages
  • Autres technologies

  6. .1 Répartition des activités

  Segmentation verticale basée sur les attributs commerciaux, divisée en sous-système de produit, sous-système d'achat, sous-système de paiement, sous-système d'avis, sous-système de service client, sous-système d'interface (connexion avec des systèmes externes tels que l'achat, la vente, l'inventaire, les SMS, etc.). Sur la base de la définition hiérarchique des sous-systèmes métier, ils peuvent être divisés en systèmes centraux et systèmes non centraux. Système central : sous-système de produits, sous-système d'achat, sous-système de paiement ; non central : sous-système d'examen, sous-système de service client, sous-système d'interface. Le rôle du fractionnement des activités : la mise à niveau vers des sous-systèmes peut être gérée par des équipes et des départements spécialisés, avec des professionnels effectuant des tâches professionnelles pour résoudre les problèmes de couplage et d'évolutivité entre les modules. Chaque sous-système est déployé séparément pour éviter un déploiement centralisé conduisant à un problème. l'application se bloque et toutes les applications ne sont pas disponibles.

  Le rôle de la définition de niveau : utilisé pour protéger les applications clés pendant les rafales de trafic et obtenir une dégradation gracieuse ;
  Schéma d'architecture après fractionnement :

  Plan de déploiement de référence 2

  
  

  Comme indiqué ci-dessus, chaque application est déployée séparément, et le système principal et le système non central sont déployés en combinaison

  6.2 Déploiement de cluster d'applications (distribué, clusterisé, équilibrage de charge)

  • Déploiement distribué : déployez l'application après la division de l'activité séparément, et l'application communique directement à distance via RPC
  • Déploiement de cluster : Haute disponibilité ; exigences pour les sites Web de commerce électronique. Chaque application doit déployer au moins deux serveurs pour le déploiement du cluster ;
  • Équilibrage de charge : il est généralement nécessaire pour les systèmes à haute disponibilité grâce à l'équilibrage de charge et les services distribués utilisent des systèmes intégrés. dans L'équilibrage de charge atteint une haute disponibilité et la base de données relationnelle atteint une haute disponibilité grâce à des méthodes actives et de sauvegarde.

  Schéma d'architecture après déploiement du cluster :

  

  
  

  6.3 Cache multi-niveaux

  Le cache peut généralement être divisé en deux types : le cache local et le cache distribué selon l'emplacement de stockage. Ce cas utilise la méthode du cache de deuxième niveau pour concevoir le cache. Le cache de premier niveau est un cache local et le cache de deuxième niveau est un cache distribué. (Il existe également la mise en cache des pages, la mise en cache des fragments, etc., qui sont des divisions plus fines) Le cache de premier niveau, le dictionnaire de données de cache, les données de points d'accès couramment utilisées et d'autres informations fondamentalement immuables/changeantes régulièrement, le cache de deuxième niveau met en cache tout le cache nécessaire. Lorsque le cache de premier niveau expire ou n'est pas disponible, les données du cache de deuxième niveau sont accessibles. S'il n'y a pas de cache de deuxième niveau, la base de données est accédée. Le rapport de cache est généralement de 1:4 et vous pouvez envisager d'utiliser le cache. (Théoriquement, 1:2 suffit).

  

  
  

  Les stratégies d'expiration du cache suivantes peuvent être utilisées en fonction des caractéristiques de l'entreprise :

  • Expiration automatique du cache
  • Expiration déclenchée par le cache

  6.4 ; Authentification unique (distribuée Session)

  Le système est divisé en plusieurs sous-systèmes. Après un déploiement indépendant, des problèmes de gestion de session seront inévitablement rencontrés. Généralement, la synchronisation de session, les cookies et les méthodes de session distribuées peuvent être utilisées. Les sites Web de commerce électronique sont généralement mis en œuvre à l’aide de sessions distribuées. De plus, un système complet d’authentification unique ou de gestion de compte peut être établi sur la base de la session distribuée.

  

  
  

  Description du processus

  • Lorsque l'utilisateur se connecte pour la première fois, écrivez les informations de session (ID utilisateur et informations utilisateur), telles que l'utilisation de l'ID utilisateur comme clé, dans la session distribuée
  • Lorsque l'utilisateur se reconnecte ; , obtenez la session distribuée. Y a-t-il des informations sur la session, sinon, accédez à la page de connexion
  • est généralement implémenté à l'aide du middleware Cache. Il est recommandé d'utiliser Redis, il dispose donc d'une fonction de persistance, ce qui facilite le chargement de. informations de session du stockage persistant après l'arrêt de la session distribuée ;
  • Lors de l'enregistrement d'une session, vous pouvez définir la durée de conservation de la session, par exemple 15 minutes, et elle expirera automatiquement une fois dépassée

   ; Combinée au middleware Cache, la Session distribuée implémentée peut très bien simuler une session Session.

  Cluster de bases de données 6.5 (séparation lecture-écriture, sous-base de données et sous-table)

  Les grands sites Web doivent stocker des quantités massives de données afin d'obtenir un stockage de données massif, une haute disponibilité et des performances élevées, redondantes. la conception du système est généralement adoptée. Généralement, il existe deux manières de séparer la lecture et l'écriture, ainsi que les sous-bases de données et les tables. Séparation de lecture et d'écriture : généralement, pour résoudre le scénario dans lequel le taux de lecture est bien supérieur au taux d'écriture, un principal et un de secours, un principal et plusieurs secours, ou plusieurs primaires et plusieurs secours peuvent être utilisés. Ce cas est basé sur le fractionnement des activités, combiné au partage de bases de données, au partage de tables et à la séparation lecture-écriture. Comme indiqué ci-dessous :

  

  
  

  • Après le fractionnement de l'activité : chaque sous-système nécessite une bibliothèque distincte
  • Si la bibliothèque séparée est trop grande, elle peut être à nouveau divisée en bibliothèques en fonction des caractéristiques de l'entreprise ; comme bibliothèque de classification des produits, bibliothèque de produits ;
  • Une fois la base de données divisée, s'il y a une grande quantité de données dans le tableau, le tableau sera généralement divisé en fonction de l'ID, de l'heure, etc. .; (L'utilisation avancée est un hachage cohérent)
  • Lecture et écriture séparées sur la base de sous-bases de données et de tables

  Le middleware associé peut faire référence à Cobar (Alibaba, actuellement plus maintenu), TDDL (Alibaba) , Atlas (Qihoo 360) et MyCat. Les problèmes avec les séquences, JOIN et les transactions après le partitionnement des bases de données et des tables seront introduits dans le partage thématique des bases de données et des tables de partitionnement.

  6.6 Servitisation

  Extraire les fonctions/modules communs à plusieurs sous-systèmes et les utiliser comme services publics. Par exemple, le sous-système d'adhésion dans ce cas peut être extrait en tant que service public.

  

  
  

  6.7 File d'attente de messages

  La file d'attente de messages peut résoudre le couplage entre les sous-systèmes/modules et obtenir un système asynchrone, hautement disponible et hautes performances. C'est la configuration standard des systèmes distribués. Dans ce cas, la file d’attente de messages est principalement utilisée dans les liens d’achat et de livraison.

  • Une fois que l'utilisateur a passé une commande, celle-ci est écrite dans la file d'attente des messages puis renvoyée directement au client ;
  • Sous-système d'inventaire : lit les informations de la file d'attente des messages et termine la réduction de l'inventaire ; lit les informations de la file d'attente des messages, pour la distribution

  

  Actuellement, les MQ les plus couramment utilisés incluent Active MQ, Rabbit MQ, Zero MQ, MS MQ, etc., qui doivent être sélectionnés en fonction de spécificités. scénarios commerciaux. Il est recommandé d’étudier Rabbit MQ.
  

  6.8 Autres architectures (technologies)

  En plus du fractionnement des activités, des clusters d'applications, de la mise en cache multi-niveaux, de l'authentification unique, des clusters de bases de données, de la servitisation et des files d'attente de messages introduits ci-dessus. Il existe également des CDN, des proxy inverses, des systèmes de fichiers distribués, des systèmes de traitement de Big Data et d'autres systèmes. Je ne le présenterai pas en détail ici. Vous pouvez demander à Du Niang/Google Si vous en avez l'occasion, vous pouvez également le partager avec tout le monde.

  Résumé de l'architecture

  

  L'architecture des sites Web à grande échelle est continuellement améliorée en fonction des besoins de l'entreprise. Des conceptions et des considérations spécifiques seront apportées en fonction de différentes caractéristiques commerciales. Cet article décrit uniquement. un site Web régulier à grande échelle. J'espère que certaines des technologies et méthodes impliquées vous inspireront.
  

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!