Микросервисная архитектура: теория и практика

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

В какой-то момент объём кода вырос до полного собрания сочинений Толстого. Как следствие – обновления разрабатываются все дольше, а тестировать их все сложнее. Это стандартная проблема для сложного программного обеспечения. Решить проблему узких мест на проекте можно используя микросервисы: везде, где есть «тяжелые» процессы, теоретически их можно вынести в специальное окружение.

Простыми словами – вы берете тяжелый и неповоротливый процесс. Убираете его из приложения, и запускаете в отдельном контейнере, где он работает сам по себе. А потом обращаетесь к нему при необходимости.

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

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

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

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

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

Сервисы связываются между собой и с клиентами с использованием лёгких протоколов, например, HTTP. В результате создается простая для настройки система, которую проще регулярно обновлять. Ключевая идея микросервиса – независимость от окружающей среды и высокий уровень повторного использования.

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

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

Работать с микросервисами мы умеем уже очень давно. Году так в 2014 мы разрабатывали на Symfony логистический проект – расчет маршрутов доставки. Когда пользователь выбирает, например, доставку из Копенгагена в Токио, и ему предлагается несколько маршрутов по разным ценам.

Сначала маршруты рассчитывались откровенно долго: на поиск одного маршрута уходило от десяти до тридцать секунд, а маршрутов получалось несколько. Чтобы решить проблему, мы использовали одновременно несколько сервисов (демонов) расчета маршрута плюс сервер очередей.

Пользователь выбирал город. Задача попадала на сервер очередей. Демоны забирали эту задачу и рассчитывали каждый свой маршрут. То, что в один поток рассчитывалось бы 5-10 минут, мы получали в среднем за 15 секунд за счет параллельного расчета. Для сегодняшних реалий это очень много, но на момент разработки проекта – это был прорыв.

Микросервисы удобно реализуются при разработке на фреймворках – мы любим Laravel, Symfony – тоже ок. А вот для сайтов на Битрикс – все не так просто. Интернет-магазин нашего постоянного клиента Ormatek работает именно на Битриксе. На начало 2021 года там было около 200 тысяч товарных предложений.

Может показаться странным, что у магазина матрасов и мебели такой объемный каталог. Но каждая кровать может быть представлена в десятке размеров. С десятком вариантов оснований. А еще в 40+ вариантах исполнения. Если всё это перемножить – получается 4000+ вариантов на одну кровать. Очень серьезно.

Такой объем каталога создавал две проблемы:

Мы вынесли поиск, фильтрацию, сортировки и импорт в микросервисы. Для этого внедрили поисковую систему Elasticsearch. При старой архитектуре (использовался штатный модуль поиска 1С-Битрикс) поиск занимал около 10 секунд, что для обычного пользователя слишком много.

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

Да, сначала мы пытались оптимизировать битриксовый поиск. И даже довели его скорость до 8 секунд. Но уперлись в ограничения Битрикса. Начали думать в сторону кеширования, но в случае с фильтром кеширование бесполезно, так как каждую комбинацию и каждый параметр фильтрации (малейшее движение ползунка) кешировать нецелесообразно.

Итак, мы решили перенести сортировку и фильтры в Elasticsearch. Если очень примитивно и схематично, то вот что у нас происходит теперь:

В рамках оптимизации мы написали каждому параметру фильтрации/сортировки во всех разделах товаров свой запрос в Elastic. Суммарно, страницы списка товаров, в том числе кроватей, стали загружаться менее, чем за 3 секунды.

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

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

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

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

Заодно решили проблему «узких мест» – часто выполняемых участков кода, которые своей производительностью ограничивали работу всей системы в целом. Весь функционал, который требует много ресурсов, например поиск или оптическое распознавание (OCR), мы также вынесли в отдельные сервисы, работающие в изолированной среде. Чтобы они не отбирали ресурсы у остальных частей проекта.

Появилась возможность гибко управлять серверными ресурсами, на которых работает проект. Для критичных сервисов всегда можно выделить отдельный сервер. Если функционал не очень важен и не хочется позволять ему сильно много – пожалуйста. Можно дать ему, скажем, один процессор и полмегабайта памяти и сказать: «Крутись, как можешь». При монолитной архитектуре ограничить по ресурсам какую-то функциональность проекта было нельзя – там работает принцип «кто первый встал – того и тапки.

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

По сути докер – это виртуальный сервер. Можно создать в рамках одного физического сервера (компьютера) много виртуальных серверов и разделить ресурсы между ними так, как надо нам. А потом разместить микросервисы в докерах, чтобы они не толкались и не дрались друг с другом за ресурсы.

В качестве бонуса – в каждом докере можно использовать свое программное обеспечение. Например, у нас есть сервер разработки – dev. Там докеры используются, в том числе, для сайтов с разными версиями PHP, чтобы ничего не конфликтовало.

Еще добавилась такая такая штука, как балансировщик нагрузки (мы используем Docker Swarm). Это, по сути, система-оркестратор, которая позволяет управлять всем зоопарком микросервисов и гибко перераспределять ресурсы между ними.

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

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

Все было готово. Но у нас были пользователи в SingularityApp. Огорчать и терять их было нельзя. Надо было перевести их на новую архитектуру так, чтобы они ничего не заметили, кроме того, что все стало работать лучше и быстрее.

Сначала мы оставили одновременно два сервера SingularityApp: новые устройства пользователей автоматически заходили на микросервисный сервер, а старые – на монолитный. Никакой практической разницы для пользователей не было, приложение на обоих серверах работало одинаково.

Постепенно пользователи обновляли свои приложения и автоматически перетекали на новый сервер. В начале 2021 года последний из них незаметно для себя перестал пользоваться монолитом. Сейчас монолитный сервер отключен.