Configuration de mon serveur pour une API très utilisée


9

Je vais bientôt acheter un tas de serveurs pour une application que je suis sur le point de lancer mais j'ai des inquiétudes concernant ma configuration. J'apprécie tous les commentaires que je reçois.

J'ai une application qui utilisera une API que j'ai écrite. D'autres utilisateurs / développeurs utiliseront également cette API. Le serveur API recevra les demandes et les transmettra aux serveurs de travail. L'API ne contiendra qu'une base de données mysql de requêtes à des fins de journalisation, d'authentification et de limitation de débit.

Chaque serveur de travail fait un travail différent et, à l'avenir, à l'échelle, j'ajouterai plus de serveurs de travail pour être disponible pour prendre en charge les travaux. Le fichier de configuration de l'API sera modifié pour prendre note des nouveaux serveurs de travail. Les serveurs de travail effectueront un traitement et certains enregistreront un chemin d'accès à une image vers la base de données locale pour être ultérieurement récupéré par l'API pour être visualisé sur mon application, certains renverront des chaînes du résultat d'un processus et l'enregistreront dans une base de données locale .

Cette configuration vous semble-t-elle efficace? Y a-t-il une meilleure façon de restructurer cela? Quels problèmes dois-je considérer? Veuillez voir l'image ci-dessous, j'espère que cela facilite la compréhension.entrez la description de l'image ici

Réponses:


17

Disponibilité accrue

Comme Chris le mentionne, votre serveur API est le seul point de défaillance de votre mise en page. Ce que vous configurez est une infrastructure de mise en file d'attente des messages, quelque chose que beaucoup de gens ont déjà implémentée.

Continuez sur le même chemin

Vous mentionnez la réception de demandes sur le serveur API et insérez le travail dans une base de données MySQL exécutée sur chaque serveur. Si vous souhaitez continuer sur ce chemin, je vous suggère de supprimer la couche serveur API et de concevoir les Workers pour chacun accepter les commandes directement de vos utilisateurs API. Vous pouvez utiliser quelque chose d'aussi simple que le DNS à tour de rôle pour distribuer chaque connexion utilisateur API directement à l'un des nœuds de travail disponibles (et réessayer si une connexion échoue).

Utiliser un serveur Message Queue

Des infrastructures de mise en file d'attente de messages plus robustes utilisent un logiciel conçu à cet effet comme ActiveMQ . Vous pouvez utiliser l'API RESTful d'ActiveMQ pour accepter les demandes POST des utilisateurs de l'API, et les travailleurs inactifs peuvent OBTENIR le message suivant dans la file d'attente. Cependant, c'est probablement exagéré pour vos besoins - il est conçu pour la latence, la vitesse et des millions de messages par seconde.

Utilisez Zookeeper

En tant que terrain d'entente, vous voudrez peut-être regarder Zookeeper , même s'il ne s'agit pas spécifiquement d'un serveur de file d'attente de messages. Nous utilisons at $ work dans ce but précis. Nous avons un ensemble de trois serveurs (analogues à votre serveur API) qui exécutent le logiciel serveur Zookeeper et disposent d'une interface Web pour gérer les demandes des utilisateurs et des applications. Le frontend web, ainsi que la connexion backend Zookeeper aux travailleurs, ont un équilibreur de charge pour s'assurer que nous continuons à traiter la file d'attente, même si un serveur est en panne pour maintenance. Une fois le travail terminé, le travailleur indique au cluster Zookeeper que le travail est terminé. Si un travailleur décède, ce travail sera envoyé à un autre travail pour terminer.

Autres préoccupations

  • Assurez-vous que les travaux sont terminés dans le cas où un travailleur ne répond pas
  • Comment l'API saura-t-elle qu'un travail est terminé et comment le récupérer dans la base de données du travailleur?
  • Essayez de réduire la complexité. Avez-vous besoin d'un serveur MySQL indépendant sur chaque nœud de travail, ou pourraient-ils parler au serveur MySQL (ou au cluster MySQL répliqué) sur le ou les serveurs API?
  • Sécurité. Quelqu'un peut-il soumettre un emploi? Y a-t-il une authentification?
  • Quel travailleur devrait obtenir le prochain emploi? Vous ne mentionnez pas si les tâches devraient prendre 10 ms ou 1 heure. S'ils sont rapides, vous devez supprimer les couches pour réduire la latence. S'ils sont lents, vous devez être très prudent pour vous assurer que les demandes plus courtes ne restent pas coincées derrière quelques-unes qui durent longtemps.

merci beaucoup pour votre excellente réponse. Je savais que la couche API était un goulot d'étranglement, mais cela semblait la seule façon de pouvoir ajouter plus de serveurs de travail sans avoir à informer les utilisateurs de l'application manuellement. Après avoir lu votre réponse entièrement, j'ai réalisé que oui, il serait préférable que chaque travailleur dispose de sa propre API. Bien que le code soit dupliqué lorsque j'ajoute plus de travailleurs, il est plus performant pour mon scénario.
Abs

@Abs - Merci pour mon premier vote positif! Si vous décidez de supprimer la couche API, je vous suggère de ne pas faire de DNS à tour de rôle et de configurer HAProxy (de préférence une paire) comme décrit dans cet article . De cette façon, vous n'avez pas besoin de gérer les délais d'attente.
Fanatique

@abs vous n'avez pas à supprimer la couche API, mais l'ajout de redondance (basculement CARP ou similaire) serait une considération importante pour éliminer le point de défaillance unique ...
voretaq7

En ce qui concerne la messagerie, je suggère de regarder attentivement RabbitMQ avant de vous décider: rabbitmq.com
Antonius Bloch

2

Le plus gros problème que je vois est le manque de planification de basculement.

Votre serveur API est un grand point de défaillance unique. S'il tombe en panne, alors rien ne fonctionne même si vos serveurs de travail sont toujours fonctionnels. En outre, si un serveur de travail tombe en panne, le service fourni par le serveur n'est plus disponible.

Je vous suggère de regarder le projet Linux Virtual Server ( http://www.linuxvirtualserver.org/ ) pour avoir une idée du fonctionnement de l'équilibrage de charge et du basculement, et pour avoir une idée de la façon dont ceux-ci peuvent bénéficier à votre conception.

Il existe de nombreuses façons de structurer votre système. La meilleure façon est un appel subjectif auquel vous répondez le mieux. Je vous suggère de faire quelques recherches; peser les compromis des différentes méthodes. Si vous avez besoin d'informations sur une méthode d'implantation, soumettez une nouvelle question.


Comment implémenteriez-vous un mécanisme de basculement dans ce scénario? Un aperçu général serait formidable.
Abs

À partir de votre diagramme, vous devez rechercher Linux Virtual Server (LVS). Allez sur linuxvirtualserver.org et commencez à apprendre tout ce que vous pouvez.
Chris Ting

Intéressant, j'examinerai cela et les basculements en général. D'autres commentaires sur ma configuration? D'autres dangers auxquels je pourrais faire face?
Abs

@Abs: Vous pouvez faire face à de nombreux problèmes. Votre question comporte beaucoup de parties subjectives, et je ne veux pas vous mettre dans ce que je ferais personnellement. Je n'ai pas à supporter votre configuration; tu fais. Ma vraie réponse est d'en savoir plus sur le basculement et la haute disponibilité.
Chris Ting
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.