L'objectif est de créer une nouvelle startup très chargée dans des conditions modernes. Nous envisagerons la création d'architecture en utilisant l'exemple de
Billingolang , un projet de facturation universel à usage général écrit en golang. Le projet comprend l'accès via l'API, le site Web, l'intégration dans les systèmes comptables, les rapports et les graphiques.
Les systèmes à un seul filetage ont d'abord été rejetés. J'ai dû choisir entre Erlang, Golang et Rust. Golang a été choisi comme langage de programmation principal, car il est difficile de trouver des programmeurs Erlang, bien que la stabilité et l'échange à chaud du code soient un plus pour Erlang. La rouille, malgré l'absence formelle de conditions de course, est toujours plus adaptée non pas à l'écriture d'applications, mais aux pilotes et aux systèmes d'exploitation.
La messagerie entre les composants du système ne se produit pas sur le
RabbitMQ classique, mais sur
NATS - ce dernier a montré des repères sur le serveur actuellement utilisé, 1M de messages (+ 360K pour le clustering) par seconde contre 40K pour un lièvre. Oui, et il se regroupe plus rapidement et plus facilement que RabbitMQ.
Base de données:
MySQL InnoDB Cluster 7.6 (serveur MySQL 8.0). Superbe outil de mise en page et de débogage de la communauté
MySQL Workbench .
API - écrite en
Swagger (OpenAPI 2.0). Cela évite les erreurs de différents programmeurs, génère du code propre et bien documenté et une documentation API. Malheureusement, Swagger utilise
gorilla / mux pour l'enracinement par défaut , mais après avoir généré l'intégralité de l'API, la racine sera refaite pour
kataras / muxie - c'est plus rapide.
Frontend: parmi les frameworks disponibles: Iris, Beego et Revel - Revel est sélectionné. Plus lent que Iris, mais tout est prêt à l'emploi, y compris l'intégration avec les graphiques. La charge principale sera toujours supportée par l'API.
Mise à l'échelle: tous les composants du système sont assemblés dans des conteneurs LXC, tandis que devant eux se trouve l'équilibreur
HAProxy . L'idée d'évoluer se résume à passer systématiquement à des serveurs plus puissants avec la préservation de la structure des conteneurs à mesure que les clients grandissent, puis à distribuer les conteneurs sur des serveurs séparés, en remplaçant HAProxy par NATS. En plus de la mise à l'échelle classique par matériel, il y a toujours la possibilité d'augmenter le nombre de goroutine à l'intérieur des conteneurs-gestionnaires pour demander l'API et le site. Bien que ce processus, comme le montre la pratique, ait des limites logiques.
En général, l'idée principale de l'article et ma profonde conviction est que l'architecture initiale des projets à forte charge, dans les conditions modernes, est inutile de s'appuyer sur des systèmes à un seul thread, malgré leurs années d'infrastructure développée et la présence d'un grand nombre de programmeurs disponibles. Et tout le schéma du projet doit être créé au départ en établissant un transfert facile vers des équipements plus puissants et distribués. Cela permettra à l'avenir de trouver facilement un équilibre entre la mise à l'échelle du matériel et du code, sans multiplier les coûts.
Une erreur courante et la plus courante commise par les nouvelles startups est un mauvais développement initial de l'architecture. Selon le principe - "commencez rapidement à écrire, puis nous le découvrirons." En règle générale, en conséquence - cela conduit à l'effondrement du projet.
Comme on dit - «90% du succès est la préparation». N'ayez pas peur de dépenser initialement pour créer une architecture compétente et réfléchie - elle sera payante.
Bonne chance