soa技术特点 快手作品赞代

客服   拼多多砍价dy抖音ks快手 自助商城点击进入

本篇重点说明下SOA服务架构规划中服务目录规划集的形成。前面已经有很多文章说过，SOA服务架构规划不仅仅是基于SOA参考架构的思想，更多的是需要基于TOGAF和企业架构的思想来分析和构建完整的服务架构和服务目录库。

服务架构规划的重点有一项是形成完整的服务目录库，除了服务本身的多维度分层外，更加重点重要的还是识别出粗粒度和可重用的各类服务。SOA的核心思想就是要将企业的业务或信息系统划分为多个松耦合的组件，然后根据端到端流程的协同关系来识别和发现服务，即业务能力组件化和组件能力服务化；其次则是要基于云平台能力向云端集中化迁移的核心思路，来考虑整个IT应用架构中需要平台化的能力，同时将平台层能力以服务化的方式暴露出来。

在整个服务架构规划中也可以看到，对于主数据和共享数据的平台化建设，PaaS技术平台的建设，最终将识别和产生共享数据服务和平台技术服务。而对于从流程协同和业务架构分析入手，更多的产生业务服务；而对于从数据架构中的CRUD矩阵分析入手则产生数据服务。

下面再重点阐述下整个服务架构规划的核心逻辑和过程：

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

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

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

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

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

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

最后，我们需要基于集成架构视图情况soa技术特点，规划和梳理服务目录集，即按照服务的分层和分类来重新审视当前的系统间集成和能力共享。

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

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

技术服务

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

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

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

数据服务和文件服务

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

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

业务服务

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

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

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

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

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

流程服务

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

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

UI组件服务

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

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

组合服务

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

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

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