我的微服务架构是否符合最佳实践？ （STS / SPA /前端API /后端服务）

Question

目标是使应用程序具有SPA前端，并结合微服务架构实时更新。

我有 -SPA（角度） -前端API（用于SPA），公开api和signalr集线器 -一些后端服务 -用于后端操作的Azure Servicebus和用于前端api的通知，通知某些内容已更新（在这种情况下，将推送信号R消息） -Identityserver 4.0作为STS（和asp.net核心身份作为存储区）

我正在努力为我的系统构建一个良好的安全可扩展体系结构。 我不想不必要的开销，也不想创建一个庞大的整体。我希望后端服务对Internet的其余部分隐藏，但是前端Api可以访问它。

我希望前端API足够智能，以查询SPA需要的特定需求，并侦听与SPA相关的事件以通过SignalR通知。换句话说：我不想要一个愚蠢的网关。

放学吧。我只想开始实施。

如果我只允许从前端API进行访问，那么我认为从后端到STS的界限是多余的。

我真的需要一些见识。

这是我到目前为止所做的：

Answer 1

我们正在实现微服务架构，我们使用ReverseProxy终止公共请求并将呼叫转发给内部服务。

此代理中包含用于调出Identity Server的所有代码。我认为您不想从后端服务中做到这一点。

您可能想添加某种会话管理服务，该服务会创建一个标识符，然后将该标识符传递给所有服务调用。

您可能还想考虑使用Docker托管您的服务，以确保它们在环境之间是隔离和一致的，并使用诸如Kubernetes的编排工具来管理容器。