一、SOA的相关概念一SOA的定义在面向服务的体系结构(Service-Oriented Architecture,SOA)中从软件的基本原理定义可以认为 SOA 是一个组件模型它将应用程序的不同功能单元称为服务通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。二业务流程与BPELBusiness Process Execution LanguageBPEL业务流程是指为了实现某种业务目的行为所进行的流程或一系列动作。使用BPEL用户可以通过组合、编排和协调Web服务自上而下地实现面向服务的体系结构。BPEL目前用于整合现有的 Web Services将现有的Web Services按照要求的业务流程整理成为一个新的Web Services在这个基础上形成一个从外界看来和单个Service一样的Service。二、SOA的发展历史一发展过程1萌芽阶段这种广泛使用的XML允许组织定义文档的元数据实现企业内部和企业之间的电子数据交换规定了服务之间以及服务内部数据交换的格式和结构。2标准化阶段国际标准和规范—简单对象访问协议Simple Object Access ProtocolSOAP、Web服务描述语言Web Services Description LanguageWSDL及通用服务发现和集成协议Universal Description, Discovery and IntegrationUDDI。3成熟应用阶段3个重量级规范—SCA、SDO、WS-Policy。SCA和SDO构成了SOA 编程模型的基础而 WS-Policy 建立了SOA组件之间安全交互的规范。二国内SOA的发展现状与国外对比在美国过去的半个多世纪美国从主机时代、 P C时代到了现在的网络时代积累了大量的应用系统。美国实现SOA架构的关键任务是对已有系统中的功能进行提取和包装形成标准的“服务”。在中国过去近30年的IT建设多为生产型系统服务型系统普遍未开始建设大量“服务”需要全新构造才是中国 SOA的主要任务。三SOA与微服务的区别1微服务相比于SOA 更加精细微服务更多地以独立的进程的方式存在互相之间并无影响。SOA架构与微服务架构的对比如下图所示。2微服务提供的接口方式更加通用化例如HTTP RESTful 方式各种终端都可以调用无关语言、平台限制。3微服务更倾向于分布式去中心化的部署方式在互联网业务场景下更适合。三、SOA的参考架构IBM的 Websphere 业务集成参考架构(如下图所示是典型的以服务为中心的企业集成架构它可划分为 6 大类1业务逻辑服务Business Logic Service。用于实现业务逻辑的服务和执行业务逻辑的能力其中包括业务应用服务Business Application Service、业务伙伴服务Partner Service以及 应用和信息资产Application and Information Asset。2控制服务Control Service。包括实现人People、流程Process和信息Information集成的服务以及执行这些集成逻辑的能力。3连接服务Connectivity Service。通过提供企业服务总线实现分布在各种架构元素中服务间的连接性。4业务创新和优化服务Business Innovation and Optimization Service。用于监控业务系统运行时服务的业务性能并通过及时了解到的业务性能和变化采取措施适应变化的市场。5开发服务Development Service。贯彻整个软件开发生命周期的开发平台从需求分析到建模、设计、开发、测试和维护等全面的工具支持。6IT服务管理IT Service Management。支持业务系统运行的各种基础设施管理能力或服务如安全服务、目录服务、系统管理和资源虚拟化。四、SOA主要协议和规范Web服务最基本的协议包括UDDI、WSDL、SOAP通过它们可以提供直接而又简单的 Web Service支持如下图所示。1UDDIUniversal Description, Discovery and Integration 协议统一描述、发现和集成协议。包含了服务描述与发现的标准规范它使得商业实体能够彼此发现定义它们怎样在Internet 上互相作用并在一个全球的注册体系架构中共享信息。2Web服务描述语言Web Services Description LanguageWSDLWSDL 是一个用来描述Web服务和说明如何与Web服务通信的XML语言。描述了Web服务的3个基本属性。1服务做些什么—服务所提供的操作方法。2如何访问服务—和服务交互的数据格式以及必要协议。3服务位于何处—协议相关的地址如URL。3SOAP Simple Object Access Protocol协议SOAP 是在分散或分布式的环境中交换信息的简单的协议是一个基于 XML的协议。4REST 规范为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。微服务对外就是以REST API的形式暴露给调用者。RESTful即REST 形式的是对遵循REST设计思想同时满足设计约束的一类架构设计或应用程序的统称这一类都可称为RESTful可以理解为资源表述性状态转移1资源(Resource)将互联网中一切暴露给客户端的事物都可以看作是一种资源。2表述(Representational)REST中用表述描述资源在Web中某一个时间的状态。3状态转移(State Transfer)分为两种应用状态—对某个时间内用户请求会话相关信息的快照保存在客户端。资源状态—在服务端保存是对某个时间资源请求表述的快照。4超链接通过在页面中嵌入链接和其他资源建立联系。五、SOA设计的标准要求一文档标准化SOA服务具有平台独立的自我描述XML文档。Web 服务描述语言是用于描述服务的标准语言。二通信协议标准SOA服务用消息进行通信该消息通常使用XML Schema 来定义也称作XML Schema DefinitionXSD。三应用程序统一登记与集成在一个企业内部SOA 服务通过一个扮演目录列表 Directory Listing角色的登记处Registry来进行维护。应用程序在登记处Registry寻找并调用某项服务。统一描述、定义和集成是服务登记的标准。四服务质量QoS主要包括1可靠性服务消费者和服务提供者之间传输文档时的传输特性且仅仅传送一次、最多传送一次、重复消息过滤、保证消息传送。2安全性Web服务安全规范用来保证消息的安全性。3策略服务提供者有时候会要求服务消费者与某种策略通信。例如服务提供商可能会要求消费者提供Kerberos安全标示才能取得某项服务。4控制在SOA中进程是使用一组离散的服务创建的。BPEL4WS或者WSBPELWebService Business Process Execution Language是用来控制这些服务的语言。5管理针对运行在多种环境下的所有服务必须有一个统一管理系统以便系统管理员能够有效管理。任何根据WSDM实现的服务都可以由一个WSDM适应WSDM-compliant的管理方案来管理。六、SOA的作用打破信息孤岛把应用和资源转换成服务。以及把这些服务变成标准的服务形成资源的共享。七、SOA的设计原则1无状态。以避免服务请求者依赖于服务提供者的状态。2单一实例。以高内聚的实现方法来避免功能冗余。3明确定义的接口。服务的接口由WSDL 定义用于指明服务的公共接口与其内部专用实现之间的界线。4自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件实现服务的功能实体是完全独立自主的独立进行部署、版本控制、自我管理和恢复。5粗粒度。服务数量不应该太大依靠消息交互而不是远程过程调用Remote Procedure CallRPC通常消息量较大但是服务之间的交互频度较低。6服务之间的松耦合性。服务使用者看到的是服务的接口其位置、实现技术和当前状态等对使用者是不可见的服务私有数据对服务使用者是不可见的。7重用能力。服务应该是可以复用的。8互操作性、兼容和策略声明。为了确保服务规约的全面和明确利用策略来定义可配置的互操作语义来描述特定服务的期望、控制其行为。利用策略声明确保服务期望和语义兼容性方面的完整和明确。八、SOA 的设计模式一服务注册表模式服务注册表支持驱动SOA治理的服务合同、策略和元数据的开发、发布和管理。1服务注册应用开发者也叫服务提供者向注册表公布它们的功能。2服务位置也就是服务应用开发者帮助它们查询注册服务寻找符合自身要求的服务。3服务绑定服务的消费者利用检索到的服务合同来开发代码开发的代码将与注册的服务绑定、调用注册的服务以及与它们实现互动。二企业服务总线模式企业服务总线(Enterprise Service Bus, ESB)模式提供一种标准的软件底层架构各种程序组件能够以服务单元的方式“插入”到该平台上运行并且组件之间能够以标准的消息通信方式来进行交互。其核心功能如下1提供位置透明性的消息路由和寻址服务。程序组件之间无须关注对方的路由和寻址。2提供服务注册和命名的管理功能。3支持多种消息传递范型如请求/响应、发布/订阅等。4支持多种可以广泛使用的传输协议。5支持多种数据格式及其相互转换。6提供日志和监控功能。示意图如下三案例研究协同企业服务总线 SynchroESB 就是基于 SOA体系结构以ESB 为底层架构包含丰富的预制程序组件集中式管理工具和可视化应用程序开发界面的服务整合软件平台。该产品在国家高新技术产业化计划的支持下由西安协同时光软件公司和西北工业大学计算机学院联合研究开发的。系统结构如下图所示系统分为4个层次设计。四微服务模式微服务架构将一个大型的单个应用或服务拆分成多个微服务可扩展单个组件而不是整个应用程序堆栈从而满足服务等级协议。微服务架构围绕业务领域将服务进行拆分每个服务可以独立进行开发、管理和迭代彼此之间使用统一接口进行交流实现了在分散组件中的部署、管理与服务功能使产品交付变得更加简单从而达到有效拆分应用实现敏捷开发与部署的目的。微服务模式的特点如下1复杂应用解耦微服务架构将单一模块应用分解为多个微服务同时保持总体功能不变。2独立微服务在系统软件生命周期中是独立开发、测试及部署的。3技术选型灵活微服务架构下系统应用的技术选型是去中心化的每个开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术。4容错由于各个微服务相互独立故障会被隔离在单个服务中并且系统其他微服务可通过重试、平稳退化等机制实现应用层的容错从而提高系统应用的容错性。5松耦合易扩展微服务架构中每个服务之间都是松耦合的可以根据实际需求实现独立扩展体现微服务架构的灵活性。单体应用架构与微服务架构的示意如下图所示。五微服务架构模式方案微服务架构模式方案主要包括1聚合器微服务聚合器充当流程指挥者调用多个微服务实现系统应用程序所需功能。2链式微服务客户端或服务在收到请求后会发生多个服务间的嵌套递归调用返回经过合并处理的响应。3数据共享微服务该模式适用于在单体架构应用到微服务架构的过渡阶段服务之间允许存在强耦合关系例如存在多个微服务共享缓存与数据库存储的现象。4异步消息传递微服务对于一些不必要以同步方式运行的业务逻辑可以使用消息队列代替REST实现请求、响应加快服务调用的响应速度。六微服务架构面临的问题与挑战1服务发现与服务调用链跟踪变得困难。2很难实现传统数据库的强一致性转而追求最终一致性。九、构建 SOA 架构时应该注意的问题一原有系统架构中的集成需求应用程序集成的需求、终端用户界面集成的需求、流程集成的需求以及已有系统信息集成的需求。二服务粒度的控制以及无状态服务的设计1服务粒度的控制对于将暴露在整个系统外部的服务推荐使用粗粒度的接口而相对较细粒度的服务接口通常用于企业系统架构的内部。2无状态服务的设计SOA 系统架构中的具体服务应该都是独立的、自包含的请求在实现这些服务的时候不需要前一个请求的状态也就是说服务不应该依赖于其他服务的上下文和状态即SOA架构中的服务应该是无状态的服务。十、SOA实施的过程一选择SOA解决方案主要从以下3个方面进行1尽量选择能进行全局规划的方案。2选择时充分考虑企业自身的需求。3从平台、实施等技术方面进行考察。二业务流程分析主要关注1建立服务模型自顶向下分解法、业务目标分析法、自底向上分析法。2建立业务流程建立业务对象实体、过程、事件等业务对象、建立服务接口、建立服务流程。