使用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网关，用于处理所有身份验证，调节，版本控制，运行状况检查，指标，日志记录等。我们为每个微服务提供接口，并针对每个上下文分别保留请求和响应模型。该层上没有业务逻辑，您还可以在需要调用多个服务的地方汇总响应。

如果您想对这种结构有任何疑问，请随时提问。