我已经开发.Net Web API很多年了......通常我有一个API，它有10个左右不同的控制器，它们处理从注册用户、处理业务逻辑、支付等所有事情。这些都与类库、数据库等通信。没有什么花哨的，但它一直很有效。
快进到今天...我正在为一个获得大量流量的应用程序构建第2版。我知道我的应用程序会受到重创，所以我正在寻找一个具有效率和规模基础的东西。
这让我接受了Service Fabric和ASP.NET Core Web API的酷。我已经阅读了大量的教程、文章和其他问题，据我所知，Service Fabric的美妙之处在于，当事情变得忙碌时，它会在单个VM中产生多个节点。
因此，如果我保持正常模式，并使用10个以上的控制器创建单个Web API，Service Fabric是否可以完成它需要完成的工作？或者我是否应该创建多个更专注的小型API，以便Service Fabric可以在工作忙碌时添加/删除它们？
这听起来像是正确的事情，我已经设置了我的代码，通过把我的模型和数据类放在它们自己的类库中，这样它们就可以被不同的API重用，但我只是想在我做一些潜在的愚蠢之前仔细检查一下。
如果我将每个控制器拆分为自己的服务结构服务，Azure服务器是否会更高效、更好地扩展？
2条答案
按热度按时间fd3cxomn1#
在Service Fabric群集中（在Azure/单机上），一个节点等于一个VM。如果增加计算机数量，则群集中会出现更多节点。（本地开发群集并非如此。）Azure群集中的扩展非常简单：只需更改VMSS示例计数。
仅当配置示例计数为-1的无状态服务时，服务结构才会生成其新示例。这是由于添加节点而不是负载本身造成的。可以为VMSS配置autoscaling。
Service Fabric只是尝试在可用资源上平衡所有正在运行的SF Services的负载。这可能是每个节点上一种服务类型的一个示例，也可能是多种类型的多个示例。因此，一个服务可以只使用其运行节点的所有资源，就像IIS一样。（这就是为什么容器支持会顺便到来。）
Web API设计不受Service Fabric的直接影响。在IIS或其他地方运行时适用相同的规则。这实际上是您的选择。
您的常规模式将起作用。但是从它创建更小的服务可以帮助减少更改的影响。（以增加复杂性为代价。）考虑创建遵循Microservices范例提供通用功能的服务。
在微服务中，你的代码修改只涉及到更小的模块，需要更少的测试，在更新过程中性能下降更少，这样，理论上你可以在更短的时间内发布新的特性。
9jyewag02#
这要看情况。
如果你的控制器有一个关于资源使用的自然划分，那么如果你沿着这个划分线分割你的服务，你可能会得到一些好处。假设服务A使用大量的CPU，服务B主要使用HTTP，那么让SF能够自己分割CPU负载可能意味着更少的HTTP调用受到影响。
您可以从应用内部优化SF如何通过reporting load分配负载，但要以尽可能简单的方式进行，并且不要添加大量维度，最多可能每个服务一个维度。
如果所有的控制器使用相同类型的资源，并且大致相同，那么将它们拆分到单独的服务中并没有真正的好处，只会使代码管理、部署和潜在的服务间通信变得复杂。