Как микросервисы могут помочь интернет-магазинам повысить прибыль?

Если вы когда-то задумывались о запуске интернет-магазина или у вас уже есть действующий сайт, продающий товары и услуги через интернет, вы наверняка задавались вопросом о построении правильной архитектуры. Или как минимум вы спрашивали себя: выдержит ли ваш сайт пики нагрузок? Является ли система стабильной и безопасной для пользователей? Можно ли безопасно для всей инфраструктуры масштабировать проект?

Сегодня мы поговорим о микросервисной архитектуре, и какую пользу она может принести интернет-магазинам.

Считается, что микросервисная архитектура должна обладать тремя ключевыми концепциями:

1. Микросервисы идеальны для больших систем.

Самая распространённая причина, по которой компании внедряют микросервисы, связана с размером проекта. Это очень важный аспект, так как он подчёркивает определённую характеристику микросервисов - решает проблемы именно больших систем. Но понятие размера очень субъективное и тяжело найти различия между маленькими, средними и большими проектами. Разработчики сталкивались не с проблемой размера, а с ситуацией, когда система была слишком большой. Понятие "слишком большая" является более конкретным и связано с тем, что проект перешёл границы, которые мы определили изначально. Когда дело доходит до внесения изменений это может создать определенные неудобства. Другими словами, мы получаем новые проблемы, связанные с масштабом. В конечном итоге, собственник на просьбу "Передвинуть кнопку с правой стороны экрана в левую" получает отчёт о проделанной работе "Это заняло 2 месяца и стоило 1 млн. руб.".

2. Микросервисы ориентированы на задачи.

Это совершенно иной подход в разработке ПО, когда программисты сосредоточены на цели, а не просто на решении. Основное внимание при разработке уделяется исходной проблеме слишком больших систем.

3. Микросервисы взаимозаменяемы.

Это ключевой аспект архитектуры. Когда вы можете заменить любой компонент новым или использовать сервис в другом проекте. Так, компания Avito пошла дальше. Она сделала генератор микросервисов. С помощью него программист может задать программе определённые параметры и она автоматически сгенерирует всё что нужно для разработки. Ему остается только написать бизнес-логику.

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

Владислав Сидоров в своём докладе "Микросервисная архитектура: опыт Ozon" подробно указал на проблемы разработки при наличии большой монолитной системы. Несколько лет назад Ozon был крупной монолитной системой, написанной на стеке технологий Microsoft, где в качестве единственного языка программирования использовался C#.

Подобная архитектура содержала в себе множество недостатков:

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

- Зависимость от одного вендора (в данном случае Microsoft).

- Практически невозможно вносить незапланированные изменения. Представьте ситуацию, когда интернет-магазину нужно срочно отреагировать на изменения рынка и запустить маркетинговую акцию, которая требует внесение изменений в программный код сайта. При таком процессе разработки быстро это сделать не получиться. Придётся ждать практически месяц.

Давайте определимся с понятием, что же мы будем считать микросервисной архитектурой.

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

Какие компоненты можно выделить в интернет-магазине?

Обычно это может быть корзина, история заказов, виджет популярных и рекомендуемых продуктов, карточка товара и прочее. Так, в компании Ozon в качестве первого экспериментального микросервиса, который был написан на языке GO, в качестве БД использовался PostgreSql, т.е. впервые не использовался стек технологий Microsoft, являлся сервис "Мне повезёт". Он был разработан, как API для виджета мобильного приложения, по различным параметрам предлагал пользователям случайный товар. Для этого сервиса была написана определённая логика подбора товаров, сам сервис за первичным набором данных обращался к основному монолитному проекту. Этот экспериментальный микросервис был разработан на удивление быстро, не нужно было ждать всего релизного цикла. А изменения вносились практически в тот же день. Кроме того, он был очень безопасным. Если бы он сломался, то всё, что увидели бы пользователи мобильного приложения - сообщение "Ваш случайный товар не загрузился". При этом само приложение продолжило бы работу.

Из приведённого выше определения мы можем выделить следующие важные характеристики микросервисов:

- Небольшие по размеру.

- Обмениваются сообщениями (используют для взаимодействия с другими микросервисами специальную очередь сообщений).

- Имеют ограниченный контекст.

- Децентрализованы.

Большая часть работ, которая делается микросервисом, независима и не подконтрольна ядру системы.

- Независимые.

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

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

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

