Parte um, na qual o leitor se familiarizará com um breve histórico do surgimento de produtos 2GIS internos e a evolução do sistema de entrega de dados de vários scripts para um aplicativo completo.Hoje vou contar uma história que começou há 9 anos no DublGIS.
Acabei de conseguir um emprego lá. Eu tive que lidar com o módulo para exportar dados de um grande sistema interno para nossos produtos externos. E neste artigo, quero compartilhar com você como dividimos esse monólito em várias partes, como um monstro gerou várias dezenas de produtos e como todos esses produtos e projetos foram integrados no nível de dados entre si.
Devo dizer que este é apenas um artigo de revisão sem detalhes técnicos. A técnica estará na segunda parte, na qual falaremos sobre exportação de dados. Enquanto isso, apenas uma leitura leve, sem matan, com uma menção superficial da tecnologia.
Vamos lá Até 2010 Então o 2GIS ainda era um tubo DoubleGIS; de produtos externos, havia uma versão desktop e um primitivo online e uma versão para PDAs. E o interior consistia em um sistema de entrega de atualizações para usuários de nossa versão para PC e um monstro chamado DGPP, que combinava ferramentas para editar o diretório de organizações e mapas, CRM e exportar dados para produtos finais. O banco de dados estava no Firebird. O sistema foi descentralizado. Cada cidade tinha sua própria instalação e seu próprio banco de dados. A integração primitiva foi fornecida por meio de exportação / importação de arquivos. E sobre isso, em geral, isso é tudo.
O DGPP em si era um aplicativo C ++ com um conjunto de scripts VBA. Inicialmente, um escritório de terceiros desenvolveu esse sistema para o DublGIS, e somente com o tempo a empresa levou o desenvolvimento do sistema para o seu teto, formando sua própria pesquisa e desenvolvimento. O desenvolvimento do DGPP tornou-se cada vez mais difícil.
E esse foi o momento do rápido desenvolvimento do DublGIS. Novas cidades estavam se abrindo. A versão móvel para smartphones estava sendo preparada. Novos recursos apareceram. Um modelo de publicidade estava sendo desenvolvido. Em geral, era necessário um grande número de alterações, que precisavam ser feitas rapidamente.
A primeira coisa que começamos a desmontar o DGPP em pedaços foi a exportação. Nós o puxamos para um aplicativo separado, que é um serviço do Windows com um focinho no WPF. Paralelamente, o trabalho estava em andamento em um novo CRM. Para economizar tempo naquele momento, o Microsoft Dynamics CRM foi escolhido como a plataforma base.
Quanto à exportação, você apenas precisava aprender como extrair dados do Firebird e extrair toda a lógica para preparar dados de scripts VBA. Além disso, havia alguns algoritmos para dados de transporte implementados nas vantagens. Eles tiveram que ser reescritos para objetos cortantes.
Aqui vale a pena prestar atenção em um ponto. Nosso DoubleGIS da área de trabalho consumia dados em um formato binário especial, preparado por uma biblioteca C ++ envolvida em um objeto COM. E então era bastante lógico usá-lo, simplesmente conectando-se como uma referência ao projeto. Não é a melhor solução, mas falarei sobre isso mais tarde.
Com o passar do tempo, lançamos uma versão móvel e um novo CRM. Um novo produto externo apareceu no horizonte - a API pública 2GIS. E do DGPP eles já começaram a isolar um subsistema para trabalhar com um diretório de organizações com o codinome InfoRussia.
Na exportação, tornou-se necessário ler os dados de publicidade de dois sistemas: o antigo DGPP e o novo CRM. Além disso, a implementação do CRM prosseguia gradualmente, ou seja, em algumas cidades apenas o DGPP permaneceu até agora, enquanto em outros o DGPP trabalhou simultaneamente com um diretório e mapa e o CRM com informações comerciais. Além disso, a longo prazo, o lançamento do InfoRussia, que ocorreu durante vários meses, estava brilhando.
Novos sistemas introduziram complexidade não apenas pela aparência. Eles mudaram o conceito de implantação. Ao contrário do DGPP descentralizado existente em todas as cidades, esses sistemas eram centralizados, cada um com seu próprio DBMS. Além disso, eles precisavam trocar dados.
Para resolver esse problema, implementamos nosso ESB (Enterprise Service Bus). Naquela época, praticamente não havia soluções maduras que garantissem o cumprimento de alguns requisitos funcionais importantes para nós: a capacidade de transmitir XML, a ordem das mensagens e a garantia de entrega. Depois, optamos pelo SQL Server Broker, que forneceu tudo o que era necessário. É verdade que ele tinha uma velocidade de entrega bastante medíocre, mas naquela época ela estava muito feliz conosco.
O último passo foi o lançamento de um serviço de mapas chamado Fiji. Ele parcialmente carregou seus dados no ônibus. Isso preocupava diretórios e classificadores. Os dados geográficos poderiam ser retirados dele por meio da API Rest, que também foi usada pelo próprio
cliente de Fiji, escrito em WPF .
Nessa arquitetura, a exportação era central. Por meio dele, todos os fluxos de dados foram mesclados em um único repositório e distribuídos para produtos finais e nossos usuários.
Além disso, era apenas uma pequena parte do iceberg. A automação de processos internos, o surgimento de novos requisitos e novos recursos levaram ao surgimento de um grande número de produtos. Era necessário fazer análises, trabalhar com o feedback do usuário, introduzir novos modelos de vendas e novos produtos comerciais, desenvolver pesquisas, algoritmos de transporte e, em geral, produtos externos.
Por um lado, a exportação possui um grande número de provedores de dados e, por outro, um grande número de consumidores, cada um dos quais queria receber dados de uma forma específica e executá-los por meio de algoritmos especiais de preparação.
E então minha história chegou ao fim.
Na segunda parte do artigo, vou falar sobre o Export e compartilhar como ele sobreviveu a todas essas mudanças. Não haverá histórias, mas haverá abordagens específicas que aplicamos na solução de uma lista específica de tarefas.