一个很大的网络服务或许多小网站？

Question

我正在构建一组方法来为许多不同的Web应用程序提供功能，这些方法基本上从SQL中获取一些数据，然后将其传递回调用应用程序。它们必须通过Web服务实现。

所以我的问题是用大量方法创建一个大规模的Web服务或者将这些方法划分为逻辑组并将每个方法包含在他们自己的Web服务中之间的优缺点是什么。我认为在第一个版本之后会有很多后续方法实现，所以无论我做什么都必须易于维护。

如果它对我使用.Net 3.5，C＃的答案有任何影响，目前无法使用WCF。

Answer 1

一些值得思考的东西：粒度有助于更多控制，但它确实会带来相关的性能损失。如果你过于粒度，你最终可能会得到一个API，需要多次网络往返才能做任何非平凡的事情。因此，在设计服务时，我会考虑网络往返和延迟。如果该服务可能位于WAN上，我将避免使用“聊天”界面并寻找返回更多数据的方法。

例如，更喜欢检索整个用户加上他们的订单历史记录，而不是对用户数据进行一次不同的调用，并且如果大多数时间是用户和调用者都需要订单历史记录。您需要考虑如何使用该服务，并相应地考虑您的接口。

Answer 2

一个大
优点：

• 无需维护大量服务引用。
• 可以更容易找到您要找的内容，并获得概述。

缺点：

• 如果您更新了1个签名，客户端将需要添加那个巨大的（？）引用并重新读取WSDL。
• 如果有很多客户在场，就很难委派工作。

Lotsa small
优点：

• 易于维护。签名的一个变化是客户的一个小变化。

• 更容易使用不同的主机。

缺点：

• 很容易变得一团糟。

我的建议是查看服务的逻辑包。客户是否可能使用您的部分服务或全部服务？是否有任何情况需要使用服务＃1的一半和服务＃2的一半？试着弄清楚常见的场景是什么，并设计你的服务，这样他们只需创建一个代理就可以了。

Answer 3

几年前我们不得不做出同样的决定。我们采用了非常精细的方法。它非常适合我们。它允许我们将webservices变成各种API。这不是我们原来的意图，但对我们来说效果非常好。

兰迪

Answer 4

将它们分成单独的服务的好处是，如果您开始遇到性能问题，您可以随时将各个服务移动到不同的服务器上。

将它们放在一个大服务中的优点是某些代码（例如，从文件中读取配置信息）在所有服务中都是相同的，如果它们都在一个服务中，您可以重新使用代码（您也可以将重复使用的代码放在单独的类库中。）

你可以为这两种情况提出论据。我最大的两个问题是： 1）服务是否相关？将它们组合在一起是否有意义，或者您只是为了方便将它们组合在一起？如果它们相关，那么将它们组合起来可能是有意义的。

2）您期望什么样的负荷？您能否真实地期望一台服务器在接下来的几年内处理所有服务的负载？如果没有，现在最好将它们分开。