Mikhail Salosin. Golang Meetup. Utilisation de Go dans le backend de l'application « Smotri+ »

Mikhail Salosin (ci-après – MS) : – Bonjour à tous ! Je m'appelle Mikhail. Je travaille en tant que développeur backend chez MC2 Software et je vais vous parler de l'utilisation de Go dans le backend de l'application mobile « Smotri+ ».

Y a-t-il des amateurs de hockey parmi vous ?

Alors cette application est faite pour vous. Elle est disponible sur Android et iOS, et permet de regarder en direct ou en replay différentes retransmissions d'événements sportifs. L'application propose également diverses statistiques, des retransmissions textuelles, des tableaux de conférences, de tournois, et d'autres informations utiles pour les fans.

L'application inclut aussi une fonctionnalité appelée moments vidéo, c'est-à-dire que vous pouvez revoir les moments forts des matchs (buts, bagarres, tirs au but, etc.). Si vous ne souhaitez pas regarder l'intégralité de la retransmission, vous pouvez vous concentrer uniquement sur les moments intéressants.

Qu'avons-nous utilisé pour le développement ?

La majeure partie a été écrite en Go. L'API utilisée par les clients mobiles a été développée en Go. De plus, un service pour l'envoi de notifications push aux mobiles a également été créé en Go. Nous avons également dû développer notre propre ORM, dont nous parlerons peut-être un jour. Quelques petits services, tels que le redimensionnement et le téléchargement d'images pour les éditeurs, ont également été réalisés en Go.

Comme base de données, nous avons utilisé PostgreSQL. L'interface pour les éditeurs a été réalisée en Ruby on Rails avec le gem ActiveAdmin. L'importation des statistiques du fournisseur de statistiques a également été écrite en Ruby.

Pour les tests système de l'API, nous avons utilisé unittest de Python. Memcached est utilisé pour limiter les requêtes à l'API de paiement, Chef pour la gestion de la configuration, Zabbix pour la collecte et la surveillance des statistiques internes du système. Graylog2 est utilisé pour la collecte des logs, et Slate pour la documentation de l'API à destination des clients.

Choix du protocole

Le premier problème auquel nous avons été confrontés : nous devions choisir un protocole d'interaction entre le backend et les clients mobiles, en tenant compte des éléments suivants...

• La principale exigence : les données des clients doivent être mises à jour en temps réel. Cela signifie que tous ceux qui regardent actuellement la retransmission doivent recevoir les mises à jour presque instantanément.
• Pour simplifier, nous avons supposé que les données synchronisées avec les clients ne sont pas supprimées, mais masquées à l'aide de drapeaux spéciaux.
• Diverses requêtes rares (comme des statistiques, des compositions d'équipes, des statistiques d'équipes) sont effectuées par des requêtes GET classiques.
• De plus, le système devait supporter tranquillement 100 000 utilisateurs simultanément.

Nous avions donc deux options de protocole :

1. Websockets. Mais nous n'avions pas besoin de canaux du client vers le serveur. Nous avions seulement besoin d'envoyer des mises à jour du serveur au client, donc le websocket est une option redondante.
2. Les événements envoyés par le serveur (Server-Sent Events, SSE) conviennent parfaitement ! C'est assez simple et répond en principe à tout ce dont nous avons besoin.

Événements envoyés par le serveur

Quelques mots sur le fonctionnement de ce système...

Il fonctionne par-dessus une connexion HTTP. Le client envoie une requête, à laquelle le serveur répond avec un Content-Type : text/event-stream et ne ferme pas la connexion avec le client, mais continue d'écrire des données dans la connexion :

Les données peuvent être envoyées dans un format convenu avec les clients. Dans notre cas, nous envoyions sous cette forme : dans le champ event, le nom de la structure modifiée (personne, joueur) était envoyé, et dans le champ data – un JSON avec les nouveaux champs modifiés pour le joueur.

Maintenant, parlons de la manière dont l'interaction fonctionne.

• Tout d'abord, le client détermine la dernière fois qu'il a synchronisé avec le service : il consulte sa base de données locale et détermine la date de la dernière modification qu'il a enregistrée.
• Il envoie une requête avec cette date.
• En réponse, nous lui envoyons toutes les mises à jour qui ont eu lieu depuis cette date.
• Après cela, il établit une connexion au canal en direct et ne le ferme pas tant qu'il a besoin de ces mises à jour :

Nous lui envoyons une liste de changements : si quelqu'un marque un but – le score du match est modifié, s'il se blesse – cela est également envoyé en temps réel. Ainsi, dans le fil d'événements du match, les clients reçoivent instantanément des données à jour. Périodiquement, pour que le client comprenne que le serveur n'est pas hors ligne, qu'il ne s'est rien passé, nous envoyons un timestamp toutes les 15 secondes – pour qu'il sache que tout va bien et qu'il n'est pas nécessaire de se reconnecter.

