В DNN я нахожусь в процессе переноса некоторых проектов решений в микросервисы. Управление контентом - это действительно работа DNN, но давайте просто предположим, что монолитное решение выходит из-под контроля, и имеет смысл переместить контент-менеджеров в собственный микросервис в зависимости от их функций. Микросервис будет обслуживать данные содержимого, а не пользовательский интерфейс, поскольку модули DNN по-прежнему будут находиться на сайте DNN, но будут вызывать микросервис для получения данных содержимого.
Я могу реализовать безопасность с помощью токенов JWT, сгенерированных DNN, но моя главная проблема - это зависимости от DNN. Одним из примеров является то, что вызовы сборки DotNetNuke.Entities.Users.UserController не могут выполняться в микросервисе. Думаю, у меня есть следующие варианты:
- Поместите всю необходимую информацию как часть заявлений JWT - профиль пользователя, роли и т. Д. c. Это явно не идеально, так как это сделает JWt ненужным, не говоря уже о том, что это может вызвать утечку данных.
- Дублируйте logi c зависимости в микросервисе. Это возможно, но может быть сложно, так как DNN db требуется и потребует дублирования logi c сборки DNN, которая может измениться со временем, но не уверен, можно ли использовать сборку DNN вне контекста сайта DNN (микросервис будет иметь доступ к DNN db).
- Создайте конечную точку с сайта DNN и вызовите ее в микросервисе - это кажется наиболее вероятным решением, но я не уверен, что обратный вызов DNN - хорошая идея , похоже, что сайт DNN запрашивает данные у микросервиса, затем микросервис запрашивает данные обратно на сайт DNN, прежде чем он сможет создать ответ. Другими словами, циклическая зависимость (см. Диаграмму ниже).
- Передается в зависимости как часть запроса API от DNN к микросервису. Это кажется плохой идеей, поскольку зависимость передается как часть http-запроса.
Является ли вариант 3 моим лучшим вариантом, может ли это вызывать взаимоблокировки или это просто анти-шаблон? Подойдет любое другое рекомендуемое решение.
