Введение
Все чаще наши клиенты обращаются в ИНТЕРВОЛГУ с запросом на комплексную масштабную работу над проектом . Мы не удивляемся этому: время небольших доработок, "перекрашивания" кнопок и починки страничек прошло.
В 2019 году средний и крупный бизнес стремится превратить сайт в многофункциональный инструмент для взаимодействия с партнерами и клиентами. И желательно — единственный инструмент. Все чаще нас просят добавить «пару отчетиков для партнеров», программу лояльности и биллинг прямо на сайте. Позже выясняется, что отчеты — это не SUM и GROUP BY по табличке заказов, а ТЗ на десять страниц с дифурами и прочим матаном, программа лояльности должна учитывать лайки в соцсетях а биллинг должен быстро работать в реальном времени. Под капотом у таких функций — масштабные вычисления, к которым традиционный веб-сайт просто не готов.
Значительные подсчеты требуются и для интернет-магазинов федерального масштаба. Их отличия от обычного ИМ:
- Работа по всей России: GeoIP, многоскладовость и прочие вытекающие (а не один-два города)
- Десятки миллионы товаров и SKU, а не десятки тысяч
- Лихо закрученное, как лента Мебиуса, ценообразование (а не две цены: «Опт», «Розница»)
- Магазин-маркетплейса (продажа чужих товаров с партнерской комиссией)
- Десятки интеграций с разными учетными системами (и ни одной 1С!)
И, разумеется, чтобы работало быстро.
Как же сделать тяжелые вычисления вебе и не уронить сервер? За последние 2 года ИНТЕРВОЛГА разрабатывала и поддерживала сразу 4 таких проекта и у нас есть ответ.
Теория
В обоих случаях (личные кабинеты и федеральные интернет-магазины) требуется быстро оперировать большими объемами данных. Наращивание мощностей веб-сервера помогает до поры до времени. Веб как технология никогда не был сверхскоростной средой для громоздких вычислений. На то есть несколько причин:
- Язык разработки. PHP, Ruby, Python многократно проигрывают компилируемым языкам в производительности.
- Протокол HTTP. А конкретно — понятие таймаута. Считать на лету слишком долго не получится, рано или поздно серверу нужно будет оборвать соединение и браузер покажет ошибку ожидания ответа. Спасает пошаговое выполнение процедуры, но не всегда.
- Особенности ПО. Повсеместные apache и nginx успешно справляются с умеренно большим потоком пользователей, если запросы простые и отрабатывают быстро. Отдать 10 000 раз главную страницу — не проблема. А вот вычислить 10 000 балансов на лету уже не так весело.
Очевидный вариант — переложить тяжелую работу с сайта на учетную систему. УС действительно эффективнее при решении сложных задач, но они не рассчитаны на ту нагрузку, которую создает посещаемый веб-сайт. Получается конфликт: сайт считает медленно, но для тысяч пользователей, а УС — быстро, но для пяти-десяти. У нас был опыт с проектами обоих типов.
Наш вывод — ни одна из этих систем не должна заниматься постоянными тяжелыми вычислениями. Откладываем в сторону бритву Оккама и начинаем проектировать промежуточное ПО (связующее ПО или middleware). Middleware примет на себя основную нагрузку.
Пожелания к middleware:
- Работа на отдельном (от сайта и УС) сервере;
- Современный, распространенный язык программирования и фреймворк.
- Надежный подрядчик.
В простом случае промежуточное ПО можно разработать на базе 1С или 1С-Битрикс (отдельная копия, разумеется). Но если критична скорость ответа и выживаемость под высокой нагрузкой, лучше написать отдельный софт, например на Java (быстрый и современный язык), которая по скорости не уступает C/C++.
Рассмотрим более сложную задачу. Сколько middleware потребуется для такой инфраструктуры проекта?
Как ни странно, понадобится только один новый узел.
Развитие идеи middleware для большего количества IT-систем называется ESB (enterprise service bus — сервисная шина предприятия). Иногда этот подход называют интеграционной шиной или шиной данных. Как и промежуточное ПО в случае с двумя системами, это не какой-то конкретный продукт или фреймворк, а подход, призывающий совершать все транзакции между IT-системами в единой точке.
Существует паттерн проектирования, реализующий эту же логику с той же целью. Это Медиатор (Mediator). Он выступает посредником между различными классами, предотвращает прямое взаимодействие и способствует ослаблению связей в коде. Элементы системы не знают о существовании друг друга, только о существовании Медиатора. Согласитесь, очень похоже на определение middleware и интеграционной шины?
Но чем же, в таком случае, должны заниматься учетная система и сайт, если всю тяжелую работу выполняет middleware? Сайт становится простой «болванкой»? Не совсем. Мы снимаем с сайта только самые тяжелые операции, для которых он не пригоден по определению. Для всего остального он по прежнему — лучшее решение
- Сайт как «фронт»:
- выводит чистые данные клиенту,
- красивый и удобный,
- собирает пользовательские данные из форм,
- отправляет письма и СМС (не маркетинговые рассылки, а разовые уведомления),
- готовит запросы к middleware,
- выводит вычисленные результаты.
- Middleware:
- чистит данные от мусора, (intervolga@gmail.ru -> intervolga@gmail.com)
- удаляет то, что невозможно очистить (intervolga@.ru),
- стандартизирует данные (а в вашей CRM номера клиентов через «+7», «7» или «8»?)
- сопоставляет товары, статусы, адреса («г. Москва» и «гор. Москва»),
- ведет учет остатков,
- взаимодействует с десятком учетных систем,
- производит инкрементальные расчеты для ускорения типовых запросов.
- Учетная система как «бэк»:
- биллинг,
- учет транзакций,
- расчет баланса,
- складской учет,
- вычисление персональных цен.
Кейсы с конкретными задачами
Кейс 1. Отчеты в реальном времени
Задача
Строить отчеты партнеров на сайте
Правильное решение
- Каждый день middleware подводит промежуточный итог за прошедший день для каждого партнера по всем отчетам.
- Сайт не строит отчеты, только собирает заявки и ставит их в очередь.
- Из очереди заявки на отчет попадают в middleware, которое и ведет расчеты по своей копии данных из УС. Middleware считает только статистику за сегодняшний день, за предыдущие уже все посчитано.
- Middleware передает сгенерированные данные в виде готового PDF/DOC/XLS на сайт.
P.S. Приведенный сценарий хорош если в Вашей учетной системе запрещено редактировать первичку задним числом. В противном случае алгоритм усложняется.
Кейс 2. Персональные цены
Задача
На каждый товар B2B интернет-магазина практически у каждого пользователя своя скидка/наценка. Как результат — своя цена. Учетная система писалась чуть ли не во времена СССР, скидки зависят от двадцати параметров и никто не может объяснить, как оно работает.
Правильное решение
- Учетная система выгружает на сайт товары с базовой ценой (максимальная цена без скидок).
- При открытии страницы сайт отображает базовые цены товаров. По ним же происходит сортировка и фильтрация. Этот результат можно закешировать.
- Параллельно сайт запрашивает из middleware цены для нужных товаров для текущего пользователя. Сайт отображает цены.
Кейс 3. Участие в акции компании с филиалами
Задача
В B2B портале производители размещают акции для компаний-дистрибьюторов (купи X товаров по цене Y в количестве Z в каждый магазин и получи бонусы). Пользователи портала — холдинги и дистрибьюторы могут прямо на сайте принять участие в акции. Если холдинг решает принять участие в акции — то в акцию автоматически должны вступить все дочерние компании со всеми магазинами. Но не у всех компаний заключен договор с производителем. Даже если и заключен, в договоре могут быть ограничение на минимальное/максимальное количество товаров, которые компания может купить у производителя.
Задача: при подписке холдинга на акцию подписать все допустимые компании, рассчитать сумму сделки и ожидаемые бонусы за участие в акции.
Правильное решение
- Вся нужная информация для вступления в акцию доступна в middleware. Хороший вариант — master-slave репликация БД (потребуется только чтение и всегда актуальные данные).
- При вступлении холдинга в акцию сайт добавляет задание в очередь для middleware.
- Из очереди задания попадают в middleware. Middleware проверяет наличие договоров и их условия, запоминает рассчитанные данные и возвращает результат на сайт (сумма сделки, плановые бонусы).
- Сайт отображает результат вступления.
- При изменении состава холдинга или других первичных данных middleware должен пересчитать и обновить ранее запомненные данные. Тогда следующий запрос от сайта выполнится значительное быстрее.
Кейс 4. Десятки учетных систем
Задача
Для проекта типа «маркетплейс» требуется собирать номенклатуру у десятков (в перспективе — сотен) партнеров и отображать на сайте. Оформленные на сайте заказы отправлять обратно в УС каждого партнера отдельно. Заранее неизвестно, какое ПО будет у партнера и в каком формате будут предоставлены данные о товарах и заказах. Товары у партнеров примерно одинаковые.
Правильное решение
- ESB собирает товары в единую базу и выполняет сопоставление товаров с единым справочником (по артикулам, характеристикам, штрих кодам и т.д.).
- ESB анализирует цены от разных поставщиков. Если 9 разных партнеров предлагают товар за 10000 рублей, а 10-ый за 100 — возможно, сопоставление произошло некорректно и показывать такой товар на сайте нельзя.
- ESB готова обмениваться с учетными системами партнеров по самым простым протоколами в ручном режиме. CSV и YML для товаров, CSV и CommerceML 2 для заказов.
Заключение
Сделать интеграцию нескольких IT-систем можно по-разному. Если вы хотите, чтобы результат был масштабируемым, чтобы увеличение объема данных в два раза не увеличивало тормоза сайта в два раза, обращайтесь к нам. Каждую задачу нужно решать правильными инструментами. 1С для учета и сотрудников. Сайт для UX. Промежуточное ПО для «грязной» работы.
ИНТЕРВОЛГА крупный веб-интегратор, и мы любим интересные и нестандартные задачи. У вас большой и нагруженный проект ? Заполняйте форму по ссылке, мы проведем анализ вашего проекта, составим полноценное задание на работы, предложим вам подходящую для ваших целей архитектуру и реализуем ее.
Полезные ссылки:
• Разработка и доработка проектов на 1С-Битрикс.
• Настройка интеграции с 1С любой сложности.