Скорость разработки в первую очередь означает тот факт, что программисты способны быстро внести изменения в какой-то из компонентов системы. Так как микросервисы являются очень маленькими и независимыми компонентами всей системы, то внести изменения в логику добавления товаров в корзину не займёт много времени. При этом, каждый функционал может быть отдельным микросервисом. В конечном итоге, количество микросервисов и их размер может варьироваться, от нескольких десятков в Wildberries до нескольких тысяч в Ozon.

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

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

Итак, давайте посмотрим на преимущества для бизнеса, которые даёт нам внедрение микросервисной архитектуры:

1. Сокращение издержек.

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

Микросервисная архитектура позволяет проще оценивать внедрение нового функционала, внедрять новые компоненты.

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

2. Высокая стабильность.

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

Таким образом, мы получаем ключевые преимущества, напрямую влияющие на бизнес интернет-магазина:

- Более прозрачные расходы на разработку.

Мы можем оценить затраты на каждый из компонентов сайта и качественно их контролировать.

- Возможность гибко управлять расходами на сервера.

Первоначальные вложения.

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

- Подрядчик.

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

- Инструменты.

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

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

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

С подобной проблемой столкнулся Wildberries. В 2010 г. этот интернет-магазин существовал, как огромная монолитная система, написанный в виде NET-приложения и использующий MS SQL сервера. После выхода на рынок Беларуси, сервера в праздники и выходные дни не могли выдерживать нагрузку. Тогда компания приняла решение отказаться от монолитного подхода и перейти к микросервисной архитектуре, одновременно отказавшись от стека компании Microsoft, экономя на лицензиях. Wildberries внедрил горизонтальное масштабирование и теперь в период пиковых нагрузок, они могут просто подключать дополнительные сервера. Также они могут автоматически переключаться с одного дата центра на другой, тем самым повышая доступность сайта и скорость его работы.

Итак, какую же архитектуру правильнее использовать? Обычную монолитную архитектуру (когда весь проект находится на одном сервере) или микросервисную (сайт разбит на несколько независимых друг от друга сервисов)?

Начинайте с монолитной архитектуры, если:

- У вас небольшой бюджет, вы хотите сэкономить на первоначальном этапе и обратиться за разработкой к молодой команде 2-4 человека, такой команде практически невозможно разработать качественный проект разделенный микросервисами.

- Вы делаете proof of concept. Если вы только тестируете идею и в будущем вам, скорее всего, придётся вносить кардинальные изменения во всю систему. Для этой цели стандартная монолитная архитектура подходит больше всего, поскольку она поддерживает быструю итерацию.

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

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

- Часть вашего e-commerce проекта должна быть супер-эффективной. Предположим, вы делаете сложную интеграцию с Facebook, т.к. почти половина ваших товаров продаётся именно там. И вы обрабатываете большой поток веб-хуков из этой социальной сети. Этот сервис может быть написан на совсем другом языке программирования, например, на Go. При этом, админ-панель всего интернет-магазина написана на PHP. Организовать это всё в монолитной архитектуре слишком длительный и дорогой процесс.

У портала Авито, к примеру, один из первых тестовых микросервисов являлся API автозаполнения адресов, который также должен был выдерживать большую нагрузку. Также первыми микросервисами были: валидация объекта недвижимости по кадастровому номеру и рассылка email-сообщений продавцам товаров (если клиент захотел отправить им сообщение). Сейчас в Авито более тысячи микросервисов, из них около 200 критичных, а 2500 баз данных.

- Чтобы быть готовым к изменчивости рынка, вам нужно постоянно тестировать новые решения, а это значит, что ваша задача, как можно быстрее внедрять новый функционал. Предположим, что ваш e-commerce проект устраивает акции практически по всем Российским праздникам и вы рассылаете миллион уведомлений на почту своим клиентам. В случае с монолитной архитектурой вы либо будете нагружать основной сервер, либо будете вынуждены использовать сторонние сервисы для рассылок. В случае с микросервисной архитектурой это не будет проблемой, т.к. вы можете сделать отдельный сервис рассылок, который будет заниматься не только рассылкой предложений с акционными предложениями по праздникам, но и возьмет на себя рассылку всех сервисных уведомлений, отправляемых на email. Возросшая нагрузка на рассылки в праздники никак не повлияет на скорость работы всего сайта. А изменения в сервисе рассылки будет вестись намного быстрее, нежели в случае с монолитной архитектурой, где компоненты между собой связаны.

Что же дальше?

Если вы с самого начала приняли решение использовать микросервисную архитектуру, значит вы в значительной степени настроены на долгосрочную перспективу.

Но что, если финансовые возможности сегодня не позволяют этого сделать? Вы можете обратиться к подрядчикам, которые спроектируют вам монолитную архитектуру, при этом получат часть преимуществ микросервисов.

Например:

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

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