вступление
Как организация, мы находились в процессе написания новых приложений и/или сервисов на Node.js, Go, React и развертывания их в облаке AWS. Это означает, что в устаревшую кодовую базу больше не будет добавляться код, и больше не будет локальных развертываний для новой разработки/улучшения. Таким образом, идея микросервисов и микроинтерфейсов дает нам возможность иметь план миграции и разрабатывать новые запросы клиентов на усовершенствование. Так началось наше исследование маршрутизации на основе пути.
В этом сообщении в блоге я дам обзор нашей архитектуры и поделюсь некоторыми проблемами и знаниями, которые я получил на этом пути.
Мотивация
После тщательной сортировки запросов клиентов мы решили создать отдельное приложение, которое позволяет пользователям просматривать и искать контент во всех наших приложениях. Новое приложение должно учитывать существующие пользовательские привилегии, должно позволять пользователям переходить к устаревшим приложениям и из них, а также должно избегать какого-либо паритета функций и задержек.
Функциональное требование
- Пользователи должны иметь доступ к новым приложениям в/из устаревших приложений.
- Привилегии пользователя должны соблюдаться в новом приложении.
- Пользователи должны беспрепятственно просматривать/искать любые данные из нового приложения.
Нефункциональное требование
- Новое приложение должно быть построено с использованием нового технологического стека.
- Новое приложение должно быть развернуто в облаке AWS.
- Задержка
Проектирование сервиса Node.js
Думайте об этом как о посреднике, облегчающем связь между нашим новым SPA, службой входа в систему для аутентификации пользователей, службой классификации для авторизации и контента и службой хранилища метаданных для получения дополнительных сведений о контенте.
Проектирование маршрутизации на основе пути
В этом разделе мы установим связь между приложением грейдера и/от приложения просмотра. Затем мы рассмотрим, как мы добились этого в облаке AWS. Некоторые из наших основных требований — обеспечить плавный переход между приложениями, избежать каких-либо несоответствий и создать базовый микроинтерфейс для будущих вариантов использования.
Как мы видим, если пользователь щелкнет вкладку каталога в нашем устаревшем приложении, только тогда мы перенаправим пользователя в новое приложение, размещенное на AWS. Чтобы избежать каких-либо несоответствий, мы позаимствовали тот же дизайн, макет и панель навигации для нового спа.
Конструктивное решение I: доменное имя
Наше устаревшее приложение-оценщик имеет имя, например https://grader.com, и размещается локально. Таким образом, мы не можем выбрать то же доменное имя в облаке AWS, однако мы хотели выбрать имя, идентичное существующему доменному имени, а также отразить изменения следующего поколения. Итак, мы получили доменное имя что-то вроде https://product-name-grader.com.
Конструктивное решение II: название приложения
Мы хотели использовать это новое доменное имя для размещения множества SPA, поэтому наше новое приложение будет обслуживаться под ‘/catalogs’. В будущем мы хотели добавить SPA для лицензирования в `/licensing`, SPA для курсовой работы в `/coursework` и т. д.
Дизайн-решение III: создание сборки приложения React
Наш SPA был построен с использованием скаффолдинга CRA, и если вы запустите npm run build, он сгенерирует папку сборки с кусками javascript, активами и т. д. в хорошо структурированном виде, и на все они ссылаются из index.html. файл в корне папки сборки.
Примечание. Я включил меньше файлов из процесса сборки CRA, чтобы уменьшить шум в нашем обсуждении.
`index.html` будет загружен при инициализации приложения. Задержите эту мысль на секунду, так как она играет жизненно важную роль при настройке нашего CloudFront и корзины s3.
Конструктивное решение IV: развертывание
Часть I (обзор):
В приведенном ниже обзоре архитектуры показаны все компоненты, необходимые для развертывания нашего кода в корзине S3. Процессы сборки в нашей компании сильно привязаны к maven, но в вашем случае он может не понадобиться. Вкратце, подключаемый модуль maven помогает нам корректировать код и создает файл сборки, который затем копируется в корзину S3 заданием TeamCity.
Примечание. Вы можете пропустить maven и использовать npm для сборки файла. Затем вручную скопируйте файлы сборки в корзину S3 без TeamCity.
Наш S3 находится за CloudFront, который действует как фронтальная (пользовательская) точка входа. Любые обновления CloudFront, такие как изменение версии и т. д., будут выполняться с помощью CloudFormation.
Пользователи могут получить доступ к SPA, перейдя из устаревшего приложения оценивания и/или обратившись напрямую к SPA. Все запросы SPA будут обрабатываться CloudFront, который затем загружает соответствующие файлы из корзины S3 (ведь S3 похож на папку с файлами).
Если вы посмотрите на Раздел III: Создание сборки приложения React, наша папка сборки содержит файл index.html, который загружается CloudFront всякий раз, когда пользователь обращается к https://product-name-grader.com. » (то есть то же самое, что и доступ к https://product-name-grader.com/index.html). Однако мы хотели, чтобы наш URL-путь отражал предполагаемый SPA, то есть каталог.
Мы переименовали файл `index.html` в каталог (без .html ), чтобы он загружался как объект, а URL-адрес для загрузки SPA был https://product-name-grader .com/каталог
Примечание: если вы попытаетесь добавить в каталог расширение .html, то всякий раз, когда пользователь попытается получить доступ к https://product-name-grader.com/catalog.html, он будет загружать каталог. html на свой компьютер, так как это не что иное, как файл, хранящийся в ведре/папке.
Часть II (сборка и последующая сборка):
Добавляя скрипт после сборки, мы можем переименовывать и/или перемещать файлы во время нашего шага `npm run build`. Подробнее об этом читайте здесь. Ниже приведены изменения, которые нам нужно будет внести в package.json, а затем добавить сценарий пост-сборки в корневой каталог проекта.
Советы по обучению: мы поймем преимущества сценариев после сборки в проектах npm.
К концу этого у нас будет обновленная папка сборки с index.html, переименованным в catalog.html, а затем новый каталог подпапок будет содержать статический контент из сборки. Ниже приведен обзор файлов/папок процесса после сборки.
Вот коммит с изменениями после сборки.
Часть III (до S3):
Как я упоминал в предыдущих разделах, у нас есть процесс maven для запуска скрипта сборки и архивирования его под именем домашней страницы (упомянутым в package.json) и по версии pom. Затем задание группового города скопирует структуру папок сборки в артефакторию (JFrog), а следующее задание командного города возьмет последнюю сборку из артефактора и поместит ее под именем корзины S3 (т. е. catalogs-name-us-east- 1) и переименовывает файл catalog.html в каталог (делает его объектом вместо HTML-страницы).
Важно! Однако вы можете пропустить все эти автоматические процессы и создать код вручную, а затем скопировать содержимое в корзину S3.
Обновление вручную (Amazon S3):
[выбрать] catalogs.html › Действия › Переименовать объект › catalogs › Сохранить изменения.
[выбрать] catalogs.html › Действия › Изменить метаданные › Значение [ text/html ] › Сохранить изменения.
Ниже показана консоль Amazon S3 и то, как файлы должны выглядеть после того, как мы завершим описанный выше процесс (автоматически или вручную).
Часть IV (CloudFront):
В этом разделе мы сосредоточимся на том, как пользовательские запросы попадают в корзину S3 из CloudFront, и на конфигурациях CloudFront, необходимых для этого.
Происхождение распространения:
Ниже у нас есть два имени источника: одно для службы Node и одно для корзины S3. Имея службу Node и определяя поведение, мы можем направлять трафик в нашу службу Node из нашего SPA без определения полного URL-адреса API.
Пример.Обычно, когда мы выполняем вызовы API-интерфейса в SPA, мы указываем полный URL-адрес API, например https://service-name.company.com/catalogs/v1/admin/healthcheck. но с комбинацией шаблона пути, приоритета и исходного домена мы можем просто вызвать метод выборки по определенному пути, например `catalogs/v1/admin/healthcheck`.
Поведение при распространении:
Шаблоны пути сопоставляются на основе приоритета, после чего соответствующие запросы направляются к их соответствующему источнику. В нашем случае сначала сопоставляются пути службы Node (приоритет 0, 1), а затем мы сопоставляемся с корзиной S3. Если какой-либо из этих шаблонов пути не совпадает, по умолчанию маршрутизируется к S3 (поэтому по умолчанию установлено значение *).
Страницы ошибок распространения:
В этом разделе мы возвращаем запрос обратно в нашу корзину S3, если по какой-то причине мы не можем сопоставить шаблон пути.
Пример: это особенно полезно, когда мы обновляем URL-адрес с пользовательскими путями (например, catalogs/1234), но в нашей корзине S3 нет объекта с именем catalogs/1234, поэтому возникает ошибка (например, 403). Таким образом, мы направляем запрос обратно к объекту каталогов (переименованному из catalogs.html в объект каталога), который запускает логику реагирования-маршрутизатора для поиска соответствующей страницы.
К настоящему времени мы должны построить и развернуть наш SPA в облаке AWS.
Мои предыдущие три блога:
1. React: Дизайн компонентов поиска
2. React | Node: зачем нам заботиться о зависимостях?
3. Сделай сам: как починить демпфер зоны HVAC
Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn и Discord.
