Я всегда слышал о микросервисах, вероятно, потому, что это более новая концепция, и вокруг нее много шумихи, но, как новый разработчик программного обеспечения, я более подвержен монолитной архитектуре. За последний год я многое узнал об этих двух архитектурах, и в этой статье я поделюсь с вами информацией о том, когда лучше выбрать одну, а какую другую.
Что такое монолит?
Монолит — это просто один большой камень, часто в форме обелиска или колонны, согласно Merriam-Webster.
Монолитное приложение представляет собой единую унифицированную и неделимую единицу, считается традиционным способом построения приложений. Обычно при создании монолитного приложения решение включает пользовательский интерфейс на стороне клиента, приложение на стороне сервера и базу данных.
В этой архитектуре уровни приложений можно описать следующим образом:
- часть того же агрегата
- код управляется в одном репозитории
- ресурсы (например, ЦП и память) являются общими
- вся кодовая база сделана на одном языке программирования
- выпущен с использованием одного двоичного файла, развернутого как единое целое.
Почему вы должны выбрать
- Простота разработки — целью современных средств разработки и IDE является поддержка разработки монолитных приложений.
- Простота развертывания — вам просто нужно развернуть файл WAR (или иерархию каталогов) в соответствующей среде выполнения.
- Простота масштабирования — вы можете масштабировать приложение, запуская несколько копий приложения за балансировщиком нагрузки.
Что такое микросервисная архитектура
Микрослужба — это просто набор небольших служб, которые могут быть частью других небольших служб или более крупных служб и развертываться независимо друг от друга.
Эта архитектура разбивает приложение на набор небольших независимых единиц или служб, которые являются ключевыми бизнес-функциями. Идея состоит в том, чтобы разделить приложение на более мелкие взаимосвязанные службы.
Уровни приложений управляются независимо, как разные единицы. Каждая единица имеет следующие характеристики:
- код управляется в отдельных репозиториях
- ресурсы (например, ЦП и память) выделяются каждому устройству независимо
- четко определенный API (интерфейс прикладного программирования) для подключения к другим устройствам
- может быть реализован с использованием языка программирования по выбору в зависимости от инженерных или функциональных требований.
- каждый модуль выпускается с использованием собственного двоичного кода, и модули развертываются независимо.
Соображения, чтобы сделать
Иногда приложение может быть разработано с использованием как монолитной, так и микросервисной архитектуры. Однако каждая архитектура имеет ряд компромиссов, которые необходимо тщательно изучить, прежде чем принимать решение об окончательной структуре приложения.
Сложность разработки
Сложность разработки — это усилия, необходимые для разработки, развертывания и управления приложением.
- Monoliths — один язык программирования; один репозиторий; обеспечивает последовательное развитие
- Microservice – несколько языков программирования; несколько репозиториев; обеспечивает параллельную разработку
Масштабируемость
Масштабируемость — это то, как приложение является мерой способности системы увеличивать или уменьшать производительность и затраты в ответ на изменения в требованиях к обработке приложений и системы.
- Монолиты — требуют репликации всего стека; что делает его тяжелым и высоким потреблением ресурсов.
- Микросервис — требует репликации только тех единиц, которые предоставляют требуемые сервисы, что обеспечивает потребление ресурсов по требованию.
Время развертывания
Время развертывания учитывает время, необходимое для доставки функций, то есть время, необходимое для создания и доставки функции.
- Монолиты — существует один конвейер доставки, который развертывает весь стек; больше риска связано с каждым новым развертыванием, что приводит к снижению скорости доставки. Сбой в одной части приводит к задержке всего развертывания.
- Микрослужба — множество конвейеров доставки, в которых развертываются отдельные модули; меньший риск при каждом развертывании, что приводит к более высокой скорости разработки функций. Одиночный сбой не может повлиять на другие службы
Гибкость
Гибкость подразумевает способность адаптироваться к новым технологиям и внедрять новые функции.
- Монолиты — имеют низкий уровень гибкости, поскольку может потребоваться реструктуризация всего стека приложений для включения новых функций.
- Микросервис - имеют высокую скорость, так как смена самостоятельного блока проста и понятна и в перерыве измененный блок не повлияет на все приложение.
Эксплуатационные расходы
Операционные затраты представляют собой стоимость необходимых ресурсов, необходимых для выпуска продукта.
- Монолиты — имеют низкую начальную стоимость, поскольку необходимо управлять одной кодовой базой и одним конвейером. Однако стоимость увеличивается экспоненциально, когда приложение должно работать в масштабе.
- Микрослужба — высокая начальная стоимость, поскольку требуется управление несколькими репозиториями и конвейерами. Однако в масштабе стоимость остается пропорциональной потребляемым ресурсам в этот момент времени.
Надежность
Надежность рассматривает методы восстановления приложения после сбоя и инструменты, используемые для мониторинга приложения.
- Монолиты — в случае сбоя необходимо восстановить весь стек. Кроме того, видимость каждой функции низкая, поскольку все журналы и метрики собираются вместе.
- Микросервис — в случае сбоя необходимо восстановить только неисправный модуль. Кроме того, журналы и метрики для каждого модуля хорошо видны.
Заключение
Посмотрев как на микросервисы, так и на монолиты, бизнес должен выбрать лучший путь. Посмотрите, каковы ваши функциональные требования и какие ресурсы вам доступны, насколько сложным будет ваше приложение, и используйте приведенные выше пункты в качестве контрольного списка, чтобы решить, какую архитектуру использовать.
Рекомендации
Эта статья вдохновлена стипендиальной программой Udacity Cloud Native Fundamentals, которую я принял в 2021 году.
