我正在接管一个项目,从头开始取代古老的遗留系统.在我上任之前,该公司聘请了一位顾问,他将系统的基本草图放在一起并大力推动SOA.这导致了一长串“实体服务”,其目的是将它们组合成更复杂的服务组合.例如,想要委员会信息的用户会点击“委员会”服务,该服务然后调用“人员”服务以获得其成员,并使用“会议”服务来获取其会议,等等.
我理解这方面的灵活性增加,但我关心的是性能.在我看来,为其服务构建了如此精细的粒度级别的系统在翻译服务消息上花费了太多资源,并且性能将是不可接受的.在我看来,仍然可以使用基本的可重用对象来实现灵活性增益,尽管在这种情况下,技术无关的界面的好处会丢失以获得性能.
更多背景信息：请求此软件的组织目前没有稳定的需要集成的第三方软件套件.该软件将取代所有套件.目前还没有外部消费者需要在提供的网站界面之外访问数据 – 所有服务调用都来自我们系统内的其他部分.在这种情况下,SOA的选择似乎完全基于“准备”的概念.
所以我的问题是 – 在不牺牲性能的情况下,在稳定的服务中可接受的粒度级别是多少？我是否对我们将所有实体作为服务实施的性能命中过于怀疑？功能是否应该仅在需要时作为Web服务提供,而“准备”的重点是设计业务层,以便服务的概率随后被丢弃？
解决方法
首先,很难找到服务数量的“甜蜜点”.太多的服务,您的集成成本受损,太少,您的实施成本受到影响.你必须找到一个很好的平衡.
我给你的建议是遵循Juval Lowy’s methodology,因为你应该根据波动性或变化领域来分解你的服务.这将为您提供粒度级别.如果可以,你也应该read his WCF book.
至于性能,WCF本身就会支持每秒数千次调用,具体取决于您的使用案例和硬件.服务呼叫服务不是问题.如果您参与其中,该平台将为您提供支持.例如,对正确的方案使用正确的绑定(命名管道在同一台机器上调用服务,TCP用于在可能的情况下跨机器调用服务).您还应该在构建应用程序的其余部分之前实现应用程序的垂直切片并执行性能测试.这将验证您的架构.
