【发布时间】：2020-01-30 01:23:57
【问题描述】：
我们正在准备从单体架构到微服务模型的转变，作为这一转变的一部分，我正在准备设计和拆分我们的服务。我越来越多地发现重复出现的模式，我在网络上看到它被称为复合或聚合服务，但我并不完全清楚。
我的问题分为两部分：
首先，我看到的模式是，我需要在一次 UI 调用中进行对话以从 2 个或更多服务获取数据。让我们调用这些服务 A、B 和 C。现在，我可以创建另一个服务，比如服务 D，它将为这个特定调用进行编排，并将管理对服务 A、B 和 C 的下游调用。我认为这是被称为复合或聚合服务。我对此感到困惑的是，现在每次我需要一些协调时，我都必须创建另一个位于原子服务之上的服务，只是为了协调。
此外，这看起来很像 BFF（后端为前端）模式，但就我而言，我有多个“复合”服务来组成我的 BFF。我不确定，但我认为对于 BFF 来说，你的所有 UI 调用都有一个大型“编排”服务，即使这可能是 SPOF 并且看起来像是一种反模式。
因此，我的问题是，我是否应该让这些“微协调者”（例如上面示例中的服务 D）来进行协调？还是我应该让每个服务直接调用它们依赖于数据的任何服务？
其次，我是否应该只在所有请求的原子服务之上实现一层，我已经看到这有很多名称编排/api-gateway/edge-service，或者有多个这些“微编排器”或复合服务?如果顶层只有一个服务，例如 api-gateway，这似乎是一种反模式，因为现在有一个 SPOF，但我认为它被推荐为要走的路。
为了清楚起见，我将提供我上面描述的情况的具体例子，我认为这是很常见的。在 UI 中有一个登录页面，输入用户名/密码后，我们将验证凭据，如果正确，则传回所有用户信息。
将有 2 个服务来完成此操作，一个用于检查/验证用户凭据的身份验证服务和一个用于获取所有数据的用户服务。应该如何协调这个简单的调用，以便如果凭据有效，我们在同一个 api 调用中从用户服务返回数据，如果不是，我们只从身份验证服务返回一个错误。是否应该有一个复合服务来协调对这两个服务的调用，或者如果凭据有效，这些服务是否应该直接与 AuthService 交互以调用用户服务？这应该只是众多组合服务中的一种，还是应该将所有组合服务组合成一个 api-gateway 类型的服务？
我已经看过以下内容，但这并没有真正提供任何明确的答案。我的问题不仅是关于服务的组合，还包括是否应该有一个这样的组合，即一个 api 网关，或者每个需要它的交互的多个组合服务。
How do you handle validation in composite microservice request?
【问题讨论】：
标签： microservices