Service Fabric：我是否应该将我的 API 拆分为多个小 API？

Question

多年来我一直在构建 .Net Web API...通常我有一个 API 有 10 个左右不同的控制器来处理从注册用户、处理业务逻辑、支付等所有事情。这些都与类库对话与数据库等对话。没什么花哨的，但效果很好。

快进到今天...我正在为获得大量流量的应用程序构建第 2 版。我知道我的应用会受到重创，因此我正在寻找具有效率和规模基础的应用。

这让我接受了 Service Fabric 和 ASP.Net Core Web API 的酷炫之处。我一直在阅读大量教程、文章和 SO 问题，据我了解，Service Fabric 的美妙之处在于它会在事情繁忙时在单个 VM 中生成多个节点。

那么，如果我保持我的正常模式并使用 10 多个控制器创建一个 Web API，Service Fabric 可以完成它需要做的事情吗？还是我应该创建多个更专注的小 API，以便 Service Fabric 可以在事情繁忙时添加/删除它们？

这听起来是正确的做法，我已经设置了我的代码来做到这一点，将我的模型和数据类放在他们自己的类库中，这样它们就可以被不同的 API 重用，但我只是想在我做一些可能很愚蠢的事情之前仔细检查一下。

如果我将每个控制器拆分为自己的 Service Fabric 服务，Azure 服务器是否会更高效并更好地扩展？

谢谢！

Answer 1

节点

在 Service Fabric 群集（在 Azure 上/独立）中，节点等于 VM。如果增加机器数量，集群中会出现更多节点。 （本地开发集群并非如此。）Azure 集群中的扩展很简单：只需更改 VMSS 实例数。

仅当您使用实例计数 -1 配置无状态服务时，Service Fabric 才会生成它的新实例。这是由添加节点引起的，而不是由负载本身引起的。 您可以为 VMSS 配置autoscaling。

网络 API

Service Fabric 只是尝试在可用资源之间平衡所有正在运行的 SF 服务的负载。这可能是每个节点上一种服务类型的一个实例，也可能是多种类型的多个实例。因此，一项服务可以使用它运行的节点的所有资源，就像使用 IIS 一样。 （这就是为什么容器支持顺便来的原因。）

Web API 设计不受 Service Fabric 直接影响。与在 IIS 或其他地方运行时相同的规则适用。这真的是你的选择。

微服务

您的正常模式将起作用。但从中制作更小的服务可能有助于减少变化的影响。 （以增加复杂性为代价。）考虑创建遵循Microservices 范式的提供通用功能的服务。

在微服务中，您的代码更改仅限于更小的模块，需要的测试更少，更新期间的性能下降更少。这样，理论上，您可以在更短的时间内发布新功能。

Answer 2

视情况而定。

如果您的控制器对他们使用的资源有一个自然划分，那么如果您沿着该划分线划分您的服务，您可能会获得一些好处。假设服务 A 使用大量 CPU，服务 B 主要使用 HTTP，那么让 SF 能够自行拆分 CPU 负载可能意味着受影响的 HTTP 调用更少。

您可以通过reporting load 从您的应用程序内部优化 SF 如何分配负载，但要尽可能以最简单的方式进行，不要添加许多维度，每个服务最多可能一个维度。

如果您的所有控制器使用大致相同的相同类型的资源，那么将它们拆分到单独的服务中并没有真正的好处，只是代码管理、部署和潜在的服务间通信方面的复杂性。