Quelle architecture est plus évolutive

Question

Je suis en train de développer une application pour Windows azure service cloud.

La description générale de l'application est assez simple: une extrémité avant sur MVC 4, un niveau intermédiaire pour le traitement des demandes de traitement frontaux et un backend SQL Azure/Blob ...

Je ne l'ai pas commencé à écrire du code jusqu'à présent, et avant cela, je voudrais obtenir des commentaires sur le scénario suivant qui serait plus évolutif et peut-être pourquoi. Si vous pensez qu'il y a une option N'thth que je n'ai pas envisagée, veuillez l'exposer! Pour être clair, l'application à un seul niveau est hors de question.

Scénario 1:
Front-End consomme un service WCF sur niveau intermédiaire qui fait tout le traitement.

Scénario 2:
Front-End consomme un service WCF sur niveau intermédiaire qui fait la queue qui demande un SB et attend. « Niveau 3 » consomme le message et le traite, faire la queue aussi la réponse pour le service WCF pour répondre ...

Scénario 3:
files d'attente frontaux un message et une boucle d'attente pour le message de réponse. "Niveau 3" consomme le message, le traite et le remet en file d'attente pour Front-End pour arrêter d'attendre ...

Fondamentalement toutes les questions reprennent à "Comment WCF évolue horizontalement?" ...

Answer 1

La solution la plus évolutive est celle que vous avez exclue: une application Web à un seul niveau sans état partagé pouvant contenir autant de nœuds que vous le souhaitez.Il n'y a rien de plus évolutif que n serveurs Web derrière un équilibreur de charge et m nœuds de base de données distribués. Puisque vous avez exclu l'architecture la plus évolutive, vous posez la mauvaise question, car vous n'êtes probablement pas à la recherche de l'évolutivité. Peut-être que vous regardez un autre principe architectural tel que la disponibilité. Pourquoi diviser la fonctionnalité entre plusieurs services? Il y a plusieurs raisons. Le traitement asynchrone permet une meilleure disponibilité (en écrivant dans une file d'attente et ne se souciant pas des échecs). Cela nous permet également de gérer les goulots d'étranglement, tels que la base de données. Nous divisons également notre application en services afin de faciliter le développement et le déploiement. Il peut s'agir de la disponibilité, de la maintenabilité, de la sécurité, de la performance, de la déployabilité, du coût, de la convivialité, de la testabilité, de la conformité ou de quelque chose d'autre que vous recherchez. Vous avez un peu besoin de répondre à cette question pour vous-même avant de saisir le marteau de l'évolutivité. J'ai écrit CALM spécifiquement pour aider à poser et à répondre à ces questions difficiles.

Retour aux spécificités de votre question. Le de facto modèle de traitement asynchrone qui est généralement évolutif (si c'est ce dont vous avez vraiment besoin) sur Windows Azure ne contient pas WCF. Y a-t-il une raison spécifique pour WCF? Il vaudrait mieux en faire un bon, car WCF et Service Bus, s'ils ne sont pas nécessaires, introduisent une complexité inutile. Sur Windows Azure, nous implémentons le traitement asynchrone avec des rôles Web (qui hébergent l'application MVC), qui placent des messages dans les files d'attente Windows Azure, qui sont traités par les rôles de travail. Si vous avez besoin du client (navigateur) pour connaître le résultat, vous pouvez lancer un modèle CQRS ou utiliser SignalR, comme d'autres personnes l'ont mentionné. Je serais sérieusement envisager de sortir WCF.

En termes de vos scénarios:

Scénario 0: serveurs web Apatrides font tout traitement et communiquer directement avec le noeud de base de données distribuée. C'est le plus évolutif, mais a d'autres inconvénients.

Scénario 4: Le serveur frontal place le message dans la file d'attente Azure et renvoie le résultat au client. Le rôle de travailleur traite le message et place le résultat à (stockage de table ou blob). Le navigateur interroge le Javascript pour les données de résultat et les présente au client quand c'est fait. C'est CQRS-ish. (réponse de Dunnry)

Scénario 5: Le serveur frontal place le message dans la file d'attente Azure et renvoie le résultat au client. Le rôle de travailleur traite le message et envoie le résultat au client via SignalR. (Réponse de jgauffin)

je préférerais le scénario 5

Answer 2

La messagerie est toujours la solution la plus évolutive car vous pouvez configurer n'importe quel nombre de travailleurs pour qu'ils consomment les messages et les traitent.

Le passage à la gestion asynchrone n'est cependant pas trivial si vous voulez toujours que l'interface utilisateur agisse de manière synchrone. Vous basculez typciellement vers l'interface utilisateur basée sur les tâches, où il n'y a pas de rétroaction immédiate aux utilisateurs (ou rétroaction fausse).

J'ai blogué sur la façon dont vous pouvez utiliser des requêtes, des événements de domaine et les commandes à l'échelle sur: http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/

Answer 3

Vous ne dites pas ce que les exigences sont avant la fin. Est-ce un site web qui attend une réponse avec des données? Généralement, un modèle de mise en file d'attente de messages sera plus évolutif (mais pas plus rapide) car vous disposez alors de nombreuses options pour traiter les demandes. Cependant, une fois que vous suivez ce chemin, il est plus difficile d'obtenir un feedback direct synchrone à l'utilisateur sans quelques astuces (SignalR peut être un choix ici). Pour ce que cela vaut, j'ai tendance à utiliser le modèle CQRS dans le nuage car il évolue bien pour ce dont j'ai besoin. Je dois gérer le fait que la commande est traitée async et que l'utilisateur n'a pas de réponse synchrone. L'interface utilisateur doit alors gérer cela. Nous utilisons une table de traitement de commandes avec statut. Le web (notre client dans ce cas) doit interroger cette table pour savoir quand une commande a été complétée afin de savoir quand essayer et afficher des résultats pour le client. Pour nous, c'est un bon compromis pour obtenir l'échelle que nous recherchons (et d'autres avantages du CQRS).