2015-07-14 1 views
1

Nous travaillons sur une nouvelle architecture pour notre produit. Le produit sortant n'est pas exactement IoT - les appareils communiquent avec une seule boîte sur le site client et cette boîte communique avec nos serveurs.L'application communique directement avec la file d'attente des messages et la communication avec un proxy (service frontal)

Nous avons 2 options:

  1. La boîte envoyer un message directement à une file d'attente qui sera prise par le serveur de travailleurs et manipulé à elle est tour.
  2. La boîte enverra un message à un serveur frontal. Tout ce que fait le serveur est de mettre le message dans la file d'attente pour que le travailleur puisse le gérer.

Il existe des avantages et des inconvénients pour chaque méthode. Le numéro un pro pour communiquer directement avec la file d'attente est que nous n'avons pas besoin de dépenser de l'argent sur les machines pour maintenir les services frontaux. Le plus gros avantage de l'utilisation d'un serveur frontal est qu'il agit comme une couche d'abstraction par rapport à la technologie de file d'attente avec laquelle nous travaillons. Ainsi, si nous changeons la file, nous n'avons pas besoin de mettre à jour tous les clients. eux de continuer à travailler. Un autre avantage auquel nous pensons est qu'il nous permet de simuler des appels synchronios.

Bien sûr, il y a beaucoup de pour et de contre à chacun. Quelle est la manière suggérée de travailler? les meilleures pratiques? Sécurité?

+0

Quel protocole de messagerie comptez-vous utiliser? Est-ce mqtt? La communication bidirectionnelle avec les appareils est-elle requise? –

+0

@SergeiRodionov La plupart des chances ce sera AMQP. Certains services nécessiteront une communication bidirectionnelle. – developer82

+0

Je n'ai pas beaucoup d'expérience avec AMQP dans ce contexte. Nous utilisons mosquitto/mqtt pour la communication bidirectionnelle avec les points d'extrémité. Peut-être que vous pourriez enchaîner deux serveurs mqtt pour accomplir ce dont vous avez besoin. –

Répondre

0

Un aspect à prendre en compte est l'évolutivité. Vous devez prendre en charge les équilibreurs de charge pour cela.

Alors que certains protocoles de file d'attente de messages peuvent s'exécuter sur des équilibreurs de charge (voir par exemple Load blancing MQTT broker), je conseille de tester cela avant de prendre une décision. Si vous utilisez un REST ordinaire, la compatibilité de l'équilibreur de charge ne pose aucun problème.

Autres domaines à vérifier: * Compatibilité avec le pare-feu: est-ce que la "boîte" d'un netowkr différent (par exemple l'intranet de l'entreprise) est celle du serveur? Aussi dans ce cas, HTTP/REST est un choix plus sûr.