Comment la connexion en direct est-elle maintenue ?

• Tout d'abord, nous créons un canal sur lequel les mises à jour arriveront avec un tampon.
• Après cela, nous nous abonnissons à ce canal pour recevoir des mises à jour.
• Nous définissons l'en-tête approprié, afin que le client sache que tout va bien.
• Nous envoyons le premier ping. Nous enregistrons simplement le timestamp actuel de la connexion.
• Après cela, nous lisons en boucle à partir du canal tant que le canal de mises à jour n'est pas fermé. Le canal reçoit périodiquement soit l'horodatage actuel, soit des modifications que nous enregistrons dans les connexions ouvertes.

Le premier problème auquel nous avons été confrontés était le suivant : pour chaque connexion ouverte avec le client, nous créions un minuteur qui s'activait toutes les 15 secondes – donc, si nous avions 6 000 connexions ouvertes sur une machine (avec un seul serveur API), cela créait 6 000 minuteurs. Cela faisait que la machine ne supportait pas la charge nécessaire. Le problème n'était pas aussi évident pour nous, mais nous avons été un peu aidés et l'avons résolu.

En fin de compte, le ping provient désormais du même canal que celui des mises à jour.

Par conséquent, il n'y a qu'un seul minuteur qui s'active toutes les 15 secondes.

Ici, plusieurs fonctions auxiliaires – envoi d'en-tête, de ping et de la structure elle-même. Cela signifie qu'il passe le nom de la table (person, match, saison) et les informations relatives à cet enregistrement :

Le mécanisme d'envoi des mises à jour

Un peu sur la provenance des modifications. Nous avons plusieurs personnes, des rédacteurs, qui regardent la diffusion en temps réel. Ils créent tous les événements : quelqu'un a été expulsé, quelqu'un s'est blessé, un remplacement…

Avec l'aide de la CMS, les données entrent dans la base. Après cela, la base utilise le mécanisme Listen/Notify pour informer les serveurs API. Les serveurs API distribuent ensuite cette information aux clients. Ainsi, nous avons en fait seulement quelques serveurs connectés à la base et aucune charge particulière sur la base, car le client n'interagit en aucune façon directement avec celle-ci :

PostgreSQL : Listen/Notify

Le mécanisme Listen/Notify dans PostgreSQL permet d'informer les abonnés des événements qu'un certain événement a été modifié – qu'un enregistrement a été créé dans la base. Pour cela, nous avons écrit un simple déclencheur et une fonction :

Lors de l'insertion ou de la modification d'un enregistrement, nous invoquons la fonction notify sur le canal data_updates, en passant le nom de la table et l'identifiant de l'enregistrement qui a été modifié ou inséré.

Pour toutes les tables qui doivent être synchronisées avec le client, nous définissons un déclencheur qui, après la modification/mise à jour de l'enregistrement, appelle la fonction indiquée sur la diapositive ci-dessous.
Comment l'API s'abonne-t-elle à ces modifications ?

Un mécanisme Fanout est créé – il envoie des messages aux clients. Il regroupe tous les canaux des clients et diffuse les mises à jour qu'il a reçues par ces canaux :

Voici la bibliothèque standard pq, qui se connecte à la base de données et indique qu'elle souhaite écouter le canal (data_updates), vérifie que la connexion est ouverte et tout est normal. Je passe la vérification des erreurs pour gagner de la place (ne pas vérifier peut être risqué).

Ensuite, nous définissons de manière asynchrone un Ticker, qui enverra un ping toutes les 15 secondes, et nous commençons à écouter le canal auquel nous sommes abonnés. Si nous recevons un ping, nous publions ce ping. Si nous recevons un enregistrement quelconque, nous publions cet enregistrement à tous les abonnés de ce Fanout.

Comment fonctionne le Fan-out ?

En français, cela se traduit par « répartiteur ». Nous avons un objet qui enregistre les abonnés qui souhaitent recevoir des mises à jour. Et dès qu'une mise à jour arrive à cet objet, il distribue cette mise à jour à tous les abonnés qu'il a. C'est assez simple :

Comment cela est implémenté en Go :

Il y a une structure, qui est synchronisée à l'aide de Mutex. Elle a un champ qui conserve l'état de la connexion Fanout à la base, c'est-à-dire qu'à ce moment, elle écoute et recevra des mises à jour, ainsi qu'une liste de tous les canaux disponibles – une map, dont la clé est le canal et une struct sous forme de valeurs (qui, en réalité, n'est pas utilisée).

