我们正在准备从整体模式过渡到微服务模型，作为此举措的一部分，我正在准备设计并拆分我们的服务。我越来越多地发现一种重复出现的模式，我在网络上看到这种模式被称为复合服务或聚合服务，对此我还不太清楚。
我的问题分为两个部分：
首先，我看到的模式是，在某些情况下，我需要通过UI进行一次通话才能从2个或更多服务中获取数据。让我们将这些服务称为A，B和C。现在，我可以创建另一个服务，即服务D，它将仅针对该特定调用进行编排，并管理对服务A，B和C的下游调用。我将其视为被称为复合服务或聚合服务。我对此感到困惑，现在每次需要协调时，我都必须创建另一个服务，该服务位于原子服务之上，只是为了协调。
此外，这似乎很像BFF（后端后端）模式，但就我而言，我拥有构成我的BFF的多个“复合”服务。我不确定，但是我认为对于BFF来说，您可以为所有UI调用提供一个大型“编排”服务，即使这可能是SPOF且似乎是一种反模式。
因此，我的问题是，是否应该让上面示例中的服务D这样的“微协调器”进行协调？还是我应该让每个服务都直接调用它们依赖于数据的任何服务？
第二，我应该为所有请求在原子服务之上实现一层，我已经看到了很多名称，包括协调流程/ api-gateway / edge-service，或者具有多个“微协调器”或复合服务？如果顶层只有一个服务，例如api网关，这似乎是一种反模式，因为现在有了SPOF，但我认为它是推荐的方式。
为了清楚起见，我将提供上述情况的具体示例，并且我认为这很普遍。在用户界面中，有一个登录页面，输入用户名/密码后，我们将验证凭据，如果凭据正确，则将所有用户信息传回。
将有两个服务来完成此任务，一个用于检查/验证用户凭据的身份验证服务，以及一个将获取所有数据的用户服务。如何协调这个简单的调用，以便如果凭据有效，我们将在同一api调用中从User服务返回数据，否则，我们仅从Authentication服务返回错误。是否应该有一个组合服务来协调对这两个服务的调用，或者如果凭据有效，这些服务是否应该与AuthService直接交互以调用User服务？并且这应该只是其中的一种复合服务，还是应该将所有复合服务放到api-gateway类型的服务中？
我已经看过以下内容，但这并没有提供明确的答案。我的问题不仅是关于服务的组成，而且还涉及是否需要这种组成，即api网关，或者对于需要它的每次交互都应该有多个复合服务。
How do you handle validation in composite microservice request?
答案 0 :(得分：0)
身份验证和授权是一种特殊情况，其中OAuth 2授权服务器根据身份验证服务器（即LDAP等）对用户进行身份验证并返回令牌。它主要基于OAuth 2规范进行设计。让我们暂时将其保留。
服务编排有时已完成。但是，如果您经常看到自己需要进行服务编排，则需要考虑其他一些事项：
首先，您需要检查是否已正确识别服务的有限上下文。换句话说，服务之间的逻辑分工是否正确？
如果您对这种划分感到满意，则需要实现以下一种或多种模式：
此处介绍了使用CQRS和事件源处理这种情况的方法：https://stackoverflow.com/a/54676222/1235935