对SOA面向服务架构的回顾

SOA的定义

SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

在SOA里面一个关键词就是服务，服务可以理解为有价值的，可以复用的业务或技术能力。其次服务是底层资源能力对外的一种暴露方式。因此对于SOA我们可以理解为：

SOA是一种架构方法，将传统的单片式应用打破，分解为离散的、自治的业务服务，利用标准提升他们的互操作性，从而可以更好地共享、重用和组装，快速构建复合的应用从而满足业务需求的变化。

虽然不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

综合以上，结合SOA咨询和实践的经验，可以对SOA给出更加容易理解的定义即SOA本身是一种架构方法论，该方法论的重点是找寻到企业业务系统内可以复用的服务，这些服务同时具备粗粒度，离散，松耦合，无状态等基本服务特征；同时这些服务可以灵活的进行服务组合，服务组装和编排，以灵活快速的满足业务的变化。

再举个简单的例子来说明SOA架构思想。

传统的活字印刷术，用于印刷的3000-4000个字即是最基础的原子服务，有了这些原子服务我们很容易通过这些活字去排版整篇文章。文章内容有调整我们也只是需要调整这些原子服务的顺序。但是如果全是单个汉字我们其实排版工作量还是很大，所以再向上我们会出现词组或常用短句，这些即是组合服务，这样我们排版速度可以增加。

但是可以看到词组或短语的可重用程度降低了。所以越到组合服务或流程服务，复用越困难，但是要是能够复用却能大大提升效率。

从上面可以看到，SOA架构思想核心就是找到服务，组合和组装服务两点。

我们来举个例子详细说明SOA架构思想：

我们以注册一家新公司来举例，可以看到如果我们要注册一家新的公司，我们需要和银行，政府部门中的工商，税务，质量监督等多个业务部门到交道，最终完成新公司注册的完整过程。

其一：找到可复用服务

而对于各个业务部门就是我们说的业务组件，我们首先就是要看业务组件本身对外提供了什么标准的服务能力出来，即先把各个组件可共享，能够复用的能力识别出来。这些业务组件本身提供很多业务服务能力，在这里我们只列举一些和公司注册相关的能力，如下：

其二：组合和编排服务完成业务

在进行一个新企业的注册流程中，涉及到核名，办理验资报告，领取组织机构代码证等诸多的业务活动，这些业务活动都需要和上面说的业务部门（业务组件）打交道才能够完成。

而要完成整个业务流程，就是将上面业务部门暴露的服务能力基于业务活动的流转进行组装起来，这样就完成了一个完整的业务，如下：

可以看到完成整个企业注册业务流程，本身就是底层的接口服务能力的组合和组装。

如果注册流程中增加了一个验证企业信用要求，那么我们也很容易在原来的业务流程中增加一个活动节点，该活动节点调用银行的信用验证服务能力接口即可。即通过接口服务的灵活组合，组装，能够很容易的响应业务流程的变化。

SOA参考架构

Open Group SOA Reference Architecture 标准提出了一种基于 SOA 解决方案的参考架构。它提供了 SOA 分区和分解到层的高度抽象，每一层都提供一组 SOA 解决方案所需的功能。

上述SOA参考架构，可以分为9大层次：

操作系统层：

操作和 IT 系统层可捕获组织的基础架构、包括新的和已有的，这是在设计、部署和运行时支持 SOA 解决方案所必需的。该层代表实际运行时基础架构和运行在该基础架构上的其他 SOA 架构的交叉点。

服务组件层：

服务组件层包含软件组件，每个软件组件提供服务或者服务上操作的实施或 “实现”。该层也包含功能和技术组件，方便服务组件实现一个或多个服务。服务组件在其功能以及其管理和服务交互质量中反映它们所代表的服务定义。他们将服务合同 “绑定” 到操作和 IT 系统层的服务实现中。服务组件驻留在支持服务规范的容器中。服务组件层通过包装和支持松耦合实现 IT 灵活性。

服务层：

