大数据分析：SOA面向服务架构解读

一．SOA概述

SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。 SOA 并不是一个新鲜事物，而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务，但是其整体设计却是面向服务的。由于 SOA 考虑到了系统内的对象，所以虽然SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。
 
SOA 系统原型的一个典型例子是 CORBA，它已经出现很长时间，其定义的概念与 SOA 相似。SOA 建立在 XML 等新技术的基础上，通过使用基于 XML 的语言来描述接口，服务已经转到更动态且更灵活的接口系统中，CORBA 中的 IDL 无法与之相比。图 9-13 描述了一个完整的 SOA 模型。

在 SOA 模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。
 

二.SOA 设计原则

在 SOA 架构中，继承了来自对象和构件设计的各种原则，例如，封装和自我包含等。那些保证服务的灵活性、松散耦合和复用能力的设计原则，对 SOA 架构来说同样是非常重要的。关于服务，一些常见的设计原则如下：
 
（1）明确定义的接口。服务请求者依赖于服务规约来调用服务，因此，服务定义必须长时间稳定，一旦公布，不能随意更改；服务的定义应尽可能明确，减少请求者的不适当使用；不要让请求者看到服务内部的私有数据。
 
（2）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
 
（3）粗粒度。服务数量不应该太多，依靠消息交互而不是远程过程调用，通常消息量比较大，但是服务之间的交互频度较低。
 
（4）松耦合。服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有数据等，对服务请求者而言是不可见的。
 
（5）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，例如，一个服务对安全性方面的要求；也可以是与业务有关的语义方面的内容，例如，需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。
 

三．SOA的架构层次

进行SOA类型的架构设计就需要搞清楚SOA架构模型才行。并不能想当然的对系统进行简单的拆分就行，需要搞清楚SOA的架构模型是怎样的，每一块是干什么用的，这样设计由分析阶段输出的需求时才能正确的划分职责。
 
如果把SOA的架构简单的理解为是多个子系统之间的整合其实有点太过于简单，也没有真正搞清楚SOA的架构模型。按照SOA的正确方法论及目标模型，其实SOA在实现架构落地上，需要考虑到对服务的组合，不断的重用现有的服务，让企业应用可以逐步集成，快速实现业务的迭代。其实这就是本节要讲的服务的分层，通过分层将服务按照使用类型进行分配，上层服务对下层服务的包装，下层服务负责原子性的操作，上层服务对下层服务进行业务性的组合。
 
我们来看具体的每一层的作用及主要职责。

 2.1.应用服务（原子服务）

应用服务就是诸如：订单服务、仓库服务、销售服务、客户管理服务，这些服务直接对应不同的应用系统，直接服务这些应用系统的原子操作。订单服务直接原子性的插入订单，没有任何跨其他服务的分支逻辑。仓库服务只管自己的仓库逻辑。同样其他的应用服务只管好自己的职责，杜绝对其他服务的调用。
 

 
应用服务位于UI与后台之间，后台我们可以认为它是一异构的系统或者是数据库之类的。应用服务的位置位于前端与后端之间，起到类似一个服务API的作用，但是SOA中的服务还远远不止这一个应用服务，如果我们的SOA架构中只有一种类型的服务，那么这会增加我们系统的耦合程度，因为你没有对系统的服务进行层次的划分，你的业务功能会直接的落到某一个应用线上的服务，继续往下看。

 2.2.组合服务

组合服务是对应用服务的一个组合,根据实际项目的规模大小,不一定非要进行物理的隔离,在代码层面的服务化也是可以的,在将来的某一天有必要的情况下再进行物理的拆分,毕竟物理的拆分有着严重的成本和代价，对系统的稳定性带来很多挑战。所以经验告诉我们必要的时候在进行拆分。”分布式系统设计的第一个原则就是尽量不要分布式“，这是马丁.福勒大师说的，现在理解确实感同身受。
 

组合服务对下层的应用服务进行了组合，完成了一个基本的业务动作，应用服务中是最基本的基础性的原子性的操作。但是在复杂的业务需求下大部分业务功能都需要跨越多个应用线来完成一个最外层的企业动作。提交订单可能需要穿过很多应用线，订单管理、仓库、财务等等环节。所以这里我们还需要一个能在最外层对组合服务进行编排的业务服务。这个编排服务可以完全是自动化的，通过工作流引擎进行组合自动化来完成，这对企业应用的自动化流程很有意义。

 2.3.业务服务（编排服务）

业务服务是最外层的服务，向下编排了组合服务。业务服务位于最上层，当需要有跨越多个应用线来完成的业务，这个业务就放入业务服务中。比如提交订单，先检查库存、扣减库存（冻结库存），然后下单，再往后通知财务，再往后通知物流等等都是一个复杂的企业服务线。这种最外层的业务逻辑如果你不进行SOA分层然后将其放入最外层的业务服务中，你把它放入任何一个应用线都会使系统调用混乱不堪。所以问题就是需要进行纵向的划分层次。如果进行了SOA的层次划分后就不会出现互相乱用的情况。其实这里可以参考阿里的服务设计方法。（李智慧写的一本大型互联网架构与实践里面也讲到了服务要划分层次）
 

 
 
当在业务服务中执行的业务逻辑时，需要跨越多个应用线来完成。这部分的逻辑也说是职责，如果不放入这个位置，放在哪个应用线都不合适，放入哪个应用线都会使系统调用出现混乱。其实这里的问题就是我们不能用一个维度来进行SOA系统的设计，本来服务就具有组合特性，所以适当的提升服务的层次是有好处的，但是应用服务和组合服务可以在代码层面上进行构建，而业务服务也叫编排服务是需要进行物理隔离的，毕竟考虑到系统复杂度和稳定性问题这是值得的。在排查问题，系统性能、稳定性等等方面，物理的隔离有一定的作用，毕竟业务服务本来就是来组合多个应用线的，这样做会使整个系统架构很清晰。

 四.SOA架构特点：

系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】
 
系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】
 
业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

 五.SOA架构和微服务架构的区别

首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。
 
 1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
 
 2.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
 
 微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想