SOA with REST 读书笔记一

最近刚拿到马国耀翻译的这本《SOA with REST》。大致翻了下,大赞,觉得是本可比肩《REST实战》和《企业应用架构模式》的好书,就决定写几篇读书笔记,里面会包含书上的观点,同时会掺杂一些自己的理解,算是注解吧。

一 服务术语

  • 1.服务:是一个软件程序,通过发布的技术接口(服务契约)实现其功能
  • 2.服务契约:一般指一个服务保留的接口,不会包含任何的实现和细节
  • 基本的流程是 : 外部请求 —–> 服务代理 —–> 服务契约 ——> 消息处理逻辑 —–> 核心处理逻辑
  • 3.服务能力:一个服务契约向下会分解为一组服务能力,每一个服务能力体现了该服务对外部提供的功能
  • 4.服务消费者:具体访问服务的调用方。
  • 5.服务代理:是一段不公开技术接口的事件驱动程序(常称为过滤器、拦截器、监听器)。用于在服务运行时截取消息。整体上分为主动和被动两种模式。
  • 主动模式:截取到消息后,修改消息内容,例如脏字过滤。
  • 被动模式:截取到消息后,不做任何的修改,例如日志记录。
  • 6.服务组装:顾名思义就是将一组服务进行拼装。

二 服务术语上下文
1.服务和REST
构建服务有很多种方式,大体上看有分布式对象(DO),RPC,REST.每一种都有自己的适用场景。

1.1 DO 风格的架构实例有:CORBA/RMI/EJB/DCOM/.NET Remoting
优势:简化了远程通信中的一些细节,让使用者只需要关注于业务逻辑。
缺陷:

  • 1.支持抽象的工具是对象,但是在不同语言中对于对象有不同的定义,所以基本就限定在某个特定语言上。很典型的例子就是java中的EJB和.net中Remoting。
  • 2.也正是因为这种架构风格会限定在某种语言上,所以必然带来的是客户端和服务端的高度耦合
  • 3.没有定义一套统一的接口,这种限定了数据流的交互方式,而没有定义服务语义层面的设计风格,简单说非标准化,在复杂系统交互上会带来一些混乱和沟通上的成本。
  • 4.不支持数据流和管道

1.2 RPC 风格的架构实例有:SOAP/XML-RPC/Hessian/Flash AMF/DWR

  • 1.基于动词为核心的架构建模,还是停留在面向过程的方式构建服务
  • 2.Hessian只定义了数据的传输,没有定义数据的转化。SOAP将数据的传输交给了http,自己在此基础上定义了数据的转义,但是由于需要过多的考虑服务的QOS,所以太过复杂,一个过于复杂的系统就很依赖于技术专家,到最终这个系统会演变成一个专家系统,对于后续的开发和维护都是一个很大的陈本,若是这个技术专家发生任何的变动会给整个项目造成很多的困扰。
  • 3.不支持操作语义对于中间件的支持

1.3 REST 架构实例:http(万维网)
因为现在的万维网就是基于REST架构进行设计的。互联网的特点是什么?可伸缩性无法预估、对于松耦合的高要求、简单性。越是复杂的系统它的设计就应该越是简单,因为你无法预估将来面临的各种千奇百怪的问题。
所以REST风格的架构约束都是围绕这两点展开的。例如:客户端服务端模式,无状态,统一接口,可缓存,分层系统,按需代码。同时互联网中的很多中间件也都是基于此来设计:例如浏览器、网关、web服务器的缓存都是基于统一接口(get请求)来考虑的。也正因为如此,若是你用RPC或是DO风格来架构互联网性质的系统就会感觉处处受制,处处困难,背道而驰的路总是越走越窄的。
从系统耦合的角度看 DO >> RPC >> REST .

2 REST服务和SOA
http是应用层协议,带有自己的语义,不是传输层的协议,因为现在所有的互联网中间件都是基于对http友好的,所以如何构建服务上都是基于http.在这个基础上再定义自己的交互方式,我们也可以理解为自己的设计模式,CRUD是一种设计模式,CQRS也是一种设计模式,SOA、DCI、MVC、DBC也都可以算是。
总结看http是基于rest风格的应用协议,SOA、CRUD、CQRS是在此基础之上的设计模式。这些设计模式在自身的架构系统上或多或少都与REST本身有些冲突,但是在业务架构上都有其独有的优势,我们要做的是取其长处,避其短处。还有就是REST研究是系统运行时的架构,而其他都关注的是软件源代码的组织结构。两者不在一个层面上。有点架构和设计的区别。

  • 2.1 CQRS虽然已经提出很久,但是目前还是只是非主流市场,基于此国内较为有名的框架就是AXON。国内对于这种设计模式研究比较深是Jdon网站,当年同javaEye竞争,可惜失败了。
  • 2.2 DCI现在更多是框架设计中较多,无论是spring还是struts核心架构都是基于此。
  • 2.3 MVC最为知名了,也是流行最广的设计模式,行为、展示、逻辑处理的分离。
  • 2.4 SOA更多站在更高的层次看问题,解决是大系统之间交互构建,大的设计原则有八点:

1.服务松耦合:依赖性最小化
2.服务抽象:最小化元信息的可用性
3.服务的可组合性:最大化可组合性
4.标准化的服务契约:实现契约的标准化。这点应该也是借鉴了DBC(契约式设计风格),或者说DBC带来的最大作用就是契约化,前置、后置验证及不变式。
5.服务的可重用:实现逻辑和契约的通用性和可重用性
6.服务自治:实现独立的功能边界和运行环境
7.服务无状态:实现逻辑的自适应性和去状态管理,如此可增加服务的可见性、可伸缩性和可靠性,但是带来问题就是服务的验证,REST是通过缓存来解决。
8.服务的可发现性:实现元信息的交流 ,结构语义的可见性由于参数类型化

综合的看SOA的架构设计原则也是借鉴和吸收了其他设计模式的优点,并形成了一套自己的理论。具体详解可见Thomas Erl 的《SOA服务设计原则》,写的非常详细。
所以目前最适合互联网网站的架构是REST+SOA+DDD,因为这三者有其共同点,一脉相承。REST是基于资源进行架构,SOA也适用这点,DDD则就是面向对象的设计模式。

3 REST的缺陷
正所谓有得必有失,一个东西有其优势的地方,也必然有劣势的地方,为了满足互联网的特点,REST在某些方面也做出了一些牺牲,最明显的一点就是性能。对于实时性要求的场景下,它是有点无能为力的,这个也为什么淘宝的HSF,B2B的dubbo底层通信还是用RPC,甚至定义自己的通信协议。然后在最外层套一个REST的外衣,说自己也是基于REST风格的架构设计了,其实它们不过是基于http的CRUD。在一些可伸缩性可预见,同时实时性要求比较的场景下,还是不建议使用REST,RPC是个很好的选择。
因为自己搞是JAVA,所以一直很揣测证券交易系统是如何实现如此高速的下单交易的,是门技术活啊!

三 题外话
Fielding博士一直强调,没有实现超文本驱动的REST都是伪REST,超文本驱动天然跟SOA冲突,因为服务不需要超文本驱动,只需要对应的服务能力,所以在之前一直很怀疑REST和SOA如何融合来解决这个问题,或者说SOA只需要实现到REST的二层模型即可,希望看完本书可以得到答案。

作者: inter12

在这苦短的人生中,追求点自己的简单快乐

发表评论

电子邮件地址不会被公开。 必填项已用*标注