一、SOA定义

SOA即面向服务架构(Service-Oriented Architecture)。在SOA中,一切皆服务。一个服务是通过消息交换来调用的程序,一个信息系统是共同完成一个特定任务的一组服务,SOA可以概述为一种由一组自治服务创建信息系统的方法。当然具体定义SOA真不好说,反正不能简单理解为我们常用的开发技术如web服务、.net remoting或者wcf。

SOA设计四项基本原则:

1. 边界必须明确

2. 服务必须自治

3. 服务分享 Schema 和 Contract, 而不是 Class

4. 由 Policy 决定服务间的兼容性

二、面向对象和面向服务

1、面向对象(OO)
a、应用于同一平台和运行环境

b、共享类型而不是Schema

c、采用便宜, 透明通信

d、对象的标识与生命周期由系统维护

e、客户机和服务器的同步的部署

f、容易概念化,因而提供一个自然的模型

g、一般不需要状态管理

h、应用于一个可预测的序列、期限和结果

i、目标是远程透明地使用方法和类型

2、面向服务(SO)
a、应用于异构平台和运行环境

b、共享Schema而不是类型

c、采用高成本, 明确通信

d、服务是自治的: 安全和失效是隔离

e、允许的连续, 分离部署客户机和服务器

f、基于软件组件和分布的对象,依赖服务的协议

g、拥有并维护状态

h、基于消息, 异步的, 以及长通信

i、目标是提供服务隔离和调用的标准

三、SOA反模式

1、CRUD型接口

写应用的怎么能离得开CRUD?但是CRUD型接口暴露在SOA服务中往往意味着服务抽象不合理,这种类型接口带来的不良后果:

a、鼓励类似 RPC 的调用行为

RPC示例:

Serv.SendItemsToBePurchased(Array[] items);
Serv.ShippingAddress(stringAddress);
Serv.CheckOut();

消息示例:

//Client
string msg= "<Items>...</Items>";
MyMethod(msg);
//Server
[WebMethod]
void MyMethod(stringmsg){ . . . }

b、可能隐含带会话状态的交互

c、交互可能过于繁复

小结:CRUD型接口往往是抽象不合理的结果,它弱化了Contract,没有按业务功能来实现服务。有人说CRUD可以让调用方自己排列组合构造实现复杂服务,但是这种接口往往需要调用多次,而我们知道需要多个消息才能完成的操作是非常危险的,因为它很容易造成业务数据不一致。

2、数据层接口

这种服务以数据驱动,提供数据层DataTable、DataSet等重粒度的类型的返回,说到底还是抽象不合理造成的。这种接口的不良后果:

a、调用者隐性的依赖于你的服务的具体实现,结果将是紧耦合

b、Contract 没有提供足够的信息来使用这个服务

四、SOA服务设计指南

如何设计一个容易使用的、定义明确的接口?总体来说,你的接口必须:
ƒ(1)、鼓励以文档为中心的思考(特别提示: 如果你需要读一些别的文档才能调用现有接口,那你的服务分解可能不正确)
ƒ(2)、在 contract 中定义清晰的语义
ƒ(3)、通过对实现的封装达到松耦合
ƒ(4)、可以方便的从任何平台上调用 (WS-I base profile)
ƒ(5)、用一个完整的工作单元代表一个业务流程

想要真正设计实现一个容易使用定义明确的接口并不容易,有几个经验可以指导我们的实际开发工作。

1、面向接口编程

服务接口抽象非常重要,接口抽象的同时要定义契约,定义schema,接口一旦确定以后很难修改,所以SOA接口抽象的好坏决定SOA服务的成败。

对于一般的SOA服务,我们可以总结如下几种类型的接口:

a、只读(查询)

b、只写 (新增、修改和删除)

c、读和写(CRUD的组合)

通常不论什么类型的接口,输入参数不宜过多,参数组合或依赖关系不能过分啰嗦复杂;而对于返回信息则是越多越具体越好。

2、设计"大块头"的接口

服务必须封装一个完全的工作单元,这种设计说明业务„系统的实现细节被封装了,不要指望调用方排列组合CRUD型接口正确完成一个业务功能。

SOA服务需要处理失败,在一个服务内部必须要有完善的异常处理逻辑,在任何情况下操作失败都不会将服务留在一个不一致的状态,不能依赖于调用者调用另一个服务来修复错误。

a、服务的分解

• 以业务文档驱动的业务流程模型

• 不要试图使服务可扩展或灵活性
b、服务的自治性

• 任何事情都不要依赖于调用者

• 预期到调用者在使用你的服务时会犯错误

• 永远不要让服务处于一种不一致的状态

个人所接触过的某些SOA服务在实现的过程中从来没有考虑过接口,因为CRUD惯了,很多人认为原子的操作就是万能的接口。

3、避免共享分布式事务
对于大块头接口,在一个长的流程中如何保持数据的一致性?这种情况下某些业务可能需要用到分布式事务。但是在SOA服务实现中,应该避免分布式事务,而应优先考虑Reservation (预约保留)模式或者补偿机制。

Reservation 模式提供了最自治的保护,Reservation 模式的好处:

a、数据的一致性依赖于服务和它的业务规则

b、一致的处理失败情形 (超时,通讯中断等)
Reservation 模式的问题:

a、你必须为reservation定义业务规则 ,系统有变得更加复杂的风险

b、进度中工作项的隔离不会像二次提交的事务(2PC)那样自动化

当然我们还可以采用补偿方式,但不要依赖于调用者来完成,实在不能系统自动解决则人工介入。

4、保证幂等性

重复消息是SOA服务实现中非常常见的问题,你永远不要指望调用方每次请求消息不一样,对于读操作,重复消息可能无害,可对于写操作很可能就是灾难。Idempotent (幂等)模式用于处理重复的消息非常合适。Idempotent (幂等)模式的基本处理思路是:

a、调用者给消息一个唯一请求 ID 标识

• 服务的Ccontract 可以说明这是必须的

• ID 标识一个工作单元,这个工作单元只应执行一次

• 工作单元ID可以是Schema的一部分,也可以是一个定制的SOAP Header

b、接收者在执行一个工作单元必须先检验该工作单元是否已经执行过。检查是否执行的逻辑通常是根据唯一请求 ID ,在服务端查询请求是否有记录,是否有对应的响应信息,如果有,直接把响应信息查询后返回;如果没有,那么就当做新请求去处理。

Idempotent 模式的好处:

a、服务的自治性增强了,不需要依赖于调用者作正确的事

Idempotent 模式的缺点:

a、需要为缓存响应消耗大量的存储空间

b、需要为缓存管理付出性能的代价

5、避免共享Schema

一个很常见的问题,对于多个服务,应该用同样的 Schema还是每个服务定义自己的 Schema?

你可能会说,服务实现后就非常稳定了,应该很少改动。所以一个共享Schema搞定,维护也只维护一份,这样不是很爽吗?

但是,业务变化是永恒的主题,服务也需要拥抱变化。你永远也不能保证服务实现不会变化,也不能假设每次变化共享Schema只做增量永远向下兼容。

所以,根据实际开发和维护经验,最合理的做法是给每个服务定义自己的 Schema(哪怕现有的Schema暂时都是一模一样的),因为共享 Schema 使得独立变更每个服务比较困难,并给服务的调用者带来不必要的麻烦。

Duplicate Is Evil,但服务实现中应该避免假设适当重复,这样应对变化才能更加游刃有余,体会到这种好处需要开发认知能力提升到一定高度。

6、重视性能

需求即功能,性能也是一项功能。对于开发人员,没有人愿意自己开发的接口被人说性能差。我们应该在设计时就考虑性能,在项目开发的整个过程中要对服务性能进行反复测试,循序渐进改善系统性能。
„主要有两种量化SOA服务性能的方法:

a、机器吞吐率 (requests/sec)

b、响应时间 (time to first/last bytes)

优化服务性能的方法通常有如下几种:

a、减少本地数据IO,尽量减少调用本地的web服务以减少网络IO;

b、尽量使用原始数据类型参数,避免在调用之间维护服务器状态;

c、考虑对服务的结果进行缓存;

d、要有批量多次的思路,选择适用的大数据包传送方式,或者对结果进行压缩;

e、异步处理,但会增加开发和维护难度。

7、其他

a、避免循环调用

服务之间相互引用,或者几个服务之间隐式地构成闭环调用,这种情况会引发无意识的递归造成系统崩溃。

b、重视安全性
服务调用的安全性也是一个问题。可以通过ESB实现服务注册、角色授权、权限分配等基本安全控制,但是仍不能保证传输和调用安全性。可以采用一些技术解决方案增强安全性,比如微软的WSE(Web Services Enhancements)。

参考:

<<SOA服务设计原则>>

<<Understanding SOA with Web Services(中文版)>>

http://www.infoq.com/cn/news/2009/09/reservations

SOA服务设计与实现的几个语言无关的原则速记的更多相关文章

  1. SOA 实现:服务设计原则

    http://www.ibm.com/developerworks/cn/webservices/ws-soa-design/ 引言 面向服务的体系结构(Service-Oriented Archit ...

  2. 老徐FrankXuLei 受邀为花旗银行讲授《微软WCF服务分布式开发与SOA架构设计课程》

    老徐FrankXuLei 受邀为花旗银行上海研发中心讲授<微软WCF服务分布式开发与SOA架构设计课程> 受邀为花旗银行上海研发中心讲授<微软WCF服务分布式开发与SOA架构设计课程 ...

  3. 微观SOA:服务设计原则及其实践方式

    大 量互联网公司都在拥抱SOA和服务化,但业界对SOA的很多讨论都比较偏向高大上.本文试图从稍微不同的角度,以相对接地气的方式来讨论SOA, 集中讨论SOA在微观实践层面中的缘起.本质和具体操作方式, ...

  4. 企业SOA架构设计理论

    SOA简介 SOA(Service-Oriented Architecture,面向服务架构)是一种将信息系统模块化为服务的架构风格.拥有了服务之后,我们就可以迅速地将这些服务按不同方式重新组合,从而 ...

  5. SOA架构设计经验分享—架构、职责、数据一致性

    阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DD ...

  6. SOA架构设计(转发)

    阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DD ...

  7. [转]SOA架构设计经验分享—架构、职责、数据一致性

    阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DD ...

  8. 【转】SOA架构设计经验分享—架构、职责、数据一致性

      1.背景介绍       最近一段时间都在做系统分析和设计工作,面对的业务是典型的重量级企业应用方向.突然发现很多以往觉得很简单的问题变得没有想象的那么容易,最大的问题就 是职责如何分配.论系统架 ...

  9. 高可用服务设计之二:Rate limiting 限流与降级

    <高可用服务设计之二:Rate limiting 限流与降级> <nginx限制请求之一:(ngx_http_limit_conn_module)模块> <nginx限制 ...

随机推荐

  1. 【java】:常用工具类

    PS; 平时用到的一些工具类,验证非空.字符切割.时间转换.金额转换 package com.jws.common.util; import java.io.UnsupportedEncodingEx ...

  2. easyui form表单提交应注意的问题

    今天在一个项目中用到表单提交,代码如下: $('#CreateForm').form('submit', { onSubmit: function () { ajaxCreateFrom(this, ...

  3. CAD二次开发 - 可缩放块(四)

    1.说明 可进行缩放性注释的对象有:文字.标注.图案填充.公差.多重引线.块及属性. 2.为图形添加.删除注释比例步骤 1)使用AnnotationScale类(在DatabaseServices命名 ...

  4. sharepoint 网站创建

    打开开始菜单,右键sharepoint管理中心以管理员身份打开 打开管理web应用程序菜单,并新建web应用程序 新建web应用程序配置,大多数采用默认配置. 建议自定义端口号,URL的端口号和设置的 ...

  5. juery与表单中name="nodeName"引起的冲突

    引入jquery时,表单中如果有name="nodeName"的表单项,会有一些奇怪的冲突. 表单HTML代码如下: <form id="formAddEquipN ...

  6. VS2013 密钥 – 所有版本(Visual Studio Ultimate,Premium,Professional,TFS)

    Visual Studio Ultimate 2013 KEY(密钥):BWG7X-J98B3-W34RT-33B3R-JVYW9 Visual Studio Premium 2013 KEY(密钥) ...

  7. 基音周期提取2-基于线性相关系数的Matlab实现

    基音周期提取2-基于线性相关系数的Matlab实现 基音周期提取结果 图1 基音提取结果 算法说明 线性相关系数 也称"皮尔逊积矩相关系数"(Pearson product-mom ...

  8. Android本地数据存储复习

    Android本地数据存储复习 Android无论是应用层还是系统层都需要在本地保存一些数据,尤其在应用层中使用的就更为普遍,大体有这么几种:SharedPreference,file,sqlite数 ...

  9. SVN修改用户名与密码

    由于在svn的界面中并没有为我们提供直接更换用户名密码的地方,所以一旦我们需要更换用户名的就需要自己想一些办法. 解决方案如下: 在Eclipse使用SVN的过程中大多数人往往习惯把访问SVN的用户名 ...

  10. H3C IRF mad检测

    这里 irf 两个交换机 S4 S5 S4 S4的MEmber id 为1 IRF member 1 renumber 1 S4的 irf 优先为10 irf member priority 10 链 ...