我应该在哪里过滤微服务架构模式中的 MS 级外部服务响应？
Where should I filter an MS level external service response in microservice architecture pattern?
我在我的微服务前面使用 API 网关 (BFF) 来处理 UI 需求。
例如我有一个调用外部服务的微服务。
在 UI 我不需要（现在）外部服务提供的所有信息。
我的 MS 应该只将当前需要的数据传递给 BFF，还是传递整个响应，我应该 "filter" BFF 中的 MS 响应？
例如：
从单一责任原则的角度来看，最好return只是相关数据，更多的信息意味着对一个方法或一个action.Because你不是唯一的用户system.It其他用户在调用getUsers方法时会感到困惑，却收到与用户无关的信息。
这取决于您希望如何使用您的外部用户服务。
如果您认为该服务将服务于不同类型的请求，并且最好 return 所有信息，该服务应该 return 一切。然后你的 BFF 将过滤到 return 只需要的数据。
如果您只想将此外部用户服务用于此目的，它应该 return 只需要服务。
总而言之，您需要有一个良好的域设计来决定服务有多大，要传输多少数据，有多少其他组件将使用该服务。
您问题的答案取决于速度因素。
如果应用程序必须非常快怎么办
如果您需要真正快速的服务，那么您需要使用包含 BFF 层的最少数据传输操作来创建执行路径。
如果外部服务层只有一个执行路径和一个需要你的API，你可以在微服务端过滤多余的数据。这减少了 MS 和前端层之间的数据传输量。
或者您可以在 MS 或 BFF 层上缓存外部用户服务结果，以大大提高您的应用程序的速度。当然，如果可能并且有意义的话。
如果速度因素不那么重要怎么办？
通常，提高速度 and/or 性能会使您编写更多代码，例如单独的执行路径或其他内容。如果速度因素不是那么重要，您可以减少代码量并在正常请求和过滤请求之间重用相同的执行路径，并在前端过滤结果。
这会对您的代码库产生积极影响。更少的代码 - 更少的问题。
首先，BFF 模式的重点是为前端提供一个专门构建的接口，它们可以自由地从包含它们的服务中收集数据。我建议：
- 如果
Microservice 微服务（在您的图表中）在返回数据之前以某种方式操作数据，则在写入数据时操作它们（如果可以的话，可能通过观察外部系统中的某些事件）并存储处理后的结果（可能是本地副本）。
- 如果您不需要在数据发送到 BFF 时对其进行操作，那么您正在进行的任何处理（理论上）都可以在请求的上下文之外异步完成，而不是在线，如果它失败，则有不必要的不可用风险（这称为时间耦合）。
如果以上两种情况之一可行，我非常强烈建议您避免使用菊花链同步网络请求，因为这会大大降低您的可用性（如果每个服务都是95% 可用，两者加起来是 90% 可用，而不是 95%，这很快就会变坏）。延迟是一个问题（正如@picolino 正确提到的那样），但根据我的经验，延迟比可用性更受关注的情况要少得多。无论如何，扁平化调用堆栈将大大减少处理请求所花费的时间。
从责任分配的角度来看，以上两种方案也都不错；一个服务将拥有客户数据，而另一个数据不需要拥有传递，BFF 可以异步通知它做任何它需要的横切关注点。
当且仅当上述 none 可行时，我建议您在做出决定之前稍微考虑一下您正在开发的服务的合同及其所需的数据。盲目地传递整套数据可能是也可能不是一个好主意，这取决于您那里的 Microservice 服务的职责性质。
我在我的微服务前面使用 API 网关 (BFF) 来处理 UI 需求。
例如我有一个调用外部服务的微服务。
在 UI 我不需要（现在）外部服务提供的所有信息。 我的 MS 应该只将当前需要的数据传递给 BFF，还是传递整个响应，我应该 "filter" BFF 中的 MS 响应？
例如：
从单一责任原则的角度来看，最好return只是相关数据，更多的信息意味着对一个方法或一个action.Because你不是唯一的用户system.It其他用户在调用getUsers方法时会感到困惑，却收到与用户无关的信息。
这取决于您希望如何使用您的外部用户服务。
如果您认为该服务将服务于不同类型的请求，并且最好 return 所有信息，该服务应该 return 一切。然后你的 BFF 将过滤到 return 只需要的数据。
如果您只想将此外部用户服务用于此目的，它应该 return 只需要服务。
总而言之，您需要有一个良好的域设计来决定服务有多大，要传输多少数据，有多少其他组件将使用该服务。
您问题的答案取决于速度因素。
如果应用程序必须非常快怎么办
如果您需要真正快速的服务，那么您需要使用包含 BFF 层的最少数据传输操作来创建执行路径。
如果外部服务层只有一个执行路径和一个需要你的API，你可以在微服务端过滤多余的数据。这减少了 MS 和前端层之间的数据传输量。
或者您可以在 MS 或 BFF 层上缓存外部用户服务结果，以大大提高您的应用程序的速度。当然，如果可能并且有意义的话。
如果速度因素不那么重要怎么办？
通常，提高速度 and/or 性能会使您编写更多代码，例如单独的执行路径或其他内容。如果速度因素不是那么重要，您可以减少代码量并在正常请求和过滤请求之间重用相同的执行路径，并在前端过滤结果。
这会对您的代码库产生积极影响。更少的代码 - 更少的问题。
首先，BFF 模式的重点是为前端提供一个专门构建的接口，它们可以自由地从包含它们的服务中收集数据。我建议：
- 如果
Microservice微服务（在您的图表中）在返回数据之前以某种方式操作数据，则在写入数据时操作它们（如果可以的话，可能通过观察外部系统中的某些事件）并存储处理后的结果（可能是本地副本）。 - 如果您不需要在数据发送到 BFF 时对其进行操作，那么您正在进行的任何处理（理论上）都可以在请求的上下文之外异步完成，而不是在线，如果它失败，则有不必要的不可用风险（这称为时间耦合）。
如果以上两种情况之一可行，我非常强烈建议您避免使用菊花链同步网络请求，因为这会大大降低您的可用性（如果每个服务都是95% 可用，两者加起来是 90% 可用，而不是 95%，这很快就会变坏）。延迟是一个问题（正如@picolino 正确提到的那样），但根据我的经验，延迟比可用性更受关注的情况要少得多。无论如何，扁平化调用堆栈将大大减少处理请求所花费的时间。
从责任分配的角度来看，以上两种方案也都不错；一个服务将拥有客户数据，而另一个数据不需要拥有传递，BFF 可以异步通知它做任何它需要的横切关注点。
当且仅当上述 none 可行时，我建议您在做出决定之前稍微考虑一下您正在开发的服务的合同及其所需的数据。盲目地传递整套数据可能是也可能不是一个好主意，这取决于您那里的 Microservice 服务的职责性质。