Эта страница переведена с помощью Cloud Translation API.

Бэкэнд-архитектуры для серверов веб-приложений, управляемых контентом.

Бэкэнд-архитектура означает, как структурирована серверная часть вашего веб-приложения. Бэкэнд-архитектура определяет, как части приложения взаимодействуют друг с другом для обработки входящих запросов и создания ответов. При создании веб-приложения выберите серверную архитектуру на основе ваших конкретных требований и факторов, включая стоимость (как текущую, так и масштабируемую), сложность вашего приложения, цели масштабирования и опыт вашей команды.

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

Если у вас есть серверная часть веб-приложения, учтите ограничения вашей текущей архитектуры. Например, по мере того, как ваше приложение масштабируется и требует повышения его производительности и надежности, подумайте, следует ли провести рефакторинг частей вашего приложения или перенести их на другую архитектуру, более подходящую для вашего возросшего масштаба. Например, гибридные (или мультиоблачные) архитектуры позволяют перенести некоторые рабочие нагрузки в облако до полного перехода. Также важно учитывать стоимость, время и риск, связанный с такой миграцией.

Монолитная Архитектура

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

Структурные слои

Пользовательский интерфейс (UI), который включает в себя компоненты для представления функций приложения, обычно представляет собой веб-приложение или настольное приложение, которое взаимодействует с пользователями.
Логика приложения — это место, где находятся основные функции. Эта часть кодовой базы содержит правила, вычисления и операции, которые определяют, как работает приложение.
Уровень доступа к данным содержит функции для чтения и записи данных, а также преобразования между структурами данных приложения и схемой базы данных. Этот уровень отвечает за взаимодействие с базой данных приложения или хранилищем данных.
База данных — это место, где приложение хранит свои данные. Обычно существует одна база данных, в которой хранятся все данные приложения, включая пользовательские данные, конфигурации и другую информацию.
Компоненты промежуточного программного обеспечения выполняют такие задачи, как аутентификация, маршрутизация запросов и проверка данных. Эти компоненты помогают управлять потоком данных и запросов.
Некоторые монолитные приложения имеют точки интеграции с внешними сервисами или API. Эти точки позволяют приложению взаимодействовать со сторонними сервисами, источниками данных или другими системами.

Структурные уровни обычно являются частью единой кодовой базы. Эта база кода содержит все приложение и обычно организована в каталоги, модули и классы. Разработчики работают над различными частями кодовой базы для создания и поддержки приложения. Однако все приложение обычно развертывается как единое целое. При внесении обновлений или изменений все приложение развертывается заново.

Потенциальные проблемы

По мере роста монолитных приложений кодовая база становится сложной и ее трудно поддерживать. Это может привести к длительным циклам разработки и трудностям в понимании всей кодовой базы.
Развертывание изменений в монолитном приложении может быть рискованным, поскольку изменения, внесенные в одну часть кода, могут непреднамеренно повлиять на другие части приложения. Это может привести к длительному и подверженному ошибкам процессу развертывания.
Монолитные приложения сложно масштабировать, поскольку они развертываются как единое целое. Вы должны масштабировать все приложение, даже если только один компонент испытывает повышенный спрос.
Монолитные приложения часто полагаются на один технологический стек или язык программирования, поэтому ваши возможности использовать лучший инструмент для конкретной задачи в приложении могут быть ограничены.
Даже в периоды низкого спроса монолитные приложения требуют для работы значительных ресурсов. Затраты на обслуживание также увеличиваются по мере старения приложения, поскольку становится все сложнее обновлять и исправлять приложение, не вызывая регресса.
Команды разработчиков, работающие над монолитными приложениями, часто организуются вокруг всего приложения, что приводит к увеличению размера команды и более сложной координации между ее членами.

Бессерверные архитектуры

Используя бессерверную архитектуру, вы можете создавать и запускать приложения без управления физическими или виртуальными серверами. Поставщик облачных услуг автоматически управляет инфраструктурой, масштабированием и распределением ресурсов, чтобы разработчики могли сосредоточиться на написании кода для своих приложений. Бессерверные архитектуры могут упростить разработку, снизить эксплуатационные расходы и оптимизировать затраты за счет устранения необходимости обслуживания серверов. Они хорошо подходят для микросервисов, обработки данных в реальном времени, веб-приложений с переменными рабочими нагрузками и обработки событий.

Бессерверные архитектуры на основе событий

Бессерверные архитектуры на основе событий — это особый тип бессерверной вычислительной архитектуры, которая полагается на события или триггеры для инициирования выполнения функций или микросервисов. Компоненты системы взаимодействуют посредством событий, а функции вызываются в ответ на события. Они часто полагаются на асинхронную связь, поскольку функции запускаются событиями, затем обрабатывают их независимо и могут создавать события, которые затем запускают последующие действия. Этот тип бессерверной архитектуры является хорошим вариантом для создания масштабируемых, быстро реагирующих и слабосвязанных систем.

Облачные функции Google и облачные функции для Firebase позволяют создавать и развертывать функции, управляемые событиями, в полностью управляемой бессерверной среде. Он позволяет запускать код в ответ на различные события и триггеры, включая HTTP-запросы, сообщения Cloud Pub/Sub, изменения в облачном хранилище Google, обновления базы данных Firebase Realtime, без необходимости управлять инфраструктурой. Ключевые функции включают поддержку нескольких языков, масштабируемость, детализированное выставление счетов, интеграцию сторонних разработчиков, надежную регистрацию и мониторинг, а также интеграцию с другими сервисами Google и Firebase.

Бессерверные архитектуры могут быть экономически эффективными для многих случаев использования, особенно для приложений с различными рабочими нагрузками, потребностями в быстрой разработке и непредсказуемым трафиком. Надежность зависит от поставщика облачных услуг, поскольку существуют соглашения об уровне обслуживания (SLA), обеспечивающие конкретные целевые показатели производительности и надежности. Вы должны оценить свой конкретный вариант использования и требования, чтобы определить, является ли бессерверная архитектура лучшим вариантом.

Контейнеризация

Контейнеризация позволяет упаковывать приложения и их зависимости в легкие портативные контейнеры. Они обеспечивают согласованную среду приложений, поддерживающую разработку и развертывание на различных системах и платформах. Некоторые бессерверные платформы предлагают возможность запуска контейнерных рабочих нагрузок. Запуск контейнеров в бессерверной среде может оказаться полезным, если у вас есть сложные рабочие нагрузки или рабочие нагрузки с отслеживанием состояния, которые невозможно выразить в виде базовых функций. Он обеспечивает гибкость с точки зрения языковой поддержки и сред выполнения.

Cloud Run — это бессерверная вычислительная платформа, которая позволяет разработчикам развертывать и запускать контейнерные приложения в полностью управляемой среде. Он обеспечивает простой способ создания, развертывания и масштабирования приложений без управления базовой инфраструктурой. Он подходит для широкого спектра веб-приложений и микросервисов, особенно с переменными рабочими нагрузками, а также для случаев, когда контейнеризация дает преимущества с точки зрения упаковки и согласованности приложений.

Микросервисные архитектуры

Приложения разбиваются на небольшие части, которые слабо связаны и реализуют отдельные функции или возможности. Эти службы могут взаимодействовать через асинхронные сообщения, каналы на основе событий или напрямую, предоставляя интерфейс. Каждый сервис разрабатывается, тестируется и масштабируется независимо в своем контейнере, которым часто управляют через службу оркестрации, например Kubernetes , или развертывают с помощью управляемой платформы, например Cloud Run .

Развертывания микросервисов обычно также используют преимущества парадигмы бессерверных приложений, не полагаясь на централизованный сервер.

Разделение приложения на автономные службы может упростить сложную систему. Четко определенные границы и цели могут ускорить разработку и улучшить обслуживание. Каждый микросервис можно разрабатывать независимо, используя наиболее эффективные фреймворки или инструменты. Связь между службами часто осуществляется с помощью событий, связи публикации-подписки, конвейеров сообщений или удаленных вызовов процедур, таких как gRPC .

Для оркестровки задач в рамках микросервисной архитектуры рассмотрите возможность использования платформы, которая поддерживает целевые платформы, достаточную глубину для задач и типов рабочих процессов, которые вы оркеструете, а также обработку ошибок и телеметрию для отладки проблем. Популярные варианты включают Conductor или предложения от облачного провайдера, такого как Google Workflows .

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

Сравнение различных архитектур серверных частей веб-приложений, управляемых контентом.

В следующей таблице сравниваются архитектуры с ключевыми требованиями к серверной части веб-приложения, управляемого контентом.

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

Узнайте больше о серверной архитектуре для веб-приложений, управляемых контентом.

Вот несколько ресурсов, где можно узнать больше об архитектурах веб-приложений, управляемых контентом, в том числе о том, как перенести приложение на другую архитектуру:

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

Обзор

Фреймворки и языки