Микросервисная архитектура как элемент улучшения клиентского опыта: кейс М.Видео-Эльдорадо

О преимуществах использования микросервисной архитектуры на базе OpenJDK в крупном сетевом ритейле, особенностях, которые нужно учитывать при внедрении, и бенефитах, которые получает компания в случае успешной реализации проекта, мы поговорили с Александром Зеленюком, руководителем департамента по развитию технологической платформы Группы «М.Видео-Эльдорадо».

R&L: В чем заключаются преимущества микросервисной архитектуры по сравнению с монолитной? Чем, на ваш взгляд, объясняется повышенный интерес к этому подходу?

А. Зеленюк: На всякий случай сразу оговорюсь, что у данного подхода есть не только плюсы, но тем не менее их гораздо больше, чем минусов. Из преимуществ в первую очередь я бы отметил большую гибкость по сравнению с монолитными системами. Последние представляют собой единый конгломерат технологий, каждая из которых предназначена для реализации конкретной бизнес-логики. При работе с микросервисами любой атомарный кусочек бизнес-процесса мы можем отделить, автономно реализовать его и использовать в различных бизнес-процессах без доработок. Тем самым и достигается гибкость и в разработке, и в выстраивании бизнес-процессов.

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

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

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

Отсюда вытекает следующий важный момент – мы достаточно легко можем внести изменения в уже действующий бизнес-процесс, заменить фрагмент бизнес-сервиса, ничего не разрушив. И если у нас грамотно выстроены процессы автотестирования, контроля качества кода на уровне одного микросервиса, то мы с большой долей вероятности (а в идеале со стопроцентной уверенностью) можем сказать, что при внесении изменений в этот микросервис при выполнении ряда контрольных пунктов не один бизнес-процесс сломан не будет. Это будет справедливо, кстати, даже если какой-то микросервис будет написан заново. А при малейшем изменении в монолитной системе ее приходится тестировать полностью. Или – принимать эти изменения на веру и надеяться, что ничего не «полетит».

R&L: Как микросервисы работают именно в ритейле?

А. Зеленюк: Отличным примером работы микросервисов является система обработки заказов. Что она собой представляет? Это, по сути, база данных, в которую складываются все заказы, сделанные в магазинах, в интернете, с мобильного приложения, через call-центр. Вся логика по обработке всего объема заказов (а именно контроль резервирования товаров, отслеживание оплат, создание чеков и их обработка, и еще огромное количество операций над заказами) реализована в едином приложении, построенном как единый монолит. В связи с эти каждое самое незначительное изменение затрагивает всю систему, при том, что таких изменений в нашем бизнесе – масса. Соответственно для поддержания системы в работоспособном состоянии приходится держать огромный штат разработчиков, и любая доработка процесса обработки заказов заставляет тратить большой объём ресурсов разработки и времени на то, чтобы все оттестировать и довести до продакшена.

Поэтому мы решили кардинально изменить и переосмыслить решение и архитектуру такой системы и провести миграцию данного приложения на микросервисную архитектуру. Каждая часть процесса обработки заказов должна выполнять одну атомарную функцию, так появились отдельные микросервисы «зарезервируй товар», «прием оплаты за заказ», «сформируй чек продажи» и многие другие. А кроме того, для того чтобы уметь гибко настраивать и управлять бизнес-процессами и отдельными компонентами, мы внедрили и BPMN движок, который позволяет гибко настраивать последовательность выполнения операций и следить за их выполнением. Так, например, мы настраиваем разные пути обработки и исполнения для партнёрских заказов, заказов клиентов b2c или b2b и так далее независимо друг от друга.

R&L: В какой момент и чем было обусловлено решение о переходе на микросервисную архитектуру?

А. Зеленюк: Изучать возможности перехода на микросервисы мы начали около пяти лет назад, когда мы начали активно развивать омниканальную бизнес-модель. На тот период розница, интернет-канал, мобильное приложение и call-центр представляли собой отдельные ИТ-системы. Нашей приоритетной задачей стало научиться предоставлять клиенту одинаковые условия покупки (цены, скидки, акции) независимо от канала. Было два варианта действий: создавать модуль расчета в каждой системе, при том что системы с точки зрения технологий были абсолютно разными и унификация представлялась довольно сомнительным предприятием. Либо попробовать вынести эту логику в отдельный сервис, разобраться с API и научить систему общаться с этим сервисом. Это была, так сказать, первая проба пера, которую еще нельзя было назвать полноценным микросервисом.

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

