SOA服务粒度

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

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

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

　　 重用性

　　所谓重用性，就是指服务能够应用于不同上下文的能力。重用可以说是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的范畴，则要求服务尽可能提供粗粒度的、较稳定的接口，保证服务请求者以一致的方式使用系统中所暴露出的服务。最后，需要记住的一点 是，服务的颗粒度在其生命周期内不是一成不变的，它是随着业务的调整变化，以及服务的迭代发展过程，不断演化精炼、甚至重构的。

 

       服务的设计牵涉到两个重要的概念，一个是粒度，一个是耦合。
      

       粒度表示的是一个服务的大小，它可以理解为服务操作的范围，粗粒度的服务，操作的内容广而且杂；细粒度的服务，操作的内容细而且简单。粗粒度的服务设计， 可以减小服务之间的耦合性，但付出的代价就是增加服务的复杂性，服务具备了太多的功能，增加了设计的复杂性和维护的难度；细粒度的服务，可以让服务的实现 变得简单，但这样会增加服务的数量，服务过细过多，这样必然有一些服务需要组合才能实现一定的功能，那样就增加了服务之间的耦合度，只要其中一个服务发生 了变动，势必牵一发而动全身。

耦合代表的是服务与服务之间的关系。SOA的初衷就是为了降低系统各个部分之间的耦合性，使得服务可以重用。但很显然，耦合性是受到服务粒度很大的影响，而且从某种程度上讲，粒度的选择就决定了系统内部的耦合性。

那么应该以什么为准则来确定一个服务的粒度呢？遗憾的是，网上搜索了各种SOA的介绍和各个厂商的文档，似乎找不到一个统一的标准，因为服务粒度往 往要根据需求来确定。SOA提倡服务要粗粒度，但这样的说法太笼统，系统必然会有细粒度的服务存在，很多粗粒度的服务不过是一些细粒度服务的组合。所以我 的看法是，粗中有细。

我的想法是，把服务分解为三种类型，一种是基本服务，一种是组合服务，一种是合成服务。

• 基本服务。基本服务即是系统提供的最小粒度的服务，或者说是原子服务。这类服务考虑的是利用它们的可重用性，它们是组成一些较大粒度的服务的基 础。基本服务可以说是原有系统跟业务需求细分的中间结合点，它既是原有系统能够提供的最细粒度的服务，同时也是要设计的系统最细粒度的服务。
• 合成服务。合成服务是基本服务简单的组合，只是为了把具有相同功能但操作不同的业务对象的基本服务组合到一起，形成一个对外提供相同功能的服务。它类似设计模式里面的工厂模式，只要告诉服务接口传进来的是哪一个业务对象，那么服务就能自动识别应该调用哪一个基本服务。
•  组合服务。组合服务是系统里面最复杂的部分，它不是基本服务的简单堆积到一块，它是最大粒度的服务，里面各个基本服务的关系受到工作流程的控制。它是基本服务与工作流程的结合。

基于上面的理解，我们的服务设计遵循这样的设计思路：先从功能模块分离出基本服务，各个功能模块可以看成是合成服务，由功能模块分离出来的就是基本 服务；然后在基本服务的基础上设计组件和业务对象；设计完组件和业务对象之后再来设计组合服务。这样不管组合服务需要多少，组合服务多复杂，都可以通过基 本服务和工作流程进行各种形式组合起来。而且组合服务经常需要变动，这样的设计能够保证这些变动不会引起太大的改动。它们的组合关系可以用下面的图来表 示。

 这 样的设计思路也体现了SOA的自顶向下的设计方法：功能模块->服务->组件和业务对象。服务不是凭空想象出来的，它必须要满足客户的需求， 而客户需求的体现就是系统要提供的功能，所以功能模块的设计是服务设计的前提。以我们团队这次IBM大赛的方案为例子，我们在理解大赛组委会给出的业务需 求外，自己也设想了一些需求，对应这些需求，我们设计了系统的功能模块。不同的业务角色有不同的业务需求，所以功能模块对应不同的角色也就有所不同。下面 的图列举的是财务人员所需要的功能模块：

系统功能模块是系统提供的各类服务的编排和合成。在设计完系统的功能模块后，在这个基础上把各个功能模块的服务提取出来，一个功能模块可能由一个服务组成，也可能由多个服务组成。
服 务的基础是组件，一些重要的组件能够单独封装成服务。基础服务其实就是一个业务组件，它是基于商务对象的原子操作。它是封装好的组件，它只关心定义好的组 件接口，和需要传递的对象，而不关心实现这个操作是如何用代码来实现。业务组件包含两个重要的含义，一个是“操作”，一个是“操作的对象”。组件的设计是 基于面向对象的，可以说，它就是一个类，但它只能是一个抽象类，只有定义，没有实现。

基础服务跟合成服务、组合服务之间的关系可以用下面的图来举个例子：

 订 单处理服务（Order Service）是各种基本服务的组合，基本服务包括产品类别服务（ProdClass Service）、产品库存服务（ProdStorage Service）、客户信息服务（Cust Service）、消息服务（Msg Service）等等。基本服务针对一个特定的业务操作对象，比如客户信息服务处理的是客户信息，它操作的对象就是客户信息，操作就包括新增、修改、删 除、查找等等基本操作。订单处理服务包括了各种基本服务，但它不是同时调用这些基本服务，而是必须按照一定的工作流程，比如先新增客户信息，然后再查找产 品类别、产品库存，然后再发送消息，这些顺序由工作流引擎来控制。

同步服务（Synchronize Service）是各种基本服务的合成，基本服务包括产品类别服务（ProdClass Service）、产品库存服务（ProdStorage Service）、客户信息服务（Cust Service）等等。相比订单处理它就简单不少，它只需要根据请求调用相应的服务完成操作就可以，没有顺序的要求。
虽然本文描述的只是一种业务场景下的服务粒度的选择，但我想从我们团队的设计经历，可以总结出一种对服务粒度选择的方法，那就是自顶向下，由粗到细，然后再从基础到合成、组合。