Erster Teil, in dem der Leser einen kurzen Überblick über die Entstehung interner 2GIS-Produkte und die Entwicklung des Datenlieferungssystems von mehreren Skripten zu einer vollwertigen Anwendung erhält.Heute werde ich Ihnen eine Geschichte erzählen, die vor 9 Jahren bei DublGIS begann.
Ich habe gerade einen Job dort bekommen. Ich musste mich mit dem Modul zum Exportieren von Daten aus einem großen internen System für unsere externen Produkte befassen. Und in diesem Artikel möchte ich Ihnen mitteilen, wie wir diesen Monolithen in mehrere Teile geteilt haben, wie ein Monster mehrere Dutzend Produkte erzeugt hat und wie all diese Produkte und Projekte auf Datenebene untereinander integriert wurden.
Ich muss sagen, dass dies nur ein Übersichtsartikel ohne technische Details ist. Die Technik wird im zweiten Teil sein, in dem wir über den Datenexport sprechen werden. In der Zwischenzeit nur leichtes Lesen ohne Matan mit oberflächlicher Erwähnung der Technik.
Lass uns gehen. Far 2010 Damals war 2GIS noch ein Röhren-DoubleGIS, von externen Produkten gab es eine Desktop-Version und eine primitive Online-Version sowie eine Version für PDAs. Das Innere bestand aus einem Update-Bereitstellungssystem für Benutzer unserer PC-Version und einem Monster namens DGPP, das Tools zum Bearbeiten eines Verzeichnisses von Organisationen und Karten, CRM und zum Exportieren von Daten in Endprodukte kombinierte. Die Datenbank befand sich in Firebird. Das System wurde dezentralisiert. Jede Stadt hatte ihre eigene Installation und eine eigene Datenbank. Die primitive Integration wurde durch Dateiexporte / -importe bereitgestellt. Und im Großen und Ganzen ist das alles.
DGPP selbst war eine C ++ - Anwendung mit einer Reihe von VBA-Skripten. Ursprünglich entwickelte ein Drittbüro dieses System für DublGIS, und erst mit der Zeit nahm das Unternehmen die Entwicklung des Systems unter sein Dach und gründete eine eigene Forschungs- und Entwicklungsabteilung. Die Entwicklung von DGPP ist immer schwieriger geworden.
Und dies war die Zeit der rasanten Entwicklung von DublGIS. Neue Städte wurden eröffnet. Die mobile Version für Smartphones wurde vorbereitet. Neue Funktionen wurden angezeigt. Ein Werbemodell entwickelte sich. Im Allgemeinen war eine große Anzahl von Änderungen erforderlich, die schnell durchgeführt werden mussten.
Das erste, was wir begannen, DGPP in Stücke zu zerlegen, war der Export. Wir haben es in eine separate Anwendung gezogen, bei der es sich um einen Windows-Dienst mit einem Maulkorb auf WPF handelt. Parallel dazu wurde an einem neuen CRM gearbeitet. Um zu diesem Zeitpunkt Zeit zu sparen, wurde Microsoft Dynamics CRM als Basisplattform ausgewählt.
Für den Export mussten Sie lediglich lernen, wie Sie Daten aus Firebird extrahieren und die gesamte Logik zum Vorbereiten von Daten aus VBA-Skripten herausholen. Zusätzlich wurden einige Algorithmen für Transportdaten auf den Pluspunkten implementiert. Sie mussten in scharfe Gegenstände umgeschrieben werden.
Hier lohnt es sich, auf einen Punkt zu achten. Unser Desktop-DoubleGIS verbrauchte Daten in einem speziellen Binärformat, das von einer in ein COM-Objekt eingebundenen C ++ - Bibliothek erstellt wurde. Und dann war es ziemlich logisch, es einfach als Referenz für das Projekt zu verwenden. Nicht die beste Lösung, aber ich werde später darüber sprechen.
Im Laufe der Zeit haben wir eine mobile Version und ein neues CRM eingeführt. Ein neues externes Produkt ist am Horizont aufgetaucht - die öffentliche API 2GIS. Und von DGPP haben sie bereits begonnen, ein Subsystem für die Arbeit mit einem Verzeichnis von Organisationen mit dem Codenamen InfoRussia zu isolieren.
Beim Export wurde es notwendig, Werbedaten aus zwei Systemen zu lesen: dem alten DGPP und dem neuen CRM. Darüber hinaus wurde die Implementierung von CRM schrittweise vorangetrieben, dh in einigen Städten blieb bisher nur DGPP übrig, während in anderen Städten DGPP gleichzeitig mit einem Verzeichnis und einer Karte und CRM mit kommerziellen Informationen arbeitete. Darüber hinaus war auf lange Sicht die Veröffentlichung von InfoRussia, die über mehrere Monate stattfand, glänzend.
Neue Systeme führten Komplexität nicht nur durch ihr Aussehen ein. Sie haben das Konzept der Bereitstellung geändert. Im Gegensatz zur dezentralen DGPP, die in jeder Stadt stand, wurden diese Systeme zentralisiert, jedes mit seinem eigenen prallen DBMS. Außerdem mussten sie Daten austauschen.
Um dieses Problem zu lösen, haben wir unseren Enterprise Service Bus (ESB) implementiert. Zu dieser Zeit gab es praktisch keine ausgereiften Lösungen, die die Erfüllung einiger wichtiger funktionaler Anforderungen für uns sicherstellen würden: die Fähigkeit zur Übertragung von XML, die Reihenfolge der Nachrichten und die Garantie der Zustellung. Dann haben wir uns für SQL Server Broker entschieden, der sofort alles Notwendige gab. Zwar hatte er eine eher mittelmäßige Liefergeschwindigkeit, aber zu dieser Zeit war sie ziemlich zufrieden mit uns.
Der letzte Schritt war die Veröffentlichung eines Kartendienstes namens Fidschi. Er hat seine Daten teilweise in den Bus hochgeladen. Dies betraf Verzeichnisse und Klassifikatoren. Die Geodaten konnten ihm über die Rest-API entnommen werden, die auch vom
Fidschi-Client selbst verwendet
wurde und in WPF geschrieben wurde .
In dieser Architektur stand der Export im Mittelpunkt. Dadurch wurden alle Datenströme in einem einzigen Repository zusammengeführt und an Endprodukte und unsere Benutzer verteilt.
Außerdem war es nur ein kleiner Teil des Eisbergs. Die Automatisierung interner Prozesse, die Entstehung neuer Anforderungen und neuer Funktionen führten zur Entstehung einer Vielzahl von Produkten. Es war notwendig, Analysen durchzuführen, mit Benutzerfeedback zu arbeiten, neue Verkaufsmodelle und neue kommerzielle Produkte einzuführen, Such-, Transportalgorithmen und im Allgemeinen externe Produkte zu entwickeln.
Einerseits hat der Export eine große Anzahl von Datenanbietern und andererseits eine große Anzahl von Verbrauchern, von denen jeder Daten in einer bestimmten Form empfangen und über spezielle Vorbereitungsalgorithmen ausführen wollte.
Und dann ging meine Geschichte zu Ende.
Im zweiten Teil des Artikels werde ich Ihnen über den Export erzählen und mitteilen, wie er all diese Änderungen überstanden hat. Es wird keine Geschichten geben, aber es wird spezifische Ansätze geben, die wir bei der Lösung einer bestimmten Liste von Aufgaben angewendet haben.