Ваш вопрос очень открытый. Мы внедрили микро интерфейсы в прошлом году, так что вот как мы это делаем. Это ни в коем случае не является «единственным способом» создания микро-интерфейсов. Если вы не видели их, их стоит прочитать, поскольку они охватывают наиболее распространенные архитектурные шаблоны, возникающие при проектировании микро-интерфейсов:
- Микро-интерфейсы
- Мозаика проекта
- Одиночный SPA
Шаблоны делятся на две категории:
- Управление рендерингом внешнего интерфейса, находящимся исключительно в коде на стороне клиента (это делает Single SPA)
- Управление рендерингом внешнего интерфейса, частично находящимся на стороне клиента, частично на стороне сервера
Технически вы можете добавитьтретий:
Управление рендерингом веб-интерфейса, полностью находящимся на стороне сервера
Мы реализовали # 2, и Project Mosaic, связанный выше, также делает это. Наш дизайн немного отличается от архитектуры мозаики. Вот как работает наше приложение:
У нас есть магазин с описанием шаблонов, которые будут отображаться. Для этого мы используем Redis, но это может быть любое хранилище данных. Шаблоны содержат:
a. Маршруты, по которым должен отображаться шаблон (это регулярное выражение)
b. «Области» в шаблоне, которые должны быть отображены. Они содержат идентификатор и ранг, поэтому служба, отвечающая за рендеринг, может правильно сортировать шаблоны
c. «Ресурсы» в шаблоне, которые должны быть отображены. Они содержат сценарии и теги ссылок, которые будут помещены в DOM.
d. Родительский шаблон, если таковой имеется, вместе с областью на родительском шаблоне, где должен отображаться дочерний шаблон
У нас есть приложение на стороне сервера, которое определяет подходящие шаблоны для данного маршрутаи создает JSON-представление DOM для этого маршрута.
У нас есть клиентское приложение, которое поддерживает частичное представление DOM в качестве Virtual DOM, рендеринг JSON-представления возвращаетсясерверное приложение в Virtual DOM, которое используется для окончательной визуализации реальных изменений в DOM при изменении маршрута.
Клиентское приложение также отвечает за прослушивание изменений с использованием History API,и запросить у бэкэнда обновления для представления DOM по заданному маршруту.
Мы строим наши микро-интерфейсы на основе общего шаблона, который мы разработали. После завершения мы загружаем в CDN и используем адрес CDN в вышеупомянутых ресурсах шаблона для рендеринга внешнего интерфейса по соответствующим маршрутам.
В общих чертах, так разработано наше приложение внешнего интерфейса. ,Мы используем Kubernetes и воспользовались преимуществами написания пользовательских контроллеров в сочетании с пользовательскими определениями ресурсов, чтобы легко развернуть наши интерфейсы. Но вы можете сделать это просто с любым хранилищем данных, Kubernetes не нужен.
Относительно сеанса пользователя, аутентификации и т. Д. Это наша установка:
Сервер авторизации
а. Предоставляет страницу входа в систему
b. Устанавливает токен JWT в локальное хранилище при успешном входе в систему
Клиентское приложение для перехвата fetch запросов, вставляя заголовок Authorization с токеном JWT из локального хранилища
Функция обратного прокси-сервера Traefik ForwardAuth для проверки JWT в Authorization to:
a. Подтвердите сеанс пользователя
b. Определить пользователя
c. Найдите пользователя и его разрешения
Хранилище данных (Redis), чтобы установить требования авторизации для данного маршрута. Это очень похоже на шаблоны, описанные выше. Информация об авторизации, содержащаяся в этом хранилище данных, состоит из:
a. Маршруты, к которым относятся требования (как регулярное выражение)
б. Применимые разрешения, которые должны применяться
Опять же, для этого мы создали пользовательский контроллер и пользовательское определение ресурса, чтобы легко создавать и удалять требования авторизации для нашего приложения. Но в этом нет необходимости.
Когда запрос поступает через обратный прокси-сервер, вызывается сервер аутентификации, проверяется токен пользователя, ищется его профиль и ищутся требования приложения для маршрута ипо сравнению с разрешениями, предоставленными пользователю. Если это подтвердится, ответ верен в Traefik, если нет - 401 Not Authorized, и traefik отклонит запрос.
Это все на довольно высоком уровне. Но на самом деле это очень хороший дизайн для нас, потому что у нас есть всего несколько мест, где обрабатывается авторизация, и разработчикам не нужно обращать никакого внимания на авторизацию при написании своих веб-интерфейсов (или бэкэндов в этом отношении, поскольку мы также используем микро-сервис). архитектура на бэкэнде).
Надеюсь, это полезно.