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 мають власників; чутливі значення відфільтровано; навчання з відмов охоплюють залежності, випуски, зони, регіони та повідомлення клієнтів.