Question

我有一个看起来像这样的网络服务：

public class TheService : System.Web.Services.WebService
{
  [WebMethod(EnableSession = true)]
  public string GetData(string Param1, string Param2) { ... }
}

换句话说，它包含在一个类中，在那里，我有一个公共方法，还有另一个私有方法可以读取数据库。

我面临的问题是可扩展性。我正在构建一个应该适用于每日1,000个用户的Web应用程序，每个用户每天将对Web服务执行大约300-500个呼叫，因此每天大约需要300,000到500,000个请求。我需要再向Web服务添加9个调用。其中一些调用将涉及数据库写入。

我的问题是：我最好创建9个单独的Web服务，或继续使用我提供的一项服务并添加其他方法。或者可能是不同的，更好的。我打算在Azure上部署应用程序，所以我并不真正关心硬件，只关注应用程序方面。

Answer 1

将Web方法拆分为多个Web服务对您没有帮助;负载均衡会。

Answer 2

我不会根据卷或出于性能/可伸缩性原因做出决定。如果通过将它们集中在一起或将它们分开来获得任何性能上的好处，您将无法获得太多好处在以一种方式对服务进行分组时可以执行的任何分组或过滤也可以使用以其他方式分组的服务来完成。在服务器之间进行分区的能力也是一样的。

<强>设计

相反，我会专注于尝试使您的代码易于理解和维护。将您的服务分组，使其在您的计划中在建筑上最有意义。从问题域的角度（而不是解决方案域的角度），将它们按逻辑分组，使它们最有意义地进行分组。

由于您可以随意对其进行分组，因此我建议您阅读SOLID，这是一套创建软件架构的指导原则。

列出的一项特别重要的原则是Interface Segregation Principle，可由the notion that "many client specific interfaces are better than one general purpose interface."定义

性能和可扩展性

由于您提到性能和可伸缩性是一个问题，我建议您遵循此计划：

确定您可以等到修补/维护软件的时间，
确定您的预期负载，包括平均和峰值每次负载（您已确定平均值），以及您希望此流量随时间增长的程度（特别是在没有修补/维护的情况下您可以继续增加的时间）软件）
创建一个模型，准确描述将要完成的调用以及比率（每个时间和每个服务器）
创建尽可能接近镜像这些模型的自动化。尝试对平均流量和峰值流量进行建模，并超越最高流量的流量
在运行此自动化时配置您的代码，数据库，网络流量和磁盘流量
确定瓶颈，以及它们是否在可接受的容差范围内
优化您的瓶颈（根据需要），并从分析步骤重复
您的软件的下一个版本，从顶部重复添加方案/加载/自动化
使用现有测试执行回归测试，并根据新比例进行修改

Answer 3

Web服务的数量不会对应用程序的可伸缩性产生任何影响。

找到瓶颈将有助于扩展。如果您的瓶颈是数据库，您可能需要找到调整查询的方法，将数据划分到更多的商店等等......如果您的瓶颈是Web服务上的CPU（天蓝色的Web角色），那么向群集添加多个Web角色将有所帮助。 Azure支持。

但是，只是不要开始添加角色。了解您的瓶颈所在。测量，分析和调整。

Azure本地具有devfabric和IIS，以帮助您在本地进行分析。

Answer 4

由于物理限制而不一定由于逻辑布局而将Web服务拆分为多个Web角色可能值得考虑因为：

使用Azure，您可以相互独立地扩展角色。这意味着，如果不同的网络方法需要以不同的模式进行扩展（即：您的第一个网络方法在早上和午餐后具有最大的音量，而您的其他两种网络方法在晚上和夜间具有最大音量），并且最后2个Web方法通常是全天都是平的，很可能值得通过可伸缩性约束而不是逻辑约束来跨Roles分割方法。

通过增加/减少分配给每种方法的服务器，您可以以更高的精度微调最佳功率与需求。

HTH

Answer 5

实际上，正如Igorek所建议的那样，创建单独的Web服务将提供更精细的横向扩展。在该场景中，您可以将不同的Web服务部署到不同的角色，每个角色都有自己的实例集（以及为每个角色创建不同实例大小的选项）。 Windows Azure将在角色的所有实例之间进行负载平衡。

从粒度角度来看：

最小粒度：将所有方法合并到一个Web服务中，托管在单个角色上。当您扩展到多个实例时，所有服务方法请求都在所有实例之间进行负载平衡。因为您将所有内容组合到一个角色中，您会发现这是针对成本进行优化的：您可以在单个实例中运行所有Web服务代码（实际上是2个实例，以便为自己提供SLA）。
更细化：创建单独的Web服务，每个Web服务都有自己的方法，并且托管在同一个角色上（允许您按照Merlyn的描述练习SOLID原则）。与第一个选项具有相同的基本性能特征，因为所有请求仍在同一组实例中进行负载平衡。
最精细：创建单独的Web服务，每个Web服务都有自己的方法，并在单独的角色上托管每个Web服务端点，从而允许每个Web服务端点的独立VM大小调整和横向扩展。此选项的运行时成本较高，因为现在每个Web Service端点至少有一个实例（同样，现实世界中的2个实例，实时应用程序）。

Answer 6

我不确定您的情况，但是将昂贵的（从CPU / DB的角度来看）任务转移到单独的Worker Role通常是Azure的良好解决方案。在这种情况下，您将拥有一个WebRole，其服务将接收请求（它将是轻量级的，因此您不会有很多实例）并为Worker Roles创建任务以及将处理该任务的一个或几个Worker角色 - ＃ 1可以为每种任务创建工作者角色（将类似的操作分组，如向DB读取/写入数据）或＃2一个工作者角色可以处理任何类型的任务。我没有看到＃2中的任何好处，因为要获得相同的行为，您可以创建一个包含许多实例的WebRole并处理所有实例。因此，您可以通过添加/删除工作者角色来控制处理时间。

正如其他人所建议的那样 - 使用Azure平台本身不会使应用程序可扩展，特别是如果您使用的是SQL Azure，则需要实现分片或添加许多DB来避免所有请求都有一个大数据库。

我不知道这是否与此任务有关，但只是为了让你知道 - Azure正在丢弃在60秒内未激活的连接（我没有找到某种方法来增加超时，你可以谷歌这个问题）。这可能是一个问题，您是将Web服务移植到Azure，您的响应可以达到60秒。避免它的一种方法是保持连接活动，如果客户知道这个“功能”，这很简单。

有多少网络服务

6 个答案: