微服务设计:以操作为中心还是以对象为中心？

Question

我们将围绕REST设计微服务应用程序。该应用程序旨在从许多异构存储库中搜索、创建、更新和检索文档。

我想知道我是否需要围绕操作建立服务模型(每次操作都得到、放置、发布、修补、.或者在存储库(每个后端存储库=服务)周围。

Answer 1

微型服务应该围绕他们在系统中提供的服务进行设计。

因此，例如，您可能有一个用户服务，它唯一的职责是存储和验证用户。然后，您的系统中的所有其他服务都将使用此服务对用户进行身份验证。

而且您可能有一个文档存储服务，它只会存储一个文档(即它也不担心用户身份验证，或者在每个请求中将文档转换成不同的格式)。

我不太清楚您所说的“围绕操作建立服务模型”是什么意思，但是如果您的意思是您有一个用于GET的微服务和一个用于PUT的微服务，并且每个微服务都有在其中处理此任务的所有服务，那么不，这不是一个好主意，也是某种意义上的失败。

Answer 2

两样都能用。这取决于您想要如何定义资源。您可以从文件获取/发布存储库，或者提供让您的服务找到它，或者让用户在URI中指定一个选项，或者您可以将/Post分别送到每个存储库，并将其放在客户机上，以便在调用存储/检索文档之前知道或查找文档的正确存储库。

在可测试性和重用方面，更简单的资源是好的，但另一方面，您确实希望尽可能多地将更简单的操作组合成更复杂的操作，以便在服务空间中尽可能地将表示与逻辑分开，以减少对多个表示模式重新编码的数量。如果延迟需求允许的话，这往往会形成多层服务。此外，使用更精细的谷物服务，您可以更容易地进行负载平衡，尽管与所有分布式应用程序一样，数据库或网络可能是无声的瓶颈。基本上，可以选择将公共实现拆分到其他web服务中，还是只使用不公开为web服务的公共库。

Answer 3

您应该围绕存储库创建服务，而不是关于操作的服务，就像在操作案例中一样，实体上的业务逻辑将在不同的服务中被分散，这不是一个好方法。

同样，在存储库中，首先定义服务提供的确切业务价值，然后从存储库中只选择这些实体并定义服务。

了解更多关于微服务的知识--您可以从这里阅读。

如果您仍然有疑问，通过指定存储库中的实体来问更具体的问题，将有助于:)