Конечно, за последние годы мы совершили серьёзный рывок и сейчас моментально понимаем, где нам нужны микросервисы, в каком количестве, как они будут взаимодействовать между собой. Также мы изменили подход к процессам проектирования: если раньше при принятии решения о включении той или иной функциональности в общий сервис мы исходили из бизнес-необходимости, сейчас мы можем заранее предлагать бизнесу микросервис (или набор микросервисов) с определенной value для решения конкретной бизнес-задачи, не дожидаясь, пока заработают все связанные с этим направлением системы.

R&L: Как эволюционировала ваша микросервисная архитектура за пять лет? На каких элементах/направлениях сейчас делаете акцент?

А. Зеленюк: Первые микросервисы мы создавали на базе Java-приложения, написанного командой из 5–6 человек, – и они уже умели обрабатывать определенные запросы от пользователей на расчет заказа или корзины.

В 2018 году, когда создавалось мобильное приложение для М.Видео, мы подготовили 40–50 микросервисов – таких как работа с личным кабинетом пользователя, оформление заказов, поиск товаров, отзывы, характеристики и пр. Были сделаны существенные вложения в инфраструктурную часть, в процессы сборки и тестирования. Мы внедрили функцию автоматического тестирования для любого микросервиса, написанного на данной платформе. Т. е. на тот момент каждый микросервис имел обязательный quality gate по прохождению автоматических тестов, что как минимум на 50% снижало косты и время на вывод микросервиса в продуктив.

Затем по рекомендации коллег из компании BellSoft мы перешли на Liberica JDK, среду исполнения Java, которую они разрабатывают и поддерживают в России, являясь одним из мировых лидеров OpenJDK. И постепенно с их помощью выявили ряд усовершенствований – например, начали использовать компактные контейнеры для микросервисов.

В итоге 2020 год для нас прошел под знаком не только пандемии – но и трех ключевых направлений развития микросервисной платформы. Во-первых, мы оптимизируем и автоматизируем все, что можно, с точки зрения Continuous Deployment и Continuous Integration – речь идет о проектах по автотестированию, нагрузочной автоматизации и пр. Во-вторых, это новый подход к контейнерам и оркестрации сервисов, в рамках которого мы работаем с Kubernetes, занимаемся кластеризацией микросервисов и их автомасштабированием. В-третьих – это миграция в облака с постепенным отказом от собственной инфраструктуры в ЦОД, что позволит значительно экономить и время, и финансы, и трудозатраты.

R&L: В самом начале вы упомянули, что есть не только плюсы. Какие особенности/недостатки микросервисной архитектуры необходимо учитывать при переходе к ней, как вы с ними справлялись, какие рекомендации можете дать тем, кто пока только готовится пойти по этому пути?

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

Первая и основная проблема обусловлена сложностью внедрения микросервисной архитектуры. Вторая – несмотря на относительную зрелость технологии она не слишком хорошо представлена на рынке. Кроме того, при ее внедрении необходимо перестраивать майндсет, при чем на разных уровнях, начиная с проектирования: нет смысла сначала прорисовать архитектуру бизнес-решений, а уже только потом задуматься, каким образом ее можно притянуть к микросервисам. Нужно научиться изначально мыслить категориями микросервисов.

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

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

Сейчас количество новых решений для ИТ-сфере растет намного интенсивнее, чем еще пару лет назад. И микросервисная архитектура идеально подходит для их тестирования и внедрения, с минимальным ущербом для бизнеса. К счастью, уровень разработчиков, работающих в микросервисном мире, постоянно растет вместе с рынком и с ИТ–инновациями.

R&L: Вы упомянули про сложности с поддержкой микросервисов – каким образом вы решаете эти проблемы?

А. Зеленюк: Здесь нам очень пригодилась помощь от коллег из BellSoft – в плане использования компактных контейнеров и обновления версий JDK. Для меня как руководителя самый главный показатель качества поддержки – отсутствие у разработчика страха перед обновлением версий Java, даже на LTS-релизах или релиз-кандидатах, и сборкой собственных приложений на Java.

R&L: Делая вывод из сказанного, можно сказать, что ИТ-ландшафт компании был перестроен очень сильно…

