我正在接管一个项目，从头开始取代古老的遗留系统。在我上任之前，该公司聘请了一位顾问，他将系统的基本草图放在一起并大力推动SOA。这导致了一长串“实体服务”，其目的是将它们组合成更复杂的服务组合。例如，想要委员会信息的用户会点击“委员会”服务，该服务然后调用“人员”服务以获取其成员，并使用“会议”服务来获取其会议，等等。
我理解这方面的灵活性增加，但我关心的是性能。在我看来，为其服务构建了如此精细的粒度级别的系统在翻译服务消息时花费了太多资源，并且性能将是不可接受的。在我看来，仍然可以使用基本的可重用对象来实现灵活性增益，尽管在这种情况下，技术无关的界面的好处会丢失以获得性能。
更多背景信息：请求此软件的组织目前没有稳定的需要集成的第三方软件套件。该软件将取代所有套件。目前还没有外部消费者需要访问所提供的网站界面之外的数据 - 所有服务调用都来自我们系统内的其他部分。在这种情况下，SOA的选择似乎完全基于“准备”的概念。
所以我的问题是 - 在不牺牲性能的情况下，在稳定的服务中可接受的粒度级别是多少？我是否对我们将所有实体作为服务实施的性能命中过于怀疑？功能是否应该仅在需要时作为Web服务提供，而“准备”的重点是设计业务层，以便服务的概率随后被丢弃？
答案 0 :(得分：4)
首先，很难确定服务数量中的“甜蜜点”。太多的服务，您的集成成本受到太大影响，您的实施成本也会受到影响。你必须找到一个很好的平衡。
我建议您遵循Juval Lowy's methodology，因为您应该根据波动性或变化领域来细分您的服务。这将为您提供粒度级别。如果可以的话，你也应该read his WCF book。
至于性能，WCF本身会支持每秒数千次调用，具体取决于您的使用案例和硬件。服务呼叫服务不是问题。如果您参与其中，该平台将为您提供支持。例如，对正确的场景使用正确的绑定（命名管道在同一台机器上调用服务，TCP在可能的情况下跨机器调用服务）。您还应该在构建应用程序的其余部分之前实现应用程序的垂直切片并执行性能测试。这将验证您的架构。
答案 1 :(得分：3)
当我说“服务”时，我指的是可以执行完全独立操作的完整垂直组件。除非有特殊要求，否则我不希望更细致。在我对SOA的看法中，服务应该执行可以独立执行的有意义的业务功能。服务不应该要求其他服务来完成其功能。
答案 2 :(得分：1)
在不牺牲性能的情况下，稳定的服务可以接受什么级别的粒度？
个别实体。如顾问所述。
我是否对我们将所有实体作为服务实施的性能打击持怀疑态度？
是。太过持怀疑态度。
一个体面的框架可以优化其中一些请求，以便它们不会涉及大量的网络开销。
与SQL数据库一样，问题基本上得到了解决。您会发现您作为服务呈现的底层应用程序是瓶颈。 SOA层主要是管道。这些位仍然需要在管道中移动，SOA层比大多数替代方案更智能地组织它们。
服务是否只在需要时才实施，而“准备”的重点是设计业务层，以便服务的概率随后被丢弃？
是
这就是“敏捷”的意思。
查找用户故事。仅构建该故事的服务（和实体）。
对于前几个故事，您将获得一些重要的开销，将您的SOA框架全部平方并作为一个简单，可重复的发布步骤进行部署。
永远不要在一些不太可能的未来为你“可能”需要做的事情进行广泛的“准备”。阅读敏捷以及如何确定积压的优先顺序。