Пример: переход от монолита к микросервисам
Я работал в проекте Crypterium — это сайт и мобильное приложение для доступа к криптокошельку. Можно было пополнять кошелек банковской картой и переводить деньги по номеру телефона. Изначально это был монолит на Java с несколькими сторонними API, которые предоставляли партнеры проекта. Эти API позволяли отправлять и принимать платежи, создавать кошельки и адреса, отправлять СМС.
В определенный момент разработчиков перестал устраивать монолит: чтобы обновить фрагмент кода, нужно поднимать новые версии библиотек во всëм приложении. Микросервисы же позволяют писать новый сервис на новых технологиях, а старые оставить на старых. Если понадобится — в будущем исправим, если нет — работает и работает. Именно в этом главный плюс микросервисной архитектуры: фрагменты кода изолированы друг от друга, и правки в одном из них не требуют правок в другом.
Разработчики Crypterium решили писать новую функциональность на новом языке — Kotlin вместо Java. Это был хороший повод внедрить микросервисную архитектуру. Чтобы не переписывать всë целиком, решили начать с новых задач. Например, я разрабатывал микросервис интеграции с ЮKassa, QIWI и другими платëжными системами. Функциональность монолита тоже постепенно переносили на микросервисы. Первыми на очереди были самые нагруженные части, потому что микросервисная архитектура позволяет перераспределять нагрузку именно туда, где она нужна.
Переход на микросервисы не был для Crypterium оптимальным решением. На микросервисную архитектуру сложнее настроить мониторинг, потому что нужно отслеживать больше блоков. Если нет хорошего инфраструктурного решения для оркестрации микросервисов, возникают трудности. У нас же в качестве такого решения выступала сама программа: несмотря на то что сервисы были отдельными, их код хранился в том же репозитории, что и монолит. Это замедляло тестирование и отладку каждого сервиса.
Эту боль предполагалось исправить, но она была не в приоритете. Наш IT-директор понимал, что бизнес платит нам зарплату за готовые работающие решения, а не за то, что мы написали красивый код. Он говорил: «Ребята, давайте сейчас как-нибудь сделаем, начнем получать деньги от продукта, а потом уже будем переписывать, наводить красоту». Я с ним согласен, потому что разработку можно затягивать сколь угодно долго, но рано или поздно у инвесторов закончатся деньги, а программа всё еще не вышла на окупаемость.
В итоге проект так и остался гибридом: часть сервисов перенесли, но основа так и осталась на монолите. Переводить всë на микросервисы просто не было смысла.
Пример: проект изначально на микросервисах
В проекте White Sky Digital Lab я участвовал в разработке интернет-банкинга для ФорБанка. С самого начала писали код под микросервисы, и это было кайфово, потому что мы использовали готовое решение и не думали об инфраструктуре. Нас интересовали только бизнес-логика и код.
В отличие от монолитной архитектуры, которая позволяет легко обращаться из одного сервиса в другой, микросервисы требуют оркестрации. Ведь это отдельные сущности — каждый на своем порте, хосте и со своим URL. Возникает вопрос, как организовать их взаимодействие: как поднять микросервис, как зарегистрировать его для других микросервисов, как его обновить. Это должно происходить бесшовно: поднимаем новую версию и ведем на нее все запросы, перестаем лить трафик на старую. Когда запросы на старый сервис закончились, отключаем его и полностью переходим на новый.
Чтобы решать вопросы организации сети микросервисов, опытные разработчики создали библиотеки. Такие библиотеки позволяют объединить все микросервисы в один контур, где они сами общаются между собой. Снаружи остается только один главный сервис, который принимает запросы и направляет их, куда нужно. В White Sky Digital Lab мы использовали Netflix Eureka — специальную программу, которая координирует микросервисы: регистрирует, выдает им имена, следит за обновлениями и перенаправлением запросов.
Микросервисная архитектура позволила нам писать новые сервисы на новых технологиях и сделать так, чтобы владение кодом было распределено между людьми. В этом случае конкретному разработчику не нужно знать код всей программы — достаточно знать код микросервиса, над которым он работал. Если нужно обратиться к коду одного из микросервисов, можно спросить у владельца кода или у коллег, и они подскажут, где этот код находится. А если грамотно формировать URL микросервисов, используя префикс проекта, тогда их вообще не придется искать.
Разобраться в коде микросервиса можно намного быстрее и проще, потому что он решает одну или ограниченный ряд задач. Всë содержание кода находится в узком контексте. Ты понимаешь: это сервис денег, и если здесь есть Transaction ID, то это ID денежной транзакции, а не телефона или базы данных. У тебя нет разночтений — ты знаешь, что здесь всë касается денег. Это упрощает работу.
Микросервисы: переходить или не переходить
Микросервисы порой усложняют написание кода. Казалось бы, логика конкретного действия должна быть инкапсулирована в одном микросервисе. Так и есть, но по факту пользовательский флоу (User Story) идет не по маленькой функциональности — наоборот, у тебя длинная операция.
Например, нужно сделать пополнение кошелька. Сначала идет запрос от фронтенда на бэкенд начать процесс вывода на карту. Подключается сервис выводов на карту: User ID, сумма, реквизиты карты. Этот сервис вывода говорит: «Сходи к сервису пользователей и посмотри, есть ли у этого человека право вывода на карту». Если я хочу посмотреть, как проверяются права, я должен зайти в этот микросервис. Потом сервис, который проверяет наличие денег на счете. Потом сервис проверки реквизитов. Дальше переходим непосредственно к выводу на карту и вызываем сервис партнера, чтобы он сделал выплату. По каждому сервису нужен отдельный репозиторий. А в монолите это всё в одной кодовой базе, и ты видишь там всë, что тебе нужно, если нагрузка небольшая.
Часто те, кто внедряет микросервисы, получают микросервисную сложность, а из бонусов, которые она дает, используют только один: легкую организацию кода. Но если подходить к написанию кода с умом, это можно получить и в монолите. До нагрузки около 500 тысяч пользователей приложения отлично работают на монолитной архитектуре. А микросервисы — это накладные расходы на тестирование сервисов и поддержку репозиториев, даже просто больше вкладок с документацией в браузере. Наличие большего количества элементов на каждом шаге дает дополнительные шаги, а в монолите меньше шагов, можно просмотреть весь код от и до.
Просто в определенный момент каждый уважающий себя разработчик, архитектор, аналитик начал говорить: «Давайте следующий проект делать на микросервисах». Часто стимулом для перехода на микросервисную архитектуру становится желание разработчиков ее попробовать, хотя нет ни большой нагрузки, ни необходимости делить код. Я лично считаю, что микросервисная архитектура не нужна в 70–80% случаев, где применяется сейчас. Это просто мода, под влиянием которой на микросервисы перешли даже те, кому это совсем не нужно.
Где были по-настоящему нужны микросервисы, так это в Сбербанке. Там я работал в проекте «Сверка». Это огромные объемы данных — все транзакции по всей стране за день: пенсии, штрафы, зарплаты, переводы. Тогда разработчики еще не говорили о микросервисной архитектуре, но мы ее уже применяли. Было несколько шагов обработки данных: загрузка, парсинг, формирование удобоваримого для программы формата данных, анализ и загрузка результатов обработки. Каждый из этих шагов — отдельный микросервис. Единственное, мы отправляли запросы не через Registry или URL, а в очередь, и другой микросервис считывал данные из этой очереди. Совершал обработку, передавал в другую очередь и так далее. По сути, это была микросервисная архитектура, хотя это так не называлось.
В Сбербанке это было необходимостью, потому что нужно было распределять оперативную память между сервисами. Мы видели, что на парсинг данных тратится много ресурсов, один микросервис не справляется. Тогда мы поднимали его в большем количестве экземпляров. Это было то, что нужно.
Так что нельзя однозначно сказать, какая архитектура лучше. Определенные задачи лучше решает монолитная архитектура, определенные — микросервисная. Нужно смотреть на задачи и, отталкиваясь от них, решать, какая архитектура уместна в конкретном случае.
