Часть первая, в которой читатель познакомится с краткой историей появления внутренних продуктов 2ГИС и эволюцией системы доставки данных от нескольких скриптов до полноценного приложения.

Сегодня я расскажу вам историю, которая началась 9 лет назад в компании ДубльГИС.

Я как раз только устроился туда работать. Мне предстояло заниматься модулем экспорта данных из большой внутренней системы для наших внешних продуктов. И в этой статье я хочу с вами поделиться тем, как мы дробили этот монолит на несколько частей, как один монстр породил из себя несколько десятков продуктов и как все эти продукты и проекты интегрировались на уровне данных между собой.

Сразу скажу, что это просто обзорная статья без каких-либо технических деталей. Техника будет во второй части, в которой мы поговорим про экспорт данных. А пока лишь легкое чтиво без матана с поверхностным упоминанием технологий.

Поехали. Далекий 2010 год. Тогда 2ГИС был еще ламповым ДубльГИСом, из внешних продуктов была настольная версия и примитивный онлайн и версия для КПК. А внутренности состояли из системы доставки обновления пользователям нашей ПК версии и монстра под названием DGPP, который совмещал в себе инструменты для редактирования справочника организаций и карты, CRM и экспорта данных в конечные продукты. База данных лежала в Firebird. Cистема была децентрализована. В каждом городе была своя инсталляция и своя БД. Примитивная интеграция обеспечивалась через файловые экспорты / импорты. И на этом, по большому счету, все.



Сам DGPP представлял из себя приложение на C++ с набором VBA-скриптов. Изначально эту систему для ДубльГИСа разрабатывала сторонняя контора, и лишь со временем разработку системы компания забрала под свою крышу, сформировав собственный R&D. Развивать DGPP становилось все сложнее и сложнее.

А это было время начала бурного развития ДубльГИСа. Открывались новые города. Готовилась мобильная версия для смартфонов. Появлялись новые фичи. Развивалась рекламная модель. В общем, требовалось большое количество изменений, и делать их нужно было быстро.

Первое, с чего мы начали разбирать DGPP на кусочки, стал экспорт. Мы вытащили его в отдельное приложение, представляющее из себя windows service с мордой на WPF. Параллельно велась работа над новой CRM. Для экономии времени на тот момент в качестве базовой платформы был выбран Microsoft Dynamics CRM.



Что касается экспорта, нужно было просто научиться добывать данные из Firebird и вытащить всю логику подготовки данных из VBA-скриптов. Кроме того, были некоторые алгоритмы для данных транспорта, реализованные на плюсах. Их пришлось переписать на шарпы.

Тут стоит обратить внимание на один момент. Наш десктопный ДубльГИС потреблял данные в специальном бинарном формате, который готовился библиотекой на C++, обернутой в COM-объект. И тогда было вполне логично использовать его, просто подключив как reference в проект. Не самое удачное решение, но об этом я расскажу после.

Время шло, мы зарелизили мобильную версию и новую CRM. На горизонте забрезжил новый внешний продукт — публичное API 2ГИС. А из DGPP уже начали вычленять подсистему для работы со справочником организаций под кодовым названием InfoRussia.

В экспорте возникла необходимость читать рекламные данные уже из двух систем: старого DGPP и новой CRM. Причем внедрение CRM шло постепенно, т. е. в одних городах пока оставался только DGPP, а в других работали одновременно DGPP со справочником и картой и CRM с коммерческой информацией. Кроме того, в перспективе светил релиз InfoRussia, который состоялся в течение нескольких месяцев.



Новые системы вносили сложности не только своим появлением. Они изменили концепцию развертывания. В отличие от децентрализованного DGPP, который стоял в каждом городе, эти системы были централизованы, каждая со своей толстенькой СУБД. Кроме того, им необходимо было обмениваться данными.

Для решения этой задачи мы реализовали свою Enterprise Service Bus (ESB). На тот момент практически не было зрелых решений, которые бы обеспечивали выполнение некоторых важных для нас функциональных требований: возможность передачи XML, порядок сообщений и гарантию доставки. Тогда мы остановились на SQL Server Broker, который давал из коробки все, что требовалось. Правда, обладал довольно посредственной скоростью доставки, но нас на тот момент она вполне устраивала.

Последним шагом стал релиз картографического сервиса под названием Fiji. Он частично выгружал свои данные в шину. Это касалось справочников и классификаторов. Геоданные можно было забирать у него через Rest API, которым пользовался и сам клиент Fiji, написанный на WPF.



В этой архитектуре экспорт занимал центральное место. Через него все потоки данных сливались в единое хранилище и раздавались конечным продуктам и нашим пользователям.

Кроме того, это была всего лишь малая часть айсберга. Автоматизация внутренних процессов, появление новых требований и новых фич привело к появлению огромного числа продуктов. Нужно было делать аналитику, работать с фидбэком от пользователей, внедрять новые модели продаж и новые коммерческие продукты, развивать поиск, транспортные алгоритмы и в целом внешние продукты.

У экспорта появилось с одной стороны большое количество поставщиков данных, с другой — большое количество потребителей, каждый из которых хотел получать данные в специфическом виде и прогонять их через специальные алгоритмы подготовки.



И вот моя история подошла к концу.

Во второй части статьи я расскажу вам про Экспорт и поделюсь, как он пережил все эти изменения. Там не будет никаких историй, зато будут конкретные подходы, которые мы применяли в решении конкретного перечня задач.