Première partie, dans laquelle le lecteur se familiarisera avec un bref historique de l'émergence des produits internes 2GIS et de l'évolution du système de livraison de données de plusieurs scripts à une application à part entière.Aujourd'hui, je vais vous raconter une histoire qui a commencé il y a 9 ans chez DublGIS.
Je viens de trouver un emploi là-bas. J'ai dû gérer le module d'exportation des données d'un grand système interne pour nos produits externes. Et dans cet article, je veux partager avec vous comment nous avons divisé ce monolithe en plusieurs parties, comment un monstre a généré plusieurs dizaines de produits et comment tous ces produits et projets ont été intégrés au niveau des données entre eux.
Je dois dire que ce n'est qu'un article de revue sans aucun détail technique. La technique sera dans la deuxième partie, dans laquelle nous parlerons de l'exportation de données. En attendant, seule lecture légère sans matan avec une mention superficielle de la technologie.
Allons-y. Loin 2010 Ensuite, 2GIS était encore un tube DoubleGIS, à partir de produits externes il y avait une version de bureau et une primitive en ligne et une version pour PDA. Et l'intérieur consistait en un système de mise à jour pour les utilisateurs de notre version PC et un monstre appelé DGPP, qui combinait des outils pour éditer le répertoire des organisations et des cartes, CRM et exporter des données vers les produits finaux. La base de données était dans Firebird. Le système était décentralisé. Chaque ville avait sa propre installation et sa propre base de données. L'intégration primitive a été fournie via les exportations / importations de fichiers. Et là-dessus, c'est tout.
DGPP lui-même était une application C ++ avec un ensemble de scripts VBA. Initialement, un bureau tiers a développé ce système pour DublGIS, et ce n'est qu'avec le temps que l'entreprise a pris le développement du système sous son toit, formant sa propre R&D. Le développement de DGPP est devenu de plus en plus difficile.
Et ce fut l'époque du développement rapide de DublGIS. De nouvelles villes s'ouvraient. La version mobile pour smartphones était en préparation. De nouvelles fonctionnalités sont apparues. Un modèle publicitaire se développait. En général, un grand nombre de modifications étaient nécessaires et devaient être apportées rapidement.
La première chose que nous avons commencé à démonter DGPP en morceaux a été l'exportation. Nous l'avons intégré dans une application distincte, qui est un service Windows avec un museau sur WPF. En parallèle, des travaux étaient en cours sur un nouveau CRM. Pour gagner du temps à cette époque, Microsoft Dynamics CRM a été choisi comme plate-forme de base.
En ce qui concerne l'exportation, il vous suffisait d'apprendre à extraire des données de Firebird et à extraire toute la logique de préparation des données à partir de scripts VBA. De plus, certains algorithmes de transport des données ont été mis en œuvre sur les avantages. Ils ont dû être réécrits sur des objets tranchants.
Ici, il convient de prêter attention à un point. Notre bureau DoubleGIS a consommé des données dans un format binaire spécial, qui a été préparé par une bibliothèque C ++ enveloppée dans un objet COM. Et puis il était tout à fait logique de l'utiliser, se connectant simplement comme référence au projet. Ce n'est pas la meilleure solution, mais j'en parlerai plus tard.
Au fil du temps, nous avons lancé une version mobile et un nouveau CRM. Un nouveau produit externe est apparu à l'horizon - l'API publique 2GIS. Et de la DGPP, ils ont déjà commencé à isoler un sous-système pour travailler avec un répertoire d'organisations nommé InfoRussia.
A l'export, il est devenu nécessaire de lire les données publicitaires de deux systèmes: l'ancien DGPP et le nouveau CRM. En outre, la mise en œuvre du CRM se faisait progressivement, c'est-à-dire que dans certaines villes, il ne restait jusqu'à présent que le DGPP, tandis que dans d'autres, le DGPP fonctionnait simultanément avec un annuaire et une carte et un CRM avec des informations commerciales. En outre, à long terme, la publication d'InfoRussia, qui s'est déroulée sur plusieurs mois, a brillé.
Les nouveaux systèmes introduisaient la complexité non seulement par leur apparence. Ils ont changé le concept de déploiement. Contrairement au DGPP décentralisé qui se trouvait dans chaque ville, ces systèmes étaient centralisés, chacun avec son propre SGBD dodu. De plus, ils devaient échanger des données.
Pour résoudre ce problème, nous avons implémenté notre Enterprise Service Bus (ESB). À cette époque, il n'existait pratiquement pas de solutions mûres qui garantiraient la satisfaction de certaines exigences fonctionnelles importantes pour nous: la capacité de transmettre du XML, l'ordre des messages et la garantie de livraison. Ensuite, nous avons opté pour SQL Server Broker, qui a fourni tout ce qui était nécessaire. Certes, il avait une vitesse de livraison plutôt médiocre, mais à ce moment-là, elle était assez satisfaite de nous.
La dernière étape a été la sortie d'un service de carte appelé Fidji. Il a partiellement téléchargé ses données dans le bus. Cela concernait les répertoires et les classificateurs. Les géodonnées peuvent lui être extraites via l'API Rest, également utilisée par
le client fidjien lui
- même
, écrite en WPF .
Dans cette architecture, l'exportation était centrale. Grâce à elle, tous les flux de données ont été fusionnés en un seul référentiel et distribués aux produits finaux et à nos utilisateurs.
De plus, ce n'était qu'une petite partie de l'iceberg. L'automatisation des processus internes, l'émergence de nouvelles exigences et de nouvelles fonctionnalités ont conduit à l'émergence d'un grand nombre de produits. Il était nécessaire de faire des analyses, de travailler avec les commentaires des utilisateurs, d'introduire de nouveaux modèles de vente et de nouveaux produits commerciaux, de développer des algorithmes de recherche, de transport et, en général, des produits externes.
D'une part, l'exportation a un grand nombre de fournisseurs de données et, d'autre part, un grand nombre de consommateurs, chacun souhaitant recevoir des données sous une forme spécifique et les exécuter via des algorithmes de préparation spéciaux.
Et puis mon histoire a pris fin.
Dans la deuxième partie de l'article, je vais vous parler d'Export et vous raconter comment il a survécu à tous ces changements. Il n'y aura pas d'histoires, mais il y aura des approches spécifiques que nous avons appliquées pour résoudre une liste spécifique de tâches.