.NET performances ESB

Question

Je commence à concevoir une nouvelle version de l'un des produits de télécommunications de mon entreprise, et pour fournir l'équilibrage de charge et l'évolutivité, je considérais une sorte d'ESB (.NET open source). J'espère améliorer le débit du système en évitant les bases de données relationnelles et en utilisant (peut-être) des files d'attente non-transactionnelles alimentant des caches distribuées en mémoire (Velocity ou memcached par exemple).

Je n'ai jamais utilisé une architecture comme celle-ci pour un système en temps réel, et je suis inquiet que ce que je gagne en simplicité de développement au jour le jour, je perds en débit (qui pour cette application est hyper -critique). J'ai seulement joué avec NServiceBus, donc je n'ai aucune idée si elle (ou ses frères) est appropriée comme base pour les applications en temps réel sans sql. Qu'est-ce que tu penses?

Comment juger ces produits? Devrais-je acheter une application commerciale à la place, éviter ESB comme la peste, ou utiliser une autre approche?

Answer 1

Andrew,

Quand on parle de débit, les architectures à base de messages parallèles ont tendance à travailler très bien. NServiceBus a spécifiquement évolué à des niveaux très élevés, et lorsqu'il est utilisé conjointement avec des magasins persistants non verrouillés, il peut fonctionner de manière considérable. Quand vous parlez en temps réel, vous ne parlez pas de temps réel en temps réel - car vous êtes toujours sous Windows, et même pas en programmation en C/C++. En d'autres termes, il semble que l'objectif principal est le débit plutôt que la faible latence. Je pense que vous trouverez que les ESB peuvent très bien fonctionner pour vous.