51 votes

Dans quels domaines un middleware orienté message comme AMQP est-il utile?

Ce problème n'MOM (Message Oriented Middleware) résoudre? L'évolutivité? L'intégration?

Dans le domaine qui sont-ils généralement utilisé et dans quels domaines sont-ils généralement pas utilisés?

Par exemple, dire, c'est Google à l'aide de cette solution pour principal moteur de recherche, ou à la puissance de GMail?

Ce sujet des plus gros sites comme wal-mart, eBay, FedEx (à peu près un Java boutique) et buy.com (presque MS boutique)? Ne MAMAN résoudre un besoin là-bas?

Va-t-il de sens que lorsque vous écrivez une Application qui vous permet de contrôler le serveur-côté et avoir un environnement homogène (dire des dizaines d'instances Amazon EC2 exécutant tous Linux + Java Jvm) et où les clients sont, ainsi, des navigateurs Web?

Est-il judicieux pour les applications de bureau qui ont besoin de communiquer avec un serveur?

Ou est-ce "seulement" pour les grandes entreprises où vous avez généralement un heureux mélange d'un grand nombre de systèmes différents qui ont besoin de communiquer d'une manière ou d'une autre?

Je suis un peu confus quant à ce qu'ils sont utiles pour l', et je pense qu'avec l'exemple de l'endroit où ils sont appropriés et où ils ne sont pas appropriées j'ai pu mieux comprendre leur utilisation.

30voto

alexis Points 1099

C'est une grande question.

Les principaux usages de la messagerie sont: mise à l'échelle, le déchargement de travail, l'intégration, le suivi, la gestion des événements, de routage, de réseautage, de pousser, de mobilité, de mise en mémoire tampon, la mise en queue, partage des tâches, des alertes, la gestion, l'exploitation forestière, du lot, de la livraison des données, pubsub, multidiffusion, de l'audit, la planification, la ... et plus encore. En gros: rien où vous avez besoin de données, mais ne veulent pas faire une demande de base de données. (La mise en cache une autre, plus longue histoire).

Une autre façon de voir cela est de constater que de nombreuses applications utilisées à être construit en supposant que les utilisateurs (personnes) effectuer des actions qui seraient réalisées par l'exécution d'une transaction sur une base de données (y compris des lectures, des écritures). Mais aujourd'hui, de nombreuses actions ne sont pas initiées par l'utilisateur. Au lieu de cela ils sont lancés par l'application. Par exemple, "dites-moi quand le livre que je veux acheter est en stock". La meilleure façon de résoudre ce type de problèmes est à la messagerie d'une certaine sorte. Si vous l'appelez middleware ou push web ou en temps réel de la vinaigrette n'a pas d'importance. Il est tout de messagerie.

Lorsque vous activez les applications d'initier ou de réagir à des événements, alors il est beaucoup plus facile à l'échelle parce que votre architecture peut être basé sur des composants faiblement couplés. Il est également beaucoup plus facile à intégrer ces composants si votre messagerie est basé sur un support stable, évolutive, utilisable outil, de préférence à l'aide de open Api standards et des protocoles.

J'espère que cette aide. Nous essayons de maintenir une liste de liens utiles à propos de la messagerie ici

Veuillez entrer en contact avec des questions et des commentaires sur tout cela, nous sommes morts faciles à trouver.

13voto

alexis Points 1099

Pour répondre à vos questions spécifiques:

Dans le domaine qui sont-ils généralement utilisé et dans quels domaines sont-ils pas utilisé?

Comme les bases de données, systèmes de messagerie surgissent de partout.

Par exemple, dire, c'est Google à l'aide de cette solution pour principal moteur de recherche, ou à la puissance de GMail?

Google utilise beaucoup de cultivés à la maison de la technologie, mais beaucoup de leur ouvrir la source des cotisations et connu des cas d'utilisation suggèrent que la messagerie est (ou devrait être) centrale à quelques-uns des principaux services.

Ce sujet des plus gros sites comme wal-mart, eBay, FedEx (à peu près un Java boutique) et buy.com (presque MS boutique)? Ne MAMAN résoudre un besoin là-bas?

Très bien.

Un exemple de cas d'utilisation est mise à l'échelle de la page web demandes. Lorsque l'utilisateur effectue une requête web, le serveur web le met sur une file d'attente pour le traitement en arrière-plan. Cela signifie que le serveur web puisse continuer à travailler alors que la demande est traitée. Cela signifie également que le serveur web n'a pas besoin de connaître la façon dont la demande est traitée, le système de maintenance, de mise à niveau et de restauration beaucoup plus simple parce que les parties principales sont "découplé".

Donc, de toute façon, le web, la demande est traitée par un retour en fin de service, ou éventuellement par de nombreux services, par exemple 'rechercher le titre d'un livre', 'tirage panier", "obtenir de la publicité', 'vérifier le compte d'utilisateur'... Enfin, tous les résultats se mettre sur une autre file d'attente, prêt pour la collecte et la réponse de l'utilisateur par le serveur web. Généralement, le système comprend également un délai d'attente d'environ 100ms de sorte que toutes les demandes en retard juste sont jetés. L'utilisateur voit une chose qui les a traitées dans l'intervalle de temps. C'est une des raisons pourquoi certains grands sites de commerce électronique ont des pages qui s'affichent à charger dans les stades.

Il y a beaucoup plus de cas d'utilisation...

Va-t-il de sens que lorsque vous écrivez une Application qui vous permet de contrôler le serveur-côté et avoir un environnement homogène (dire des dizaines d'instances Amazon EC2 exécutant tous Linux + Java Jvm) et où les clients sont, ainsi, des navigateurs Web?

Certainement. Si vous avez un inconnu, ou non, le nombre d'utilisateurs, côté serveur cas, et l'application des latences, alors il est logique d'utiliser la messagerie, même si ce n'est qu'une solution évolutive substrat pour les non-blocage de la RPC.

Est-il judicieux pour les applications de bureau qui ont besoin de communiquer avec un serveur?

Dans beaucoup de cas. Un cas très commun est lorsque le serveur pousse des événements de l'application de bureau, par exemple, de jeu, tweets, les prix des alimentations dans les finances, système d'alertes....

Ou est-ce "seulement" pour les grandes entreprises où vous avez généralement un heureux mélange d'un grand nombre de systèmes différents qui ont besoin de communiquer d'une manière ou d'une autre?

Certainement pas uniquement pour les "legacy" l'intégration " des cas, mais ils sont aussi importantes. Au RabbitMQ, le plus gros clients, nous avons en termes de pure échelle ou le volume des messages sont les fournisseurs de cloud et de big fournisseurs d'applications web.

6voto

t0mm13b Points 21031

Je vais répondre une seule réponse, à partir de l'expérience préalable de prendre un coup d'oeil à ce middle-ware qui est utilisé par de grandes entreprises là - middle-ware a qu'un seul but - de la colle dis-systèmes connectés (écrit dans différentes langues) de telle sorte qu'ils peuvent interagir les uns avec les autres et de rationaliser les processus d'affaires - Entera que j'ai de l'expérience avec, crée une couche du milieu dans lequel la zone d'unix à l'aide de procédés écrit en C, d'interagir avec le système central (DB2, COBOL) par l'intermédiaire d'un avant la fin de l'écrit dans PowerBuilder (je ne suis pas de nommage de l'entreprise!).

À partir de la description que j'ai donné, Entera est un middle-ware, qui héberge un certain nombre de choses - intégration en douceur des flux de données, indépendamment de la endian format, la capacité pour les différentes langues pour parler de la middle-ware broker (courtier est un CORBA ou DCE comme processus, qui est conforme à " L'Open Group) qui écoute sur un port particulier) et est spécifiée par un IDL qui permet un processus semblent être locale - si vous comprendre la terminologie utilisée dans l'accès distant en vertu de Microsoft .NET Framework, vous n'êtes pas loin de la marque! Le middle-ware génère des talons qui sont liés au moment de la compilation et de gérer la création du processus, l'hébergement outre d'un port, multi-threading au moment de l'exécution, et aussi, les modernes front-end (tels que .NET, Java, PowerBuilder, même l'indicible VB6...ok...VB.NET pour les puristes) peuvent interagir par l'ouverture d'une connexion vers le port spécifié sur une adresse IP particulière, et en utilisant les bouchons générés, peut interagir directement avec elle.

