SOA - How granular should services be to maintain performance?_问答_开发者

开发者_如何学Go

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.

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".

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.

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.

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.

When I say "Service", I mean the complete vertical component that can perform a complete independent operation. And I don't prefer going in more granularity unless there is exceptional requirement. In my view of SOA, A service should perform the meaningful business function that can be independently performed. A service should not require another service to complete its function.

What level of granularity is acceptable in a stable of services without sacrificing performance?

Individual entities. As described by the consultant.

Am I being too skeptical of the performance hits we'll take implementing all our entities as services?

Yes. Way too skeptical.

A decent framework can optimize some of these requests so that they don't involve a lot of network overheads.

As with SQL databases, the problems are largely solved. You'll find that the underlying applications that you're presenting as services are the bottlenecks. The SOA layer is largely plumbing. The bits still need to move through the pipes, the SOA layer just organizes them more intelligently than most of the alternatives.

Should services only be implemented 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?

Yes.

That's what "Agile" means.

Find a user story. Build just the services (and entities) for that story.

You will have some significant overhead for the first few stories in getting your SOA framework all squared away and deployable as a simple, repeatable release step.

Never do extensive "preparation" for things you "may" need in some improbable future. Read up on Agile and how to prioritize a backlog.