9

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

我理解这样做的灵活性，但我担心的是性能。在我看来，以如此精细的服务粒度构建的系统在翻译服务消息上花费了太多资源，并且性能将无法接受。在我看来，仍然可以使用基本的可重用对象来获得灵活性增益，尽管在这种情况下，与技术无关的接口的好处会失去以获得性能。

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

所以我的问题是——在不牺牲性能的情况下，稳定的服务可以接受什么样的粒度级别？我是否对我们将所有实体实现为服务所带来的性能影响持怀疑态度？功能是否应该仅在需要时作为 Web 服务提供，而将“准备”的重点放在设计业务层上，以便以后将服务丢弃在其之上？

4

3 回答 3

4

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

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

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

于 2011-04-01T13:39:57.693 回答
3

当我说“服务”时，我是指可以执行完全独立操作的完整垂直组件。除非有特殊要求，否则我不喜欢更细化。在我对 SOA 的看法中，服务应该执行可以独立执行的有意义的业务功能。一个服务不应该需要另一个服务来完成它的功能。

于 2011-04-01T13:34:40.293 回答
1

在不牺牲性能的情况下，稳定的服务中可接受的粒度级别是多少？

个体实体。正如顾问所描述的那样。

我是否对我们将所有实体实现为服务所带来的性能影响持怀疑态度？

是的。太半信半疑了。

一个体面的框架可以优化其中的一些请求，这样它们就不会涉及很多网络开销。

与 SQL 数据库一样，问题在很大程度上得到了解决。您会发现作为服务呈现的底层应用程序是瓶颈。SOA 层主要是管道。这些位仍然需要通过管道移动，SOA 层只是比大多数替代方案更智能地组织它们。

是否应该只在需要时才实施服务，而将“准备”的重点放在设计业务层上，以便以后将服务丢弃在其之上？

是的。

这就是“敏捷”的意思。

查找用户故事。仅为该故事构建服务（和实体）。

在前几个故事中，在将 SOA 框架全部整理好并作为一个简单、可重复的发布步骤进行部署时，您将有一些重大开销。

永远不要为在某个不太可能的未来“可能”需要的东西做大量的“准备”。阅读敏捷以及如何确定积压工作的优先级。

于 2011-04-01T13:36:39.567 回答