Deux méthodes – Connected et Disconnected – permettent d'indiquer au Fanout que nous avons une connexion avec la base, qu'elle est établie et que la connexion à la base a été rompue. Dans ce dernier cas, il faut déconnecter tous les clients et leur faire savoir qu'ils ne peuvent plus écouter et qu'ils doivent se reconnecter, car la connexion avec eux est fermée.

Il existe également une méthode Subscribe, qui ajoute un canal aux « écouteurs » :

Il y a une méthode Unsubscribe, qui retire le canal des écouteurs, si le client s'est déconnecté, ainsi qu'une méthode Publish, permettant d'envoyer un message à tous les abonnés.

Question: – Qu'est-ce qui est transmis par ce canal ?

MS : – Un modèle qui a changé ou un ping (essentiellement juste un nombre, un entier).

MS : – On peut transmettre n'importe quoi, n'importe quelle structure, la publier – elle est simplement convertie en JSON et c'est tout.

MS : Nous recevons une notification de « Postgres » - elle contient le nom de la table et l'identifiant. Avec le nom de la table, nous obtenons l'enregistrement dont nous avons besoin à partir de l'identifiant, puis nous envoyons cette structure pour publication.

Infrastructure

Comment cela se présente-t-il du point de vue de l'infrastructure ? Nous avons 7 serveurs physiques : l'un d'eux est entièrement dédié à la base de données, tandis que les six autres exécutent des machines virtuelles. Nous avons 6 copies de l'API : chaque machine virtuelle avec l'API fonctionne sur un serveur physique séparé - c'est pour la fiabilité.

Nous avons deux frontaux, dotés de Keepalived pour améliorer la disponibilité, afin qu'en cas de problème, un frontal puisse remplacer l'autre. De plus, nous avons deux copies du CMS.

Il y a aussi un importateur de statistiques. Il existe une base de données esclave, d'où des sauvegardes sont périodiquement effectuées. Il y a Pigeon Pusher - l'application qui envoie des notifications push aux clients, ainsi que des éléments d'infrastructure : Zabbix, Graylog2 et Chef.

En réalité, cette infrastructure est surdimensionnée, car 100 000 utilisateurs peuvent être servis avec moins de serveurs. Mais comme nous avions le matériel - nous l'avons utilisé (on nous a dit que c'était possible - alors pourquoi pas).

Les avantages de Go

Après avoir travaillé sur cette application, certains avantages évidents de Go se sont révélés.

• Une excellente bibliothèque HTTP. Grâce à elle, on peut créer beaucoup de choses "prêtes à l'emploi".
• En plus, des canaux qui nous ont permis de réaliser très facilement le mécanisme d'envoi de notifications aux clients.
• Le détecteur de concurrence est une fonctionnalité remarquable qui nous a permis de corriger plusieurs bugs critiques (infrastructure de staging). Tout ce qui fonctionne sur le staging est lancé, compilé avec l'option Race ; et nous, en conséquence, pouvons vérifier sur l'infrastructure de staging les problèmes potentiels que nous pourrions avoir.
• Minimalisme et simplicité du langage.

Nous recherchons des développeurs ! Si quelqu'un est intéressé, n'hésitez pas.

Questions

Question de l'auditoire (Q) : - J'ai l'impression que vous avez omis un point important concernant le Fan-out. Est-ce que je comprends bien que lorsque vous envoyez une réponse au client, vous vous bloquez si le client ne souhaite pas lire ?

MS : – Non, nous ne sommes pas bloqués. Tout d'abord, tout cela est derrière nginx, donc il n'y a aucun problème avec les clients lents. Deuxièmement, le client dispose d'un canal avec un tampon – en gros, nous pouvons y mettre jusqu'à cent mises à jour... Si nous ne pouvons pas écrire dans le canal, il l'efface. Si nous voyons que le canal est bloqué, nous fermons simplement le canal, et c'est tout – le client se reconnectera s'il y a un problème. Donc, il n'y a en principe pas de blocage ici.

Q : – N'aurait-il pas été possible d'envoyer immédiatement l'enregistrement dans Listen/Notify plutôt que dans une table-identifiant ?

MS : – Listen/Notify a une limite de 8000 octets sur le preload qu'il envoie. En principe, cela aurait pu être envoyé si nous avions affaire à un petit volume de données, mais je pense que [comme nous le faisons] c'est simplement plus fiable. Les limitations viennent du « PostgreSQL » lui-même.

Q : – Les clients reçoivent-ils des mises à jour sur les matchs qui ne les intéressent pas ?

MS : – En général, oui. En règle générale, il y a 2-3 matchs en parallèle, et c'est assez rare. Si un client regarde quelque chose, c'est généralement le match en cours. De plus, le client dispose d'une base de données locale où toutes ces mises à jour sont stockées, et même sans connexion Internet, le client peut consulter tous les matchs précédents pour lesquels il a des mises à jour. En gros, nous synchronisons notre base de données sur le serveur avec la base de données locale du client, afin qu'il puisse travailler en mode hors ligne.