服务层由所有在 SOA 中定义的逻辑服务构成。该层包含在设计过程中使用/创建的服务、业务功能和 IT 表现形式的描述，以及在运行时使用的合同和描述。服务层是一个平行层，提供 SOA 中支持的业务功能，并介绍 SOA 中支持的服务的功能。

业务流程层：

业务流程层包含流程表示、构成方法和构建块，聚合松耦合服务使其成为一个与业务目标保持一致的有序流程。数据流和控制流用来支持服务和业务流程之间的交互。交互可能存在于一个企业中，也可能跨多个企业。SOA 参考架构中的业务流程层在连接业务水平要求和 IT 级解决方案组件中充当一个中央协调角色，通过与集成层、服务质量层、信息架构层以及服务层协作完成。

消费者层：

消费者层是消费者的入口，不管是人、程序、浏览器或者自动操作，以及与 SOA 相互作用都可从此切入。这使得一个 SOA 解决方案可以支持一个客户端独立的、通道不可知的功能集，通过一个或多个通道（客户端平台或设备）独立消费以及开出账单。

集成层：

集成层是一个横切关注点，支持和提供调节能力，包括变换、路由和协议转换，从服务发起者向正确服务提供者传输服务请求。它支持实现一个 SOA 所需的功能，比如路由、协议支持和转换、消息传递/交互风格、异构环境支持、适配器、服务交互、服务实现、服务虚拟化、服务消息传递、信息处理和转换。集成层也负责维护松耦合系统中存在的解决方案一致性。这里出现的集成主要是服务组件、服务和流程层（“功能” 层）的集成。

服务质量层：

服务质量层也是一个横切关注点，支持 SOA 相关关注点的非功能性需求 (NFR)，为在任何给定解决方案中处理它们提供一个焦点。它还提供确保 SOA 满足以下需求的方法：监测、可靠性、可用性、可管理性、事务性、可维护性、可扩展性、安全性、安全、生命周期，等等。它与传统 FCAPS（过失、配置、会计、性能、安全）范围相同，从 ITIL 到 RAS（从可靠性、可用性、适用性），保持将同种管理和监控应用到今天的商业领域，对于管理服务和 SOA 解决方案来说是非常重要的，可能需要扩展来处理面向自然的服务和许多 SOA 解决方案的跨域边界。

信息架构层：

信息层负责以统一的表示形式呈现一个组织其各方面信息，正如其 IT 服务、应用程序和系统所提供的那样，保证业务需求和流程与业务词汇（词汇表和术语）保持一致。该层包括信息架构、业务分析和业务智能、元数据因素，确保包括关于信息架构的关键因素，也可被用于作为通过数据集市和数据仓库实现业务分析和业务智能创建的基础。

治理层：治理层确保一个组织中的服务和 SOA 解决方案遵守定义策略、指导方针和标准，这些均定义为一个应用于组织中的目标、策略和规章的功能，一个 SOA 解决方案将提供所需的业务价值。SOA 治理活动应该符合 Corporate、IT 和 Enterprise Architecture 治理准则和标准。

企业内SOA应用核心思想

面向服务架构很容易将SOA理解为一种技术架构，而SOA本身更多的是一种架构风格，这种架构风格和传统软件开发最大的不同则是更加体现了业务和流程驱动IT的思想，体现了IT系统组件化和服务化构建思想，体现了由于服务本身可以重用，可以通过服务的组合和编排来满足业务的实现。SOA作为一种架构风格，使需求方和供给方有了共同的语言和价值约定；SOA作为一种架构风格，使服务不再单纯的是一种技术能力，而更多的是一种业务能力和IT资产。

对于传统架构和SOA面向服务架构的区别，可以用下表描述：

面向服务则重点就是一切以服务为中心，从服务识别、服务分析、服务设计、服务开发和服务上线使用一切都是以服务为中心。但是要注意到面向服务本身不是在传统面向结构或面向对象基础上的一个新方法，而是对传统面向对象和组件化思想的提升。从前面SOA定义可以看到两个重点，一个是要找到可重用的服务，同时这些服务满足离散，自治和无状态等基本条件；其次是服务本身可以组合和编排，以满足流程整合的需要。

