使用 Service Fabric 的微服务在哪里放置控制器

Question

我有一个在 .NET Core 中有多个服务的微服务项目。在放置控制器时，有两种方法：

1. 将控制器放在各自的微服务中，每个微服务中都有Startup.cs。
2. 将所有控制器放在一个单独的项目中，并让它们调用各个服务。

我认为第一种方法将涉及较少的编码工作，但第二种方法使用接口等将控制器与实际服务分开。 使用这两种方法在 Fabric 中创建和管理它们的方式是否存在差异。

Answer 1

这是一个非常广泛的话题，可以引发讨论，因为这完全取决于偏好、经验和技术堆栈。我会加两分钱，但不要将其视为一项规则，只是我对这两种方法的看法。

第一种方法（每个服务的 API 相互隔离）：

• 服务将自己公开其公共 API，您需要采用服务发现方法以使客户端能够调用每个微服务，一个简单的方法是使用反向代理通过服务名称转发调用。
• 每个服务及其 API 都可以独立扩展
• 这种方法更好地部署单个更新，而无需关闭其他微服务。
• 这种方法往往有更多的代码重复来处理授权、身份验证和其他常见方面，从那里您将最终在所有服务上使用共享库。
• 这种方法增加了故障点，这很好，因为故障会影响较少的服务，如果一个API发生故障，其他服务不会受到影响（如果故障不影响机器，例如内存泄漏或CPU使用率高)。

第二种方法（单一 API 将调用转发到正确的服务）：

• 您有一个端点，服务发现将发生在 API 中，所有工作都将由每个服务处理。
• 即使一项服务消耗的资源比其他服务多得多，API 也必须针对所有人进行扩展。只是服务会独立扩展。
• 这种方式，添加或修改api端点，你可能会更新API和服务，取下API会影响其他服务。
• 这种方法减少了代码重复，您可以集中许多常见方面，例如授权、请求限制等。
• 这种方式故障点少，如果一个微服务宕机，大量调用依赖于这个服务，API会处理更多的连接和挂起的请求，这会影响其他服务和性能。如果它出现故障，所有服务都将不可用。与第一种方法相比，第一种方法将弹性卸载到代理或客户端。

总之， 两种方法都有相似的努力，不同之处在于努力将分为不同的领域，您应该评估两者并考虑维护哪一个。在比较中不要只考虑代码，因为与发布、监控、日志记录、安全性、性能等其他方面相比，代码对整体解决方案的影响很小。

Answer 2

在我们当前的项目中，我们有一个面向公众的 API。对于每个领域，我们都有几个单独的微服务项目。作为个体，我们可以根据每个微服务使用的资源进行扩展。例如，我们有一个消耗大量资源的成像服务，因此扩展它更容易。您也有机会单独部署它们，如果任何服务出现故障，也不会破坏整个应用程序。

在所有微服务之前，我们有一个 API 网关，用于处理所有身份验证、限制、版本控制、健康检查、指标、日志记录等。我们为每个微服务提供接口，并为每个上下文单独保留请求和响应模型.该层没有业务逻辑，您还可以在需要调用多个服务时聚合响应。

如果您想询问有关此结构的任何内容，请随时询问。