SOA - 服务在维护性能方面应该多么精细？

Question

我正在接管一个项目,从头开始取代古老的遗留系统.在我上任之前,该公司聘请了一位顾问,他将系统的基本草图放在一起并大力推动SOA.这导致了一长串"实体服务",其目的是将它们组合成更复杂的服务组合.例如,想要委员会信息的用户会点击"委员会"服务,该服务然后调用"人员"服务以获取其成员,并使用"会议"服务来获取其会议,等等.

我理解这方面的灵活性增加,但我关心的是性能.在我看来,为其服务构建了如此精细的粒度级别的系统在翻译服务消息时花费了太多资源,并且性能将是不可接受的.在我看来,仍然可以使用基本的可重用对象来实现灵活性增益,尽管在这种情况下,技术无关的界面的好处会丢失以获得性能.

更多背景信息:请求此软件的组织目前没有稳定的需要集成的第三方软件套件.该软件将取代所有套件.目前还没有外部消费者需要访问所提供的网站界面之外的数据 - 所有服务调用都来自我们系统内的其他部分.在这种情况下,SOA的选择似乎完全基于"准备"的概念.

所以我的问题是 - 在不牺牲性能的情况下,在稳定的服务中可接受的粒度级别是多少？我是否对我们将所有实体作为服务实施的性能命中过于怀疑？功能是否应该仅在需要时作为Web服务提供,而"准备"的重点是设计业务层,以便服务的概率随后被丢弃？

Answer 1

首先，找到服务数量的“最佳点”确实很困难。服务太多，您的集成成本会受到影响；服务太少，您的实施成本也会受到影响。你必须找到一个良好的平衡点。

我给您的建议是遵循Juval Lowy 的方法，即您应该按波动区域或变化区域来分解您的服务。这将为您提供粒度级别。如果可以的话，您还应该阅读他的 WCF 书籍。

至于性能，WCF 本身将支持每秒数千次调用，具体取决于您的用例和硬件。服务调用服务是没有问题的。只要你尽自己的一份力量，平台就会支持你。例如，为正确的场景使用正确的绑定（命名管道在同一台计算机上调用服务，TCP 在可能的情况下跨计算机调用服务）。您还应该实现应用程序的垂直切片，并在构建应用程序的其余部分之前进行性能测试。这将验证您的架构。