第一步找服务的过程，是系统分析和建模从上向下的过程，要充分体现流程驱动IT的实现，通过流程的分解，业务建模和数据建模，识别业务组件和业务能力，通过跨系统或组件的流程交互识别可重用的服务。最终形成可重用的服务资产库。

第二步服务的组装和编排则更多是从下向上的过程，对于原子服务我们可以组合为组合服务，对于业务服务我们可以通过组合和编排形成流程的服务和流程服务；最终使可重用的服务满足流程交互的需要。

在跨系统的流程集成和SOA应用集成过程中，高端建模重点则是EA企业架构或TOGAF方法论，从业务架构，数据架构和应用架构，逐层分解和展开分析来得出总体的跨业务系统流程交互和集成架构。而对于系统内的SOA应用，则重点仍然是业务组件识别，通过组件间交互得到的服务组件和服务识别，可重用的服务组件单元的提取。

同时对于企业内部的SOA实施，业务系统本身的建设也必须满足和符合SOA架构思想，如果说一个应用系统基于SOA架构，我们至少需要看到该应用系统有明确的业务组件和服务组件定义，而且组件之间满足高内聚低耦合的要求；其次对于组件间的交互都通过服务的方式进行，或者至少预留了服务接口；其次内部这些服务可以灵活的重用或组合。至于是否有内部的ESB总线反而不是重点，但是我们看到如Java开发内部的IOC机制基本也基于内部的软总线思路，实现良好的互操作性和位置透明。

SOA另外一个核心是实现两个层面的解耦。

一个是业务和技术的解耦，业务实现不再依赖于某种特定的技术或语言，只要满足业务标准都可以来实现SOA和服务，正是因为业务和技术松耦合，技术的变化对业务影响越小。另外一个方面则是操作方法和业务数据实体的解耦，对于操作方法我们后续可以通过WSDL文件定义，而传输的数据实体又可以通过XSD定义，对于传统RUP开发方法中，类似于控制类和实体类的分离。

笔者在长期的SOA规划建设和实施过程中，经常听到有人说SOA已经过时或者说SOA是国外厂商忽悠的产物。

但是很多企业在信息化规划和建设中根本没有理解SOA组件化和能力复用的思想，以为是上了一套SOA中间件或ESB产品即是满足了SOA架构要求，而SOA真正的难点则在于组件和服务的识别，共享能力的提供和开放，内部业务系统和组件基于SOA服务形成的松耦合架构关系。可以讲业务能力的组件化和组件能力的服务化是SOA最为核心的思想和指导原则。只有在这一步建设好了才谈得上进一步的基于SOA服务的流程组合和编排，端到端流程的建模设计和实现等。

服务架构规划总体方法论

以下基于企业架构思想的服务架构规划方法的总体方法论构图：

业务调研和端到端流程分析

服务架构规划的首要工作是当前业务和IT现状调研，初始阶段不能陷入细节，应从端到端业务流程分析入手，如对于工程项目建设，供应链，研发生命周期管理，财务概预核决算，从客户提出产品或服务的需求到最终的能力交付，都可以看到有不少的端到端流程，这些端到端流程是导入服务架构的基础。通过端到端流程梳理可以看到流程在多个业务部门和单位之间的协同，最终再将业务流程协同映射到跨多个业务系统或业务组件间的业务和数据协同。跨系统交互核心流程分析和梳理是识别组件或服务的一个关键步骤。

由于企业整个服务目录规划前期只会涉及到系统间协同和能力开放，因此分析到跨系统的端到端流程已足够分析和识别有价值的服务。基于自顶向下的思路我们不会马上落入到某一个业务活动，或者某一个业务系统中功能细节，而是分而治之，先将业务系统内部处理流程和逻辑看为黑盒，先分析清楚哪些能力是业务系统必须开放出去以实现跨系统流程交互的。

在跨系统流程交互分析中，自然会分析到业务协同和交互过程中传递的业务对象，我们会进一步去分析这些业务对象映射的数据对象，通过单独数据对象的分析以方便我进行单纯的数据架构建模和数据CRUD分析，这个对于后续分析和识别数据分析是相当重要的。

