SOA服务切分原则整理

1,什么是服务的颗粒度？一般的说法，服务颗粒度（service granularity）就是指一个服务包含的功能大小。举个例子，对于电信九七系统中的营业受理来说，提交客户订单就是一个典型的粗粒度的服务，而实现这个提交订单服务的一系列内部操作，比如说创建客户资料，生成客户订单，记录产品属性，更新帐务关系等等就可能成为一系列细粒度的服务。细粒度的服务（fine-grained）提供相对较小的功能单元，或交换少量的数据。完成复杂的业务逻辑往往需要编排大量这种细粒度的服务，通过多次的服务请求交互才能实现。相反，粗粒度的服务（coarse-grained）则是在一个抽象的接口中封装了大块的业务/技术能力，减少服务请求交互的次数，但相应也会带来服务实现的复杂性，交互大量的数据，并因此而不能灵活更改以适应需求的变化。就像任何事物都有两面性一样，服务粒度不能太大或者太小，而应该大小合适。一个良好的SOA架构设计，必须在服务粒度设计上维护一种平衡，以获得成本降低，灵活响应的好处。
2,SAP将流程划分为核心流程（core process）和支撑流程(context process)。其中，支撑流程是指那些不可或缺的，但又不影响企业差异化的流程，如财会管理流程等，它们关注的是如何提升生产效率，降低生产成本。因此这些流程在分解过程中，一旦识别出自治的（事务一致、上下文独立的）、粗粒度的服务就可以结束，因为它们相对稳定。而核心流程是指企业独特的，差异化的，代表企业竞争力的业务流程，如营销销售流程等。它们需要比支撑流程更细粒度地分解，以获得最大的灵活性，因为它们是时刻变化的。
3,服务颗粒度越大，意味着包含的功能越多，业务逻辑越复杂，网络延迟就会增加，对客户端响应变慢。而服务颗粒度越小，也就意味着包含的功能越简单，虽然单个服务执行效率很高，但从业务意义上，完成一项业务任务所需的服务调用次数越多，来回请求响应次数增加。一般来说，服务都是远程调用的，这种来回请求响应的次数增加意味着显著的性能开销。因此，为了保证服务的性能可控，一方面需要限制服务包含的功能范围和复杂度，也就是说服务粒度不能太粗；另一方面需要限制服务调用的次数和复杂度，也就是说服务粒度不能太细。
4,服务的设计牵涉到两个重要的概念，一个是粒度，一个是耦合。
5,订单处理服务（Order Service）是各种基本服务的组合，基本服务包括产品类别服务（ProdClass Service）、产品库存服务（ProdStorage Service）、客户信息服务（Cust Service）、消息服务（Msg Service）等等。基本服务针对一个特定的业务操作对象，比如客户信息服务处理的是客户信息，它操作的对象就是客户信息，操作就包括新增、修改、删除、查找等等基本操作。订单处理服务包括了各种基本服务，但它不是同时调用这些基本服务，而是必须按照一定的工作流程，比如先新增客户信息，然后再查找产品类别、产品库存，然后再发送消息，这些顺序由工作流引擎来控制。
6,目前各应用系统最大的问题在于后台的服务实际上就是根据功能需求确定的,一切以功能为导向的设计都是庸俗设计，当我们在这样面向功能的服务思路的影响下，服务粒度的划分就永远纠缠不清了，没有基于业务本质的抽象，都是面向具体易变的功能，这时讨论服务粒度都是毫无意义的，其实就是在围绕功能编写程序而已
7,服务的划分和粒度应该建立在架构的基础上（参见下图），这才是SOA的精要，服务要划分为服务组件和基础服务组件两各层面，这是服务设计的关键！
8,服务组件它不同于传统的服务直接操纵数据和处理业务逻辑，它不直接与数据层打交道，更不涉及具体的业务逻辑，它通过组合调用基础服务组件实现一个具体的业务功能
9,基础服务组件不要面向功能，就是说它不关心是那个具体的业务功能在调用它，它面向业务领域的核心基础逻辑，负责与业务对象和数据层交互，因此也封装了该领域的数据。它的特征是稳定的，与数据层是紧密关联的，它与数据层一起构成应用系统稳定的核心和关键，其他部分包括服务组件和UI都是非关键和随时可以替换的。
10,通过重用获得降低开发维护成本，缩短应用交付周期，提升质量等种种好处。
11,与任何基于分解的范例相一致，粒度的大小直接影响到服务的可重用性。一个简单的经验法则就是细粒度的服务更容易被重用。换句话说，就是粒度越粗，服务越少被重用或者越难以被重用。因为随着粒度增加，越来越多的业务规则和上下文信息被嵌入到业务逻辑中，服务逐渐变得具有特定的业务意义。要使用它，我们必须首先了解它到底封装了哪些规则，否则我们无法确信这个服务正是我们所需要的。这并不意味着我们就不要构建粗粒度的服务，事实上粗粒度的服务往往还停留在“business-grained”层面，它让业务用户和IT人员可以直接对话，对业务有直接的意义，应该暴露出来。同时，如果我们仅仅机械地考虑重用性，将出现大量粒度很小的功能单元，这将对系统整体性能和容量带来严重的影响
12,细粒度的服务可以更容易地组装，为交付新的业务功能或改变业务流程提供了更多的灵活性。但是，仅仅考虑灵活性将导致大量的细粒度的服务，带来昂贵的开发成本，并使得维护变得困难。因此，在考虑业务流程灵活性的同时，考虑后台服务的良好组织、效率和开发维护成本，对于识别和设计粒度适中的服务是至关重要的
13,服务识别方法之一就是自顶向下的一级级流程分解，直到不能或者不需要进一步分解为止，其中识别出来的业务活动就是候选的业务服务。因此，一个有效的经验法则就是区别对待不同的业务流程，因为并不是每一个业务流程都需要相同的灵活性




流程服务：企业真正的业务实现,根据业务流程的需要对服务进行相应的组合和编排
业务服务：提供给客户一定的现实意义的业务功能。业务服务面向客户完成既定的业务功能， 有相应的执行者和业务执行规则。
组件服务：组件服务不直接面向客户，业务角色之间的信息交互；运算处理业务状况；存储和管理业务状况信息和执行规则。
基础服务：提供技术层面的数据采集，存储，计算，传输，分发等功能，或者将遗留系统封装为服务






---------------------------
重用性 灵活性 高内聚低耦合


服务是一个自主的，可重复使用的，可发现的，无状态的，有一定粒度的功能，并且是一个复合应用程序或一个组合服务的一部分。


粗粒度的服务可以有效降低交互的复杂性，但灵活性降低


服务应该是无状态的。它有一个无状态的执行上下文，但它不会有中间状态来等待一个事件或一个回调。状态有关的数据的保留一定不能超出的服务的请求/响应。这是因为状态管理消耗了大量的资源，这可能会影响服务的可重用 可伸缩性和可用性


SOA 最主要的应用场合在于解决在网络环境下的不同商业应用之间的业务集成问题。在网络环境下由于大量异构系统并存，不同计算机硬件工作方式不同，操作系统不同、编程语言也不同，各个系统之间无法通信，使得系统集成非常艰难。SOA架构以松耦合性，位置透明性以及协议无关性等一些典型特性来解决异构系统之间的集成问题








关于服务，一些常见和讨论的设计原则如下：
（1）无状态。以避免服务请求者依赖于服务提供者的状态。
（2）单一实例。避免功能冗余。
（3）明确定义的接口。服务的接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界线。WS-Policy用于描述服务规约，XML模式（Schema）用于定义所交换的消息格式（即服务的公共数据）。使用者依赖服务规约来调用服务，所以服务定义必须长时间稳定，一旦公布，不随意更改；服务的定义应尽可能明确，减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。
（4）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
（5）粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用（RPC），通常消息量比较大，但是服务之间的交互频度较低。
（6）服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术、当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
（7）重用能力。服务应该是可以重用的。
（8）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，比如一个服务对安全性方面的要求；也可以是跟业务有关的语义方面的内容，比如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。WS- Policy用于定义可配置的互操作语义，来描述特定服务的期望、控制其行为。在设计时，应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。


参考：
http://www.ibm.com/developerworks/cn/webservices/0708_xinsheng/index1.html

http://www.tech-ex.com/broadcast/tvgroup/gdtv/hl_09.html