Angular и NestJS в Azure: архитектура для рабочей среды

Клиентская часть на Angular и серверная часть на NestJS могут использовать TypeScript, но работают в разных средах, имеют разные границы доверия и по-разному масштабируются. Рабочая система обычно включает код в браузере, статические ресурсы, необязательное серверное формирование, HTTP API, фоновых потребителей, базу данных, объектное хранилище, обмен сообщениями, идентификацию, направление на внешней границе, цепочки поставки и телеметрию. Название «одно веб-приложение» скрывает решения, от которых впоследствии сильнее всего зависят надежность и стоимость.

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

Прежде чем называть службы Azure, начертите границы развертывания и ответственности. Сборка Angular, среда Angular SSR, API NestJS и фоновые обработчики обычно должны иметь независимые версии, даже если ими занимается одна команда. Долговечные данные не должны жить в файловых системах этих составляющих. Определите среды, регионы, клиентов, частоту выпусков и ответственного за каждую поверхность платформы. В наших проектах по разработке на Angular, инженерии NestJS и поставке в Azure такая общая модель согласует решения о приложении и эксплуатации.

Выберите способ формирования для каждого маршрута и разместите среду Angular

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

Результатом CSR или предварительного создания являются неизменяемые файлы. Разместите их в Azure Static Web Apps или Blob Storage за подходящей CDN либо Azure Front Door. Для JavaScript, CSS, шрифтов и изображений с отпечатком версии установите длительный срок кеширования, а оболочку HTML и запасные правила маршрутизации сделайте совместимыми с порядком развертывания. Решите, как браузер получит настройки среды выполнения, помня: каждое значение, переданное JavaScript, становится общедоступным. Для каждой среды отдельно определите источники API, CORS, политику безопасности содержимого, доступ к картам исходного кода и адреса возврата после аутентификации.

Использование SSR означает появление отдельной службы Node.js, которую нужно делать доступной, защищать, масштабировать и оплачивать. Разместите ее в App Service или Container Apps, добавьте явные проверки состояния и ограничения времени и масштабируйте независимо от API NestJS. Компоненты должны безопасно выполняться на сервере; библиотеки только для браузера загружайте с задержкой, а сторонним изменениям DOM не позволяйте разрушать гидратацию. Передаваемые HTTP-данные и кеши нужно разграничить по маршруту, пользователю, языку и клиенту: слишком широкий ключ кеша способен превратить ускорение в утечку данных.

Измеряйте весь путь на настоящих устройствах и данных, похожих на рабочие. SSR может ускорить появление первого содержимого, но увеличить время до первого байта или отложить взаимодействие, если формирование и гидратация слишком тяжелы. Следите за Core Web Vitals, задержкой серверного формирования, ошибками гидратации, весом сборки, долей попаданий в кеш, нагрузкой на источник и поведением запасного пути. Постепенную гидратацию или отложенные представления внедряйте лишь там, где измерения на реальных пользователях доказывают пользу.

Разделите API, фоновые обработчики и общедоступную границу

Синхронный путь запроса должен быть коротким. На общедоступной границе Azure Front Door может обеспечить глобальное направление, ускорение, правила TLS, контроль состояния источников и защиту WAF. Не добавляйте API Management автоматически: он оправдывает место, когда реальную задачу решают подключение потребителей, подписные продукты, квоты, преобразования, исполнение правил, управление версиями или портал разработчика. Каждый посредник означает дополнительные настройки, задержку, стоимость и еще одну поверхность отказа.

Обычный API NestJS размещайте в App Service, если подходят управляемая веб-среда, предсказуемое масштабирование HTTP и ячейки развертывания. Container Apps выбирайте, когда пользу дают редакции контейнеров, независимые обработчики, задания, масштабирование KEDA по событиям или связанные службы. AKS требуется лишь при подтвержденной потребности в API Kubernetes, операторах, специальном планировании или средствах уровня кластера. Переносимость упаковки помогает, но правила входа, проверки состояния, идентификации, масштабирования, внедрения и восстановления остаются специфичными для платформы.

Долгую и надежную работу вынесите из HTTP. API должен проверить команду и права, зафиксировать окончательное состояние и поставить задание в очередь через транзакционный журнал исходящих событий или другой механизм, не способный незаметно потерять передачу. Обработчик NestJS потребляет сообщения Service Bus с ограниченной одновременностью, идемпотентным выполнением, явным подтверждением, предельным числом повторов и назначенным ответственным за неразобранные сообщения. Обнаружение дубликатов уменьшает повторные отправки в пределах настроенного промежутка, но не заменяет идемпотентного потребителя: блокировки, подтверждения и перезапуск все равно могут вызвать повторную доставку.

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

Проектируйте идентичность, секреты и сетевые пути как единое целое

Сделайте идентичность основой архитектуры. Конечные пользователи входят через подходящий каталог Microsoft Entra или внешнего поставщика идентификации; API NestJS проверяет издателя, получателя, подпись, время и тип токена, а затем применяет разрешения на уровне ресурса. Защитники маршрута в браузере улучшают навигацию, но не обеспечивают безопасность. Различайте личность клиента, администратора из числа сотрудников, нагрузки и цепочки CI/CD, поскольку их жизненные циклы и возможный масштаб ущерба различаются.

Назначайте API, обработчикам и среде SSR отдельные управляемые идентичности, если им нужны разные права. Предоставляйте узкие роли плоскости данных для Key Vault, Storage, Service Bus, Azure SQL, PostgreSQL и других служб, поддерживающих Microsoft Entra. Идентичность лишь обозначает субъекта и ничего не разрешает без роли или правила. Предпочитайте краткосрочные токены строкам соединения, удаляйте лишние назначения и проверяйте не только успешный доступ, но и ожидаемый отказ.

