Ограничения производительности монолитного приложения
Существует множество причин, по которым можно изменить архитектуру системы. Операционная гибкость, затраты, масштабируемость и производительность являются лишь некоторыми из факторов, которые играют роль в определении архитектуры системы. В нашем примере мы более подробно рассмотрим, как производительность становится фактором для системы доставки дронов.
По мере роста бизнеса доставки беспилотных летательных аппаратов Fabrikam нагрузка системы увеличивается. Текущая архитектура напрягается под нагрузкой. Fabrikam хочет повысить гибкость масштабирования приложения, недоступного в текущей монолитной архитектуре. Улучшение масштабируемости приложения является одним из факторов для Fabrikam рассмотреть возможность перемещения своего приложения на микросервисную архитектуру.
Масштабирование монолитных и микрослужб
Одним из основных преимуществ архитектуры микрослужб является увеличение масштабируемых возможностей. Так как службы разделены, их проще масштабировать по отдельности по мере увеличения нагрузки между ними.
Мы видим это различие в возможностях в системе доставки дронов. С монолитной архитектурой все службы содержатся в одном экземпляре приложения. Они предоставляют интерфейс API клиентам для отправки запросов на доставку и управления ими. По мере увеличения запросов клиентов нагрузка на систему увеличивается. Чтобы избежать негативного влияния на взаимодействие с пользователем, необходимо выделить дополнительные ресурсы.
В монолитной архитектуре масштабирование этой службы также требует масштабирования ресурсов для других служб, так как они содержатся в каждом экземпляре приложения. Это неэффективно, так как загрузка для других служб может быть минимальной и не требует дополнительного использования ресурсов.
В архитектуре микрослужб, так как каждая служба является отдельной, мы можем масштабировать API независимо от других служб. Это соглашение повышает эффективность, так как нам не нужно использовать ресурсы ненужных служб.
Проблемы с монолитной архитектурой доставки дронов
Служба пакетов была определена как важная часть бизнеса и изначально была частью монолита. Клиенты резко увеличивают свою зависимость от нее, и производительность негативно влияет, так как эта нагрузка увеличивается. Чтобы справиться с этой ситуацией, Fabrikam выделила команду разработчиков с полным контролем над этой частью бизнеса. Команда планирует разрабатывать и итерировать эту службу и отвечать исключительно за все аспекты службы пакетов.
Поскольку пакетный сервис находится в монолите, команда не может работать автономно. Они должны полагаться на общие данные и структуры данных. Они также не могут итерировать так быстро, как им нужно. Наряду с проблемами производительности и масштабируемости эта служба определяется как основной кандидат для микрослужбы.
Давайте рассмотрим, как Fabrikam может анализировать и разлагать свое приложение, чтобы воспользоваться архитектурой микрослужб.