将WCF服务拆分为单独的，更具凝聚力的服务是一个好主意吗？

Question

我在WCF服务（或多个服务）中需要实现许多不同的功能单元。 令我惊讶的是，将这些部门拆分为自己的服务有许多优势：

• 松耦合
• 可能更强大-一个人的失败无法消除一切
• 长期可扩展性

但是有成本：

• 更多管理
• 运行附加服务的开销

我对最近的费用特别感兴趣。 运行两个服务的开销是否超过那些服务较小（例如，两个或三个非常轻的操作）的收益？

如果将它们分开是一个好主意，那么我应该在哪条线上进行划分？ 我可以严格按功能，按其InstanceMode或按其托管类型（IIS v Windows）划分服务。 是否有适用的一般方法或建议集？

感谢任何建议。

Answer 1

拆分为多个服务并不一定意味着它拆分成多个应用程序。
但是您也可能要获得鲁棒性和可伸缩性。

因此，是的，请将它们分成最小的内聚单元。
最好早点做，分解现有服务会更加复杂。

---

额外

您应该按功能分类，这仅意味着定义多个[ServiceContract]定义。

您只需要按托管类型（IIS / WinService）进行分隔即可。

这留下了一个问题，即多个服务（例如IIS上）是否应为1个应用程序，共享数据层等。这具有一些短期利益，紧密结合的服务可能应该合并。

但总的来说，创建单独的应用程序可提供最佳的可伸缩性和可用性，以及更好的更改选项。

Answer 2

像所有事物一样，这取决于。 就诸如appfabric之类的东西而言，您可以轻松地扩展服务并使用IIS和Windows来增强鲁棒性。

确保较小的表面积是好的，但是除非有能证明您需要的度量标准，否则为什么要打扰呢。 首先使用WCF基础结构。