我多年来一直在构建.Net Web API ...通常我有一个API，它有10个左右的不同控制器，可以处理从签署用户，处理业务逻辑，付款等所有事情。这些都与类库有关与数据库等交谈。没什么特别的，但它一直很有效。
快进到今天......我正在为获得大量流量的应用构建版本2。我知道我的应用程序会受到重创，所以我正在寻找具有效率和规模基础的东西。
这使我接受了Service Fabric和ASP.Net Core Web API的酷感。我一直在阅读大量的教程，文章和SO问题，据我所知，Service Fabric的优点在于，当事情变得繁忙时，它会在单个虚拟机中产生多个节点。
因此，如果我维护我的正常模式并使用10多个控制器创建一个Web API，那么Service Fabric可以做它需要做的事情吗？或者我应该创建多个更集中的小API，以便Service Fabric可以在忙碌时添加/删除它们？
这听起来是正确的事情，我已经设置了我的代码，通过将我的模型和数据类放在他们自己的类库中，以便它们可以被不同的API重用，但我只是想在我做一些可能愚蠢的事情之前仔细检查。
如果我分手，将每个控制器都说成自己的Service Fabric服务，那么Azure服务器是否会更有效率和更好地扩展？
谢谢！
答案 0 :(得分：1)
<强>节点
在Service Fabric群集中（在Azure /独立站点上），节点等于VM。如果增加计算机数量，则会在群集中显示更多节点。 （本地开发群集不是这种情况。）Azure群集中的扩展很简单：只需更改VMSS实例计数。
仅当您使用实例计数-1配置无状态服务时，Service Fabric才会生成它的新实例。这是由添加节点引起的，而不是由加载本身引起的。 您可以为VMSS配置autoscaling。
Web API
Service Fabric只是尝试在可用资源之间平衡所有正在运行的SF服务的负载。这可以是每个节点上的一个服务类型的一个实例，或者是多个类型的多个实例。因此，一个服务可以使用它运行的节点的所有资源，就像使用IIS一样。 （这就是容器支持即将到来的原因。）
Web API设计不受Service Fabric的直接影响。适用的规则与在IIS或其他地方运行时相同。这真的是你的选择。
<强>微服务
您的正常模式将起作用。但是，从中提供更小的服务可以帮助减少变化的影响。 （以增加复杂性为代价。）考虑创建在Microservices范例之后提供通用功能的服务。
在微服务中，您的代码更改范围限定为较小的模块，需要的测试较少，更新期间性能降低较少。这样，理论上，您可以在更短的时间内发布新功能。
答案 1 :(得分：1)
取决于。
如果您的控制器对其使用的资源进行了自然划分，那么如果您沿着该划分线拆分服务，您可能会获得一些好处。假设服务A使用大量CPU，而服务B主要使用HTTP，那么SF能够自行拆分CPU负载，这意味着可以减少受影响的HTTP呼叫。
您可以优化SF从应用内部按reporting load分配负载的方式，但是以最简单的方式进行，并且不要添加多个维度，最多可能每个服务一个维度。
如果您的所有控制器使用大致相同的相同类型的资源，那么将它们分离到单独的服务中并没有什么好处，只是代码管理，部署和潜在的服务间通信的复杂性。