服务颗粒度的选择

对于SOA的服务粒度，我们谈的比较多的是SOA本身是一种粗粒度服务设计的思路。内部的业务规则和操作可能比较复杂，但是组件之间的交互需要屏蔽这些复杂性，是粗粒度的一种服务。

首先再解释下怎样来界定粗粒度这个词？对于粗粒度我们还是从两个方面来看，首先是服务传递的数据的数据结构的复杂程度，以供应商查询服务来举例，如果我一次查询的是供应商基本信息+联系信息+地址地点信息+财务信息的复合实体，那么数据结构是比较复杂的，可以看做是比单纯查询供应商基本信息更加粗粒度的服务；其次可以看要实现服务所需要的结果，服务在内部所需要执行的业务操作和逻辑多少来确定，以查供应商基本信息和校验供应商信用两个服务来举例，第一个内部设计的业务操作和逻辑少，而第二个则设计到需要查询供应商交货，货品质量，材料成本等多个相关信息，经过相关规则处理后才能返回供应商信用评级，那么第二个服务可以作为是粗粒度服务，这类服务可以通过细粒度的原子服务组合或编排生成。

从服务的分层来看，包含有数据服务，业务服务，业务组合服务，流程服务，对于流程服务一般都是粗粒度的服务，这类服务本身可重用性已经很低，一般是个别的子流程服务可以重用，流程服务本身就是重用其它业务服务，通过BPEL编排来完成的。所以随着流程服务的不断增加，业务服务和组合服务本身的可重用性讲直接影响到系统本身的复杂度和管理难度。

SOA从短期来看仍然是以解决跨系统的流程集成为主，如果业务系统本身全部SOA化完全可能导致过渡设计，但是业务系统本身仍然可以参考IBM 的SOMA方法论的思路，以流程驱动和业务建模的思路来考虑CBM组件化业务模型，分析和识别关键业务组件，通过流程交互分析识别用例，通过用例进一步分析识别用例到服务模型的一个转化。对于业务系统本身的架构并不一定要完全SOA化，但是需要预留服务层，方便已有的业务逻辑方法方便的暴露为web service服务。

服务本身的可重用性要从两个方面来考虑，其一是该服务用于流程编排的时候的可重用性，一个可重用的服务可以用于多个业务流程；其二不是体现在流程编排上的可重用，而是体现在对服务消费方的可重用，还是举供应商查询的例子，如果ERP系统提供这个服务可以被SRM，CRM，PDM等多个系统消费和使用，则服务的可重用性高。

数据服务重要体现在数据集成通过服务提供和消费的方式进行。数据服务最大的特点是数据传递本身不承载业务规则，如果仅仅是数据服务即和传统的数据交换平台无异，虽然数据服务进行需要传递相应的数据表，但是我们发现仅仅是数据服务会导致本来属于某个业务系统的业务规则和逻辑外漏，而且数据服务本身虽然可重用性可能很高，但是数据服务往往却很难直接应用到服务编排。

业务服务同数据服务的最大区别就是业务服务本身是承担了业务规则，具有完整的业务事务处理能力。由于业务服务有明确的事务性，因此业务服务本身并不会有太大的数据量。业务服务粒度粗的时候可以屏蔽内部的业务操作的复杂性，仅仅暴露简单的业务服务接口，但是可能会导致业务服务的重用性低；但是如果业务服务的粒度太细，虽然可重用高，但是开发和集成成本也会很大。 这个时候我们考虑的关键问题是一个业务组合服务是否一定要拆分出原子服务? 这些原子服务本身的可复用性和管理这些原子服务的成本如何进行权衡。

流程服务封装完整的业务流程或独立定义的子流程，所有需要保存服务调用之前的状态和调用结束之后的状态，并最终向客户应答的服务，都应该设计为流程服务。同时，流程服务的状态在任何一个时间点都应该是能够监控的，流程服务中本身还可能涉及到HWF人工工作流节点，调用多个业务服务或原子服务，流程服务本身一般已经是粗粒度服务。

====================================================================================================================================

服务颗粒度的困扰

        概念理解 

1. 服务颗粒度：一个服务包含的功能大小。
2. 细粒度的服务：（fine-grained）提供相对较小的功能单元，或交换少量的数据。
               优点：完成复杂的业务逻辑往往需要编排大量这种细粒度的服务，灵活性强
               缺点：需要通过多次的服务请求交互才能实现。
   粗粒度的服务：（coarse-grained）则是在一个抽象的接口中封装了大块的业务/技术能力。
               优点：减少服务请求交互的次数，减少成本
               缺点：会带来服务实现的复杂性，交互大量的数据，并因此而不能灵活更改以适应需求的变化。
3. 良好的SOA架构设计，必须在服务粒度设计上维护一种平衡，以获得成本降低，灵活响应的好处。

选择SOA就意味着将业务流程或功能用服务来表达，而服务的颗粒度直接影响到服务的质量，包括灵活性和效率等诸多方面。 因此，选择合适的颗粒度对服务设计是至关重要的。因为老被人问起，节前就有了就“服务颗粒度”问题写点东西的想法，没想到却因此困扰了我整个国庆节。回头想这其中很重要的一个原因，就是业界并没有就此形成一个非常清晰的答案。一个服务应该选择怎样的颗粒度，目前来看基本上还是一个主观的度量，并没有一个严格的标准可以遵循，很大程度上取决于设计者的经验。

 

    什么是服务的颗粒度？一般的说法，服务颗粒度（service granularity）就是指一个服务包含的功能大小。举个例子，对于电信九七系统中的营业受理来说，提交客户订单就是一个典型的粗粒度的服务，而实现这个提交订单服务的一系列内部操作，比如说创建客户资料，生成客户订单，记录产品属性，更新帐务关系等等就可能成为一系列细粒度的服务。细粒度的服务（fine-grained）提供相对较小的功能单元，或交换少量的数据。完成复杂的业务逻辑往往需要编排大量这种细粒度的服务，通过多次的服务请求交互才能实现。相反，粗粒度的服务（coarse-grained）则是在一个抽象的接口中封装了大块的业务/技术能力，减少服务请求交互的次数，但相应也会带来服务实现的复杂性，交互大量的数据，并因此而不能灵活更改以适应需求的变化。就像任何事物都有两面性一样，服务粒度不能太大或者太小，而应该大小合适。一个良好的SOA架构设计，必须在服务粒度设计上维护一种平衡，以获得成本降低，灵活响应的好处。

 

尽管没有一本Bible让我们可以依此正确地设计服务的粒度，但我们还是能从与之相关的多方面利弊权衡的设计实践中，总结出一些能够帮助正确选择服务颗粒度的经验法则。识别并设计一个粒度适中的服务，我们可以主要从以下三个方面权衡考量。

 

x  重用性

所谓重用性，就是指服务能够应用于不同上下文的能力。重用可以说是SOA的核心思维，通过重用获得降低开发维护成本，缩短应用交付周期，提升质量等种种好处。

与任何基于分解的范例相一致，颗粒度的大小直接影响到服务的可重用性。一个简单的经验法则就是细粒度的服务更容易被重用。换句话说，就是颗粒度越粗，服务越少被重用或者越难以被重用。因为随着颗粒度增加，越来越多的业务规则和上下文信息被嵌入到业务逻辑中，服务逐渐变得具有特定的业务意义。要使用它，我们必须首先了解它到底封装了哪些规则，否则我们无法确信这个服务正是我们所需要的。这并不意味着我们就不要构建粗粒度的服务，事实上粗粒度的服务往往还停留在”business-grained”层面，它让业务用户和IT人员可以直接对话，对业务有直接的意义，应该暴露出来。同时，如果我们仅仅机械地考虑重用性，将导致大量颗粒度很小的功能单元，这将对系统整体性能和容量带来严重的影响。就拿大家常用来描绘SOA的乐高玩具为喻，一个最小尺寸的1x1的乐高积木，带有一个标准的凸起接口，通过它几乎可以与任何其它乐高积木拼装出任意可以想想的物体，其广泛的重用性是不言而喻的。但是当你真正尝试用这种粒度的积木完成一个复杂物体拼装的时候，你可能会感叹：“Oh, My God! It’s mission impossible!”，因为，为此付出的时间和成本的代价几乎是不可接受的。因此，我们在一心希望构建美好的重用世界之前，需要先掂量清楚服务颗粒度的选择。

在这里，我借用关于演讲的一个有名的“迷你裙定律”来尝试表达服务颗粒度的选择上的权衡之道。“mini-skirt theory”告诉我们，一个出色的演讲应该“short enough to keep people interested, but long enough to cover the important part”。套用在服务颗粒度的选择上，一个设计良好的服务应该“fine-grained enough to be reusable, but coarse-grained enough to make business sense”。

 

x  灵活性

所谓灵活性，就是能够容易地因情形做出改变的能力。SOA的目标之一就是让IT变得更灵活，能够更快地适应持续变化的业务环境。因此，灵活性作为设计良好的服务的重要考量，理所当然地也是选择服务粒度的重要标准之一。众所周知，细粒度的服务可以更容易地组装，为交付新的业务功能或改变业务流程提供了更多的灵活性。但是，仅仅考虑灵活性将导致大量的细粒度的服务，带来昂贵的开发成本，并使得维护变得困难。因此，在考虑业务流程灵活性的同时，考虑后台服务的良好组织、效率和开发维护成本，对于识别和设计粒度适中的服务是至关重要的。

我们知道，服务识别方法之一就是top-down的一级级流程分解，直到不能或者不需要进一步分解为止，其中识别出来的的业务活动就是候选的业务服务。因此，一个有效的经验法则就是区别对待不同的业务流程，因为并不是每一个业务流程都需要相同的灵活性。如何确定哪些流程需要更多的灵活性，哪些流程不需要，可以参考SAP就企业业务流程的一个观点。SAP将流程划分为核心流程（core process）和支撑流程(context process)。其中，支撑流程是指那些不可或缺的，但又不影响企业差异化的流程，如财会管理流程等，它们关注的是如何提升生产效率，降低生产成本。因此这些流程在分解过程中，一旦识别出自治的（事务一致、上下文独立的）、粗粒度的服务就可以结束，因为它们相对稳定。而核心流程是指企业独特的，差异化的，代表企业竞争力的业务流程，如营销销售流程等。它们需要比支撑流程更细粒度地分解，以获得最大的灵活性，因为它们是时刻变化的。

 

x  性能

灵活性和效率往往是成对出现的，性能因素自然也是限制服务粒度不能太大或者太小的约束之一。Dan Foody曾在他的weblog里建议Webservice的每一个operation执行应该在5ms到5s之间完成，小于5ms或者 大于5s就意味着服务粒度要么太小，要么太大。我在这里倒不想评价这个量化的指标有多大指导意义，而是借此希望引起大家的思考，并不是服务粒度越小或者越大，系统性能就会一定越好。

一个服务本身的复杂度以及业务到服务映射的复杂度（即实现一个业务活动所需的服务调用次数）是影响SOA性能的两个主要方面。服务颗粒度越大，意味着包含的功能越多，业务逻辑越复杂，网络延迟就会增加，对客户端响应变慢。而服务颗粒度越小，也就意味着包含的功能越简单，虽然单个服务执行效率很高，但从业务意义上，完成一项业务任务所需的服务调用次数越多，来回请求响应次数增加。一般来说，服务都是远程调用的，这种来回请求响应的次数增加意味着显著的性能开销。因此，为了保证服务的性能可控，一方面需要限制服务包含的功能范围和复杂度，也就是说服务粒度不能太粗；另一方面需要限制服务调用的次数和复杂度，也就是说服务粒度不能太细。我想这才是前面提到的5ms和5s背后真正的原因。很显然，二者的着眼点是背离的，为了符合性能的需求，需要在二者之间折中妥协。

 

     除以上几点之外，还存在其它可能影响服务颗粒度决策的因素，比如服务类别和使用范围等等。如果服务使用的范围有限，如仅仅在Intra-Application范畴，则可以选择相对较细粒度的服务接口，为服务请求者提供更多的灵活性；随着范围扩大，服务大小也应随之扩大，如Multi-Enterprise的范畴，则要求服务尽可能提供粗粒度的、较稳定的接口，保证服务请求者以一致的方式使用系统中所暴露出的服务。最后，需要记住的一点是，服务的颗粒度在其生命周期内不是一成不变的，它是随着业务的调整变化，以及服务的迭代发展过程，不断演化精炼、甚至重构的。

 

写下这篇文章有两个原因：一是将脑子里这堆零散的几点认知整理并记录下来；更重要的是希望借此让更多的人把对这个问题的想法谈出来，争取让这问题越辩越明，这才是这篇文章的初衷。因为说到底，这个问题的答案还是来自于实践中的检验和总结。因此，如果大家对此有任何看法或经验，请分享出来，我会因此受益良多。

====================================================================================================================================

如何决定服务的粒度？

我们常常听到关于在SOA部署中服务的粒度应该有多大的讨论。对于其他更传统的架构方式，粗粒度和细粒度的激烈争论已经持续了很多年，换言之，这并不是SOA独有的问题。这也是不存在普适方案的又一例证：有时候大小很重要！最近的一份报告又给这个激烈的争论火上浇油：

“服务”并不仅仅是一个按照标准暴露出API的对象，也不是面向对象编程的“放大版”。确实，如同面向对象给过程式编程带来了另一层次的抽象和思维，面向服务也给面向对象编程带来了另一层次的抽象和思维。

报告里继续展开论点：

确实，面向服务的运动根本不是关于技术的！它是一个面向业务的运动，里头的抽象正是关于企业如何看待自身组织中变化不息的方方面面，以及如何用松耦合的方式将它们组织起来，从而造就出平缓而可预测的成本变动。这就是说我们要重新思考我们看待IT能力的方式，而不是简单地以同样的方式暴露出同样的资源，而仅仅是采用了新的接口或者中间件。

跟过去几年中围绕这个主题的其他讨论一样，这份报告强调了跟服务粒度相关的困难，报告中将细粒度的服务定义为“针对一个相对较小的功能单元，或者交换少量的数据”，而粗粒度的服务则是在单个交互中抽象了大量功能的服务。其他人已经讨论过决定服务的粒度为何是服务生命周期中的一个关键方面，因为它不但影响一组松耦合的服务之间的复合能力，还影响了单个服务的可复用性。

报告继续讨论了自顶向下和自底向上两种开发服务的方式（或多或少两种都是必需的）：

……从业务过程或者业务模型开始着手，然后将之递归地分解成子过程或子模型，直到达到某些条件，再继续分解就会违反这些条件为止。或者，架构师可以从已经实现的IT系统开始着手，从已有的API和访问点中暴露出服务的接口，以这些接口为基础创造出服务的契约，然后将它们组合起来，直到满足业务过程的需求。

无论你是在开发复合服务还是原子服务，都会对服务的粒度有所影响：

第一眼看起来似乎所有原子服务都是细粒度的，而复合服务是粗粒度的，但事实未必如此。由于粒度是对交互和业务适合程度的一种量度，而原子性是对过程分解的一种量度，因此很可能出现粗粒度的原子服务和细粒度的复合服务。

最后报告给出了一份粒度表格，里面列出了服务的粒度和原子性之间的取舍。对于过去几年中曾经做过服务开发的大多数人来说，最后的结论毫不意外：

……适当的面向服务分析和设计方式应该从以下五个关键方面分别考虑粒度和原子性的问题：服务的可复用性、效率、事务性、可消费性（Consumability）和可见性。一开始从复用的角度看应该成为复合服务的，实际上可能出于事务性的考虑而应该成为原子服务。类似地，出于可见性和安全审查的考虑似乎应该成为细粒度服务的，可能因为效率的关系而应该改用粗粒度。这份服务粒度表格仅仅是一位高效的企业架构师腰带上挂着的又一把工具。

那么，粒度大小重要吗？是的，而有时候更大并不意味着更好。而且，即使一个粗粒度的服务在特定的环境下非常适合，并不意味着它在别的环境下也是最好的。服务是跟使用它们的应用一起演变的。

====================================================================================================================================

服务粒度设计原则与服务组合—兼谈应用软件的症结(二)

   摘要：企业应用架构、企业技术架构               参阅：序  消灭人狼  软件的十大命题 编程规则

       SOA、SOA、SOA！

      现在许多企业都在进行基于SOA的应用治理,这里的关键是服务和架构,架构在上一篇<架构简述>中已经作了介绍,本文重点讨论服务粒度设计原则和服务组合。

      困扰目前应用领域的主要问题是服务的粒度如何把控，服务如何组合使用？

      先说服务粒度，服务该如何划分，粒度如何把握，这是系统的关键，目前应用领域在这方面没有标准和指导原则，造成系统混乱、死板，也是目前应用软件的主要症结，如果解决好这个问题，许多事情迎刃而解。

      目前各应用系统最大的问题在于后台的服务实际上就是根据功能需求确定的（那些前后不分，没有清晰服务概念的系统不在讨论范围之内），一切以功能为导向的设计都是庸俗设计，当我们在这样面向功能的服务思路的影响下，服务粒度的划分就永远纠缠不清了，没有基于业务本质的抽象，都是面向具体易变的功能，这时讨论服务粒度都是毫无意义的，其实就是在围绕功能编写程序而已。

      服务的划分和粒度应该建立在架构的基础上（参见下图），这才是SOA的精要，服务要划分为服务组件和基础服务组件两各层面，这是服务设计的关键！

     服务组件实现的功能类似于面向功能的服务，但细节上完全不同，它不同于传统的服务直接操纵数据和处理业务逻辑，它不直接与数据层打交道，更不涉及具体的业务逻辑，它通过组合调用基础服务组件实现一个具体的业务功能。

      基础服务组件不要面向功能，就是说它不关心是那个具体的业务功能在调用它，它面向业务领域的核心基础逻辑，负责与业务对象和数据层交互，因此也封装了该领域的数据。它的特征是稳定的，与数据层是紧密关联的，它与数据层一起构成应用系统稳定的核心和关键，其他部分包括服务组件和UI都是非关键和随时可以替换的。

      服务组件粒度的设计原则

      将服务拆分为服务组件和基础服务组件后，再谈论粒度就有了基础，首先服务组件的粒度不重要，按功能要求划分即可；基础服务组件的粒度才是设计的重点，这时基础服务组件的设计摆脱了功能的束缚，就容易界定了，高内聚、低耦合是宏观的指导原则，但不易把握，因此给出如下基本原则：

      1）  独立和完整性原则。

      保证一个基础服务组件业务概念的独立和完整，这是基础服务组件设计的最关键原则，一个基础服务组件完成业务领域某个完整、而独立的事项，它可以被多个服务组件共享使用，它做的事情既不多也不少，恰到好处。

       2）  单一职责原则。

      基础服务组件职责要单一，只做一件事，做好本职工作，不做分外之事；只有做到单一职责，才能提高基础服务的共享能力和稳定性。

       3）  原子性原则。

      基础服务组件应该具备不可再分的性质，也就是说如果将一个基础服务组件拆开，拆开的两部分将从来不会被独立使用，还必须联合使用，这就是基础服务组件的原子性；反之，如果一个基础服务组件可以被拆分为两或两个以上的组件，并且它们都可以被独立使用，说明该组件的职能不单一，不满足原子性原则，必须进一步拆分。

      4）  数据相关性原则。

      基础服务组件是对基础业务逻辑和数据的封装，它通常都会与数据层交互；如果不需要与数据层交互的组件，可以纳入到公共函数层，不作为服务组件管理，例如，账号合法性校验，计息模块等。

      5）  相互操作性原则。

      基础服务组件允许相互调用，可以使用共享公共库函数。

      把握好上面的原则，就可以合理地确定基础服务组件的粒度了。

 

                                                          企业级应用系统架构图

                     

     

      服务组合

      服务组合是一个更广泛的话题，涉及到架构的各个层面，单独讨论某一个具体层面都是片面的，从上面的图可以清晰地看到服务组合在三个层面都会发生：

      1）  UI层 -- 丰富

      一个复杂用户界面可能会关联多个后台服务、文件服务、消息服务，可能会启动或参与一个业务流程，这是服务组合最灵活、最丰富多彩的层面。

      2）  中台 -- 灵活

      中台的服务统一接入通常表现为对服务请求的简单转发，服务组合则由流程平台或服务组合平台实现，它们通常表现为可视化的流程组织或服务过程脚本语言。

这一层面是按业务流程或过程对服务的组合，是系统实现对业务灵活性的关键设计。

      3）  后台服务层 -- 细腻

      服务组件实际上是对基础服务组件的过程组合，是面向功能的基础封装，我们虽然强调基础服务组件的重要性，但服务组件才是真正提供各系统使用的服务，也就是说从应用系统的角度看，服务组件是唯一可见的服务，基础服务组件被服务组件隔离和隐藏，服务组件是为了实现系统功能而对基础服务组件进行的最有效组合。

      这一层的服务组合的特点是细腻和相对稳定，它虽然没有基础服务那样稳定，但相对于业务流程和UI层的组合而言还是相对稳定的。

     参阅：http://blog.csdn.net/xabcdjon/article/details/6876058

               http://blog.csdn.net/xabcdjon/article/details/6707050

====================================================================================================================================

服务颗粒度

编辑锁定

本词条缺少名片图，补充相关内容使词条更完整，还能快速升级，赶紧来编辑吧！

尽管没有一本Bible让我们可以依此正确地设计服务的粒度，但我们还是能从与之相关的多方面利弊权衡的设计实践中，总结出一些能够帮助正确选择服务颗粒度的经验法则。识别并设计一个粒度适中的服务，我们可以主要从以下三个方面权衡考量。

中文名

服务颗粒度

外文名

service granularity

释    义

指一个服务包含的功能大小

重用性

服务能够应用于不同上下文的能力

目录

1. 1 简介
2. 2 重用性
3. 3 灵活性
4. 4 性能

简介编辑

什么是服务的颗粒度？一般的说法，服务颗粒度（service granularity）就是指一个服务包含的功能大小。举个例子，对于电信九七系统中的营业受理来说，提交客户订单就是一个典型的粗粒度的服务，而实现这个提交订单服务的一系列内部操作，比如说创建客户资料，生成客户订单，记录产品属性，更新帐务关系等等就可能成为一系列细粒度的服务。细粒度的服务（fine-grained）提供相对较小的功能单元，或交换少量的数据。完成复杂的业务逻辑往往需要编排大量这种细粒度的服务，通过多次的服务请求交互才能实现。相反，粗粒度的服务（coarse-grained）则是在一个抽象的接口中封装了大块的业务/技术能力，减少服务请求交互的次数，但相应也会带来服务实现的复杂性，交互大量的数据，并因此而不能灵活更改以适应需求的变化。就像任何事物都有两面性一样，服务粒度不能太大或者太小，而应该大小合适。一个良好的SOA架构设计，必须在服务粒度设计上维护一种平衡，以获得成本降低，灵活响应的好处。

重用性编辑

所谓重用性，就是指服务能够应用于不同上下文的能力。重用可以说是SOA的核心思维，通过重用获得降低开发维护成本，缩短应用交付周期，提升质量等种种好处。

与任何基于分解的范例相一致，颗粒度的大小直接影响到服务的可重用性。一个简单的经验法则就是细粒度的服务更容易被重用。换句话说，就是颗粒度越粗，服务越少被重用或者越难以被重用。因为随着颗粒度增加，越来越多的业务规则和上下文信息被嵌入到业务逻辑中，服务逐渐变得具有特定的业务意义。要使用它，我们必须首先了解它到底封装了哪些规则，否则我们无法确信这个服务正是我们所需要的。这并不意味着我们就不要构建粗粒度的服务，事实上粗粒度的服务往往还停留在”business-grained”层面，它让业务用户和IT人员可以直接对话，对业务有直接的意义，应该暴露出来。同时，如果我们仅仅机械地考虑重用性，将导致大量颗粒度很小的功能单元，这将对系统整体性能和容量带来严重的影响。就拿大家常用来描绘SOA的乐高玩具为喻，一个最小尺寸的1x1的乐高积木，带有一个标准的凸起接口，通过它几乎可以与任何其它乐高积木拼装出任意可以想想的物体，其广泛的重用性是不言而喻的。但是当你真正尝试用这种粒度的积木完成一个复杂物体拼装的时候，你可能会感叹：“Oh, My God! It’s mission impossible!”，因为，为此付出的时间和成本的代价几乎是不可接受的。因此，我们在一心希望构建美好的重用世界之前，需要先掂量清楚服务颗粒度的选择。

在这里，我借用关于演讲的一个有名的“迷你裙定律”来尝试表达服务颗粒度的选择上的权衡之道。“mini-skirt theory”告诉我们，一个出色的演讲应该“short enough to keep people interested, but long enough to cover the important part”。套用在服务颗粒度的选择上，一个设计良好的服务应该“fine-grained enough to be reusable, but coarse-grained enough to make business sense”。

灵活性编辑

所谓灵活性，就是能够容易地因情形做出改变的能力。SOA的目标之一就是让IT变得更灵活，能够更快地适应持续变化的业务环境。因此，灵活性作为设计良好的服务的重要考量，理所当然地也是选择服务粒度的重要标准之一。众所周知，细粒度的服务可以更容易地组装，为交付新的业务功能或改变业务流程提供了更多的灵活性。但是，仅仅考虑灵活性将导致大量的细粒度的服务，带来昂贵的开发成本，并使得维护变得困难。因此，在考虑业务流程灵活性的同时，考虑后台服务的良好组织、效率和开发维护成本，对于识别和设计粒度适中的服务是至关重要的。

我们知道，服务识别方法之一就是top-down的一级级流程分解，直到不能或者不需要进一步分解为止，其中识别出来的的业务活动就是候选的业务服务。因此，一个有效的经验法则就是区别对待不同的业务流程，因为并不是每一个业务流程都需要相同的灵活性。如何确定哪些流程需要更多的灵活性，哪些流程不需要，可以参考SAP就企业业务流程的一个观点。SAP将流程划分为核心流程（core process）和支撑流程(context process)。其中，支撑流程是指那些不可或缺的，但又不影响企业差异化的流程，如财会管理流程等，它们关注的是如何提升生产效率，降低生产成本。因此这些流程在分解过程中，一旦识别出自治的（事务一致、上下文独立的）、粗粒度的服务就可以结束，因为它们相对稳定。而核心流程是指企业独特的，差异化的，代表企业竞争力的业务流程，如营销销售流程等。它们需要比支撑流程更细粒度地分解，以获得最大的灵活性，因为它们是时刻变化的。

性能编辑

灵活性和效率往往是成对出现的，性能因素自然也是限制服务粒度不能太大或者太小的约束之一。Dan Foody曾在他的weblog里建议Webservice的每一个operation执行应该在5ms到5s之间完成，小于5ms或者 大于5s就意味着服务粒度要么太小，要么太大。我在这里倒不想评价这个量化的指标有多大指导意义，而是借此希望引起大家的思考，并不是服务粒度越小或者越大，系统性能就会一定越好。

一个服务本身的复杂度以及业务到服务映射的复杂度（即实现一个业务活动所需的服务调用次数）是影响SOA性能的两个主要方面。服务颗粒度越大，意味着包含的功能越多，业务逻辑越复杂，网络延迟就会增加，对客户端响应变慢。而服务颗粒度越小，也就意味着包含的功能越简单，虽然单个服务执行效率很高，但从业务意义上，完成一项业务任务所需的服务调用次数越多，来回请求响应次数增加。一般来说，服务都是远程调用的，这种来回请求响应的次数增加意味着显著的性能开销。因此，为了保证服务的性能可控，一方面需要限制服务包含的功能范围和复杂度，也就是说服务粒度不能太粗；另一方面需要限制服务调用的次数和复杂度，也就是说服务粒度不能太细。我想这才是前面提到的5ms和5s背后真正的原因。很显然，二者的着眼点是背离的，为了符合性能的需求，需要在二者之间折中妥协。

除以上几点之外，还存在其它可能影响服务颗粒度决策的因素，比如服务类别和使用范围等等。如果服务使用的范围有限，如仅仅在Intra-Application范畴，则可以选择相对较细粒度的服务接口，为服务请求者提供更多的灵活性；随着范围扩大，服务大小也应随之扩大，如Multi-Enterprise的范畴，则要求服务尽可能提供粗粒度的、较稳定的接口，保证服务请求者以一致的方式使用系统中所暴露出的服务。最后，需要记住的一点是，服务的颗粒度在其生命周期内不是一成不变的，它是随着业务的调整变化，以及服务的迭代发展过程，不断演化精炼、甚至重构的。