SOA - 服务应该多细化才能保持性能? [英] SOA - How granular should services be to maintain performance?

问题描述

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

I am taking over a project to replace an ancient legacy system from the ground up. Before I came on, the company hired a consultant who put together a basic sketch of the system and pushed SOA heavily. This resulted in a long list of "entity services", with the intention of them being composed into more complex service combinations. For instance, a user wanting committee info would hit the "Committee" service, which then calls the "Person" service to get its members, and the "Meeting" service to get its meetings, and so on.

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

I understand the flexibility gains in this, but my concerns are about performance. It seems to me that a system built with such a fine level of granularity to its services spends too many resources on translating service messages, and the performance will be unacceptable. It also seems to me that the flexibility gains can still be made using basic reusable objects, although in that case the benefit of a technology-agnostic interface is lost to gain performance.

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

For more background: The organization requesting this software does not currently have a stable of third-party software suites that need integrating with. This software will replace all suites. There are also currently no outside consumers who need to access the data outside of the provided website interface -- all service calls will be from other pieces inside our system. The choice of SOA in this case seems entirely based on the concept of "preparation".

所以我的问题是——在不牺牲性能的情况下，稳定的服务中可接受的粒度级别是多少?我是否对我们将所有实体实现为服务所带来的性能影响过于怀疑?是否应该仅在需要时才将功能作为 Web 服务提供，而将准备"重点放在设计业务层，以防止以后将服务置于其上的可能性?

So my question -- what level of granularity is acceptable in a stable of services without sacrificing performance? Am I being too skeptical of the performance hits we'll take implementing all our entities as services? Should functionality be available as web services only when they are needed, with the "preparation" focus instead going into designing the business layer for the probability of services later being dropped on top of it?

推荐答案

首先，在服务数量中找到甜蜜点"肯定是困难的.服务太多，您的集成成本会受到影响；太少，您的实施成本会受到影响.你必须找到一个很好的平衡点.

First off, finding the "sweet spot" in the number of services is difficult for sure. Too many services, and your integration costs suffer, too few, and your implementation costs suffer. You have to find a good balance.

我给你的建议是遵循 Juval Lowy 的方法，因为你应该打破按波动领域或变化领域降低您的服务.这将为您提供粒度级别.如果可以，您还应该阅读他的 WCF 书籍.

My advice to you is to follow Juval Lowy's methodology in that you should break down your services by areas of volatility, or areas of change. This will give you your granularity level. You should also read his WCF book if you can.

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

As for the performance, WCF will inherently support many thousands of calls per second depending on your use cases and hardware. Services calling services is not a problem. The platform will support it if you do your part. For example, use the right binding for the right scenario (named pipes to call services on the same machine and TCP to call services across machine where possible). You should also implement a vertical slice of the application and do performance testing before building the rest of the application. This will verify your architecture.

这篇关于SOA - 服务应该多细化才能保持性能?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！