我使用WCF 4.0并且从技术角度很好地了解如何构建服务.我现在已经和WCF合作了3年了. 尽管如此,我和其他人谈到了关于构成服务的软件单元应该是什么以及不应该做什么的不同观点.我与之
尽管如此,我和其他人谈到了关于构成服务的软件单元应该是什么以及不应该做什么的不同观点.我与之交谈的很多人都认为服务应该是精细的.事实上,我以前的公司花了很多时间将他们的一些大会变成了服务(所以我被告知).
在许多情况下,我无法看到服务如何更好……也许它并不总是应该如此.我举一个例子：在我们的系统中,我们有一个大型服务,它已经发展成为两个不同的独立工作.我将它分成两个服务,原因有两个：性能和故障隔离(我们在Windows服务中自托管,没有IIS).问题是,尽管提供了两个独立的业务流程(一个服务可以关闭而不影响另一个),但它们都有一大堆共同的业务逻辑.
现在有人告诉我,这个通用逻辑应该分成SOA主体下的第三个服务,并由两个新分离的服务使用.正如我所看到的,这只是部分地解除了首先拆分大型服务的好处：我们引入了性能瓶颈和单点故障.如果第3个服务的主机进程发生故障,则1和2将无法继续工作.现在我们遇到了许多服务的“深层”结构.一个人出去,任何依赖服务都会因为他们的电话永远无法应答而超链接.
现在,如果通用逻辑只是一个库而不是一个服务,我们就可以获得代码重用的好处,没有性能瓶颈和故障隔离,因为每个服务都在自己的内存中执行自己的程序集副本.此外,没有序列化开销.
人们对此有何看法？在决定什么时候应该是服务或图书馆时,是否有规则或一般准则？还有其他建议吗？
谢谢
迈克尔
然后,您可以运行多个服务来实现“核心”功能.您可以获得冗余和可靠性(如果需要,您甚至可以将流程1和2路由到单独的实例,但更愿意进行负载平衡),但您可以获得单独服务的松散耦合和可维护性.
我相信SOA是一个伟大的原则,但需要非常谨慎的架构,并且很容易出错.如果你确实弄错了,后果可能会很严重.