Распиливаем монолит на микросервисы: наш опыт для американской аналитической компании
Привет! На связи Александр Долгов, CEO в Innovedge Soft. Мы занимаемся разработкой сайтов, мобильных приложений и интеграционных сервисов любой сложности. На днях коллега по цеху затронул интересную и непростую тему “Монолит vs микросервисы”, которая неожиданно (учитывая нетехническую направленность ресурса) нашла отклик у сообщества.
“Тем лучше!” - подумали мы, ведь у нас как раз готовилось описание кейса по распиливанию на микросервисы интересного и сложного проекта для одной аналитической компании из США. Итак, готовьте ножовки. Будем пилить!
Предпосылки
История классическая. Наш клиент - эксперт в своем деле (аналитика и маркетинг), имеющий пул своих клиентов от текущего работодателя, в один прекрасный момент подумала “why not” и начала делать бизнес. У него, конечно, был друг разработчик в доле, который кодил первую версию системы. Он, естественно, обещал себе, что с первым профитом введет регламенты разработки, code style и прочее, но время шло, проект, катясь по релизной дорожке, рос как снежный ком, впитывая в себя все новую и новую функциональность.
На момент обращения к нашей команде, реализованная система клиента представляла собой развернутый в облаке web-портал, который, в зависимости от типа авторизованного пользователя, предоставлял доступ к определенному набору функций: для контракторов, работающих “в полях” и собирающих данные для аналитики, и для менеджеров компании клиента, которые этими контракторами и собранными данными управляют.
С точки зрения кода это было одно большое решение ASP.NET MVC с общим бэкендом и фронтендом, использующее общую довольно распухшую базу данных MS SQL Server.
Что и почему пилим?
Главные боли клиента на тот момент:
- Поддержка и расширение функциональности. Из-за плохо продуманной архитектуры и тесной связанности компонентов, правки багов и внедрение новых фич приводили к непредсказуемым результатам. Работая, к примеру, над бэкендом блока для контракторов, часто что-то ломалось у менеджеров, и наоборот.
- Стабильность. Наличие общего бэкенда у двух по сути разных порталов означало, что если что-то пошло не так при релизе менеджерского портала, работа встанет у всех контракторов, и наоборот.
- Связанность бэкенда и фронтенда. Из-за особенности инструментов, использованных при разработке системы, в большинстве случаев, изменение функциональности фронтенда вело к ре-деплою системы целиком.
- Безопасность. Клиент пришел к нам после предварительно проведенного аудита безопасности с твердым намерением развернуть у себя свой отдельный сервер авторизации.
- Безопасность. Клиент пришел к нам после предварительно проведенного аудита безопасности с твердым намерением развернуть у себя свой отдельный сервер авторизации.
Реализация
Состав проекта
Решение для нас было очевидным:
Не менее очевидным для нас были и сервисы, на которые монолит должен был быть распилен:
- Авторизационный сервис
- Сервис для контракторов
- Сервис для менеджеров
Тут следует уточнить, что каждый микросервис это по сути API для соответствующего портала. Фронтенд часть для каждого сервиса также реализуется в виде отдельного проекта/приложения. Просто формально фронт не относится к микросервисам, поэтому в нашем перечислении не указан.
Главным условием заказчика было сохранение работоспособности портала на всем протяжении модернизации системы. Внедрение обновленных порталов должно было быть плавным, т.е. даже в рамках одного портала новый функционал должен был выкатываться по-модульно. Например, если для менеджерского портала готов модуль "Отчеты", то по умолчанию, после авторизации, мы попадаем в старый портал, но при переходе в Отчеты попадаем уже на обновленную версию.
Такой масштабный проект - это еще и отличный шанс обновить фреймворки и инструменты, которые использовались для оригинальной системы. Бэкенд-сервисы решено было делать с использованием последней на тот момент версии .NET. Фронт на Angular. Помимо этого, для сервиса авторизации был использован Identity Server, но это запрос клиента, против которого мы возражать не стали.
Ну и куда без новых фич. Раз уж рядом с монолитом растут с нуля новые порталы, то не добавить в них накопленные за последнее время хотелки - преступление.
План действий
С чего же начать? Вопрос при распиливании краеугольный. Но единственно верного ответа на него, к сожалению, нет. Все очень сильно зависит от текущей функциональности, целевого набора микросервисов, особых требований клиента, и т.д.
В нашем случае план был следующий:
- Реализация авторизационного сервиса. Пользователь, прошедший авторизацию должен иметь доступ как к старому порталу, так и к соответствующему новому порталу.
- Реализация промежуточной логики с отдельным служебным порталом, через который администраторы могли настраивать какие модули порталов должны открываться в старом портале, а какие уже в соответствующих новых порталах.
- Реализация сервиса для контракторов и фронтенд для портала, который его использует.
- Реализация сервиса для менеджеров и фронтенд для портала, который его использует.
Логика в данной последовательности действий довольно четкая. Сперва мы должны модернизировать фундаментальный функционал: возможность пользователям авторизовываться, восстанавливать и сбрасывать пароль, включать-отключать двухфакторную авторизацию. Затем, параллельно начав работать над новыми порталами, часть команды обеспечивает функционал, который позволяет управлять вводом в эксплуатацию модернизированных частей функциональности.
Ну и порядок реализации самих порталов не случаен - все же источником данных в портале менеджеров служат данные, которые создаются и изменяются в портале контракторов. Значит сервис контракторов (по крайней мере его определенная часть) должен быть реализован первым.
Разработка
Сам по себе процесс разработки ничем не отличался от привычного, за исключением ряда нюансов:
- Неровная конфигурация команды. У клиента была небольшая инхаус команда, которая была дополнена нашим разработчиком и нашим же тимлидом. В команде клиента были как сильные разработчики с американского рынка, так и пара откровенно слабых ребят из Пакистана.
- Довольно много функционала брали из внешних библиотек (календари, PDF viewrer’ы и т.д.). То есть максимально экономили на разработке того, что могли заместить готовой библиотекой. Отсюда кропотливый выбор подходящих библиотек. Вообще, это отдельная тема для статьи, которую мы уже готовим.
- Рваный темп. Пока мы орудуем ножовкой, бизнес как работал так и работает. А это значит, что если в действующем портале возникали баги (или нужна была критически важная фича), мы должны были править код соответствующим образом, и зачастую не только для действующего портала, но и для уже реализованного функционала новых порталов.
Результаты
В результате за 9 месяцев работы команды разработки из 3-5 человек (на разных этапах размер команды менялся), новые порталы были запущены. Помимо более чистой архитектуры, клиент получил обновленный современный фронтенд и с десяток крупных фич, накопившихся в бэклоге.
Если подвести некий итог, то, приступая к такому рода проекту нужно иметь в виду следующее:
- Будет много плохого кода. Неочевидных решений. Запрятанной бизнес-логики. Это нужно учитывать при обсуждении схемы работы. Фикс-прайс тут выглядит тупиковым подходом как для заказчика, так и для подрядчика.
- Перед распиливанием монолита очень важно досконально знать реализованную бизнес-логику - это поможет спланировать в какой последовательности и по какому принципу система будет делиться на микросервисы.
- Ну и самое главное: у всех сторон должно быть понимание для чего все это делается. “Микросервисы” - звучит модно и молодёжно. Но нужны они не всем и не всегда.
Переход на микросервисы, описанный в статье, может выглядеть привлекательно на первый взгляд, однако не учитывает многих критических аспектов. Первое — это подцененная сложность разделения монолита на микросервисы, которая требует глубокого понимания бизнес-логики и может привести к значительным временным и финансовым затратам. Во-вторых, статья не обсуждает потенциальное увеличение сложности управления инфраструктурой и межсервисного взаимодействия, что может негативно сказаться на производительности и надежности системы. В-третьих, выбор микросервисной архитектуры не всегда оправдан с точки зрения бизнес-целей и может привести к переусложнению архитектуры без заметного прироста в гибкости или масштабируемости.
Согласен с вашим комментарием. Именно поэтому посчитал важным закончить статью фразой:
"Ну и самое главное: у всех сторон должно быть понимание для чего все это делается. “Микросервисы” - звучит модно и молодёжно. Но нужны они не всем и не всегда."
Так что да, хотя переход на микросервисную архитектуру может иметь свои преимущества, включая повышение гибкости и масштабируемости системы, необходимо внимательно взвешивать все его аспекты и учитывать особенности конкретного проекта и бизнес-задач.
спасибо, что вы есть, такая компания. Которая занимается переливанием пустого в порожнее, однако поддерживает рынок разработчиков тем, что не выкидывает их в рынок и не роняет зарплаты в итоге.
Побольше бы вас еще, чтобы потом было 4 микросервиса, вы сделали 8, потом через годик 16. Потом посидели подумали, наняли больше людей и сделали 32. Через три года решили все-таки сократить, опять до 4 и так по кругу.
спасибо!
Вы сейчас сидите за компом, прости Господи (а не стоите у станка или не в шахте какой-нибудь руду добываете) только потому что когда-то другие компании придумали 4 байта, 8 байт, 16 байт, 32 байта, ..... 4 мбайта, 8 мбайт, 16 мбайт .... и так по кругу!
Обращайтесь :)
Статья рассказывает о проекте по переводу монолитной системы на микросервисы
Саммари:
- Команда Innovedge Soft модернизировала систему аналитической компании
- Перевели монолитную архитектуру в микросервисную
- Проект включал авторизационный сервис и отдельные сервисы для разных пользователей
- Работоспособность системы поддерживалась на протяжении всей модернизации
- Обновили фреймворки и инструменты, включая .NET и Angular
- Модульная реализация новых функций
- Использование Identity Server для авторизации
- Проект осуществлялся командой разработчиков с разным уровнем квалификации
- Интеграция внешних библиотек для экономии времени и ресурсов
- Процесс разработки сопровождался работой над текущими багами и фичами
- Результатом стал запуск новых порталов с современным дизайном и архитектурой
- Важность детального знания бизнес-логики и планирования перед распиливанием монолита
- Микросервисы не всегда являются лучшим выбором для всех проектов
Стараюсь выделять самое важное для вас.
так а база осталась общая? просто разделили монолит на 2 монолита, но поменьше?