Почему сначала надо разрабатывать (модульный) монолит? #перев | ИТ-архитектура

Почему сначала надо разрабатывать (модульный) монолит?

#перевод_для_канала_itarchitecture

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

В микросервисном подходе также есть несколько недостатков - система становится сложной для обслуживания и диагностики проблем (логирование и отслеживание). И это очень важно при работе с микросервисами.

Между тем, создание монолитов само по себе не является лучшим решением. В последние годы мы часто видели идентификацию монолита с архитектурой big ball of mud (“большой шар грязи”) или только написания устаревающего кода, что на самом деле некорректно. Да, монолиты не могут масштабировать независимые части системы или релизить их отдельно, в этом самые большие недостатки монолита. Тем не менее, вы можете писать отличный и качественный код внутри. Также монолит приносит нам гораздо меньшую сложность, сокращение сетевых вызовов, упрощение логирования и т.п.

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

Когда мы хотим построить модульный монолит, важно сначала разделить систему на управляемые модули, прежде чем собирать эти модули в монолит для развертывания. Поскольку вся связь между модулями может привести к межсетевым вызовам, если вы решите разбить его на сервисы в будущем, high cohesion (высокая согласованность) и low coupling (низкая связность) имеют решающее значение. Это означает, что вся межмодульная связь должна быть абстрактной, асинхронной или основанной на обмене сообщениями, чтобы модули могли обрабатывать вызовы, которые будут проходить по сети в будущем.

Как мы можем реализовать такую концепцию? Мы создаем отдельные модули, каждый из которых может иметь свою собственную архитектуру, и эти модули объединяются в один API Gateway (шлюз API). Это позволяет нам развертывать всю систему как монолит, но позволяет нам извлекать отдельные модули в сервисы, если это необходимо в будущем.