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

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.

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.

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.