Введение
Есть множество разных способов для создания как небольших, так и крупномасштабных приложений. Хоть и не существует единственного «правильного» способа, полезно знать преимущества и недостатки каждого варианта, которые позволят принять обоснованное решение о выборе подхода, лучше всего подходящего для вашего конкретного случая использования. В этой статье я собираюсь сравнить монолиты, микросервисы и бессерверную архитектуру.
💎 Монолитная архитектура
Монолитное приложение — это приложение «все в одном».
Обычно все функции содержатся в единой кодовой базе, написанной на одном языке программирования и технологическом стеке. Например, если вы создаете интернет-магазин для продажи футболок, у вас может быть одно приложение, которое обрабатывает оформление заказа, платежи, отвечает за управление запасами и за обновление заказов.
Приложения Monolith легче создавать и развертывать, поскольку они состоят из меньшего количества компонентов, чем микросервисы. Однако эта простота достигается за счет более сложных взаимодействий между этими компонентами, что может затруднить их масштабирование по мере роста вашего бизнеса или адаптации к изменяющимся требованиям (например, при добавлении новых функций).
Монолитные приложения — это не всегда плохо. Для простых приложений они могут быть идеальными. На самом деле, на заре разработки программного обеспечения микросервисов не существовало. Наши первые компьютеры были монолитными машинами, которые могли выполнять только одну задачу одномоментно (вспомните калькуляторы). Когда мы начали использовать персональные компьютеры и, в конечном итоге, мобильные устройства, наша вычислительная мощность резко увеличилась, но у нас по-прежнему одновременно работало только одно приложение — сама ОС по-прежнему была монолитной по своей природе.
Монолиты могут применяться в определенных случаях, но они могут быть не идеальными для каждого приложения, которое вы создаете сегодня или завтра. Например, если в вашем приложении много данных, связанных с каждой пользовательской записью, и вы сталкиваетесь с проблемами производительности из-за слишком большого количества запросов к базе данных, которые выполняются слишком быстро (это называется «запросами в секунду»), то разбиение записей пользователей на отдельные сущности, которые можно запрашивать по отдельности, может помочь решить эти проблемы, уменьшив количество запросов, выполняемых к строкам каждой таблицы базы данных в каждый момент времени...
Монолиты подходят для некоторых приложений, но для более сложных систем вы можете пойти дальше и разбить их на микросервисы.
➕ К преимуществам относятся:
1. Простая эволюция приложений
С точки зрения бизнес-логики приложение действительно не имеет ограничений (особенно если вам нужны определенные данные для новой функциональности).
2. Индивидуальная надстройка и сквозная функциональность обрабатываются только один раз
Задачи сквозной функциональности должны обрабатываться только один раз. Например, настройка пула подключений к источнику данных, выбор и настройка параметров Tomcat, безопасности, ведения журнала, управление исключениями, мониторинг и т. д.
3. Простота добавления в проект новых членов команды
В одном месте находится весь исходный код. Новые члены команды могут быстро ознакомиться с приложением и отладить определенный функциональный поток.
4. Низкие затраты на ранней стадии разработки приложения
Создается, упаковывается и развертывается одна единица развертывания, содержащая весь исходный код. Что может быть проще? Инфраструктура или разработка, если они вам нужны.
5. Простота разработки
Одним из распространенных методов создания приложений является монолитный подход. Никакой другой информации не требуется. Весь исходный код находится в одном месте, что упрощает его понимание.
6. Простота отладки
Поскольку весь код находится в одном месте, отладка упрощается. Найти проблему, следуя потоку запросов, очень просто.
7. Простота тестирования
Вы тестируете один сервис независимо от каких-либо зависимостей. Обычно все очевидно.
8. Простота развертывания
Рекомендуется развертывать только один модуль развертывания (например, jar-файл). Нет никакой зависимости. Нет критических изменений, когда пользовательский интерфейс упакован с внутренним кодом. Все находится в одной области и меняется там.
После успешного запуска приложения начинают появляться проблемы с монолитной архитектурой. Рост приложения является прямой причиной. Часто монолитное приложение через некоторое время превращается в другое по следующим причинам.
➖ К недостаткам относятся:
1. Тесная связь между сервисами (взаимозависимости)
Если вы измените что-то в одном сервисе, это может нарушить функциональность другого сервиса, потому что они были тесно связаны друг с другом без каких-либо уровней абстракции между ними (например, между ними не было интерфейсов).
2. Владение кодом неприменимо
Структура расширяется. Следующим логичным шагом будет распределение обязанностей между различными командами. Например, одна команда может сосредоточиться на обслуживании рейсов, а другая — на обслуживании выставления счетов. Однако различий между этими услугами нет. Команды могут влиять друг на друга.
3. Проблемы с производительностью
В случае проблем с производительностью вы можете масштабировать всю монолитную службу. Но как быть с базой данных? Все сервисы опираются на единую базу данных. Вы можете начать с оптимизации запросов к базе данных или с использования реплик чтения. Однако этот тип оптимизации ограничен.
4. Инфраструктура стоит денег
В случае низкой производительности следует масштабировать весь монолитный сервис. Это увеличивает стоимость работоспособности приложения.
5. Технологии прошлого
Предположим, ваше приложение написано на Node.js 11.2.0. Сколько времени займет миграция всего монолита с несколькими службами под ним на Node.js 18.0.0? Что делать с задачами, необходимыми для добавления нового функционала? Возможно, приложение никогда не будет перенесено.
6. Отсутствие адаптивности
Когда вы используете монолитную архитектуру, вы ограничены технологиями, которые используются в вашем монолите. Другие инструменты использовать нельзя, даже если они лучше подходят для решения поставленной задачи.
7. Проблемы с развертыванием
Даже незначительные изменения требуют повторного развертывания всего монолита.
🍇 Архитектура микросервисов
Микросервисы — это приложения «все-в-одном», разбитые на более мелкие части.
Микросервисы — это архитектурный шаблон, который упорядочивает приложение как набор слабосвязанных мелкомодульных сервисов, взаимодействующих через облегченные протоколы. Это отличается от монолита, который представляет собой приложение, написанное на одном языке и работающее вместе как одна единица кода.
Архитектура микросервисов — это современный подход к разработке программных приложений из набора отдельных модулей (сервисов). Каждая услуга обычно ориентирована на одну задачу (оплата, доставка и т. д.) или бизнес-функцию и может быть построена с использованием уникального набора технологий.
Это обеспечивает гибкость как для инженерных групп, так и для бизнеса в целом. Например, приложения на основе микросервисов легче масштабировать. Отдельные сервисы часто быстрее разрабатывать и развертывать, чем монолитные приложения. И на этом преимущества микросервисов не заканчиваются.
Есть много компаний, использующих микросервисы для своих продуктов и услуг, и вот список некоторых из них, которые поделились своим опытом: Comcast Cable, Uber, Netflix, Amazon, eBay, Sound Cloud, Karma, Microsoft, Groupon, Hailo, Gilt, Zalando, Lending Club, AutoScout24 и т. д.
Давайте углубимся в преимущества микросервисов. Вы увидите, как этот подход помогает компаниям создавать долговечные и высокопроизводительные приложения, сокращать время выхода на рынок и эффективно адаптироваться к изменениям.
➕ К преимуществам относятся:
1. Микросервисы легче тестировать
Вы можете тестировать и изменять небольшие части системы, вы можете тестировать микросервис без необходимости тестировать всю систему. Вам не нужно «поднимать» все свои экземпляры только для того, чтобы вы могли запустить несколько тестов на одном маленьком фрагменте. Вам также не нужно беспокоиться о поломке остальной части вашего приложения при опробовании новых функций или исправлении ошибок в отдельном микросервисе. Это значительно упрощает работу разработчиков, поскольку они могут сосредоточиться на своей части проекта, не беспокоясь о том, как это повлияет на другие части или что-нибудь сломается от взаимодействия с ним.
2. Вы можете повторно использовать код и создавать библиотеки функций с помощью микросервисов
Вы можете повторно использовать код между микрослужбами и создавать библиотеки функций, которые могут совместно использоваться службами. Это означает, что вы можете создать узкоспециализированные функции для одной службы, а затем использовать тот же код в других местах. Вот почему люди любят говорить о «монолитах» как о чем-то монолитном — они такие большие, что их трудно изменить, а поскольку они такие большие, их трудно разбить на более мелкие части.
3. Микросервисы помогают ускорять процессы в компании
Подход на основе микросервисов позволяет сосредоточиться на одном деле. Он позволяет использовать больше людей и больше инструментов, что облегчает быстрое развитие без ущерба для качества. Микросервисы позволяют внедрять гибкие методологии разработки, быстро выполнять итерации, поскольку они модульные по своей природе. Каждый сервис имеет свою собственную кодовую базу, что позволяет легко обновлять или заменять их при необходимости.
4. Сокращение стоимости и времени на разработку
Несмотря на значительные затраты, связанные с созданием гибкой команды и инфраструктуры микросервисов, данный подход широко признан как значительный источник экономии средств, особенно в долгосрочной перспективе. Мы уже упоминали несколько преимуществ, напрямую влияющих на конечный результат: более быстрый выход на рынок, более низкие затраты на обновление и масштабирование системы и так далее. Кроме того, адаптивность микросервисов влияет на структуру команды. Это позволяет использовать модель выделенной команды для создания гибких групп — как внутренних, так и удаленных — отвечающих за конкретные модули или бизнес-функции. Эти команды могут работать параллельно, повышая производительность и скорость работы.
5. Каждый модуль развертывается независимо
Микросервисы можно развертывать независимо в любом приложении, поскольку они являются отдельными модулями. При изменении любого модуля нет необходимости перестраивать и развертывать все приложение. Меньшие кодовые базы обеспечивают более простое и быстрое развертывание. Это связано с тем, что в сервисах нужно управлять меньшим количеством зависимостей. Непрерывное развертывание также возможно благодаря независимому развертыванию отдельных служб. В результате программное обеспечение всегда актуально для пользователей.
➖ К недостаткам относятся:
1. Увеличивающаяся сложность
Cервис-ориентированная архитектура, основанная на API, состоит из множества структурных частей. Следовательно, требуется больше ресурсов для поддержки системы и обеспечения ее работы. Также может потребоваться более сложная стратегия тестирования, поскольку сервисы имеют мало общего и требуют индивидуального тестирования и отладки. Несмотря на эти проблемы, многочисленные преимущества микросервисов, а также реальный опыт и доказанные конечные преимущества побуждают компании переходить на микросервисы и продолжать инвестировать в этот подход.
2. Глобальное тестирование и отладка затруднительны
По сравнению с программным обеспечением на основе микросервисов тестирование монолитного приложения значительно проще. Нам осталось только запустить наше приложение, убедиться и протестировать его подключение к базовой базе данных. Каждая служба в приложении на основе микрослужб должна сначала запускаться и тестироваться отдельно. После того как все сервисы запущены, необходимо еще раз протестировать приложение в целом.
3. Не подходит для небольших приложений
Архитектура микросервисов — отличный выбор для больших приложений. Однако для небольших приложений это, скорее всего, потребует больше времени и трудностей в реализации.
4. Микросервисы могут представлять угрозу безопасности
Микросервисы создают значительные проблемы с безопасностью по сравнению с монолитными приложениями из-за значительного увеличения объема данных, которыми обмениваются модули. Поскольку вы используете несколько небольших контейнеров, вы подвергаете большую часть вашей системы воздействию сети, что означает, что большая часть вашего порядка уязвима для потенциальных злоумышленников.
Также стоит отметить, что поскольку контейнеры легко воспроизводимы, недостаток в одном модуле может быстро перерасти в более крупную проблему. Исходный код часто используется в нескольких приложениях, предоставляя хакерам легкий доступ. В результате, если не используются надлежащие инструменты и обучение, микросервисы могут быстро превратиться в угрозу безопасности.
🎈 Бессерверная архитектура
Ваше приложение работает на сервере, которым вы не управляете.
Без необходимости управлять инфраструктурой, можно создавать и запускать приложения и сервисы, используя бессерверную архитектуру. Хотя ваше приложение продолжает работать на серверах, ваш облачный провайдер (AWS, GCP, AZURE и т. д.) берет на себя все администрирование сервера. Для запуска ваших приложений, баз данных и систем хранения вам больше не нужно выделять, масштабировать и обслуживать серверы. Пользователи могут взаимодействовать с приложениями и получать доступ к их бизнес-логике через серверы, но администрирование серверов требует значительного количества времени и ресурсов. Команды должны следить за обслуживанием серверного оборудования, программным обеспечением и обновлениями безопасности, а также за созданием резервных копий. Разработчики теперь могут сосредоточиться на создании кода приложения, переложив вышеописанные обязанности на стороннего поставщика, внедрив бессерверную архитектуру.
Бессерверная архитектура существует уже более десяти лет. Amazon представила первую массовую платформу FaaS, AWS Lambda, в 2014 году. В настоящее время большинство разработчиков по-прежнему используют AWS Lambda для создания бессерверных приложений, но у Google и Microsoft также есть собственные FaaS-предложения, называемые Google Cloud Functions (GCF) и Azure Functions соответственно.
При разработке онлайн-приложений очень мало случаев использования, когда бессерверные архитектуры неприменимы. Все связано с доступностью и развитием управляемых облачных сервисов. Многие компании даже используют гибридную стратегию, когда они разрабатывают как можно больше бессерверных технологий и используют другие технологии, чтобы заполнить пробелы.
➕ Преимущества использования бессерверной архитектуры
1. Стоимость
Вы платите только за поступающие запросы, поэтому вы не платите за серверы или виртуальные машины, которые не используются.
2. Масштабируемость
В рамках ограничений параллелизма экземпляры функций автоматически добавляются или удаляются в ответ на колебания трафика.
3. Производительность
Бессерверные решения позволяют инженерам отправлять свой код в релиз без необходимости управлять какими-либо серверами, что сокращает время доставки и позволяет бизнесу быстро расти.
➖ Недостатки использования бессерверной архитектуры
1. Отсутствие контроля
Вы не можете контролировать программный стек, который использует ваш код в бессерверных настройках. Вы должны полагаться на поставщика облачных услуг для решения любых проблем, которые затрагивают один из ваших серверов из-за сбоя оборудования, отключения центра обработки данных или других проблем.
2. Безопасность
Поставщик облачных служб может одновременно запускать код нескольких своих клиентов на одном сервере. Данные вашего приложения могут быть раскрыты, если общий сервер настроен неправильно.
3. Зависимость от поставщика
Крупные облачные провайдеры, такие как AWS, предоставляют различные сервисы, включая API, очереди сообщений и базы данных, которые можно использовать вместе для создания бессерверных приложений. Хотя компоненты от нескольких поставщиков можно комбинировать, сервисы от одного поставщика интегрируются легче всего.
4.Влияние на производительность
Когда функции вызываются после продолжительного периода бездействия, возникают так называемые «холодные» старты (часто встречаются в бессерверных установках), которые приводят к тому, что выполнение кода приостанавливается на большее число секунд.
5. Тестирование
Unit-тесты могут проводиться разработчиками для функционального кода, но интеграционные тесты, которые оценивают, как взаимодействуют внешние и внутренние компоненты, сложны в исполнении.
🔚 Вывод
Монолитная архитектура идеальна для небольших приложений благодаря быстрой разработке, простоте тестирования и отладки, а также низкой стоимости. Однако по мере роста системы она может стать препятствием для бизнеса и должна эволюционировать в другую форму.
Как видите, использование микросервисов дает множество преимуществ. Они позволяют создавать более модульные и удобные в сопровождении приложения с меньшим риском поломки при внесении изменений. Они также предоставляют вашей команде больше гибкости во взаимодействии над проектом, облегчая им продуктивную работу на всех уровнях опыта — от младших разработчиков до тех, кто работает с этими типами систем в течение многих лет.
Бессерверная архитектура определяет внутреннюю структуру программы, тогда как микросервисы отвечают за построение вашего приложения на макроуровне. Бессерверное приложение может соответствовать или не соответствовать концепции микросервисов (хотя это часто рекомендуется). Все или некоторые микросервисы (или же ни один) в архитектуре микросервисов могут быть созданы с использованием технологии бессерверной архитектуры.
Бессерверная архитектура — это потрясающий инструмент для компаний, стремящихся ускорить выход на рынок и создавать масштабируемые и легкие приложения. Но микросервисы могут быть лучшим вариантом, если ваши приложения используют множество непрерывно выполняемых длительных задач. В гибридной архитектуре разработчики могут использовать микросервисы для обработки большинства запросов, но делегировать некоторые быстрые задачи, такие как хранение базы данных — бессерверным операциям.
Какую архитектуру вы сейчас используете или планируете использовать, и почему вы ее выбрали?