А. Зеленюк: Да, безусловно. Еще два года назад сложно было предположить, что мы будем размещать данные в публичных облаках. Сейчас же это уже мейнстрим. Мы понимаем, что в будущем новый подход принесёт нам огромные бенефиты – с точки зрения как скорости, так и финансов, как не парадоксально это звучит. И замечательно, что мы можем обучать своих сотрудников работе в новых реалиях, а не раздувать штат для поддержки громоздкой инфраструктуры, можем не покупать серверы у производителей, а использовать их как сервис.

Пять–шесть лет назад наша инфраструктура состояла из множества серверов, размещенных в ЦОДе и даже в магазинах, обслуживающих монолитные приложения типа SAP, ERP, приложения для call-центров, кассовых систем. Избавиться от них полностью пока не удалось, но мы много работаем в этом направлении. И в центральном офисе, например, многие проекты – как для сотрудников, так и для клиентов – уже реализуются исключительно на микросервисах. Нельзя, конечно, сказать, что эти два мира существуют отдельно друг от друга – на сегодняшний день мы научили работать монолиты и микросервисы в связке, и сейчас наш ИТ-ландшафт немного напоминает разноцветный и разнотканевый ковер. Наша цель при этом – максимально уйти в облака и микросервисы, особенно в приложениях, разработанных для сотрудников магазинов и call-центров, занимающихся продажами и коммуникациями с клиентами. Мы находимся в начале пути, уровень нашей «клаудизации» сейчас можно оценить на 20–30%. Рассчитываю, что через 2–3 года мы дойдем и до 100%.

R&L: Вы сказали, что в основном концентрируетесь на обучении своих сотрудников. А какова ситуация на рынке труда, есть там специалисты в области микросервисной архитектуры?

А. Зеленюк: Знание этой сферы – серьезный козырь в рукаве кандидата в любую ИТ-команду, и сейчас на рынке не так много свободных специалистов, которых можно привлекать на серьезные проекты по миграции на микросервисную архитектуру, поскольку в большинстве своем они нарасхват. В «М.Видео-Эльдорадо» перед такими экспертами сейчас открываются прекрасные карьерные возможности – мы планируем расширить этот проект на оба наших брендах и тиражировать его максимально широко.

R&L: С точки зрения клиентского опыта – как именно микросервисы помогают его улучшению?

А. Зеленюк: Прежде всего, мы существенно сократили time to market, иначе говоря, новые фичи мы теперь можем выпускать в продакшн минимум раз в неделю – благодаря автоматическому тестированию, миграции на облака и другим проектам, о которых я рассказывал выше.

Что касается конкретно пользы от микросервисов, поясню на примере. Примерно год назад мы запустили сервис доставки мелкогабаритных товаров на такси. Изначально микросервис умел проверять габариты товара и организовывать доставку в радиусе 30 км от магазина. Работая в бэк-энде с этим микросервисом, мы заменили порядка 10 других микросервисов, способствующих улучшению услуг по доставке товаров. Например, клиент может уехать из магазина на такси вместе со своим заказом. Мы сейчас проверяем гипотезы, в каких агрегаторах такси люди заказывают эти товары и в какие районы. Такая аналитика позволит нам значительно усовершенствовать сервис и избежать ненужных затрат на доставку. Мы научились относительно точно определять ближайший и самый удобный с точки зрения логистики магазин. И все это мы освоили в течение полугода – благодаря первичному микросервису доставки товара на такси. И все последующие микросервисы постепенно встраиваются в customer journey наших покупателей.

R&L: Каким компаниям, на ваш взгляд, переход на микросервисы жизненно необходим, а каким лучше работать по старой модели?

А. Зеленюк: Полагаю, что он необходим любому крупному ритейлу. Но важно при этом не переусердствовать и не начать везде и всюду создавать микросервисы. Мы на данном этапе занимаемся миграцией только в тех областях, где видим возможность получить явное преимущество – за счет гибкости, быстроты внедрения и пр.

Однако далеко не все системы подлежат переводу на микросервисы – например, ERP-системы, системы для бухгалтерии. Существенных бенефитов от миграции, по крайней мере, на текущем этапе, я не вижу. Микросервисы важны там, где их польза очевидна и где они позволят добиться улучшения time to market, повышения гибкости и оперативности во внедрении и смене различных технологий.