有多少个Web服务？

Question

我有一个类似于以下结构的 web 服务：

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

换句话说，它包含在一个类中，在这个类中，我有一个公共方法和另一个私有方法，该方法对数据库进行读取。

我面临的问题是可伸缩性。我正在构建一个Web应用程序，应该适用于每天1,000个用户，并且每个用户每天将进行约300-500次对Web服务的调用，因此每天大约有300,000到500,000个请求。我需要向Web服务添加9个更多的调用。其中一些调用将涉及数据库写入。

我的问题是：我最好创建9个单独的Web服务还是继续使用我已经拥有的一个服务并添加其他方法。或者也许是不同和更好的东西。我计划在Azure上部署应用程序，因此我真正关心的是应用程序方面，而不是硬件方面。

- frenchie

Answer 1

实际上，像Igorek建议的那样创建单独的Web服务将提供更细粒度的扩展。在这种情况下，您可以将不同的Web服务部署到不同的角色中，每个角色都有自己的一组实例（以及为每个角色创建不同实例大小的选项）。Windows Azure将在一个角色的所有实例之间进行负载均衡。

因此，从粒度的角度来看：

- 最不精细：将所有方法合并到单个Web服务中，托管在单个角色上。随着您扩展到多个实例，所有服务方法请求都会在所有实例之间进行负载平衡。由于您将所有内容合并到一个角色中，因此您会发现这对成本进行了优化：您可以在单个实例中运行所有Web服务代码（真正的应用程序需要2个实例以获得SLA）。 - 更加精细：创建单独的Web服务，每个服务具有自己的方法，并在同一角色上托管（允许您执行Merlyn描述的SOLID原则）。与第一个选项具有相同的基本性能特征，因为所有请求仍然在同一组实例之间进行负载平衡。 - 最精细：创建单独的Web服务，每个服务具有自己的方法，并将每个Web服务端点托管在单独的角色上，从而允许每个Web服务端点进行独立的VM大小和扩展。这个选项具有更高的运行时成本，因为现在每个Web服务端点至少需要一个实例（在真实世界的应用程序中需要2个实例）。

- David Makogon

Answer 2

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

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

我不知道是否与此问题相关，但只是想让您知道-Azure会断开60秒内未活动的连接（我没有找到一些方法来增加超时时间，您可以Google此问题）。如果您正在将Web服务移植到Azure并且您的响应可能需要60秒，则可能会出现问题。避免它的一种方法是保持连接活动，如果客户端知道这个“特性”，那就很简单。

- Ivan Sokalskiy

---

好的，谢谢您提供的信息；我不认为我有任何超过60秒的任务，但了解这一点总是很好的。 - frenchie

Answer 3

将网络方法拆分为多个Web服务在这里不会有所帮助；负载平衡将是解决方案。

- Icarus

---

@frenchie：确切地说，拆分Web方法不会有任何区别。 - Icarus

@Icarus - 在不同的角色上运行不同的Web服务端点可以实现独立的扩展，正如Igorek所建议的那样。 - David Makogon

Answer 4

我不会基于服务数量或性能/可伸缩性原因来做出决策。将它们放在一起或分开不会带来多少性能收益。任何分组或筛选操作在服务分组方式改变后仍然可以完成。在服务器之间的划分能力也是相同的。

设计方面，我建议您关注代码的易懂性和可维护性。按照程序中最合理的架构将服务进行逻辑分组，从问题域的角度而非解决方案域的角度考虑如何将它们逻辑分组。

由于您可以自由地对它们进行分组，我建议您阅读SOLID，这是一组创建软件架构的指导原则。其中特别重要的原则之一是接口隔离原则，其定义为“许多客户端特定接口比一个通用接口更好”。

在性能和可伸缩性方面，请确保您的服务具有良好的负载平衡，并根据需要进行扩展。

由于您提到性能和可扩展性是一个问题，我建议您遵循这个计划：

• 确定您可以等待多长时间才能修补/维护软件
• 确定您的预期负载，包括平均每时间段的负载和峰值负载，并确定您预计在没有修补/维护软件的情况下，这些流量将在多长时间内增长
• 创建一个模型，描述要执行哪些调用以及以哪些比例（每时间段和每台服务器）进行调用
• 创建自动化程序，尽可能精确地模拟这些模型。 尝试对平均流量和峰值流量进行建模，并超越您的最高规模流量
• 在运行此自动化程序时对您的代码、数据库、网络流量和磁盘流量进行分析
• 确定瓶颈所在，并确定其是否在可接受的容忍度范围内
• 优化您的瓶颈（如有必要），并从分析步骤开始重复操作
• 在您的软件的下一个版本中，从头开始添加场景/负载/自动化程序
• 使用现有测试进行回归测试，改为适应新的规模

- Merlyn Morgan-Graham

---

好的，很酷；不是拆分或组合方法会有所区别，但我仍然会将它们拆分，只是为了让它看起来漂亮。谢谢。 - frenchie

Answer 5

网页服务的数量对应用程序的可扩展性没有任何影响。

找到瓶颈将有助于扩展性。如果您的瓶颈是数据库，您可能需要找到调整查询、将数据分区到更多存储等方法。如果您的瓶颈是Web服务上的CPU（Azure中的Web角色），那么将多个Web角色添加到集群中将有所帮助。Azure支持这样做。

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

Azure还有devfabric和IIS本地工具来帮助您进行本地分析。

- bryanmac

Answer 6

基于物理限制而不是逻辑布局，将web服务拆分为多个web角色可能值得考虑，原因如下:

使用Azure，您可以独立地扩展每个角色。这意味着，如果不同的Web方法需要按不同的模式扩展（例如：您的第一个Web方法在早上和午餐后有最大量，而其他两个Web方法在晚上和夜间有最大量），而后两个Web方法在一天中通常保持不变，那么根据可扩展性约束而不是逻辑约束来拆分您的方法非常值得考虑。

通过独立增加/减少分配给每个方法的服务器，您可能能够更加精确地调整功率和需求之间的最佳平衡。

希望对你有所帮助。

- Igorek