Key Vault все равно нужен для учетных данных сторонних служб, ключей подписи, сертификатов и прочих неизбежных секретов. Где это уместно, ссылайтесь на секреты средствами платформы размещения, но учитывайте порядок обновления. В Container Apps изменение секрета действует на уровне приложения и не создает новую редакцию; чтобы действующие редакции увидели значение, их нужно перезапустить или заменить. Ограничьте право просматривать значения секретов, выполняйте замену с переходным перекрытием и никогда не добавляйте секреты в сборки Angular, образы, хранилище кода, журналы цепочки поставки или телеметрию.

Входящие и исходящие сетевые пути чертите отдельно. Определите, остаются ли источники общедоступными за Front Door или доступны частным образом, как работает частный DNS, где завершается TLS, как среда выполнения обращается к службам данных, откуда загружаются образы и как специалисты развертывают изменения во время происшествия. CORS является правилом браузера, а не сетевым экраном. Частные конечные точки сами по себе не управляют исходящим движением. В каждой среде и регионе восстановления проверьте разрешение имен, маршруты, сертификаты, правила межсетевого экрана и идентичность.

Сделайте отказы данных и сообщений явной частью системы

Azure Database for PostgreSQL или Azure SQL выбирайте по поведению предметной области, требованиям к запросам и транзакциям, имеющемуся опыту, расширениям, совместимости, вариантам доступности и целям восстановления, а не по родству с программной платформой. У каждого делового факта должен быть один окончательный владелец. Явно моделируйте изоляцию клиентов, шифруйте соединения, рассчитывайте пулы соединений для общего числа реплик и следите за насыщением базы до того, как автоматическое масштабирование вычислений умножит число подключений.

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

Azure Managed Redis добавляйте для измеренной потребности в кеше, координации или временном состоянии, а не по привычке. Определите источник истины, ключи, границу клиента, TTL, аннулирование, защиту от одновременного промаха, поведение вытеснения и допустимый срок устаревания. До запуска спроектируйте работу без кеша. Файлы храните в Blob Storage, а не на дисках экземпляров; доступ к каждому объекту разрешайте по деловым правилам, проверяйте тип и размер, сканируйте недоверенное содержимое, для прямой передачи выдавайте краткосрочный ограниченный доступ и установите правила хранения и удаления.

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

Выпускайте составляющие отдельно, но эксплуатируйте один продукт

Создавайте каждый артефакт один раз и продвигайте его неизменяемую идентичность. Ресурсы Angular, образ SSR, образ API и образ обработчика могут проходить среды с разной скоростью, но их совместимость должна быть известна. Формируйте перечень составляющих программного обеспечения, проверяйте зависимости и образы, при необходимости подписывайте артефакты или удостоверяйте происхождение, а развертывайте по дайджесту, а не изменяемой метке. Ресурсы Azure создавайте через Bicep или Terraform, просматривая изменения инфраструктуры вместе с изменениями приложения.

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

Используйте ячейки App Service или редакции Container Apps, чтобы прогреть и проверить кандидата до перевода движения. В режиме одной редакции Container Apps оставляет запросы на прежней версии, пока новая не будет готова; режим нескольких редакций поддерживает весовое распределение и прямое испытание конкретной редакции. До продвижения проверьте признаки состояния, запуск, потребителей сообщений, настройки и совместимость базы. Заранее определите смысл отката, если миграция уже записала новые данные или событие ушло в другую систему.

Подключайте наблюдение к Node.js еще до загрузки модулей NestJS, чтобы трассировка охватила библиотеки. Связывайте участки браузера, SSR, API, базы данных, Service Bus и обработчиков сквозными идентификаторами, одновременно отфильтровывая токены, учетные данные, секреты в строках запроса и лишние персональные сведения. У каждой среды выполнения должны быть стабильные название службы и версия. Отслеживайте результаты для пользователя, задержку, частоту ошибок, насыщение, возраст очереди, неразобранные сообщения, время формирования и отметки развертывания относительно SLO. Отбор и срок хранения должны оставлять достаточно доказательств для происшествий, не превращая телеметрию в бесконтрольное хранилище данных.

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

Контроль готовности к рабочей эксплуатации

• Способ формирования подтвержден доказательствами: CSR, предварительное создание, SSR и гидратацию выбирают отдельно для каждого маршрута; ключ кеша охватывает все существенные признаки пользователя, клиента, языка и содержимого; Core Web Vitals и задержку серверного формирования измеряют на реальных пользователях.
• Границы сред выполнения определены: статические ресурсы, SSR, API и обработчики развертываются и масштабируются независимо; общедоступный вход есть только у необходимых источников; у каждой среды имеются проверки состояния, ограничения, сроки ожидания, идентичность с наименьшими правами и ответственный владелец.
• Состояние выдерживает отказ: изменения схемы совместимы с предыдущей версией, пределы пулов соединений учитывают все реплики, правила аннулирования кеша определены, доступ к файлам разрешается явно, потребители сообщений идемпотентны, у неразобранных сообщений есть владелец, а проверки восстановления соответствуют RPO и RTO.
• Поставка находится под контролем: CI/CD использует федеративную идентичность, продвигает неизменяемые артефакты, согласует совместимость базы и приложения, проверяет прогретого кандидата, ограничивает права в рабочей среде, сохраняет доказательства и имеет испытанный откат или путь исправления вперед.
• Эксплуатация повторяет путь пользователя: связанная телеметрия охватывает браузер, SSR, API, данные, сообщения и обработчики; у оповещений по SLO есть владельцы; чувствительные значения отфильтрованы; учения по отказам охватывают зависимости, выпуски, зоны, регионы и оповещение клиентов.