Question

关于SOA /微服务架构的最佳实践，我几乎没有任何问题。我们目前有单一的应用程序，但我们想开始将其划分为服务。

所以，这是一个问题：假设我有一个用户。用户可能有多个主题。用户可以添加/上传文档到主题。我们想为文档创建一个单独的服务。

所以它看起来像：

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

当用户/客户端上传文档时，他指定了应该将文档上载到的主题。有关哪个主题属于哪个用户/客户端位于前端/主要单片服务（以及此服务的数据库中）的数据。

问题：应该＆＃34;访问控制＆＃34;检查位于？换句话说，应该在哪里检查，如果用户可以将文档上传到指定的主题（或者主题属于该用户）？

我看到三个选项：

检查将在Frontned / Main-monolithic Service中，然后此服务将调用Documents Service。所以文件服务信任前端/主要单片。
支票将通过服务电话进入文件服务，但目前会引入循环依赖：

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的内容。您的monolith可以调用此服务。测试这个小重构。

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

下一步提取DocumentService并将调用保留在monolith中的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意味着最重要的是在人工通信中增加大量开销以完成工作。如果你和你的团队控制住了这个，这绝对是你要走的路。

单片 - ＆gt; SOA。需要的建议

2 个答案: