微服务应用设计

Question

我正在设计一个具有Microservices后端和SPA前端的应用程序。我对性能有些担心，一个要填充的CRUD页面可能需要调用6或7个服务端点，而我无法想象调用速度会很快。

实现一个额外的服务层是否是一个良好的实践，该层本质上使用所需的所有信息创建视图模型，而不是要求客户端进行如此多的调用？这种模式叫什么？

Answer 1

你有两个基本的选择。

1. 为UI创建一个“包装”服务，该服务对其所需的每个服务进行聚合调用，并将数据以UI需要的形式放入其中。
2. 为您感兴趣的每个资源创建一个始终拥有存储在它自己的数据存储中的最新信息的服务。

我已经做了第一，它的规模不是很好。特别是如果您必须对数据进行分页，并且有复杂的搜索查询，需要过滤存储在不同微服务中的数据。如果你强烈期望你可能需要这样的能力，我就不会进这个兔子洞。

我们现在开始越来越多地与#2一起工作。根据我的研究，有很多商店遵循这种“模式”。它被称为甚至驱动的数据管理。这意味着每个微服务可以在数据更改时广播异步事件，任何人都可以订阅这些事件，并通过适当更新其数据存储来作出反应。在您的示例中，您可能有一个简单的数据存储库，用于存放为UI服务所需的所有信息，并确保正确捕获这些事件并更新数据。

这是使用微服务架构非常严重的缺点之一。由于有界上下文，数据管理要困难得多。您沿着聚合调用的路径走下去，直到您意识到这还不够，然后您可能不得不开始进行事件驱动的数据管理，这只是大量额外的工作，以便将数据“去或”成一个数据存储，以便快速查询。

Answer 2

我通常实现一个服务层，用于满足每个特定客户端的需求。我想你说的是一个webapp应用程序，它需要发出6-7个请求来呈现页面。正如您已经注意到的那样，对于web客户端来说，这不是可伸缩的，也是无法执行的。

实现一个额外的服务层是否是一个良好的实践，该层本质上使用所需的所有信息创建视图模型，而不是要求客户端进行如此多的调用？

是的，这就是我要做的。我会创建一个新的微服务，以满足这一网络应用的需求。在这个微服务中创建一个API，将one应用程序的页面/请求映射到对其他服务的一个或多个请求。for应用程序应该只对每个动作/页面向后端发出一个请求。

这种模式叫什么？

我不知道这是否是一种特定的模式，但它本质上是相当于适配器模式的微服务。