Approches de conception de serveur de fichiers

Question

J'ai travaillé à la conception d'un serveur de fichiers qui pourrait décharger le site Web principal et servir les images/fichiers sur le Web au client.

Les principaux objectifs du serveur de fichiers:
- Enlever la charge du serveur principal qui héberge le site
- Réutiliser la base de code du serveur Web existant et éviter la duplication de code/logique pour une meilleure maintenabilité
- être évolutive pour augmenter téléchargements
- Masquer le chemin d'accès de téléchargement réel de l'utilisateur

En gardant ci-dessus à l'esprit, je pourrais proposer deux approches. Diagramme de séquence représentation des deux approches pour faciliter la compréhension [des excuses pour l'utilisation asymétrique du diagramme de séquence]. Aucune de ces approches ne satisferait tous mes objectifs.

Laquelle de ces approches recommanderiez-vous pour atteindre mes objectifs?
Y a-t-il une meilleure troisième approche?

Certaines différences, je pouvais penser:
- Approche # 1 conduirait à dupliquer le code BL provoquant maintenabilité émet
- Approche # 2 serait la réutilisation du code et centraliser BL réduire maintenabilité émet
- Approche # 1 réduirait les appels réseau tandis que # 2 les augmente

Le concept de serveurs de fichiers, l'évolutivité des téléchargements, la distribution de la bande passante ont tous été là depuis un moment maintenant. S'il vous plaît partagez vos pensées!

MISE À JOUR:
Approche # 1 semble très attrayante car elle prend la charge hors du serveur principal complètement. Le seul problème à résoudre dans # 1 est les problèmes de duplication de code et de maintenabilité. Cela pourrait être surmonté en ayant un seul projet pour BL/DAC comprenant la fonctionnalité requise à la fois par le service Web et le serveur de fichiers. Et référencez l'assembly/bibliothèque dans les projets de service Web et de serveur de fichiers. Maintenant, il n'y a qu'un seul code BL/DAC à maintenir et évite également les appels réseau dans l'approche # 2.

Answer 1

En servant des images/fichiers au client, je suppose que vous parlez des fichiers statiques css, js etc.

La plupart du temps, une solution simple est la meilleure solution. Hébergez-les simplement sur un serveur différent sous un sous-domaine différent, c'est-à-dire http://content.mydomain.com/img/xyz.jpg. Vous pouvez les héberger dans un centre de données sur un serveur dédié donnant votre perforamace (près de la colonne vertébrale), vous pouvez équilibrer l'URL et avoir 2+ serveurs dans 2+ centres de données différents, vous procurant resilliance et évolutivité. Vous devez ensuite trouver un remplacement lors de la promotion de votre site pour remplacer les chemins de contenu dev/uat par le chemin de contenu en direct (vous devez seulement le faire dans les fichiers CSS car vous pouvez stocker les chemins pour le contenu utilisé dans les fichiers aspx pour les données de configuration).