读书笔记： 《分布式JAVA应用 基础与实践》 第二章 大型分布式JAVA应用与SOA

一、为什么需要 SOA

当应用获得用户的认可后，会不断发展。以豆瓣网为例，早期豆瓣网只有书评的功能，随着用户的增加，发展出今天的豆瓣社区，豆瓣读书，豆瓣电影和豆瓣音乐等功能。这些功能有各自的特色，但又有很多可公用的业务逻辑。例如用户信息、评价等，如果各个系统都维护自己的用户信息和评价，会造成的问题一方面是当修改评价逻辑或用户信息的读取方式时，所有系统都要修改，相当复杂；另一方面是每个系统上都有多种业务逻辑，就像在一个小超市中，，一个人负责收银、清洁、摆货、咨询等各种各样的事情，当顾客多到一定程度时，这个人就无法负责这么多事情了，系统也同样如此。

第一个现象是系统多元化带来的问题，可采用共用业务逻辑的部分进行抽象的方法，形成多个按领域划分的共用业务逻辑系统；第二个现象是系统访问量、数据量上涨后带来的典型问题，同样可采取拆分系统的方式来解决。

在构建了共用业务逻辑系统和拆分系统后，最明显的问题就是系统之间如何交互。如果不控制，会出现多个系统之间存在多种交互方式： HTTP 、 SOCKET 、 HESSIAN 、 RMI 、 WEBSERVICE 等；同步、异步等方式可能都会出现，导致开发人员每访问一个子系统，都可能要学习不同的交互方式 more 时也会造成各开发团队重复造轮子，对于应用的性能、可用性也带来极大的挑战。

对以上问题，很容易想到的办法就是统一交互的方式， SOA 无疑是实现这种方式的首选。

SOA 全称是面向服务架构（ Service-Oriented Architecture ），它强调系统之间以标准的服务方式进行交互，各系统可采用不同的言语、不同的构架来实现，交互则全部通过服务的方式来进行。

 

二、 SOA 平台带来的挑战

1．  服务多级调用带来延时

如 A 调用 B 、 B 调用 C……

2.       调试 / 跟踪困难

3.       更高的安全 / 监测的要求

4.       现有应用的移植

5.       服务 QOS(Quality of Service) 的支持

6.       高可用和高度可伸缩

7.       多版本和依赖管理

 

 

三、 SOA 平台的实现

实现 SOA 时，可参考的标准或概念有 SCA 、 ESB ，同时业界也有一些实现了 SCA 、 ESB 的框架。

 

1. 基于 SCA 实现

SCA ，由 IBM, Oracle( 包括之前的 BEA ， Sun) ， RedHat, SAP 及 Siemens 等共同制定的规范，规范的名字定为 Service Component Architecture, 简称 SCA 。

SCA 标准景要定义了如何发布服务、如何调用服务及支持的通信协议和交互方式三方面的内容。

 

1.1 发布服务

以接口方式提供，要求系统本身已有相的接口实现，通过 XML 定义。

1.2. 调用服务

同样可通过简单地定义 XML 即可实现

1.3. 支持的的通信和交互方式

SCA 标准默认提供的通信方式为 SCA,Webservice 和 JMS 三种。 SCA 方式指由框架根据运行情况来选择采用相应的通信方式，如框架发现需要调用的服务在同一 JVM 中，则会自动切为本地调用，如在不同 JVM 中，则会采用 Webservice 或 JMS 等方式。 Webservice 的实现为 HTTP 方式； JMS 则可用多种方式，取决于具体的 SCA 框架。

在交互方式上， SCA 标准没有明确的定义。

 

1.4 常用的 SCA 实现框架 Apache Tuscany 。

1.4.1 发布服务 ： Tuscany 遵守 SCA 标准编写，支持多种发布方式，包括发布为 Webservice 、 Ajax 、 Corba 、 erlang 、 JMS 、 Jsonrpc 、 RMI 、 EJB 、 HTTP 及 RSS 方式。

1.4.2 调用服务： 和发布服务一样，支持多种应用集成及调用方式，并包括了多语言的支持。

1.4.3 通信及交互方式： 比 SCA 标准多出了很多，例如对 Ajax 、 Jsonrpc 、 RMI 等都提供了支持。

1.4.4 调试跟踪： 服务器抛出异常时，会将此信息带回到调用端

1.4.5 依赖管理 ：没有在 SCA 的标准上做扩展，因此仍然不是很好实现。

1.4.6 高性能和高可用： 没有做专门处理，如须确保性能，可自行基于 Tuscany 扩展实现交互方式。

 

2. 基于 ESB 实现

ESB 和 SCA 不同，它不是标准，可以认为是概念，核心思想是基于消息中间件来实现系统间的交互。基于消息中间件所构建的此系统交互的中间场所称为总线，系统间交互的数据格式采用统一的消息格式，由总线完成消息的转化、路由，发送到相应的目标应用。

 

通常 ESB 框架须具备以下五个要素

1)      标准的消息通信格式

2)      消息路由

消息路由是指当总线接到消息后，根据消息中的数据来决定需要调用的系统。

3)      支持多种的消息交互类型

请求 / 响应和发布 / 订阅方式

4)      支持多种网络协议

总线要和多个系统进行交互，通常要支持多种网络协议，例如 TCP/IP 、 UDP/IP 、 HTTP 等

5)      支持多种数据格式并能进行相互转换

多个系统均须发送消息至 总线，并由总线进行消息转发，但各个系统消息中的数据格式可能不一致，此时总线要支持数据的转换。

 

2.1 Mule 为常用的 ESB 实现框架之一

2.1.1 发布服务： Mule 支持以 Webservice 、 jms 等方式将 Spring 或普通的 JAVA 对象发布为 Mule Service ，配置上较为简单，但和 Tuscany 比还是弱了点

2.1.2 调用服务： 相对比较麻烦，这是由于 ESB 强调一切都以消息的方式发送给总线决定的。

2.1.3 通信及交互方式： 支持 Webservice 和 jms 两种通信方式。可明确指定 synchronous 的参数来实现同步通信，或不指定默认为异步通信。

2.1.4 调试 / 跟踪： 未提供特别支持

2.1.5 依赖管理： 本身未提供支持，可通过开源框架 MuleGalaxy 实现。

2.1.6 高性能和高可用： 未做专门处理

 

 

四、总结

SCA 标准及 SCA 标准实现的框架对于服务的统一交互支持得很好， ESB 及 ESB 框架则更适用于需要解耦方式的服务交互及复杂的多服务交互场景，但无论是 SCA 标准、 ESB ，还是已有的相关框架，在实现一个大型应用的 SOA 平台时都仍然有不少需要自行扩展实现的地方，特别是在调试 / 跟踪、依赖管理及高性能、高可用方面。

 

作者认为，对于一个更加完善的 SOA 平台 , 还应具备以下几点：

1.       支撑集群环境

2.       完善的服务治理

服务治理的主要目的是为了保障服务能够稳定、高性能地运转。之前提及的依赖管理也属于服务治理的一项，服务运行状况的监测、服务的安全控制、服务的流量限制、服务故障根源的推测及服务可用性的保障也都属于服务治理的范畴。要实现这些功能仅靠 SOA 平台还很难做到，通常还要有系统架构的配合。

3.       服务 QOS(Quality of Service) 的支持

指 SOA 平台按照服务配置的 QOS 来分配相应的硬件资源，例如 A 服务的 QOS 配置为每秒最多支撑 5000 请求，且响应时间 95% 需要在 1 秒以内， SOA 平台要能收集目前服务的运行状况来合理分配机器资源，要做到这点难度非常高。