我使用WCF 4.0，并且从技术角度了解如何构建服务。我现在和WCF一起工作了3年。
尽管我和其他人谈过，但对于构成服务的软件单元应该是什么以及什么不应该是什么，我们有不同的想法。我与之交谈的很多人都认为服务应该是精细的。事实上，我以前的公司花了很多时间将他们的一些大会变成了服务（所以我被告知）。
在很多情况下，我看不出服务如何更好......也许并不总是这样。我举一个例子：在我们的系统中，我们有一个大型服务，它已经发展成为两个不同的独立工作。我将它分成两个服务，原因有两个：性能和故障隔离（我们在Windows服务中自托管，没有IIS）。问题是，尽管提供了两个独立的业务流程（一个服务可以关闭而不影响另一个），但两者都有相当大的共同业务逻辑。
现在有人告诉我，这个通用逻辑应该分成SOA主体下的第三个服务，并由两个新分离的服务使用。正如我所看到的，这只是部分地解除了首先拆分大型服务的好处：我们引入了性能瓶颈和单点故障。如果第3个服务的主机进程发生故障，则1和2将无法继续工作。现在我们遇到了许多服务的“深层”结构。一个人熄火，任何相关的服务都会因为他们的电话从未被应答而超时。
现在，如果通用逻辑只是一个库而不是一个服务，我们就可以获得代码重用的好处，没有性能瓶颈和故障隔离，因为每个服务都在自己的内存中执行自己的程序集副本。此外，没有序列化开销。
人们对此有何看法？在决定什么时候应该是服务或图书馆时，是否有规则或一般准则？还有其他建议吗？
由于 迈克尔
答案 0 :(得分：4)
这是反对使用服务的公平论据，但正确的方法可能是使用服务总线。
然后，您可以运行多项服务来实现“核心”功能。您可以获得冗余和可靠性（如果需要，您甚至可以将流程1和2路由到单独的实例，但更愿意进行负载平衡），但您可以获得单独服务的松散耦合和可维护性。
我相信SOA是一个很好的原则，但需要非常谨慎的架构，并且很容易出错。如果你确实弄错了，那么后果可能是可怕的。
答案 1 :(得分：2)
在衡量图书馆或服务是否是针对特定问题的更好方法时，我可能有两个关键考虑因素。
首先是潜在的消费者：如果他们完全在你的控制范围内，并且在过程中托管它们是可行的，那么图书馆将是一种合法的方法。如果不存在外部消耗的可能性，那么这可能是更好的选择，因为设计，开发和测试工作可能远远低于同等服务。
其次是API的“粒度”。需要对服务进行架构以减少“烦躁” - 良好的服务往往具有强大的操作，其行为根据消息内容进行调整。例如。 Addorder（msg）vs CreateHeader（h），GetCustomer（c），AddOrderCustomer（h，c），AddOrderLine（p，1）等。前者是我对服务操作的期望，而后者更典型图书馆。如果问题不适合那种风格的API，或者你不能投入必要的努力来使设计正确，那么库就更合适了。