Хабрахабр

История одного монолита

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть