我读过很多关于Web服务方面的参考文献，文章中都强调设计服务的粒度是如何的重要，确实是这样的。但是实际上，针对如何使粒度合适，这些参考文献并没有提出任何有用的建议。虽然这个问题可能没有完美的答案,因为至今也没有一本指导书可以使你做到确保粒度时时刻刻保持最优，但是下面的这些分析也许可以给你很大的帮助。

　　你可以从以下三个关键方面来考虑粒度问题:

　　性能和规模
　　事务处理和状态
　　商业适应性

　　性能和规模

　　Web服务可以通过远程进行访问。这意味着需要花大量的资金在实现信息往返上。由于这个原因，你需要重新审视服务的设计，去除不必要的调用。例如,在为每一个项目调用“添加项目”之后，不要创建包括“创建PO模板”的购买订单 - 而是创建唯一的“创建PO”服务。

　　下面是一些简单的经验方法:

　　把执行时间少于5秒的(相关)操作组合起来 (因为就算是一个简单的“ping”，它的时间开销的最低限度也要在几毫秒，最终以时间百分率太高而结束,这个时间仅仅是其自身的基础结构所占用的。

　　把执行时间超过5秒的操作拆分开(如果可能的话)。这通常意味着你正在尝试着一次就执行过多的操作。那些需要花费长时间的操作可以限制并发的消耗量，这样的话你的服务便可以得到处理。

　　就规模而言，许多Web服务的实现正是受到了它们所高效处理的消息大小的限制。一个原因是，整个消息需要被调入内存中，所以你需要考虑处理并发调用所需的内存大小。特别地，当消息的大小小于1MB时，这时是安全的。因为当消息大小超过这个极限时，为了符合这个限制，将会执行有差异操作。所以，在调整粒度时应当考虑消息大小。

　　事务处理和状态

　　你应该避免设计那些需要在操作之间维护过渡状态的服务。这不仅影响性能(需要启动在调用之间保存其数据的服务)，而且会影响故障恢复 – 在一个群组中，当其中的一个节点出现故障时，会有发生什么事情?另外一种表达方式就是:每个操作都要是独立性的。

　　如果一个操作正要改变数据，那么数据更改应该作为一个事物处理的一部分来执行(决不可以多于一个的事务处理)。这样做的原因是，当第一个事务处理完成之后，如果系统在某处发生故障，那么处理这个故障恢复就会非常的困难，尤其是当期望用户会为故障做出赔偿时。

　　次之，这样做还可以避免在一个操作中输入过多的信息。让我们再来看这个“创建PO”的例子。虽然这个例子看起来好像是一个完美合理的粒度，但是当同时创建多个购买订单时的“创建多个PO”会怎么样呢?这也许看起来是合理的(因为可能信息往返会比较少)，但是这意味着什么?实际上，这代表PO可以影响另外一个PO – 如果在处理提交的多个PO中，其中的一个问题发生，那么所有的处理都将被拒绝并且结束。

　　商业适应性

　　了解你的业务，这样的话你才能够理解什么样的粒度是有意义的 – 虽然这看起来很符合逻辑，但是很多开发人员和工程师都不会因为要理解他们所做事情的蓝图而花费额外的精力。对于实现一个成功的服务设计，这是至关重要的。

　　也就是说，要从易用性和通用性上来考虑粒度。争取做到使用一个简单的操作来实现完整的商业任务，并且仅当绝对必要的时候才添加一个额外的操作。如果简单化使其更通用(反之亦然)， 那么你是正确的。如果你使得粒度适合，那么重用你的服务的机会就会大大增加。