- PVSM.RU - https://www.pvsm.ru -
Когда задумывается большой продукт или маленький софт начинает вырастать в левиафана, какой путь развития выбрать? Стоит ли все переписывать с нуля или продолжать «исторически сложившиеся» традиции? Да и вообще, стоит ли пересматривать саму концепцию архитектуры?
Здравствуйте! Меня зовут Константин, и я являюсь ведущим разработчиком одной довольно крупной системы, которая начиналась когда-то как эксперимент. Небольшой сайт на PHP, созданный буквально «на коленке» и, конечно же, монолитом. Шло время, сайт рос и столкнулся с рядом проблем, решение которых поставило вопрос «а дальше-то как?».
Монолит или микросервисы? Что же выбрать? Базовое отличие подходов, на мой взгляд, состоит в том, что монолит подразумевает централизованный цикл обработки запроса пользователя, а микросервисы — децентрализованный. Общие достоинства и недостатки обоих подходов широко известны и не раз перечислены (например, тут [1], тут [2] или тут [3]). Однако есть и не столь явные и очевидные факторы, влияющие на выбор архитектуры.
А надо ли вообще выбирать? Стоит ли игра свеч? Я думаю, безусловно, стоит. Но подходить к вопросу надо с холодной головой. Иначе одни проблемы просто заменятся на другие.
В моем случае переломный момент наступил, когда сайт перестал «вмещаться» в ресурсы одного сервера. Тогда было принято решение переписать систему в соответствии с наилучшим по моему мнению вариантом — гибридным. Есть общие рекомендации [4] по развитию продукта в «гибридном случае». Но я хотел бы его дополнить несколькими рекомендациями.
Проектируя стартовый монолит, возможности дальнейшего подключения внешних сервисов нужно заложить сразу. Сразу строить межкомпонентные связи так, как будто эти компоненты уже (или почти уже) «внешние сервисы». Особенно, если они ресурсоемкие.
Сразу же продумать политику работы с кешами и хранилищами данных (БД и файлы). Например, обеспечить общий доступ к сессии пользователя.
И самое главное — не кидаться в крайности. Для себя я вывел следующую формулу хорошего проекта: «эффективная система — это сбалансированная система». В частности, это выражается в том, что в микросервисы я выношу только большие, логически обособленные фрагменты ядра. И то, только при выполнении хотя бы одного из условий:
Как результат такого подхода получилась система, 95% функционала, которой располагается в ядре, и 5% — в микросервисах. Но при этом на ядро приходится только 60% всей нагрузки. И при этом можно гарантировать, что нагрузка на отдельные сервера не превысит критических значений.
Так что микросервисы — это (с определенного размера продукта) хорошо, если использовать их только в случае реальной необходимости, а не в силу моды или «потому что круто». Есть большие продукты [5], которые успешно живут монолитом. Но иногда монолитом задачу не решить…
Спасибо!
Автор: Константин
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/323777
Ссылки в тексте:
[1] тут: https://habr.com/ru/post/311208/
[2] тут: http://devopsru.com/news/2016-05-10-microservice-trade-offs.html
[3] тут: https://eax.me/microservices-vs-monolithic/
[4] общие рекомендации: https://tproger.ru/translations/monolithfirst/
[5] продукты: https://habr.com/ru/post/459206/
[6] Источник: https://habr.com/ru/post/459810/?utm_source=habrahabr&utm_medium=rss&utm_campaign=459810
Нажмите здесь для печати.