业务和数据架构规划

其次，基于业务和IT调研的内容，我们会初步分析和构建当前企业的流程和业务架构，数据架构和应用架构，同时在业务架构中识别和分析相关的业务组件。如果仅仅是分析到系统间的话，那么最终的业务系统就是相关的业务组件，这跟我们识别和分析的粒度密切相关。

集成架构规划

以上内容分析完成后，接着可以构建完整的企业业务系统间的集成架构视图，也可理解为当前的系统间详细接口和集成情况。这个图梳理清楚后，系统间交互的接口、交互关系已基本全部梳理清楚。对于集成架构图的形成，一方面是采用跨系统流程分析和梳理中的接口交互，数据架构CRUD分析中的数据共享和交互；一方面是由底向上的分析当前系统间已有的历史接口情况，并对接口的业务场景和对应流程进行补充梳理，以形成完整的集成架构视图。

集成架构视图做好后，可以将前期分析的端到端流程执行情况，进一步在集成架构视图上进行交互模拟，以确保核心的接口交互和服务没有遗漏。特别要注意在前面我们重点分析的是端到端流程，但是很多不是端到端流程场景，例如只跨了两个业务系统的简单业务流程或协同，业务需要进一步考虑清楚，否则会出现较多的集成接口遗漏。

从集成架构到服务架构

最后，我们需要基于集成架构视图情况，规划和梳理服务目录集，即按照服务的分层和分类来重新审视当前的系统间集成和能力共享。下面来看下几类典型服务的进一步服务识别和规划。

流程服务：注意端到端流程也是流程服务，但是该流程更加长，也很多对应到最终的流程编排和组合。因此需要从端到端流程中进一步找寻流程协作片段。这种流程片断最好是完全的自动化业务流，或者有较强的一致性和事务要求，这些都可以识别为流程服务。

业务服务：业务服务更多强调的是业务规则类服务，或者强调基于业务功能操作触发的单条数据操作类服务。业务服务将更加体现服务调用的实时性，和业务操作场景的绑定以及业务逻辑的体现。或者可以理解为对于业务流程中横向实时协同的服务都可以看做为业务服务。

数据服务：更多的是从数据CRUD分析中识别出来的服务，其中既包括了主数据，也包括了共享动态数据。一个服务如果更多是事后非实时的共享数据传递或数据查询，则更多的是数据服务。从这个层面来说业务服务和数据服务本身存在一些较难界定清楚的地方。也有一些方法是单独仅仅将主数据和共享数据中心提供出来的分析规划为数据服务，其它全部为业务服务。

服务全部识别清楚后，还需要进一步对服务进行归并去重，服务组合或拆分，服务关键属性的定义，以方便根据服务类型，服务技术分层，服务提供系统多层面来规划完整的服务目录库和服务视图。

服务架构和功能架构规划

对于服务架构规划实际上包括了两个方面的内容，如下：

服务分层规划：基于SOA架构思想对服务分层

服务功能架构规划：对于不同类型的服务采用什么技术工具进行集成和管理

所以整个规划首先是要梳理和规划清楚服务目录，服务的类型和分类，其次才是考虑采用什么样的技术手段，或者类似ESB总线集成中间件平台进行管理。

01-服务分层架构规划

企业实施SOA项目的重要任务之一就是服务交付。为此，我们需要定义服务架构愿景。有了服务架构的约束，才能确保SOA项目始终以一致的策略和方法执行服务交付，从而实现SOA长期目标。根据服务的功能和技术特性，SOA参考服务架构逻辑视图如下图所示：

其中，SOA统一服务总线的作用类似于一个服务中介，中介的责任是协调和调度业务服务，它的功能包括UDDI、适配器、消息协议转换、消息传输、服务代理等。对于SOA服务管理平台则是提供对SOA服务全生命周期管理。运行在SOA基础设施之上的服务被划分为几种基本服务类型：技术服务、数据服务、业务服务和展现服务。这些基本服务进行组合可以形成组合应用。

技术服务

技术服务是与业务无关，提供某种技术能力的服务。技术服务一般由企业内部的技术平台或技术组件提供，技术服务一般来源于企业业务需求中关于消息、日志、会话、数据访问、缓存、分布式计算、中间件服务、数据库服务等相关的非功能性需求。

技术服务本身特点是高重用度，每次服务调用数据量小但是并发量相当大，同时技术服务本身对上层的平台组件、业务组件都造成约束，一旦出现故障影响面将相当大。

对于企业私有云PaaS平台建设，与业务无关的相关技术能力（日志、消息、安全、缓存、文件、通知）等都可以抽取为公用的技术服务，以提供统一的逻辑处理和服务管控。由于技术服务本身的特点，建议的技术服务实现和接入方法最好是采用Restful Web Service+本地SDK包的方式轻量接入。

数据服务和文件服务

数据服务和文件服务本身也属于业务服务的大范畴，但是由于其开发模式、开发工具与普通的业务服务有所不同，所以将数据服务独立出来。主要是考虑在大数据量和大文件业务场景下的数据集成和传递。

对于此类服务的特点主要体现在服务调用并发量大，但是每次服务传递的数据量大，如果所有的数据都经ESB进行数据传输和转换将对ESB的性能造成巨大影响。因此对于这类服务建议是采用传统ETL+Web Service服务结合的模式进行实现。对于服务本身仅仅是实现服务代理和请求信息，而批量的数据传送等仍然是通过传统的ETL模型进行。

业务服务

业务服务是在SOA中最常被提起的。在SOA架构体系中，我们把业务服务分为两类：由业务分析人员定义的可以重用的流程服务（称为业务流程服务）和由IT人员定义的满足特定业务需求的服务。在这一节中，我们主要描述后面的这种业务服务。

业务服务的识别方法一般有两种方法：包括自顶向下的方法和自下向上的方法。

自顶向下的方法是从业务处理的流程中（比如采购请款的业务处理），分解成具体的活动，这些活动可以是自动化的，也可以是人工处理。以采购请款的处理流程为例，查询订单、网上请款、请款单生成等都是业务服务。自下而上的方法则是从当前的各个部门的业务职责和工作清单上进行业务服务的分析和识别。

业务服务本身有明确的业务价值，是特定的业务场景和业务规则的粗粒度抽象，上层业务应用和业务组件，可以通过开放和暴露的业务服务能力进行相应的服务组合，编排和协同，以满足业务流程的需要。

业务服务可以被其它业务服务或者多个业务流程服务重用。但是由于业务服务本身的无状态特性，在业务服务实现过程中需要考虑事务处理必须在服务内部完成，事务不能跨越服务的边界。

流程服务

业务流程服务也是业务服务的一个特例。它将共享的业务流程封装为服务，业务流程服务可以是一个完整的业务流程，或者是独立定义的子流程。比如“起草及审批合同”的公共处理流程就可以被定义为服务的形式，这样就可以被更高层的流程重用。这种层次的重用对于建立一致的业务处理非常有价值。

业务流程服务可以是无状态的或者是有状态的。无状态的流程服务完全是由自动化的活动组成，并且在一个单一的事务背景下执行。有状态的业务流程服务可以长期处于运行状态，会涉及到人工工作流，并包含多个原子的事务。

UI组件服务

UI组件服务主要是处理应用信息的表示，所有底层的服务都可以通过用户界面，比如门户应用系统，暴露给用户使用。门户应用被分成许多可被重用的portlet，这些portlet包含来自多个数据源的信息并且能够与底层的多个系统进行交互。通过portlet的重用性，就可以实现表示逻辑的复用；通过组合portlet就可以灵活的开发门户应用。同时还可以根据企业业务需求支撑iframe技术。

UI组件服务跟传统的运行库（library）相比，门户页面改动更灵活方便，但由于网路延迟，消息处理延误等因素，效能会稍微降低。所以，通常不会将通过服务总线调用展现服务。

组合服务

