把一个WCF服务分解成独立的、更有凝聚力的服务是个好主意吗?
本文关键字：服务 好主意 凝聚力 一个 WCF 分解 独立 | 更新日期: 2023-09-27 18:06:36
我有许多不同的功能单元需要在一个(或多个)WCF服务中实现。我突然意识到，将这些单元拆分为各自的服务有很多好处:
- 可能更健壮-一个故障不能使所有
- 长期可扩展性
但这是有代价的:
- 更多管理
- 运行附加服务的开销
我对最后的成本特别感兴趣。运行两个服务的开销是否大于这些服务较小(比如两个或三个非常轻的操作)的好处?
如果把它们分开是一个好主意，我应该在哪些方面进行分割?我可以严格按照功能，或者它们的InstanceMode，或者它们的托管类型(IIS vs Windows)来拆分服务。这里是否有适用的通用方法或建议?
感谢您的建议
将其拆分为多个服务并不一定意味着将其拆分为多个应用程序。
但是，为了获得健壮性和可伸缩性，您不妨这样做。
所以，是的，把它们分成最小的内聚单位。
最好尽早这么做，因为拆分现有的服务会复杂得多。
另外
您应该按功能划分，这意味着定义多个[ServiceContract]定义。
你只需要按主机类型(IIS/WinService)分开。
这就留下了一个问题:多个服务(例如IIS)是否应该是一个应用程序，共享数据层等。这有一些短期的好处，紧密结合的服务可能应该合并。但总的来说，创建独立的应用程序提供了最好的可扩展性和可用性，以及更好的更改选项。
看情况而定。就我个人而言，像appfabric这样的东西，你可以很容易地扩展服务，并使用IIS和Windows来帮助实现健壮性。
当然，较小的表面积是好的，但除非有指标证明你需要它，否则为什么要麻烦呢?首先使用WCF基础结构