SOA：库与服务：库是更好的选择吗？

Question

我使用 WCF 4.0，并且对如何从技术角度构建服务有很好的了解。我已经在 WCF 工作了 3 年了。

尽管如此，我和其他与我交谈的人对于什么应该是构成服务的软件单元以及什么不应该有不同的想法。与我交谈过的许多人都认为服务应该是细化的。事实上，我以前的公司花了很多时间将他们的一些装配转变为服务（有人告诉我）。

在许多情况下，我看不出一项服务如何更好......也许并不总是应该如此。我给你举个例子：在我们的系统中，我们有一个大型服务，它确实已经发展到可以执行两种不同的独立工作。我将把它分成两个服务有两个原因：性能和故障隔离（我们自己托管在 Windows 服务中，没有 IIS）。问题是，尽管服务于两个独立的业务流程（一个服务可以关闭而不影响另一个），但两者都有相当多的共同业务逻辑。

现在有人建议我，这个通用逻辑应该被分离到 SOA 主体下的第三个服务中，并由两个新拆分的服务使用。在我看来，这只是部分抵消了拆分大服务的好处：我们引入了性能瓶颈和单点故障。如果第三个服务的宿主进程宕机了，那么 1 和 2 就不能再做它们的工作了。这种情况现在发生在我们身上，我们拥有许多服务的“深层”结构。一个出去，链上的任何依赖服务都超时，因为它们的呼叫永远不会得到应答。

现在，如果通用逻辑只是一个库而不是服务，我们将受益于代码重用、没有性能瓶颈和故障隔离，因为每个服务都在自己的内存中执行自己的程序集副本。也没有序列化开销。

人们对此有何看法？在决定什么时候应该是服务或图书馆时，是否有规则或一般准则？还有其他建议吗？

谢谢 迈克尔

Answer 1

这是一个反对使用服务的公平论据，但正确的方法可能是使用服务总线。

然后您可以运行多个服务来实现您的“核心”功能。您可以获得冗余和可靠性（如果需要，您甚至可以将流程 1 和 2 路由到单独的实例，但更喜欢负载平衡），但您可以获得单独服务的松散耦合和可维护性。

我认为 SOA 是一个伟大的原则，但需要非常仔细的架构，并且很容易出错。如果你确实弄错了，那么后果可能很可怕。

Answer 2

在权衡图书馆或服务是否可能是解决给定问题的更好方法时，我可能有两个关键考虑因素。

首先是潜在的消费者：如果他们将完全在您的控制范围内并且可以在进程内托管他们是可行的，那么库将是一种合法的方法。如果没有外部消费的可能性，那么这可能是更好的选择，因为设计、开发和测试工作可能会大大少于同等服务。

其次是 API 的“粒度”。需要对服务进行架构以减少“喋喋不休”——一个好的服务往往具有强大的操作，其行为会根据消息内容进行调整。例如。 Addorder(msg) vs CreateHeader(h), GetCustomer(c), AddOrderCustomer(h,c), AddOrderLine(p,1) 等。前者是我对服务操作的期望，而后者更典型的图书馆。如果问题不适合这种 API 风格，或者您无法投入必要的精力来正确设计，那么库会更合适。