组合应用是指主要在共享服务之上构建的应用。常见的组合应用包括门户应用、B2B流程等。业务、数据和连接在以服务的形式开发完成后，组合应用就可以利用这些服务完成业务的需求。这通常也是服务自顶向下的识别方法：首先确定组合应用的流程，然后将组成这些应用的服务识别出来，之后再进行设计和开发。随着新的服务不断增加，组合应用也会不断演变和扩展。在SOA架构下，这样就提供了一种基于服务的、可以粒度更小的、渐进式的应用开发方法，可以很大程度上减少项目的风险。

业务流程可以表现为业务流程服务或者组合应用，两者的区别在于是否将业务流程封装为共享服务。业务流程服务暴露为共享服务，并且必须遵循服务的治理等规则。如果一个流程不需要被共享，则没有必要封装为共享的业务流程服务。理论上讲，没有被共享的业务流程和利用共享业务服务编排的业务流程服务，都可以称为组合应用。

随着服务的增加，通过快速组装形成新应用的能力就会提高。最终组合应用甚至可以完全能够由现有的服务来组合完成，从而极大地减少开发的投入，降低IT的成本。下图描述了SOA参考架构中各个层次是如何关联，如何被调用的，以及如何映射到不同的应用系统中，可以作为组合应用实现层次参考：

01-服务功能架构规划

对于企业私有云PaaS平台中的服务层，一方面是需要实现纵向的SOA服务共享和能力开放，一方面是要实现上层业务组件的业务服务和流程协同。因此服务层已经不是传统企业信息化架构中单纯的ESB服务总线平台能力，而需要扩充更多的内容进行补充。

在进行服务层功能架构规划前，首先分析企业内部SOA集成和共享需求，如下：

从上表的需求分析可以看到，根据业务场景和交换类型的不同，往往需要服务层提供不同的服务开发方法和服务集成技术来进行支撑，而最终接入和注册的服务又通过SOA中的服务总线形成统一的服务目录库进行发布和集中管控。

结合传统的ESB参考架构和企业实际业务集成和服务共享需求，功能架构规划可以参考下图：

服务集成整体功能架构设计

在私有云PaaS平台总体架构下，服务总线的概念已经超越了传统的ESB。为了进一步满足对大数据服务和集成、技术服务、业务服务等不同服务类型的高性能和高可靠性支持，SOA服务总线必须要整合原有的ESB企、数据集成和交换平台、轻量服务总线等各种总线能力，并通过服务目录库和统一的服务治理和管控平台，形成一个完整的SOA服务总线架构体系。

基于企业私有云PaaS平台的实际实践，给出SOA思想的总体功能架构设计图如下：

在该图中可以看到，整个SOA服务总线架构包括了服务总线（ESB业务服务总线、数据服务总线、技术服务总线）、BPM、规则引擎、元数据、服务目录库、基础管理、服务管控几个方面的核心内容。具体描述如下：

业务服务总线

由传统的ESB承担业务服务的注册和接入、服务能力的共享。其中包括了服务鉴权、服务路由、服务代理、消息事件管理、消息数据映射等基本功能。为了方便遗留业务系统的接入，增加了对各种消息转换，协议适配等功能。

数据服务总线

实现数据服务能力开发和数据集成，对于数据服务总线的实现需要借助传统的ETL数据交换与集成能力，以及ESB业务服务代理能力共同来实现。数据服务既包括了结构化的数据库数据交换和集成，也包括了跨业务系统的大文件传输和集成。

技术服务总线

实现PaaS平台的各种技术服务能力的注册和接入。由于技术服务本身的大数据量，高并发特性，在整个大的总线功能架构中需要采用一种轻量的服务总线模式来实现和管控。

业务流程管理和规则引擎

实现端到端的业务流程建模，执行和监控。其中既包括了传统的HWF人工工作流引擎的能力，也包括了业务自动化工作流通过服务组合和编排的能力。在BPM实际的业务建模和设计过程中，对于比较复杂的业务规则实现可以进一步借助规则引擎的能力。

元数据管理

对于服务总线的元数据管理，包括了服务元数据、流程元数据、规则元数据等多方面内容。元数据一方面包括了服务定义的详细结构化数据信息，也包括了整个服务目录元数据信息。

基础管理和服务管控