De toute évidence, à partir de ce qui a été décrit, vous pouvez voir comment les systèmes existants peuvent avoir une nouvelle vie respirait en elle et donc l'évolutivité du processus, l'inconvénient majeur de ce est le coût de facteur qui peut s'exécuter en thousdands de dollars. Les grandes entreprises qui utilise des mainframes que de leurs systèmes de traitement de facturation, qui génèrent un énorme chiffre d'affaires peut évidemment se permettre un tel produit cher - pour eux, il semblerait que de jeter quelques centimes dans une piscine de l'eau...à cause de l'utilisation de la middle-ware qui prolonge le processus de l'entreprise, et de respirer une nouvelle vie, peut s'étendre de l'entreprise par un bon nombre d'années dans le futur sans se soucier d '"héritage" étiquette attachée à elle.

D'ailleurs, je l'ai réalisée dans le cadre de ma thèse, pour ma BSc. dans les Systèmes d'Information qui couvrait cette commerciale avant la fin de l'. Il y avait une version open source de la middle-ware disponible sur sourceforge appelé FreeDCE, mais les efforts de développement ont diminué ou arrêté.

Edit: @cocotwo: c'est exactement ce Que middle-ware fait comme vous avez dit c'est un outil de plomberie...message oriented middle-ware n'est pas vraiment entendu parler de autant que je sache, parce que j'imagine, le processus (fonctions) aurait besoin d'être appelée que si elles sont localement visibles dans le domaine d'application de l'avant-fin pour le rendre facile pour interagir avec.

