Django admin + система аутентификации в микросервисной архитектуре
У меня есть проект большой Django, который в основном представляет собой монолит, содержащий приложения. Мне нужно разбить его на микросервисы.
У меня есть 2 вопроса, на которые я не смог найти однозначных ответов:
В настоящее время мы широко используем админку Django, и мне интересно, можно продолжать использовать его после того, как монолит сломан. Это значит чтение и управление данными со всех микросервисов в "используемом поработать над "пользовательским интерфейсом. Также было бы полезно, чтобы этот процесс проходил более гладко.
Аутентификация и авторизация - сможем ли мы по-прежнему использовать это встроенное «приложение» в микросервисной архитектуре? Является ли это возможным перенести эту пару только на другой сервис и общаться с ним через HTTP?
Ответы 1
Currently we're using Django admin extensively and I wonder if it's possible to continue using it once the monolith is broken. It means reading and manipulating data from all the microservices in a "used to work on" UI. It would also be helpful for this process to be done more smoothly.
Да, вы можете, но он не может получить доступ к другим базам данных микросервисов (ни для записи, ни для чтения). Это означает, что если микрослужба администратора обновляет некоторую статью (или любые типы сущностей, которые у вас есть, это всего лишь пример), это не сразу отражается в микросервисе, отображающем эту статью. У вас должен быть какой-то механизм для передачи обновлений от администратора другим микросервисам. Таким образом, общие базы данных / таблицы не подходят.
Authentication and authorization - Would we still be able to use this built in "app" in a microservice architecture? Is it possible to take this pare only to another service and communicate with it over HTTP?
Да, но нужно разделить его на две части. Одна сторона отвечает за управление пользователями и ролями / разрешениями, а другая отвечает за аутентификацию пользователей и проверку того, может ли пользователь выполнять какие-либо действия.
Первая сторона должна быть микросервисами (создание / администрирование или пользователей и управление ролями / разрешениями).
Часть проверки может быть микросервисом, но эти обязанности обычно берут на себя шлюз API или модуль (+ локальные реплицированные данные) в каждом микросервисе, который требует аутентификации или авторизации. Это сквозные проблемы. Если они находятся в отдельном микросервисе, возникает проблема устойчивости: если этот микросервис выходит из строя, он выдает из строя всю вашу систему.
@mrgoos 1/2. вы можете модели видеть из других микросервисов внутри одного микросервиса, но как другую модель. Модели не следует полностью импортировать. В доменно-ориентированном проектировании есть компонент, отвечающий за удаленные модели импорт: уровень защиты от коррупции; он принимает удаленные модели в качестве входных и производит локальные модели в качестве выходных. В 99% случаев локальные модели отличаются (с меньшим количеством свойств) от удаленных (источников).
@mrgoos 2/2. Например, система управления статьями имеет только идентификатор и заголовок опубликованной статьи или URL-адрес, а не все свойства, с целью отображения ссылки на нее в панели администратора.
На данный момент Админ представляет собой отражения моделей. Если я возьму (используя ваш пример) Управление статьями для микросервиса, тогда модель будет со своей собственной БД. Вы не сказали, как я могу показать на моем рабочем Admin, модели из другого микросервиса. Что касается самого обновления, я бы хотел, чтобы оно обновлялось через REST между службой администратора и первой статьей.