mvideo Jun 3 2021 at 00:11

С помощью перехода на микросервис мы ускорили бизнес-процесс в 60 раз

5 min

9.9K

М.Видео-Эльдорадо corporate blogWebsite development*

+30

Comments 15

mrbald Jun 3 2021 at 07:14

Новый алгоритм мы изначально построили так, чтобы все операции с таблицами полностью выполнялись в оперативной памяти

Чем пользуетесь, если не секрет?

mvideo Jun 3 2021 at 22:16

Никакой особой магии, использовали jdbc запросы для извлечения данных из памяти и java-коллекции для компактного размещения данных в памяти. Выбор пал в основном на структуры Map, т.к. они позволяли уйти от плоского вида данных, т.е. экономить память и иметь быстрый доступ к данным в ОЗУ.

Tamahome Jun 3 2021 at 07:46

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

Причем тут микросервис?

UFO just landed and posted this here

Verion Jun 3 2021 at 10:28

В этой истории ключевой момент отказ от операций в базе и перенос расчетов в оперативку. У нас в компании ровно такая же ситуация, и сейчас переносим все расчеты в ОЗУ. Как простой пример: доступ к данным по ключу в Couchbase у нас занимает 10 ms, тот возвращает json, его нужно десериализовать в структуру языка. Все тоже самое, только с заранее подгруженными в оперативку данными занимает на несколько порядков меньше времени (пикосекунды), отсюда и выигрыш. Вот только есть проблемы с обновлением этих данных в оперативке, но подходы есть

DenisTrunin Jun 3 2021 at 16:36

Чето по своей практике это все маркетинг. Современная БД способна в легкую исполнить вам к примеру тысячи/десятки тысяч сложных запросов в секунду. Т.е. за 10 минут это грубо будет миллион запросов. Думаю вполне возможно реализовать алгоритм расчета этих календарей который будет укладываться в этот миллион запросов. Но как правильно заметили выше, вендору это не доверили, а решили взять на себя прикрываясь модными словами микросервис и прочее.
Думаю на том же SAP порядок времени был бы таким же, тут вопрос больше кому уйдет бюджет на эту оптимизацию

mvideo Jun 3 2021 at 22:17

У нас было коробочное решение SAP ЕРП, которое и описано в статье и доработка которого требует и больших денег и ресурсов и не факт, что будет оптимальной, т.к. тут надо затрагивать глубинные алгоритмы SAP, а это уже совсем другие деньги. Поэтому было принято решение ухода от программирования на уровне pl/sql процедур СУБД Oracle и переход на более быстрый и масштабируемый функционал java и микросервисов. Т.е. тут речь вообще не о костылях, а о функциональном переносе бизнес-логики на другие рельсы. Так что следующий в этой ветке комментатор Verion прав — мы отказались от операций на уровне бд перейдя на уровень java

mudriyjo Jun 3 2021 at 09:24

Не понятно в чем тут помогли микросервисы. Микросервисы в частности решают проблему масштабируемости команд и совместной разработки
Если в вашем примере вынести функциональность в сервис — принципиально ничего не измениться

mvideo Jun 3 2021 at 22:18

У нас на МСП уже есть микросервисный подход, т.е. каждая область бизнес-функционала выделена в свой сервис и имеет свои точки входа и отдачи данных. Мы добавили к общему скоупу еще один сервис, который получал от своего окружения нужные ему данные и делал свою работу далее автономно.

mudriyjo Jun 3 2021 at 22:33

Претензия не к объяснению а к заголовку, он максимально кликбейтный — "С помощью перехода на микросервис мы ускорили бизнес-процесс в 60 раз"
Вы могли вынести логику расчета на любую архитектуре и получить такой же результат

MentalBlood Jun 3 2021 at 10:27

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

P.S. Тема логистических календарей (что там надо было посчитать, что оно так долго считалось) не раскрыта, а зря

adminustrator Jun 3 2021 at 13:51

В тексте опечатка: "общий товарооборот вдвое до 1 млрд рублей". Вы хотели написать трлн рублей, скорее всего

mvideo Jun 3 2021 at 13:52

конечно, вы правы. спасибо

Apoheliy Jun 4 2021 at 00:50

Во-первых, согласен с предыдущими комментаторами: причём здесь микросервисы? Похоже на вынос модуля расчёта во вне, нет?

Во-вторых, Вы специально обращаете внимание на скорость вычислений и компактное размещении в памяти. И что в дальнейшем нужно ещё быстрее и компактнее (бизнес требует). И задача, по вашему описанию, чисто вычислительная.
Тогда: рассматривались ли альтернативы java? Например, C++? В частности, периодически смотрю бенчмарки на вычислительные задачи и там, иногда, C++ в 2+ раза быстрее Java. А по использованной памяти выигрыш C++ может, опять же иногда, быть и в 10+ раз.
С другой стороны, время разработки на C++, иногда, больше. Однако из Вашего описания можно предположить, что запас времени на реализация алгоритма у вас был, и существенный.

mvideo Jun 7 2021 at 10:24

Расчет был вынесен не просто в отдельный модуль внутри монолита, но в отдельный контейнер со своими настройками взаимодействия с окружающей средой и гибкой настройкой джобов запуска, т.е. в отдельный сервис.

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