-
Le dernier article de cette série est destiné aux programmeurs ordinaires. Si cela ne vous intéresse pas, vous pouvez simplement lire les derniers paragraphes de cet article.
Avant de commencer à concevoir la structure du code, passons en revue ce que nous avons préparé auparavant : nous disposons d'un serveur WEB à charge équilibrée, d'un serveur DB maître-esclave et éventuellement d'un sharding, d'un cache et d'un stockage évolutif. Tous les aspects de l'organisation du code sont étroitement liés à ces préparations, je les listerai un par un, deux par trois, et chacun commencera par la phrase classique "mentionnée ci-dessus" pour faciliter la comparaison.
Ne vous précipitez pas pour lire les modèles de phrases classiques, mon esprit a sauté et je vais insérer un paragraphe. Dans le développement réel, nous faisons toujours un compromis entre performances et élégance du code. Pour les ordinateurs et les interprètes de langage d'aujourd'hui, la question du nombre de couches d'appels d'objets et du nombre de couches d'appels d'objets et de l'opportunité de déclarer les variables comme Map ou HashMap est la dernière chose à considérer. Considérez toujours la partie la plus lente du système et résolvez-la. de la partie la plus lente. Par exemple, vérifiez si l'ORM que vous utilisez fait beaucoup de choses dont vous n'avez pas besoin et s'il y a des appels de données répétés. Ce que nous faisons, c'est le développement d'applications Web, et non l'API du framework sous-jacente. Un code facile à lire et compréhensible est un aspect très important pour garantir la qualité. À quoi sert votre programme ? Il existe différentes méthodes... Oubliez ça, ce sujet. sera discuté séparément. Cet article est trop éloigné du sujet. Si vous souhaitez communiquer, vous pouvez suivre mon Weibo : http://t.sina.com.cn/liuzhiyi .
Comme mentionné précédemment, la charge du serveur WEB doit être équilibrée et le serveur d'images doit être séparé. Sur ce point, lorsque le code gère le statut du client, ne mettez pas le statut sur une seule machine. Par exemple, n'utilisez pas de session de fichier. Eh bien, faites preuve de bon sens. Si possible, il est préférable de développer dès le début une interface unifiée pour l'authentification à point unique de l'utilisateur, y compris la manière de déterminer l'état entre les domaines, la manière de déterminer l'état sur les pages statiques et la définition des paramètres de saut et de retour lors de la connexion. Fournissez une bonne interface au niveau de la couche inférieure et appliquez-la. La couche est utilisée directement (voir le service utilisateur de GAE). La conception de la connexion doit tenir compte des caractéristiques des appareils mobiles. Par exemple, les ordinateurs peuvent utiliser des fenêtres à couche flottante, mais le propre navigateur de NOKIA ou UCWEB ne peut pas gérer cette forme d'expression. Le programme doit être capable de gérer à la fois les requêtes Ajax et directement via l'URL. . demander. Le serveur d'images est séparé et les fichiers de ressources sont mieux placés sur le serveur d'images, c'est-à-dire que le serveur WEB ne sert que des programmes dynamiques. Même si c'est un peu compliqué à développer et à tester (car il faut un URI absolu pour y accéder), il sera beaucoup plus simple d'optimiser le front-end de la page à l'avenir, et l'optimisation des IO de votre serveur WEB le fera également. être beaucoup plus facile. Lorsque le programme fait référence à des fichiers de ressources, il doit y avoir une méthode de traitement unifiée. De nombreuses choses peuvent être automatiquement complétées dans la méthode, comme combiner CSS/js dans un fichier ou ajouter automatiquement QUERYSTRING après l'URI généré si le front-end est le cas. Le service de cache est utilisé, la génération de QUERYSTRING est le moyen le plus simple d'actualiser le cache du serveur et le cache du client.
Comme mentionné précédemment, la base de données sera répliquée, pourra avoir plusieurs maîtres et plusieurs esclaves et pourra être partitionnée. Lors du processus de traitement des données dans notre programme, il est préférable de les extraire et de les placer sur un calque séparé. Prenons comme exemple le modèle MVC populaire, qui consiste à placer une couche de données sous la couche M. Cette couche de données n'est pas le JDBC/PDO/ActiveRecord, etc. communément connu, mais votre propre couche de données d'accès, qui expose uniquement les méthodes à. le monde extérieur. Masquer les détails d’accès aux données. N'ayez pas peur des écritures laides à l'intérieur de cette couche de données, mais elle doit fournir toutes les fonctions de stockage de données. Ne voyez pas les mots traitant de la base de données à un autre niveau. La raison en est que dans le cas d'une base de données relationnelle unique, vous pouvez SELECT...JOIN...ou directement INSERT...INTO..., mais vous pouvez stocker certaines tables dans une base de données clé-valeur, ou Les fragmenter.Après cela, toutes les déclarations et méthodes originales devront être modifiées. Si elles sont trop dispersées, beaucoup d'efforts seront dépensés lors de la transplantation, ou un très grand modèle sera obtenu. En termes de conception au niveau des données, essayez d'éviter les requêtes JOIN. Nous pouvons faire plus de redondance et de mise en cache. Chaque type de données n'a besoin que d'une seule requête, puis la combiner dans votre programme. Pour des combinaisons de données plus complexes, lorsque les exigences en temps réel ne sont pas élevées, un traitement asynchrone peut être utilisé et les utilisateurs n'obtiennent les résultats traités qu'au moment de l'accès. Lorsque vous traitez des clés primaires, évitez d'utiliser des identifiants à incrémentation automatique et utilisez des valeurs uniques générées par certaines règles comme clés primaires. Cette clé primaire est la stratégie de distribution de partitionnement la plus simple. Même si vous utilisez un ID à incrémentation automatique, il est préférable d'utiliser un générateur d'ID à incrémentation automatique. Sinon, si la base de données esclave est écrite accidentellement, la clé primaire entrera facilement en conflit.
Comme mentionné précédemment, certains caches bloquent le devant de notre base de données. Ne traitez pas le cache de requêtes de MySQL comme un cache Lorsque l'application est légèrement complexe, QUERY CACHE deviendra un fardeau. La mise en cache est étroitement intégrée à la base de données et à l'entreprise. Parce qu'elle est étroitement liée à l'activité, il n'existe pas d'approche universelle. Mais nous avons encore quelques règles à respecter. Règle 1 : Plus le front-end est proche, plus la granularité du cache est grande. Par exemple, la page entière est mise en cache au début du WEB, une partie de la page est mise en cache au niveau suivant et un seul enregistrement de la zone est mis en cache au niveau suivant. Parce que plus nous sommes proches du backend, plus notre opérabilité est flexible et le code front-end qui change le plus est plus facile à écrire. En pratique, comme les exigences du produit changent très rapidement et que le cycle d'itération est de plus en plus court, il est parfois difficile de distinguer clairement le contrôleur et le modèle. Une mise en cache partielle est inévitable au niveau du contrôleur, mais il est nécessaire de s'en assurer. Cela arrive, le contrôleur Le cache exploité ne doit pas affecter les autres parties demandeuses de données, c'est-à-dire qu'il doit être assuré que ces données mises en cache sont utilisées uniquement par ce contrôleur. Règle 2 : Le programme ne peut pas faire d'erreurs sans mise en cache. Sans tenir compte de l'effet d'avalanche provoqué par l'invalidation du cache, votre programme doit avoir un cache et être le même que sans cache. Une fois le cache échoué, le ventilateur Weibo sera vide et l'application entière sera. foiré. Lorsque la mise en cache est essentielle, il est préférable de donner un message d’erreur à l’utilisateur plutôt que de donner un message trompeur. Règle 3 : Les mises à jour du cache doivent être atomiques ou thread-safe. En particulier lorsque la mise en cache passive est utilisée, il est très probable que le même cache soit mis à jour lorsque deux utilisateurs y accèdent. Généralement, ce n'est pas un gros problème et le cache peut être reconstruit. après son expiration, cela peut être l’une des causes de la réaction en chaîne. Règle 4 : La mise en cache a aussi un coût. Il ne s’agit pas seulement du coût de la technologie, mais aussi du coût du temps de travail. Si une fonction utilise la mise en cache et ne l'utilise pas, la différence dans le volume d'accès prévisible est faible, mais l'utilisation de la mise en cache augmentera la complexité, alors il n'est pas nécessaire d'ajouter une marque TODO et d'ajouter un traitement de mise en cache dans l'itération suivante.
Comme mentionné précédemment, le stockage des fichiers est indépendant, toutes les opérations sur les fichiers sont donc des appels à distance. Vous pouvez fournir une interface RESTful très simple sur le serveur de fichiers, ou vous pouvez fournir un service XMLRPC ou JSON. Tous les fichiers générés et traités par le serveur WEB sont notifiés au serveur de fichiers via l'interface pour le traitement. pour fournir tout stockage de fichiers. Vous constaterez que le téléchargement d’images et l’enregistrement d’articles sur de nombreux grands sites Web se font en deux étapes, pour cette raison.
Les "mentionnés précédemment" ci-dessus ont en fait été dits par d'innombrables personnes. Je les ai simplement répétés dans mes propres mots en me basant sur les articles précédents. L'essence de la véritable analyse est très simple - en plus d'une bonne superposition de logique fonctionnelle, nous avons également besoin de conception. des interfaces distinctes pour les appels de ressources externes telles que le stockage de base de données, la mise en cache, les files d'attente et les services de fichiers. Vous pouvez imaginer que votre programme s'exécute sur Amazon EC2 et utilise tous ses services Web. Votre base de données est sa SimpleDB. le stockage est son S3. La seule différence est que l'interface d'Amazon est un appel à distance et la vôtre est un appel interne.
L'interfaçage du service de support signifie que le remplacement de MySQL par PostgreSQL ne nécessite pas de modifications du programme de traitement métier, et que l'équipe de migration n'a même pas besoin de trop communiquer avec l'équipe de développement commercial, cela signifie que l'équipe de développement commercial programme plutôt l'interface ; que de programmer la base de données ; cela signifie que les performances ne seront pas ralenties par une erreur d'un développeur commercial.
Si vous n'êtes pas intéressé par l'alphabétisation des programmes, regardez simplement ici——
Une fois la conception du produit terminée et le cadre du programme construit, des conflits peuvent survenir à ce stade. Les concepteurs de produits se plaignent constamment que leurs idées n'atteignent pas les résultats souhaités, et les programmeurs se plaignent que la conception des produits est irréaliste. Ce type de plainte est principalement dû au fait que le personnel chargé des produits ne comprend pas la technologie et que le personnel technique ne comprend pas les produits. Au sens large, les produits incluent les stratégies de marché, les méthodes de marketing et la conception fonctionnelle. Lorsque l'on parle de produits et de technologies, l'accent est souvent mis sur la fonction, mais l'accent est mis en réalité sur le coût de réalisation de cette fonction et les avantages qu'elle procure. peut apporter. S'il peut être converti et s'il peut être pris en considération. Si possible, résolvez le litige. Sinon, lancez une pièce et voyez la chance. Il existe de nombreux exemples d’indicateurs qui explosent en raison de l’amélioration d’une fonction ou de retards dans les combats dus à des retards dans un projet. Les décideurs radicaux se concentrent sur les bénéfices, les décideurs conservateurs se concentrent sur les pertes et les décideurs intelligents se demanderont si le problème est vraiment si grave.
Personne ne peut prédire ce qui se passera dans le futur. Sinon, la moitié du démarrage d’une entreprise dépend de la chance. Mais il y a toujours des choses qui peuvent être dites avec précision, et il faut s’appuyer sur les données pour parler d’elles-mêmes.
Pas 100 %, mais 99,9 % des sites Web ont installé un code de statistiques d'accès, même mon http://zhiyi.us ne fait pas exception, et le réseau Xinwen parle toujours de prise de décision scientifique et de développement scientifique. Avec les statistiques, beaucoup de choses peuvent être déterminées. Par exemple, vous pouvez analyser quels canaux ont le coût d'acquisition par habitant le plus bas en fonction du taux de conversion source-cible, deviner les raisons des taux de rebond des utilisateurs en fonction de l'accès au contenu source et déterminer si la position du lien est raisonnable en fonction du clic de l'utilisateur. comportement. Combinez les données de différentes manières pour trouver des connexions internes, analyser les facteurs internes et externes, formuler des stratégies correspondantes et réduire les décisions difficiles. S'appuyer sur des données pour soutenir les opérations est une affaire très professionnelle. Bien que je ne comprenne pas les modèles mathématiques profonds et les calculs de formules complexes, j'ai progressivement appris que B est dû à A et C est dû à A et B. C'est encore relativement simple. .
Auteur de l'article : Liu Zhiyi (veuillez indiquer le lien source et l'auteur lors de la réimpression)
Source de l'article : http://zhiyi.us/