wcf - SOA:库与服务:库是更好的选择吗？

Question

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

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

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

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

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

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

谢谢
迈克尔

Answer 1

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

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

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