单片-> SOA。所需咨询

Question

对于SOA/微服务体系结构的最佳实践，我很少有疑问。我们目前有单块应用程序，但我们希望开始将其划分为服务。

因此，这里有一个问题:假设我有一个用户。用户可能有多个主题。用户可以向主题添加/上载文档。我们想为这些文件创建一个单独的服务。

所以看起来是：

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

当用户/客户端上传文档时，他指定了应该将文档上载到的主题。关于用户/客户端位于前端/主单块服务中的主题的数据(在该服务的数据库中)。

问:是否应该有“访问控制”检查？换句话说，如果用户可以将文档上载到指定的主题(或者主题属于该用户)，那么应该在哪里进行检查？

我认为有三种选择：

• 检查将在Frontned/Main-单片服务中进行，然后该服务将调用Documents。所以Documents 信任的前端/主板。
• 检查将通过服务调用在Documents中进行，但它目前将引入一个循环依赖关系： 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

但是，正如您可以想象的那样，同时开始将生产单块应用程序拆分到许多服务中是有风险的。我们希望尽可能减少错误的风险和减少错误的可能性。因此，从我们的角度来看，一个接一个地引入服务可以降低风险。

如有任何帮助/建议或建议将不胜感激！提前谢谢你。

诚挚的问候

Answer 1

和每个SOA主题一样，这是一个品味问题。我会同意第三种情况，但一步一步地去做。作为第一步，将用户和主题之间的分配提取为类似于TopicAuthorizationService的内容。此服务可由您的独角兽调用。测试一下这个小重构。

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

下一步，提取DocumentService并将对TopicAuthorizationService的调用保留在monolith中。再次:测试此重构

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意味着首先要在人类通信中增加大量开销，以完成任务。如果你和你的团队控制住了这个，这绝对是可行的方法。