企业服务总线ESB技术设计方案Word格式.docx
- 文档编号:17204697
- 上传时间:2022-11-28
- 格式:DOCX
- 页数:20
- 大小:582.98KB
企业服务总线ESB技术设计方案Word格式.docx
《企业服务总线ESB技术设计方案Word格式.docx》由会员分享,可在线阅读,更多相关《企业服务总线ESB技术设计方案Word格式.docx(20页珍藏版)》请在冰豆网上搜索。
●安全性
保证系统、数据的安全性,系统应有先进的传输加密措施和机制,并采用分级授权管理模式,同时保证系统持续、稳定的运行;
●高效性
保证系统的性能能够满足各类业务与应用的需要,整个系统的方案设计、功能融合并体现领先的信息技术和先进的管理思想;
整个系统应便于管理,提供多层次、多维度的管理手段;
●扩展性
保证系统为满足业务发展的需要所应具备的扩展能力。
2ESB服务总线技术解决方案
2.1.企业服务总线技术方案
2.1.1企业服务总线集成架构模型
SOA是在面向对象体系结构基础上扩展的新体系结构,以服务为核心来封装业务流程和应用系统,服务具有更高的抽象层次,可以实现更高级别的重用,并解决了IT系统与业务流程的相关性。
与传统构建系统的方法比较,SOA更强调标准化应用,更加重视系统的层次架构。
SOA特性之一的互联互通性就体现在系统中任一个服务能被其他服务甚至是其他系统的服务准确无误地发现及理解,而满足这种特性最直接的方式就是每个服务都遵循一系列统一标准。
因此,只要遵循SOA的理念,采用统一的标准,任何现有技术都能用来开发SOA系统。
企业服务总线集成架构与传统架构的区别在于系统均是基于“服务”构造,“服务”之间的交互和组合实现了系统之间的松耦合关系。
企业服务总线集成架构遵循SOA理念,企业服务总线集成架构中的构件包括:
(1)服务:
可以通过已发布接口使用服务,并且允许服务使用者调用服务。
(2)服务描述:
服务描述指定服务使用者与服务提供者交互的方式。
它指定来自服务的请求和响应的格式。
服务描述可以指定一组前提条件、后置条件和/或服务质量(Q0S)级别。
(3)服务使用者(服务消费者):
服务使用者是一个应用程序、一个软件模块或需要一个服务的另一个服务。
它发起对企业服务总线的服务的查询,通过传输绑定服务,并且执行服务功能。
服务使用者根据接口契约来执行服务。
(4)服务提供者:
服务提供者是一个可通过网络寻址的实体,它接受和执行来自使用者的请求。
它将自己的服务和接口契约发布到企业服务总线,以便服务使用者可以发现和访问该服务。
(5)企业服务总线:
企业服务总线充当SOA中服务提供者和服务使用者之间的连接服务的中间层。
企业服务总线“虚拟化企业里的服务”,也就是所有的服务会由企业服务总线里的一个虚拟端点来表示,而服务消费者只需要连接在企业服务总线里的虚拟服务端点,由企业服务总线在运行的时候来定位实际的服务在哪里。
企业服务总线核心是一个消息处理引擎,对于服务使用者的请求(典型的如SOAP消息),按照正确的规则去了解消息的内容,处理之后把消息发给正确的服务提供者,然后需要记录处理的中间结果,再协调服务使用者和服务提供者的关系,在两个或者多个本来没有设计为互相调用的服务间提供互相调用并监控他们的相互调用。
企业服务总线集成架构示意图
企业服务总线集成架构中的每个实体都扮演着服务提供者、使用者这两种角色中的某一种(或多种)。
企业服务总线集成架构中的操作包括:
(1)发布:
为了使服务可访问,需要发布服务描述以使服务使用者可以发现和调用它。
(2)发现:
服务请求者定位服务,方法是查询服务注册中心来找到满足其标准的服务。
(3)调用:
在检索完服务描述之后,服务使用者继续根据服务描述中的信息来调用服务。
2.1.2企业服务总线体系结构
企业服务总线是SOA体系中重要的组成部分。
企业服务总线实现了松耦合、粗粒度服务的基础结构要素,为服务提供者和消费者之间提供中介服务,为参与集成的各方屏蔽了硬件平台、软件、网络和物理位置上的差异,有效地对服务进行管理并且降低服务之间的依赖关系,提高服务调用在多变的企业应用集成场景中的灵活性。
企业服务总线应具备下图所包含的功能组件:
企业服务总线体系结构图
企业服务总线功能架构图
✓服务管理
企业服务总线提供嵌入式的服务管理,对服务运行状态及相关KPI指标进行监控,并通过多种展现方式展示,同时可以生成相关统计报表。
另外,也应支持完善的异常处理功能。
✓消息处理
企业服务总线需提供基于配置的服务组合环境,无需用户编写代码即可完成消息路由配置、消息流模型创建等操作。
同时应提供消息验证及消息转换的功能。
✓安全管理
企业服务总线需要提供认证,授权,加密等安全功能保证企业服务总线上的服务被安全的调用,以及企业服务总线可以按服务提供者需要的安全机制调用提供者。
企业服务总线通过使用明确的安全策略(如基本授权、HTTPS、SSL、WS-Policy等)为服务提供可靠的安全架构。
✓消息传输
企业服务总线需要支持多种接入方式、消息传输协议转换等,包括对服务调用者提供多种调用协议,以及能够连接使用各种私有传统接口的服务提供者。
2.1.3企业服务总线功能性需求解决方案
5.1.3.1消息传输
企业服务总线提供内建的对各种服务传输协议的支持。
企业服务总线还提供客户化传输协议的开发,使客户能够根据需要扩展服务总线的能力。
多协议传输支持包含如下功能:
功能
描述
支持的多协议
支持包括HTTP,HTTPS,JMS,MQFTE,File,FTP,SFTP,JCA,TCP/IP,E-mail(POP/SMTP)等传输协议
支持中间件之间的互操作
支持.NET,Oracle,BEAWebLogic,TibcoEMS,ORACLEMQ,ORACLEWebSphere等中间件
消息传输优化
支持基于XPath、XSLT、XQuery、XMLSchema、Java代码等对XML消息进行格式转换和路由处理
优先级传输
支持消息按优先级传输,即消息被赋予一定的优先级,优先级较高的消息优先传输
大文件传输
支持大容量的消息传输,但不建议使用
非持久化消息
支持持久化消息和非持久化消息,原则上采用非持久化消息
Base64编码
解决特殊字符的传输和解析
5.1.3.2安全管理
企业服务总线提供消息安全、身份认证、权限审计、加密签名等功能,所有参与集成的业务应用服务的安全统一由企业服务总线负责。
调用方的业务应用经过企业服务总线的身份证认证后方可访问服务;
业务应用与企业服务总线之间采用消息安全机制实现信息的安全传输。
安全管理包含如下功能:
传输安全
支持SSL/Basic授权
服务安全
支持WS-Policy/WS-Security,用户名/口令,数字签名和加密
安全策略
支持自定义安全策略,提升WS-Security&
WS-Policy
5.1.3.3消息处理
1、消息转换
消息转换用于服务使用者与服务提供者之间存在不同的数据类型,以及需要数据映射以便转换数据的情况。
消息转换包含如下功能:
支持消息类型
支持SOAP
格式定义与转换
应支持基于Schema的消息内容和消息头、规则以及过滤器进行控制,支持XSLT格式转换
支持通过对外调用方式,调用外部基于Java代码的转换
自定义处理逻辑
企业服务总线提供扩展功能,用户可自定义消息处理逻辑,如通过Xquery、Xpath、XSLT、JavaCode等方式进行扩展
字符集支持
支持中文字符
2、消息验证
消息验证可用于服务访问控制、服务版本控制,以针对不同版本的schema或WSDL验证消息。
这是为了确保消息被发送到服务端点的正确版本,或在发送消息前检查是否必须应用转换。
消息验证包含如下功能:
消息验证
支持消息的验证,对照WSDL或XMLschema验证进出的消息。
保证进出的消息符合目的地服务使用者或提供者期望的格式
验证失败的消息可记录该失败,还可以产生错误
3、消息路由
服务是由不同服务提供者提供的。
服务使用者在调用这些服务的时候,无需关心服务的实际提供者,由企业服务总线基于消息内容实现动态路由,将请求消息投递到正确的一个或多个目的地服务。
对于复杂的路由需求,服务总线还能够支持“调用外部服务(servicecallout)”操作,对一个外部服务进行调用,然后依据其返回结果完成路由操作。
动态路由包含如下功能:
动态路由
路由可以基于SOAP报文头,传输报文的头,JMS用户定义的属性,MQ的报文头,文件目录,E-mail,消息内容(XML数据和格式化的非XML数据)来进行
路由机制通过配置实现,不需要针对每一个服务使用者和服务提供者进行硬编码。
4、消息流模型
企业服务总线提供可视化的开发、配置、调试环境,用户可通过图形界面创建消息流模型,配置消息管道Pipeline,通过拖拽方式完成消息的转换、格式校验、变量定义、路由判断等一系列操作。
消息流模型包含如下功能:
消息模型
请求应答、发布订阅、查询查复
交互模式
同步、异步;
包括请求/应答、基于事件驱动的发布/订阅机制、通知、定时轮询等
可视化的集成开发环境
提供一个开发、配置、运行管理的可视化环境,支持消息流、数据格式、数据转换等开发,提供友好的图形界面,利用方便的图形工具实现对消息格式和处理规则的定制
5.1.3.4服务管理
1、服务管理监控
企业服务总线提供基于Web的控制台,能够提供所有的配置和监控功能。
管理监控平台应能够管理部署在多个服务总线的实例,展现服务的运行状况、统计信息及服务水平告警信息等功能。
企业服务总线应提供统一的日志管理功能,日志功能可以记录通过ESB平台的服务调用过程,以及在必要情况下,记录通过ESB平台的消息副本。
日志管理功能为事后审计及故障排查、分析提供依据。
服务管理监控包含如下功能:
监控指标
企业服务总线的消息通道、服务端口、性能、负载、定时器、安全等监控指标
展现形式
向用户提供多种展现方式,能够立即允许用户查看监控信息;
展现形式包括:
折线图、柱图、饼图等
展现方式
监控信息所运用的展现方式,展现方式包括:
HTML,FLEX等方式
提供完善的日志管理
记录生产环境中,传输运行时交换的信息
提供完善的操作日志
记录服务管理监控平台上的操作活动信息
2、统计分析
企业服务总线提供对服务器以及服务指标进行统计并提供分析报表。
统计分析包含如下功能:
服务统计指标
对企业服务总线及服务进行统计,并提供错误与性能统计数据及分析,服务统计指标包括:
成功/失败率;
消息数;
错误数;
异常数;
响应时间、服务处理开销、总线处理开销、报文长度、请求链路IP、总线IP
报表
向用户提供关键性能指标的分析报表,并可提供自定义报表
统计展现
具备对统计信息的展现功能,展现形式与方式请参考服务监控管理中展现项目
3、异常处理
企业服务总线提供完善的错误处理功能,能够灵活地配置服务的错误处理。
企业服务总线应提供统一的异常检测和处理机制,所有接入系统都会有一套错误代码在ESB中注册。
ESB维护一套处理机制,针对不同的错误代码,判断异常处理的逻辑。
当某类服务调用发生故障时,不会造成ESB的访问阻塞,不影响服务请求方对于其他类别服务的访问。
异常处理包含如下功能:
消息跟踪
支持利用进出消息的记录,获得消息流的精确描述,提高错误的可视性,辅助快速识别异常产生原因
异常处理机制
支持捕获多层的异常,处理SOAP中的异常;
提供丰富的客户化差错消息,可调用服务;
提供通过Email等方式的异常消息通知;
提供默认系统错误句柄处理错误;
4、服务注册/授权
用户可通过服务管理监控平台向企业服务总线手动注册服务,也可通过服务管理监控平台进行服务访问授权,发布到ESB平台的服务,只有经过ESB平台的授权,才可被合法的系统进行调用,这是由服务访问权限控制功能来保障的。
服务发现包含如下功能:
服务注册
支持向企业服务总线注册服务
服务授权
支持进行服务访问的授权
5.1.3.5流量控制
1、流量控制原则
✓保证用户体验
在系统处理能力不足时,应该及时通知用户或限制用户调用总线服务,对于不同级别的用户,总线应该提供不同总线访问通道,这样可以避免在系统达到容量限制时,所有用户都被拒绝访问服务。
✓隔离原则
在需要流量控制的情况下,首先考虑使用隔离的方法将流量分散到不同的通道中,隔离的方法可以是物理格式和逻辑隔离。
物理隔离是指在物理上分散,例如可以部署多个企业服务总线实例,为高级别用户或重要系统,关键服务单独使用。
逻辑分离是指在同一个服务总线实例上分散访问服务的能力,例如可以通过MQ通道区分不同优先级的请求或者用户,为高优先级的服务或用户提供服务。
✓保证企业服务总线健康稳定运行
在流量控制时,应保证不对其他系统或通道造成影响,例如,分多个企业服务总线物理隔离时,即使某一实例达到性能瓶颈,也不为高优先级用户服务的实例提供服务。
✓在保证各系统健康稳定运行的情况下,考虑公平及效率原则
公平原则是指为了避免某类用户、系统、服务被流量控制后,在相当长的时间内得不到系统响应,在实施流量控制后,需要对控制发生的原因进行重试请求。
效率原则是指在控制之后,应该选择合适的时机进行流量控制恢复,例如当企业服务总线空闲时。
2、基于ESB平台的流量控制场景
在一个或多个企业服务总线平台上,可以设置ESB平台的总流量,可以在流量允许的情况下提供服务。
✓控制时机
ESB平台:
控制时机为在一定时间T(建议3分钟)内,如果系统请求并发数超过ESB平台所能容纳的请求并发数,即产生流量控制。
ESB平台流量值可以事先设置,在运行过程中可以随时修改。
✓控制恢复时机
在一定时间T(建议3分钟)内,如果系统请求并发数低于ESB平台所能容纳的请求并发数的数量的80%,即开始恢复最近拒绝的ESB平台级别。
例如,ESB平台被流量控制后3分钟内,系统请求并发数持续低于所能容纳并发数则恢复各系统接入企业服务总线。
3、基于系统的流量控制场景
在一个企业中,不同的系统功能不同,有的系统重要性不是很高,可以在流量允许的情况下提供服务,对于重要的业务系统,则要实时保证为其提供服务,例如营销、财务。
系统:
控制时机为在一定时间T(建议3分钟)内,如果系统并发数超过接入层所能容纳的系统并发数,即产生流量控制。
系统并发数可以事先设置,在运行过程中可以随时修改。
在一定时间T(建议3分钟)内,如果系统并发数低于接入层所能容纳的数量的80%,即开始恢复最近拒绝的系统级别。
例如,某系统被流量控制后3分钟内,系统并发数持续低于所能容纳并发数则恢复某系统接入企业服务总线。
4、基于服务的流量控制场景
对于相同的业务系统中,不同的服务的重要性不同,需要根据服务的优先级保证重要服务的运行。
例如,对于财务系统的凭证同步服务和查询现金流量表服务,就需要首先保证凭证同步服务优先服务。
服务:
控制时机为在一定时间T(建议3分钟)内,如果服务并发数超过接入层所能容纳的服务并发数,即产生流量控制。
服务并发数可以事先设置,在运行过程中可以随时修改。
在一定时间T(建议3分钟)内,如果服务并发数低于接入层所能容纳的数量的80%,即开始恢复最近拒绝的服务级别。
例如,财务系统某查询操作被流量控制后3分钟内,服务并发数持续低于所能容纳并发数则恢复财务系统某查询操作接入企业服务总线。
为了保证服务的服务质量,通过流量控制的机制来保证服务请求方不会在单位时间内产生过多的服务请求,服务提供方不会在单位时间内接受过多的服务请求,影响服务提供方的服务质量。
2.1.4企业服务总线非功能性需求解决方案
5.1.4.1可用性
1、应用层采用PCP架构,两台应用服务器并行运行,通过负载均衡器来分配Web层的负载,单节点故障时,并发请求会自动转到另一台服务器上,系统不会停止提供服务
2、数据库层采用RAC架构,使用两台数据库服务器搭建RAC架构,OracleRAC技术采用ShareEverything架构,组成集群的每一台服务器都可以访问共享磁盘,都能对外提供服务,单节点故障时,系统不会停止提供服务
5.1.4.2及时性
应用系统采用两台服务器的PCP架构,使用负载均衡技术能够根据负载动态的分配访问,能够有效的减少前台访问的延迟,提高访问效率。
数据库层使用两台服务器的RAC技术,并使用高效的存储阵列,能够提供大数据吞吐量的支持。
提高了数据库相应速度。
5.1.4.3可靠性
使用基于企业服务总线的消息传递机制,保证数据在系统间传输过程中的一致性。
有两种消息传递机制:
同步、异步
另外,还有完备的消息备份机制以解决消息传递过程中的异常:
在消息通道处理消息过程中,有两种情况可能会导致消息发送失败,一种是消息接收者在接收消息时处于不可用的状态;
另一种是消息处理节点在处理消息时发生异常。
针对情况一,当监测到消息接收者处于正常运行状态时,取出第二次的消息全备份重新发送给消息接收者即可;
针对情况二,当监测到异常的消息处理节点恢复正常时,先取出第一次的消息全备份,接着应用该异常消息处理节点前所有的消息增量备份,重新构造消息,再次发送给该消息处理节点即可。
5.1.4.4故障恢复方案
1)故障恢复计划:
应用系统故障恢复采用对文件备份进行克隆方式进行;
数据库故障恢复使用RMAN备份的数据文件+归档日志进行恢复,通过设置RMAN的恢复参数,可以全自动进行。
2)系统冗余/备份/恢复:
应用层采用两台服务器PCP架构,数据库层采用两台服务器的RAC架构,备份文件包括保存在存储上的每周备份以及在磁带上的历史备份,保证有足够的备份,可以恢复到任意时间点。
5.1.4.5业务连续性方案
各系统之间使用基于企业服务总线的iBus集成,消息传递中有标准的备份恢复机制,保证其中一个系统维护时,不影响其他相关系统运行,并在维护系统恢复时自动恢复消息传递,保证数据的完整性及连续性。
5.1.4.6系统备份方案
1、应用系统采用备份文件系统方式
在不停机情况下备份oracle目录,便于对整个应用进行恢复,建议每月进行一次
2、数据库使用RMAN备份
在业务量较少的每周日进行一次0级备份,周一、周四进行1级增量备份,其他时间进行2级增量备份
建议在存储上保留1-2周的备份(采用压缩方式,每周整个备份文件大小小于正式数据文件),建议在磁带机上保存至少1个月的备份(可以根据实际需要确定具体的备份量)
5.1.4.7安全性
应用系统部署在公司内网,并使用VPN技术提供外部合法访问。
对于内部用户对数据库的访问,采用在数据库层设置绑定MAC地址方式,限定数据库访问权限,并结合合理的apps密码变更策略增强访问安全性。
5.1.4.8系统架构、可扩展性、集成性
使用基于企业服务总线的企业应用集成架构,是一种粗粒度、松散耦合服务架构,服务之间通过简单、精确定义的接口进行通讯,不涉及底层编程接口和通讯模型。
具有良好的跨平台能力和扩展性。
2.1.5企业服务总线部署方案
5.1.5.1部署架构原则
1、高可用性
企业服务总线作为企业服务提供和消费的核心运行和管控平台,承载着企业各种关键应用和核心应用的数据交互、数据共享和数据分发,其稳定性必须得到保证,其故障率必须降到最低。
企业服务总线的高可用性则成为其部署结构构的第一个原则,也是最重要的原则,企业服务总线必须无单点故障,必须实现平台故障时无缝切换。
可采用的部分高可用性技术如下:
1.操作系统层面:
LinuxHA(Linux),HACMP(AIX)实现机器硬件故障时的主备机切换,同时也可以实现对应用状态进行监听,在应用发生故障时,切换到备机并启动应用。
2.ESB多实例:
部署多个独立的ESB平台应用,共同对外提供服务,由OracleHTTPServer或者F5对多实例进行负载转发。
ESB多实例部署可以很好的实现水平扩展。
3.利用Cluster技术实现高可用性:
OracleHTTPServer在对多实例进行负载转发时,如果侦测到故障实例,则停止向故障实例转发,保证请求能够正常得到处理。
2、负载均衡
作为企业各种关键应用和核心应用的数据交互、数据共享和数据分发的统一服务运行平台,企业服务总线的服务和数据交互的性能则尤为重要,为了提高保证企业服务总线应用,则必须使企业服务总线各个单元能效达到最优和最高,企业服务总线的部署架构必须实现负载均衡,使企业服务服务总线每个单元根据自身的物理配置和逻辑配置实现性能最优和能力均衡。
可采用的部分负载均衡技术:
1.针对HTTP/HTTPS(包括基于HTTP的WebSerivce)接入:
OracleHTTPServer可根据部署的物理/虚拟机器的处理能力进行负载因子设定,将请求按照机器处理能力进行
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 企业 服务 总线 ESB 技术设计 方案