单体 -> SOA。需要建议

Question

关于 SOA/microservice 架构的最佳实践，我几乎没有什么问题。我们目前有单体应用程序，但我们想开始将其拆分为服务。

所以，这是一个问题：可以说我有一个用户。用户可能有多个主题。用户可能 add/upload 文档到主题。我们想为文档创建一个单独的服务。

所以它看起来像：

User/Client -- requests --> Frontend/Main-monolithic Service -- requests --> Documents Service

当 User/Client 上传文档时，他指定了文档应上传到的主题。关于哪个主题属于哪个 user/client 的数据位于 Frontend/Main-monolithic 服务中（嗯，在该服务的数据库中）。

问题：那里应该有"access-control"支票所在？换句话说，如果用户可以将文档上传到指定的主题（或者该主题是否属于该用户），应该在哪里检查？

我看到三个选项：

检查将在 Frontned/Main-monolithic 服务中进行，然后该服务将调用文档服务。所以文档服务信任 Frontend/Main-monolithic.
检查将通过服务调用在文档服务中进行，但目前会引入循环依赖：

User/Client -- requests --> Frontend/Main-monolithic Service -- requests --> Documents Service -- requests --> Frontend/Main-monolithic Service
创建多个服务，这将类似于：

User/Client -- requests --> Frontend Service -- requests --> Documents Service -- requests --> Topic Service

但是您可以想象，同时开始将生产单体应用程序拆分为大量服务有点冒险。我们希望尽可能降低风险并降低错误发生的可能性。所以从我们的角度来看，一项一项地引入服务可能会降低风险。

任何 help/advice/suggestions 将不胜感激！提前谢谢你。

此致

Answer 1

与每个 SOA 主题一样，这是一个品味问题。我会选择第三种情况，但要逐步进行。作为第一步，将用户和主题之间的分配提取到类似于 TopicAuthorizationService 的内容中。这个服务可以被你的整体调用。测试这个小重构。

Frontend/Main-monolithic Service -- requests --> TopicAuthorizationService 
Frontend/Main-monolithic Service -- writesDocument--> Filesystem/DB whatever

作为下一步，提取 DocumentService 并将对 TopicAuthorizationService 的调用保留在您的整体中。再次：测试这个重构

Frontend/Main-monolithic Service -- requests --> TopicAuthorizationService 
Frontend/Main-monolithic Service -- requests --> DocumentService 
DocumentService -- writesDocument--> Filesystem/DB whatever

第三步：将授权调用移至DocumentService。测试一下。

Frontend/Main-monolithic Service -- requests --> DocumentService
DocumentService -- requests --> TopicAuthorizationService 
DocumentService -- writesDocument--> Filesystem/DB whatever

这样可以降低影响，保证生产。

Answer 2

这不仅与服务本身的复杂性有关，还与实施、编排和管理它们的人员有关。引入 SOA 意味着首先要在人类交流中增加大量开销以完成任务。万一您和您的团队控制了这个，这绝对是可行的方法。

单体 -> SOA。需要建议

Monolithic -> SOA. Advice needed

soa