基础管理主要实现了SOA总线平台的基础管理功能，包括了系统权限管理、日志管理、安全管理、平台管控等。服务管控则是对服务注册、服务开通、服务控制、服务监控、服务运维、服务下线等服务全生命周期进行管理。

SOA服务目录库

虽然在整个SOA总线功能架构中涉及到数据总线，业务总线和技术服务总线等多方面的总线能力，但是最终都需要通过SOA服务目录库进行统一的服务发布。

服务集成架构和集成关系设计

在前面已经谈到基于服务的集成主要包括业务组件和平台的纵向集成，也包括了业务组件之间的横向服务集成。当前私有云PaaS平台环境的集成需求主要包括技术服务集成、大数据集成和业务服务集成三个方面的内容，而这三方面服务集成本身具备了不同的业务特性，简要说明如下：

技术服务：数据量和并发量大，实时要求高；

业务服务：数据量小，并发量大，实时要求高；

数据服务：数据量大，并发量小，实时要求低。

根据以上三种服务本身的技术特点，可以将服务总线本身分为ESB、大数据总线和轻量总线三种服务总线集成模式，对于三类服务总线最终都归集到统一的服务目录进行管理。

传统的ESB主要用于业务服务集成，业务服务本身对消息可靠性、数据和事务一致性要求高、路由规则复杂、服务运行数据审计要求严格，同时还存在和企业内部遗留业务系统的适配和转换。因此对于业务服务本身最适合采用ESB或传统的消息中间件进行集成。

对于技术服务，则建议采用Restful Web Service的服务方式进行开发和服务能力开放。技术服务本身数据和并发量都很大，而管控的重点本身是服务的鉴权和服务运行监控管控，而非技术服务本身数据审计，因此对于技术服务适合采用一种轻量的能够实现服务鉴权，路由和运行安全审计的总线来进行接入和统一管控。

对于大数据服务集成，虽然对数据服务本身的实时性要求不高，但是每次传输的数据量都很大。如果仍然走传统的ESB接入和集成，将对ESB的性能和内存消耗造成巨大的影响。因此对于大数据服务集成建议的方式是采用传统的ETL集成和Web Service结合的模式来实现。对于服务层只实现服务请求发起和服务代理管控，而数据本身的传输仍然走传统的ETL集成模式完成。

服务集成关系设计

在SOA服务层功能规划完成后，可以进一步分析业务应用群和PaaS平台之间通过服务层的集成关系，具体如下图：

其中PaaS技术平台层提供的4A和流程服务、DaaS数据库服务、技术服务（消息、日志、安全、文件、配置、通知、GIS）等服务能力都统一注入和接入到服务总线。实现纵向的平台层能力向上的能力开放和服务共享。

对于业务系统而言，业务系统被划分为多个松耦合的业务组件，业务组件向外暴露相应的业务服务能力，这些业务服务能力最终也注册和接入到服务总线，以实现横向的业务组件协同和端到端业务流程的整合。

服务技术架构体系

服务技术架构设计仍然是参考标准的SOA参考架构和组件化开发进行。其核心思想是首先需要参考组件化和平台化开发的思想，将传统的IT应用架构分解为多个高内聚的技术组件和业务组件，同时识别组件可以复用的原子服务能力将其共享发布，然后基于原子服务能力可以进一步进行组合服务的设计，进行服务的编排和流程组装。

在私有云PaaS平台中的服务总线，已经从传统单纯的SOA集成平台转化为了服务能力共享平台、服务和流程编排平台。其核心是共享服务能力的开放而不是跨系统或组件的数据集成和交换。当然对于传统的历史遗留系统仍然可以采用数据交换和集成的方式进行集成和接入。

对于服务技术架构设计一方面是参考SOA标准技术规范体系，一方面是参考SCA/SDO组件化设计模型和规范。在服务层设计时前期的重点是可复用的技术和业务原子服务的识别、开发和共享；后期重点则是针对原子服务的组合服务，基于原子和组合服务的服务编排和流程组装。正是因为业务流程或功能是通过底层的各种服务灵活组装和编排出来的，才使得这种服务化架构能够通过配置或重新编排的方式快速适应业务的变化。