一个大型网络服务还是许多小型网络服务？答案

【问题标题】：One big webservice or lots of little ones?一个大型网络服务还是许多小型网络服务？
【发布时间】：2009-12-18 17:48:25
【问题描述】：

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

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

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

【问题讨论】：

如果您正在寻找一个术语来描述单个 Web 服务产品随时间的无序扩展：Shawn Wildermuth 在 .NET Rocks 的第 497 集中提到了“方法污染”（参见第 17 页）转录@@goo.gl/JyEn)。
谢谢兰斯，我会检查一下。

【解决方案1】：

深思熟虑：细粒度有利于更多控制，但它确实有相关的性能损失。如果你过于细化，你最终可能会得到一个需要多次网络往返来做任何不平凡的事情的 API。因此，在设计服务时，我会牢记网络往返和延迟。如果该服务可能位于 WAN 上，我会避免制作“闲聊”界面，而是选择返回更多数据的方法。

例如，如果大部分时间用户和调用者都需要订单历史记录。您需要考虑将如何使用该服务，并相应地考虑您的接口。

【讨论】：

【解决方案2】：

一个大
优点：

缺点：

很多小的
优点：

缺点：

我的建议是查看服务的逻辑包。客户可能会使用您的部分服务还是全部？是否存在需要使用服务#1 的一半和服务#2 的一半的情况？试着弄清楚常见的场景是什么，并设计您的服务，以便他们只需要创建一个代理即可工作。

【讨论】：

像 Randy Minder 一样，我们实现了许多较小的服务，这些服务在整个应用程序中扮演着非常不同的角色。我们遇到了您描述的确切场景：我们可以轻松独立地维护它们，但是将它们打包并让它们相互同步是一个问题。有很多复制/粘贴滥用来绕过读取配置值等常见功能，但我们正在积极努力将其隔离到共享程序集。我仍然认为这是正确的方法。
现在有了Docker或者Rocket，看来他们可以提供必要的工具来避免服务碎片化导致的配置混乱。还要检查 docker-compose。

【解决方案3】：

几年前我们不得不做出同样的决定。我们采用了非常精细的方法。它为我们服务得很好。它使我们能够将 Web 服务变成某种 API。这不是我们的初衷，但对我们来说效果很好。

兰迪

【讨论】：

【解决方案4】：

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

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

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

2) 你期望什么样的负载？您真的可以期望一台服务器在未来几年内处理所有服务的负载吗？如果没有，最好现在将它们分开。

【讨论】：