Q : – Pourquoi avez-vous créé votre propre ORM ?

Alexey (un des développeurs de « Smotri+ »): – À l'époque (c'était il y a un an), il y avait moins d'ORM qu'aujourd'hui, où il y en a beaucoup. Parmi la majorité des ORM existants, je trouve que ce que je n'aime pas le plus, c'est que beaucoup d'entre elles fonctionnent sur des interfaces vides. Cela signifie que les méthodes de ces ORM sont prêtes à accepter n'importe quoi : une structure, un pointeur de structure, un nombre, quelque chose de complètement hors de propos...

Notre ORM génère des structures sur la base du modèle de données. Tout seul. Et donc, toutes les méthodes sont concrètes, n'utilisent pas la réflexion, etc. Elles acceptent des structures et s'attendent à utiliser les structures qui arrivent.

Q : – Combien de personnes ont participé ?

MS : – Au début, deux personnes ont participé. Nous avons commencé vers juin, en août la majeure partie était prête (première version). En septembre, il y a eu la sortie.

Q : – Là où vous décrivez SSE, vous n'utilisez pas de timeout. Pourquoi cela ?

MS : Si l'on parle franchement, le SSE est tout de même un protocole html5 : la norme SSE est conçue pour communiquer avec les navigateurs, autant que je sache. Il a des fonctionnalités supplémentaires pour que les navigateurs puissent se reconnecter (et autres), mais elles ne nous sont pas nécessaires, car nous avions des clients capables de réaliser n'importe quelle logique de connexion et d'obtention d'informations. Nous avons plutôt créé quelque chose de semblable au SSE, mais ce n'est pas le protocole lui-même.
Il n'y avait pas de nécessité. Autant que je sache, les clients ont mis en œuvre le mécanisme de connexion pratiquement à partir de zéro. En gros, cela ne leur importait pas.

Q : Quelles utilitaires supplémentaires avez-vous utilisés ?

MS : Nous avons principalement utilisé govet et golint pour assurer une cohérence de style, ainsi que gofmt. Nous n'avons rien utilisé de plus.

Q : Comment avez-vous effectué le débogage ?

MS : Pour être franc, le débogage se faisait principalement à l'aide de tests. Nous n'avons utilisé aucun débogueur, nous n'avons pas utilisé GOP.

Q : Pouvez-vous revenir à la diapositive où la fonction Publish est implémentée ? Les noms de variables à une lettre ne vous dérangent pas ?

MS : Non. Leur portée est suffisamment « étroite ». Elles ne sont utilisées nulle part ailleurs, sauf ici (à part à l'intérieur de cette classe), et c'est un code très compact – seulement 7 lignes.

Q : Tout ceci n'est pas très intuitif...

MS : Non-non, c'est du vrai code ! Ce n'est pas une question de style. C'est juste une petite classe utilitaire – seulement 3 champs à l'intérieur de la classe...

MS : Dans l'ensemble, toutes ces données synchronisées avec les clients (matchs saisonniers, joueurs) ne changent pas. En gros, si nous créons un autre type de sport où il faudra modifier un match, nous prendrons simplement en compte cela dans une nouvelle version du client, et les anciennes versions seront bloquées.

Q : Y a-t-il des packages tiers pour la gestion des dépendances ?

MS : Nous avons utilisé go dep.

Q : Dans le sujet de la présentation, il y avait quelque chose sur la vidéo, mais il n'y a rien sur la vidéo dans la présentation.

MS : Non, je n'ai rien sur la vidéo dans ma présentation. Ça s'appelle « Savy+ » – c'est ainsi que se nomme l'application.

Q : Vous avez dit que ça se diffuse sur les clients ?

MS : Nous ne traitions pas de la vidéo en streaming. Cela était entièrement géré par « MegaFon ». Oui, je n'ai pas mentionné que c'est une application de MegaFon.

MS : – Go – pour l'envoi de toutes les données – concernant le compte, les événements du match, les statistiques… Go – c'est entièrement le backend de l'application. Le client doit savoir d'où obtenir le lien à utiliser pour le lecteur, afin que l'utilisateur puisse regarder le match. Nous avons des liens vers des vidéos et des streams qui sont prêts.

Un peu de publicité 🙂

Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, VPS cloud pour développeurs à partir de 4,99 $, un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : Toute la vérité sur le VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbps à partir de 19 $ ou comment bien diviser un serveur ? (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).

Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64Go DDR4 4x960Go SSD 1Gbps 100 To à partir de 199 $ aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur Comment construire une infrastructure de classe entreprise avec des serveurs Dell R730xd E5-2650 v4 coûtant 9000 euros pour des clopinettes ?

Source : habr.com