À l'aide de messages peut avoir ses avantages par rapport à des appels RPC en ce que les messages sont en attente dans une zone d'attente dans le cas où un réseau de déconnexion se produit - il peut y avoir de mise en cache des données au sein de cet aspect pour permettre le front-end pour continuer, quel que soit...il pourrait être utile dans le cas de "mise à jour d'un statut particulier d'une facturation/numéro de facture" d'un chemin de données en écriture à la fin en passant par le moyen-vaisselle.

Ok, les grandes entreprises auraient avancé des systèmes d'infrastructure que les techniciens sont en permanence autour de l'horloge pour garantir une livraison de flux de données, de sorte que devrait être pris en compte. La société que j'ai travaillé avec IBM Global du contrat de Soutien à remplir afin d'assurer un maximum de disponibilité de 99% avec 6 neuf après la virgule...avec hot-swapping/équilibré-clusters/mise en miroir des systèmes en place...

Tandis qu'avec la RPC, si la déconnexion se produit, le front-end devrait être redémarré ou aurait pour gérer la déconnexion de l'événement. Ça dépend vraiment de si le message-la mise en attente du middle-ware poignées de chaque message en temps réel et de transmettre les résultats à l'avant-fin immédiatement...

C'est là que chacun (Message en attente et les RPC liées middle-ware) ont leurs forces et leurs faiblesses...et aussi le coût de facteur d'atténuation, telles que le soutien, le temps, les efforts de développement et de formation - c'est un biggie ici en tant que middle-ware sont vraiment de propriété (en dépit de la "Le Groupe" mise en page/normes) et complexes à configurer et à coller le tout ensemble via des scripts.

4voto

user378411 Points 31

De bonnes réponses et la discussion ici. Notre équipe de consultants a deux préféré "messagerie" solutions: RabittMQ et NXTera une haute vitesse de la RPC, de middleware, de la version contemporaine de Entera mentionnés ci-dessus. Mes partenaires et moi avons développé plusieurs solutions à l'aide de RabittMQ, c'est le meilleur outil disponible dans l'espace de droite maintenant. En outre, j'arrive de travailler pour la société qui fait de NXTera/Entera.

Par expérience, je peux clairement dire que ces deux produits répondent à un besoin de fiabilité et de faible entretien tel que discuté ci-dessus. Il y a des situations où un service de messagerie, comme RabittMQ, est le bon choix -- où Publier et s'abonner, certifié de livraison, les files d'attente ou store-and-forward sont nécessaires.

Dans d'autres cas, le protocole RPC (remote procedure calls) sont la meilleure et la plus rapide des solutions pour les transactions et le traitement distribué de l'entreprise ou des applications cloud. Quand il est en droit d'utiliser un RPC, mais le SAVON/.NET (oui ce sont des RPC implémentations) sont trop lents, coûteux ou complexe, une lightwieght haute vitesse RPC middleware comme NXTera/Entera est le bon choix pour nous.

Il y a quelques cas d'utilisation de chevauchement entre la RPC et de middleware message oriented middleware, et où il ya vous pouvez utiliser avec succès. Mais les deux sont solides et fiables choix.

Les grandes entreprises, je travaille avec l'utilisation à la fois de la RPC et de la Maman side-by-side. Autant que les entreprises de l'Internet, Google (Protocol Buffers) et Facebook (Épargne) montrent que la RPC est avoir un rôle à jouer dans le web moderne et du développement en nuage.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by: