最近刚拿到马国耀翻译的这本《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的二层模型即可，希望看完本书可以得到答案。
0 条评论。