在DNN中,我正在将一些解决方案项目转移到微服务中。内容管理确实是DNN的工作,但是我们仅假设整体解决方案已经失控,并且根据内容管理器的功能将内容管理器移到其自己的微服务中是有意义的。微服务将提供内容数据,而不是UI,因为DNN模块仍将驻留在DNN站点中,但将调用微服务以获取内容数据。
我可以使用DNN生成的JWT令牌实现安全性,但是我的主要问题是DNN的依赖关系。一个示例是无法在微服务中完成对程序集DotNetNuke.Entities.Users.UserController的调用。我想我有以下选择:
- 将所有相关信息作为JWT声明的一部分-用户个人资料,角色等。这显然是不理想的,因为这将使JWt变得不必要的繁重,更不用说这会导致数据泄漏。
- 将依赖关系逻辑复制到微服务中。这是可能的,但是很困难,因为需要DNN db,并且需要复制DNN程序集的逻辑,该逻辑会随着时间的变化而变化,但是不确定是否可以在DNN站点的上下文之外使用DNN程序集(微服务将具有访问权限到DNN db)。
- 从DNN站点创建一个端点并在微服务中调用它-这似乎是最可能的解决方案,但是我不确定回拨DNN是否是一个好主意,似乎DNN站点会向微服务请求数据微服务可以在创建响应之前将数据请求回DNN站点。换句话说,循环依赖(请参见下图)。
- 将依赖项作为API请求的一部分从DNN传递给微服务。这似乎是一个坏主意,因为依赖项是作为http请求的一部分传入的。
选项3是最好的选择吗,这会导致死锁还是仅仅是一种反模式?任何其他推荐的解决方案都很好。