Primera parte, en la que el lector se familiarizará con una breve historia de la aparición de productos internos de 2GIS y la evolución del sistema de entrega de datos de varios scripts a una aplicación completa.Hoy les contaré una historia que comenzó hace 9 años en DublGIS.
Acabo de conseguir un trabajo allí. Tuve que lidiar con el módulo para exportar datos desde un gran sistema interno para nuestros productos externos. Y en este artículo quiero compartir con ustedes cómo dividimos este monolito en varias partes, cómo un monstruo generó varias docenas de productos y cómo se integraron todos estos productos y proyectos a nivel de datos entre ellos.
Debo decir que este es solo un artículo de revisión sin ningún detalle técnico. La técnica será en la segunda parte, en la que hablaremos sobre la exportación de datos. Mientras tanto, solo lectura ligera sin matan con una mención superficial de la tecnología.
Vamos Far 2010 Entonces 2GIS seguía siendo un tubo DoubleGIS, de productos externos había una versión de escritorio y una primitiva en línea y una versión para PDA. Y el interior consistía en un sistema de entrega de actualizaciones para los usuarios de nuestra versión para PC y un monstruo llamado DGPP, que combinaba herramientas para editar un directorio de organizaciones y mapas, CRM y exportar datos a productos finales. La base de datos estaba en Firebird. El sistema estaba descentralizado. Cada ciudad tenía su propia instalación y su propia base de datos. La integración primitiva se proporcionó mediante exportaciones / importaciones de archivos. Y sobre esto, en general, eso es todo.
DGPP en sí era una aplicación C ++ con un conjunto de scripts VBA. Inicialmente, una oficina externa desarrolló este sistema para DublGIS, y solo con el tiempo la empresa tomó el desarrollo del sistema bajo su techo, formando su propia I + D. Desarrollar DGPP se ha vuelto cada vez más difícil.
Y este fue el momento del rápido desarrollo de DublGIS. Se estaban abriendo nuevas ciudades. Se estaba preparando la versión móvil para teléfonos inteligentes. Nuevas características aparecieron. Se estaba desarrollando un modelo publicitario. En general, se requerían una gran cantidad de cambios, que debían hacerse rápidamente.
Lo primero que comenzamos a desmontar DGPP en pedazos fue la exportación. Lo incorporamos a una aplicación separada, que es un servicio de Windows con un hocico en WPF. Paralelamente, se estaba trabajando en un nuevo CRM. Para ahorrar tiempo en ese momento, se eligió Microsoft Dynamics CRM como plataforma base.
En cuanto a la exportación, solo tenía que aprender a extraer datos de Firebird y extraer toda la lógica para preparar los datos de los scripts de VBA. Además, había algunos algoritmos para el transporte de datos implementados en las ventajas. Tenían que ser reescritos en objetos punzantes.
Aquí vale la pena prestar atención a un punto. Nuestro escritorio DoubleGIS consumió datos en un formato binario especial, que fue preparado por una biblioteca C ++ envuelta en un objeto COM. Y luego fue bastante lógico usarlo, simplemente conectando como referencia al proyecto. No es la mejor solución, pero hablaré de esto más adelante.
Con el paso del tiempo, lanzamos una versión móvil y un nuevo CRM. Un nuevo producto externo ha aparecido en el horizonte: la API pública 2GIS. Y desde DGPP ya han comenzado a aislar un subsistema para trabajar con un directorio de organizaciones con nombre en código InfoRussia.
En la exportación, se hizo necesario leer datos publicitarios de dos sistemas: el antiguo DGPP y el nuevo CRM. Además, la implementación de CRM avanzaba gradualmente, es decir, en algunas ciudades, hasta ahora solo quedaba DGPP, mientras que en otras DGPP trabajaba simultáneamente con un directorio y un mapa y CRM con información comercial. Además, a la larga, el lanzamiento de InfoRussia, que tuvo lugar durante varios meses, fue brillante.
Los nuevos sistemas introdujeron complejidad no solo por su apariencia. Cambiaron el concepto de despliegue. A diferencia del DGPP descentralizado que existía en cada ciudad, estos sistemas estaban centralizados, cada uno con su propio DBMS regordete. Además, necesitaban intercambiar datos.
Para resolver este problema, implementamos nuestro Enterprise Service Bus (ESB). En ese momento, prácticamente no había soluciones maduras que garantizaran el cumplimiento de algunos requisitos funcionales importantes para nosotros: la capacidad de transmitir XML, el orden de los mensajes y la garantía de entrega. Luego nos decidimos por SQL Server Broker, que proporcionó todo lo necesario. Es cierto que tenía una velocidad de entrega bastante mediocre, pero en ese momento ella estaba muy contenta con nosotros.
El último paso fue el lanzamiento de un servicio de mapas llamado Fiji. Subió parcialmente sus datos al autobús. Esto se refería a directorios y clasificadores. Los geodatos se le podrían quitar a través de la API Rest, que también fue utilizada por
el propio
cliente de Fiji, escrita en WPF .
En esta arquitectura, la exportación era central. A través de él, todos los flujos de datos se fusionaron en un único repositorio y se distribuyeron a los productos finales y a nuestros usuarios.
Además, era solo una pequeña parte del iceberg. La automatización de los procesos internos, la aparición de nuevos requisitos y las nuevas características llevaron a la aparición de una gran cantidad de productos. Era necesario hacer análisis, trabajar con comentarios de los usuarios, introducir nuevos modelos de ventas y nuevos productos comerciales, desarrollar algoritmos de búsqueda, transporte y, en general, productos externos.
Por un lado, la exportación tiene una gran cantidad de proveedores de datos y, por otro, una gran cantidad de consumidores, cada uno de los cuales quería recibir datos en una forma específica y ejecutarlos a través de algoritmos de preparación especiales.
Y entonces mi historia llegó a su fin.
En la segunda parte del artículo, le contaré sobre Exportar y compartiré cómo sobrevivió a todos estos cambios. No habrá historias, pero habrá enfoques específicos que hemos aplicado para resolver una lista específica de tareas.