Impact sur les performances d'avoir une couche d'accès aux données / couche de service?

Question

J'ai besoin de concevoir un système qui a ces composants de base:

• Un serveur Web qui va recevoir ~ 100 demandes / sec. Le serveur Web n'a besoin que de vider les données dans le référentiel de données brutes.
• dépôt de données brutes qui a une seule table qui obtient 100 lignes / s du serveur web.
• Une unité de traitement des données brutes (traitement simple, pas beaucoup. La suppression des données brutes non valides, l'insertion d'éléments manquants dans les données brutes endommagées etc.)
• dépôt de données traitées

Est-il logique dans le système un tel d'avoir une couche de service sur lequel tous les composants seraient construits? Toutes les interactions entre composants passera par les couches de service. Bien que cela rendrait le système facilement extensible et maintenable, aurait-il pas aussi un impact significatif sur la performance puisque j'ai tellement de trafic à gérer?

Answer 1

Que voyez-vous les coûts d'avoir une couche de service distincte?

Comment ces coûts se comparent les coûts que vous doit encourent? Dans votre cas qui semble être au moins

1. un réseau lu pour la demande
2. une écriture de base de données pour les données brutes
3. une base de données lecture des données brutes
4. une écriture de la base de données des données traitées

Plus quelques munging de données.

Quel genre de services avez-vous un esprit? Peut-être

• saveRawData ()
• getNextRawData ()
• writeProcessedData ()

pourquoi les frais généraux plus qu'un appel de procédure? Service n'a pas besoin d'impliquer « processus distinct » ou « rassemblement de service Web ».

Je maintiens que la structure est toujours de la valeur, la séparation des préoccupations dans votre application est vraiment important. En comparaison avec les activités de base de données quelques appels de procédure seront rarement coûter beaucoup.

En passant: peut-être mieux fait de la persistance des données brutes à un système de mise en attente. Vous pouvez alors obtenir une mise à l'échelle naturelle en ayant beaucoup de lecteurs de file d'attente sur des machines distinctes si vous en avez besoin. En effet, le système de mise en attente est introduit naturellement certains concepts comme le service.

Answer 2

Voici ce qui peut arriver à moins que vous gardez contre.

Dans la communication entre les couches, un format est choisi, comme XML. Ensuite, vous construisez et exécutez et découvrez les performances ne sont pas satisfaisantes.

Ensuite, vous mess avec profileurs qui laissent deviner vous quel est le problème.

Quand je travaillais sur un problème comme celui-ci, je l'utilise technique de stackshot et a trouvé rapidement le problème. Vous auriez pensé qu'il était d'E / S. NE PAS. Il est que la conversion des données en XML et d'analyse XML pour récupérer la structure de données, prenait environ 80% du temps. Il n'a pas été trop difficile de trouver une meilleure façon de faire que . Résultat -. 5x speedup

Answer 3

Personnellement sentir que vous pourriez être trop se concentrer sur les détails de mise en œuvre de bas niveau lors de la conception du système. Avant d'examiner la façon de poser les composants, ensembles ou services que vous devriez penser à la façon de l'architecte du système.

Vous pourriez commencer par les déclarations de haut niveau suivants à partir de laquelle construire l'architecture de votre système autour de:

1. Confirmer l'ensemble des compétences techniques de l'équipe de développement et les opérations / équipe de soutien.
2. D'accord sur une liste finie initiale des systèmes qui intégrera à votre service, les protocoles qu'ils prennent en charge et des SLAs.
3. décider de la stratégie de messagerie.
4. Comprendre comment vous allez déployer votre service / système.
5. Décider du choix de middleware (ESBs, Message Brokers, etc.), les bases de données (SQL, Oracle, Memcache, DB2, etc.) et les cadres 3ème partie / outils.
6. Décidez de votre mise en cache et la stratégie de données.
7. cassez votre application dans les différents domaines de la responsabilité des entreprises -. Cela vous permettra de diviser le travail et permettre une communication plus facile des étapes au cours du développement / l'expérimentation et l'
8. Concevoir chaque composant au besoin pour répondre aux domaines de responsabilité. Les domaines de responsabilité devraient vous conduire automatiquement à décider de la façon de concevoir des composants, l'assemblage ou le service.

Il est évident que pas tous les ci-dessus va correspondre à votre cas spécifique, mais je dirais qu'ils devraient au moins donner une certaine pensée.

Bonne chance.

Answer 4

abstraction et tiering introduira la latence, mais la vraie question est, qu'est-ce que vous gagnons à rendre le coût (s) utile? couplage lâche, la gouvernance, l'évolutivité, maintenabilité valeur réelle $.

Même l'application en couches le mieux conçu présentera une latence plus d'une application de parler directement à un DB. Les utilisateurs qui connaissent le système d'origine se sentiront la différence. Ils peuvent ne pas aimer, donc cela peut être une question politique autant que technique.