Principes de l'architecture

L'architecture de Zato reflète plusieurs concepts fondamentaux qui sous-tendent la conception de la plate-forme. Chaque composant de l'architecture tient compte de chacun de ces concepts.

Concept Signification
Un large spectre d'utilisation De l'IdO à l'IA et l'apprentissage automatique, en passant par les API, le transfert de fichiers, les systèmes backend d'entreprise et les ordinateurs centraux. Zato est destiné à être utilisé pour construire un large éventail de systèmes intégrés.
Productivité Le temps des développeurs est de la plus haute importance. La conception de la plateforme permet de construire rapidement des environnements d'intégration simples ou complexes. Python est l'outil le plus productif pour les intégrations et c'est pourquoi Zato est en Python.
Excellence opérationnelle La facilité d'utilisation et les capacités de suivi permettent d'améliorer constamment les processus, les plans et les procédures. Les résultats de votre travail doivent être facilement reproductibles dans différents contextes, environnements ou projets.
Évolutivité Il devrait être facile de faire évoluer les environnements, quelle que soit l'approche de déploiement privilégiée, qu'elle soit basée sur le cloud, sur des promesses, hybride, sur bare metal, Docker ou Kubernetes. Toute combinaison peut être utilisée.
Haute disponibilité Les intégrations sont au cœur même de toute organisation ou de tout projet et il est essentiel que la plate-forme élimine les points de défaillance uniques, qu'elle assure une redondance et qu'elle offre des moyens pratiques pour effectuer des mises à niveau ou des tâches de maintenance.
Sécurité Une plateforme d'intégration doit s'attendre à être régulièrement attaquée par des acteurs malveillants. Le choix même de Python, un langage sécurisé de très haut niveau, et la résilience de la plate-forme aux attaques font partie intégrante de la conception.
La simplicité au détriment de la complexité La bonne façon de construire des systèmes avancés et critiques consiste à les rendre aussi simples que possible, mais pas plus. Les composants et pièces individuels doivent être faciles à comprendre et à maîtriser.

Les principes susmentionnés sont à la base de la conception de Zato, ce qui conduit directement à l'aspect de son architecture.

Architecture d'exécution

Composant Discussion
Clusters
  • Chaque environnement Zato contient un ou plusieurs clusters. Un cluster est une collection logique de serveurs et de composants de support.
  • Les clusters peuvent fonctionner sur place, dans le cloud, directement sous Linux ainsi qu'en utilisant Docker, Kubernetes ou Vagrant.
  • Il est tout à fait possible de disposer de plusieurs clusters à des fins particulières, par exemple un pour REST et AMQP et un autre pour l'IA et le ML.
  • Un type particulier de cluster est appelé cluster quickstart. Un tel cluster peut être créé en quelques secondes, à l'aide d'une seule commande, afin de disposer rapidement d'un environnement de travail.
  • Il s'agit d'une excellente façon de commencer à utiliser Zato, car elle ne nécessite aucun travail supplémentaire. Le résultat est un environnement entièrement fonctionnel qui fonctionne avec tous les composants sur un seul hôte.
  • Les clusters Quickstart peuvent être utilisés pour les environnements de développement, de test et de production.
Serveurs
  • Les serveurs sont des conteneurs pour les services et les applications. C'est là que fonctionnent les API et les sujets de publish/subscribe.
  • Dans l'esprit de l'informatique en cloud, pour faire évoluer les environnements horizontalement, il est possible d'ajouter des serveurs à un cluster.
  • Pour faire évoluer les serveurs verticalement, il est possible d'affecter davantage de CPU à chaque serveur.
  • Les serveurs fonctionnent dans une configuration active-active, sauf si l'équilibreur de charge est configuré pour ne pas diriger les demandes vers un serveur particulier.
  • Les serveurs peuvent être ajoutés, supprimés et reconfigurés à la volée.
  • Les serveurs synchronisent leur configuration automatiquement, par exemple le déploiement d'un nouveau service sur un serveur est auto-synchronisé avec tous les autres serveurs du cluster.
Load balancer
  • L'équilibreur de charge à haute disponibilité peut être intégré ou externe.
  • L'utilisation d'un équilibreur de charge est facultative. S'il n'est pas nécessaire, par exemple s'il n'y a qu'un seul serveur dans un cluster ou s'il fonctionne sous Kubernetes, il n'est pas nécessaire de créer l'équilibreur de charge.
Dashboard
  • Une interface graphique basée sur le web pour la gestion des serveurs fonctionnant dans les clusters.
CLI et API
  • Tout ce qui peut être fait à l'aide du tableau de bord est également disponible via le CLI et l'API pour l'automatisation DevOps.

Meilleures pratiques

Apprenez à concevoir des environnements avec un objectif spécifique en tête :