ESB方案V10.docx
《ESB方案V10.docx》由会员分享，可在线阅读，更多相关《ESB方案V10.docx（27页珍藏版）》请在冰豆网上搜索。
ESB方案V10
ESB设计方案
编号：
版本：
1.0
变更记录
日期
版本
变更说明
作者
2010年11月18日
1.0
创建
王杰
目录
1.概述4
1.1数据交换技术简介4
1.1.1.EDI简介4
1.1.2.SOA（ESB）简介5
2.2.应用概述6
2.方案简介8
2.1.集成应用架构方案8
2.2.系统技术架构方案9
2.2.1运行平台9
2.2.2开发平台10
2.2.3监控平台10
2.2.4公共服务10
2.2.5适配器10
2.3.部署方案11
2.3.1.ESB系统管理监控部分部署方案11
2.3.2.硬件选型建议12
2.3.3.ESB系统逻辑分区部署方案13
2.3.4.硬件配置建议13
2.3.5.服务接口规范14
2.3.6.高性能、高可用性及扩展能力设计14
2.3.7.完善的安全机制15
3.总体方案架构（以某银行系统为例）16
3.1.接入控制17
3.2.通信接入模块18
3.3.请求系统适配19
4.集成服务功能19
4.1.服务治理19
4.2.提供对出错服务的及时检测和隔离功能20
4.3.协议转换20
4.4.消息格式转换20
4.5.服务路由21
4.6.监控和运维21
4.7.服务等级22
5.系统非功能需求22
5.1.可用性22
5.2.可扩展性22
5.3.可维护性23
5.4.安全性23
5.5.性能需求23
6.公用服务23
6.1.流量控制23
6.2.故障隔离24
6.3.统一流水号24
6.4.日志记录24
7.管理监控24
概述
数据交换技术简介
数据交换技术起始于联合工作于集团协作的思想，实现数据交换的主要目的在于实现联合模式下的多节点数据共享，实现多种应用系统之间的联合应用。
数据交换模式的出现为多应用系统之间的联合共享与数据交换提供了理论基础，并在此方面有了更多的发展。
1.1.1.EDI简介
EDI是英文ElectronicDataInterchange的缩写，中文可译为“电子数据互换”，它是一种在公司之间传输订单、发票等作业文件的电子化手段。
三个关键要素
（1）EDI是指计算机用户之间的数据交换和数据处理。
（2）EDI交换和处理的数据必须用统一的标准编制成结构化的、标准化的数据后，方可作为被传输的资料。
（3）EDI的数据发送、接收和处理都是使用电子方式自动进行的。
基于EDI的应用系统：
EDI的模块工作过程：
综合EDI的技术特点和应用分析，EDI主要基于数据交换实现企业的应用程序共享，在企业应用中，为行业应用提供底层的数据交换支持，通过数据交换，即“一方的输出等于一方的输入”理念，为企业提供了精确的数据交换服务平台。
1.1.2.SOA（ESB）简介
面向服务的体系结构（Service-OrientedArchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
不同种类的操作系统，应用软件，系统软件和应用基础结构（applicationinfrastructure）相互交织，这便是IT企业的现状。
一些现存的应用程序被用来处理当前的业务流程（businessprocesses），因此从头建立一个新的基础环境是不可能的。
企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（applicationinfrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organicbusiness）的构架。
SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务，从而保护了现有的IT基础建设投资。
ESB全称为EnterpriseServiceBus，即企业服务总线。
它是传统中间件技术与XML、Web服务等技术结合的产物。
ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。
ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。
从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。
ESB在面向服务的解决方案的治理流程中起着间接的作用，因为治理驱动着用于安全、管理和服务交互性的策略。
正如已说明的那样，ESB可以用作这些方面的策略执行点。
还必须将ESB考虑进治理决策中。
ESB为SOA思想的实现提供坚实的基础，为企业的应用提供健全的数据交换和应用集成方案。
2.2.应用概述
总体来说，可以把EDI看成一种技术标准.EDI也可以采用SOA的思想来搭建自己的解决方案平台。
●企业的应用集成问题尚未得到有效解决，企业内部资源的整合、集成架构优化仍然是企业应用集成工作的关注重点；
●IT部门面临着如何有效整合IT资源提升服务能力以及IT系统建设如何适应业务快速发展的双重压力；
●基于ESB的应用架构允许业务系统根据业务的实际要求，采用最适合的技术和产品，按照业务自身的发展计划分阶段独立构建，为各类业务应用提供独立扩展的空间。
●ESB的作用是为服务集成、服务和产品创新等应用提供基础架构的支撑作用，而不是去实现这些业务应用。
●引入ESB意味着增加了一个集中处理环节，因此需要正确处理ESB的服务监控、高可用、服务质量管理和服务连续性。
●ESB是IT基础设施应用，是SOA架构的基础，ESB的建设是一个应用集成工程项目。
●服务总线建设应坚持以业务需求驱动，采取稳妥、渐进的实施策略，保证项目的顺利实施。
现状：
●各系统之间点对点的通信交互
●复杂、难以维护的紧耦合部署环境
应用集成理念
从应用集成技术的发展过程来看，SOA（ESB）是企业应用集成技术发展到当前阶段被业界普遍接受的一种集成架构方案和设计思想
集成之前
▪用计算机代替一些孤立的、体力性质的工作环节
▪没有考虑到企业数据的集成
第0代应用集成（点对点集成）
▪点到点（Point-to-Point）的集成技术
▪点到点的简单连接，实现信息和数据的共享
第1代应用集成
▪采用CORBA/DCOM、MOM（消息中间件）等技术，实现了对企业信息的集成
▪松耦合架构
第2代应用集成业务流程管理
▪基于业务流程管理/集成（BPM/BPI）
▪实现端到端的业务流程，顺畅企业内外的数据流、信息流和业务流。
SOA整合（ESB）
▪面向服务的架构（SOA）
▪企业服务总线ESB
方案简介
2.1.集成应用架构方案
以某银行为例：
渠道系统集成
▪项目涉及三个渠道系统。
▪三个渠道统一通过ESB访问一户通后台应用的相关服务。
▪所有对外部的服务访问均通过ESB系统，包所有对外提供的服务，均发布在ESB上。
2.2.系统技术架构方案
2.2.1运行平台
运行平台内部按照集成应用的特点分为多个集成“通路”，目前考虑分为四类通路：
1、关键服务通路
关键渠道的关键业务、实时性要求高、账务相关。
2、非关键通路
非关键渠道、非关键业务，如：
明细查询等。
3、服务代理通路
从目标架构过渡过程中，与集成目标无关的交易，可以采取“穿透”的方式，减少实施工作量和实施成本。
另外，复用价值较低的服务请求也适合采用“代理模式”。
4、低成本通路
对于实时性要求不高，且信息量大的服务，可采取批量处理模式，降低集成实施成本。
例如：
批量短信服务。
实际部署环境中，每一类通路都可以有多个物理部署，用来保证系统的可靠性，同时也支持横向的扩展和减少不同系统之间的相互影响。
2.2.2开发平台
基于ESB系统标准的服务接口定义、内部统一的元数据管理、数据结构和服务接口定义、路由规则等，实现多个技术通路的统一配置开发。
开发平台的是对各个技术通路实际实现方法的抽象封装。
提供服务逻辑的开发框架和组件库，用于转换适配逻辑、公共服务逻辑等的标准化开发、组件重用和统一管理。
2.2.3监控平台
ESB应用系统要建立统一的日志规范、流水记录规范、错误码规范、系统运行状态检测规范、系统运行状态控制标准，实现对ESB系统整体统一的监视和控制。
是ESB系统的集成“控制面板”。
主要功能包括：
异常监视、通知提醒、运行控制、实时查询、统计分析、服务的配置和发布、服务管理、统一维护和版本部署等。
由于ESB系统是整个企业的服务访问枢纽，ESB可以集中监控企业内所有的服务访问，能够提供各个系统的服务质量和状态的统计数据，例如：
成功率、服务响应时间、服务访问量、服务状态异常等。
从而为行里提供决策依据，帮助行里确定IT资源的重点投向和实施计划。
2.2.4公共服务
提供统一的流量控制服务、流水号服务、冲正服务、异步流水记录、日志记录、接入参数控制等公共服务。
从而实现多技术平台、多物理部署运行环境的公共服务支持。
2.2.5适配器
适配器是ESB系统解决与外部系统之间各类差异的总称。
ESB将外部系统分为请求系统和服务系统两类。
服务系统适配器
对于服务系统，尤其是遗留服务系统，基本集成策略是由ESB项目组开发适配器进行集成。
但是服务系统适配器，并不能解决所有的服务适配问题，例如：
ESB服务接口规范与服务系统规范的复杂对应和匹配工作，尤其是涉及到多个服务系统账务服务接口的复杂流程调用部分，如果由ESB组合这类服务流程组合，解决相关的交易完整性、一致性问题，代价太大而且无法保证。
因此，实际集成实施过程中，不可避免的要涉及到对服务系统的改造工作。
请求系统适配器
对于请求系统，ESB的基本原则是要求请求系统符合ESB的技术规范和服务接口规范。
目的是减少不必要的转换适配层次，提高系统的集成服务效率，降低资源消耗。
ESB系统可为请求系统提供API，对请求系统屏蔽通讯适配、报文组包等技术细节。
请求系统只需要理解业务层面的接口规范，从而大大简化请求系统的集成工作，同时还可以加强对请求系统的监控管理，同时为接口技术实现的升级改造提供辅助支持。
ESB也可以开发适配器，实现请求系统的集成。
主要针对那些无法改造或改造成本过高的请求系统。
2.3.部署方案
2.3.1.ESB系统管理监控部分部署方案
ESB系统的部署方案必须符合企业基础架构的要求。
1）WebServer和ApplicationServer必须分离，分别部署在Web2区和APP区。
或者Web2区的应用通过生产区域的APP，访问DB。
2）用户管理要符合集团的规范。
用户权限控制统一通过UM。
UM决定用户是否有权限操作ESB的管理监控平台。
UM权限通控制通过以后，由ESB管理监控应用来进行详细的角色权限管理。
3）考虑到费用问题，可以采用Apache和Tomcat。
2.3.2.硬件选型建议
ESB系统目标架构硬件选型主要考虑从以下因素：
1）成本因素
ESB系统基于Java技术实现，具有跨平台的技术优势，因此可将成本是考虑硬件选型的首要指标，未来随着ESB应用规模的不断增长，硬件成本在项目投入所占比重将会增加，因此选择性价比高的硬件平台是提高效费比的有效途径。
2）硬件扩容周期
ESB作为平安银行最为关键的服务枢纽，必须能够快速响应应用规模的增长，其中包括硬件的采购周期、系统扩容部署速度。
3）资源调配的简便性、灵活性
ESB系统应能够针对交易量的周期性变化，灵活的增减系统资源配置，资源的调整不应对集成服务持续性造成影响。
基于上述考虑，ESB系统的硬件推荐采用刀片服务器。
刀片服务器还具有以下优点：
1）硬件成本相对低廉，配套的系统软件和中间件价格也相对较低。
2）虚拟化的集中资源管理，可有效提高资源的利用率。
3）在集群中插入新的刀片，就可以提高整体性能。
4）支持热插拔，硬件资源可以轻松地进行替换，并且将维护时间减少到最小。
5）节约空间、便于集中管理、易于扩展和提供不间断的服务。
2.3.3.ESB系统逻辑分区部署方案
2.3.4.硬件配置建议
其对应分配如下：
名称
功能分布
配置
计算单元数量
适配器/公共服务
适配器
公共服务
2cpu（4核），
16GB
memory
1*2
集成核心
WebMethods
MessageBroker
2cpu（4核）,
16GBmemory
1*2
数据库服务器
Oracle
2cpu（4核）,
16GBmemory
1
归档数据库服务器
Oracle
2cpu（4核）,
16GBmemory
1
备份资源池
作为公共备份
2cpu（4核）,
16GBmemory
1
总计
7
2.3.5.服务接口规范
ESB系统负责解决实施服务接口规范与服务系统接口的差异，可将主要的实施工作控制在ESB项目范围内，大大降低周边系统的改造工作量，配合一些系统的瘦身计划的分阶段顺利实施。
2.3.6.高性能、高可用性及扩展能力设计
高处理能力保证措施
控制信息+XML应用报文，中间层次不必解析XML应用报文，使系统不仅具备完善的管理控制能力，同时还减少了报文解析开销，提高了效率。
非阻塞的异步模式、流水线式的作业处理，提高吞吐能力。
异步记录流水日志，保证信息的完整记录，同时不影响系统的处理性能。
系统处理能力可随硬件资源的扩展线性的增长。
系统所有配置规则均加载到Cache中，运行过程中不存在对数据库配置信息的读写操作，保证系统高效运行。
持续稳定运行保障措施
所有应用模块均为群集部署，系统不存在单点故障隐患，某个模块的故障不影响正常运行。
系统应用版本的升级可按模块分别进行，不影响业务的正常运行。
采用数据库分区技术，实现海量数据记录的清理和分区切换过程15秒钟内完成，无需采用与应用相关的数据库分表方式，实现批量数据处理对总线应用透明。
系统提供完备的动态安全刷新手段，配置信息可运行时在线刷新。
可扩展性
系统可以在CPU、内存等资源增加及扩容的情况下自我线性扩展处理能力；每个逻辑模块可以采用横向扩展的多物理模块部署。
中间用队列进行通讯。
可维护性
系统具有较为完善的用户管理界面，提供对系统所有功能的维护与参数配置管理的功能；系统采用统一的服务模式和开发框架，从开发商增加可维护性，系统部署上采用多逻辑单元分离部署，减少系统内部的耦合度，增加整个系统的可维护性。
2.3.7.完善的安全机制
企业应用集成技术使复杂的银行业务流程、大量的信息和数据在各IT应用系统和业务部门之间高效的流转和共享，实现业务流程标准化和自动化，促进业务流程优化，提高建行运营效率。
任何不安全因素都会造成不可估量的损失，故所有数据的传输、处理、交换都必须在良好的安全环境下进行，因此，必须建立一套完整的安全机制，以确保整个通信系统的安全运行。
方案主要为ESB系统提供如下几个方面的安全服务：
1.密钥管理
提供安全有效的密钥管理方案，实现应用系统和ESB系统的密钥产生、密钥分发、密钥更新、密钥注销等。
提供密钥的自动更新机制，保证密钥的安全性，提供高效的对称密码算法，确保应用系统具有可用性和易用性。
2.身份认证
保证接入ESB系统的合法性，提供应用系统和ESB系统之间的双向身份认证，采用基于证书的认证模式，系统使用的数字证书由第三方CA或者采用自运行维护的CA提供。
CA证书采用离线下发的方式，以PKCS#12文件的格式安装到ESB系统和应用接入系统。
身份认证完成后，双方得到一个64个字节的随机数，通讯双方使用的对称密钥都是基于这一组随机数产生，对称密钥的选取规则双方使用相同的策略。
对称密钥和对方的公钥信息存放在系统主机的共享内存，方便应用系统加密使用
3.通讯加密
ESB系统的安全性是保障IT应用系统安全可靠运行的重要环节，使用PKI技术实现系统的密钥管理和通讯加密是目前解决此类问题的最有效途径，应用系统和ESB系统之间通讯的报文使用对称算法加密保护其机密性。
为了提高密码运算的处理速度，这里推荐使用AES算法，密钥的长度为128bit。
通讯双方在身份认证完成后，在共享内存中保存对称密钥。
客户端和服务器端的加密流程如下：
客户端加/解密流程：
1）查询共享内存中的对称密钥和算法ID，根据加密要求选取对称密钥，如
果共享内存中没有对称密钥，加/解密失败。
2）使用查询得到的对称加密密钥，对报文进行加/解密处理。
服务器端加/解密流程：
1）根据客户端的系统代码，查询共享内存的加密密钥和算法ID，如果共享内存中没有对称密钥，加/解密失败。
2）使用查询得到的对称密钥，对报文进行加/解密处理。
4.关键字段MAC
总体方案架构（以某银行系统为例）
ESB集成技术架构方案划分为四个层面：
渠道通迅接入、数据交换层、平台服务调度层、服务适配层。
系统的每个层次都可进行横向扩展，实际应用中系统处理能力可以线性增长。
⏹对于渠道服务请求的接入，ESB提供标准的通迅协议（支持TCP/IP、HTTP、SNA、FTP、MQSeries、JMS等协议和中间件）和ＭＢＳＤ标准接口规范，同时还为请求系统提供服务请求的ＡＰＩ，屏蔽通讯协议和报文格式的技术细节，能够提高请求系统的集成开发效率、减少转换适配环节，同时还大大加强了总线系统对接入的控制和管理，促进了集成应用的快速推广和可靠运行。
⏹对于改造成本过高的存量系统，通过集成开发在数据交换层实现分类路由、同步异步转换、消息格式转换、代码转换等功能。
⏹平台服务调度支持四种模式：
（一）、ＭＢ通道，用于高时效性、高一致性、高吞吐能力的服务；
（二）、ＷＥＢＭＥ通道，用于时效性和一致性要求不高的服务；（三）、服务代理通道，目标架构过渡过程中，与当期集成目标无关的交易，可以采取“穿透”的方式，减少实施工作量和实施成本。
另外，复用价值较低的服务请求也适合采用“代理模式”；（四）、低成本通道，对于实时性要求不高，且信息量大的服务，可采取批量处理模式，降低集成实施成本及节省系统资源。
⏹所有适配器需要在对存量系统分析后集成开发，ESB集成方案中集成产品的相互访问统一使用ＭＱ队列方式。
3.1.接入控制
需要完成以下功能：
1.对渠道提供不同协议的接入功能，包括MQ，webmethods,http等协议的接入。
2.对不同的渠道提供不同的接入点，实现系统负载均衡和最大限度的故障隔离，提供高容量，高可靠性的服务。
3.参数服务为渠道提供统一服务接口模式，伺服渠道下载需要的通道接入信息。
4.渠道通过轮询请求方式主动下载版本变化信息，初始化变化的连接池。
5.服务端进行主动控制，实时控制渠道的接入通路。
6.当某一接入点故障时，通过主动控制渠道接入点，把交易接入到可以的接入点，实现故障的完全隔离。
7.对压力较大的接入点，通过主动控制，把部分渠道的交易切换到压力较小的通路，实现实现负载控制。
8.服务端为渠道维护相应标识信息和其所有当前版本和历史版本信息。
9.通过维护历史版本信息，实现版本回退功能。
实现方案：
1.整体架构图
3.2.通信接入模块
负责和外部系统进行通讯，进行原始报文数据的传输。
通信接入层实现以下功能：
1．利用系统层通讯协议和请求系统进行通讯，包括TCP/IP、HTTP、SNA、FTP、MQSeries、JMS。
2．外部系统约定的通讯方式的实现，包括如何进行通讯连接，如何进行通讯应答，如何进行数据传输，如何约定通讯报文的大小，如何确定数据传输是否完毕，如何处理通讯错误，如何关闭通讯连接，如何处理通讯层数据完整性校验等。
3．识别外部系统类型。
4．多通讯连接的并发处理。
以下的功能不需要由通讯接口层完成：
1.非通讯层面的数据报文的加解密。
2.非通讯层面的数据报文的压缩，解压缩处理。
通讯接入层屏蔽了所有的通讯细节，数据交换层只知道从某个外部系统获得了或者发送了一个数据报文，至于该数据报文是如何获得或者发送的，和数据交换层本身无关。
3.3.请求系统适配
完成从服务端返回数据到标准输出之间的转换或从一个渠道端请求接口数据到ＭＢＳＤ服务标准请求数据之间的转换。
具体功能包括：
1.应用层面的数据报文的加解密。
2.应用层面的数据报文的压缩，解压缩处理。
3.数据报文类型的识别。
4.数据报文的打包拆包，根据报文类型以及相关配置将数据报文拆分成统一的数据接口或者相反。
5.数据接口之间的转换，根据定义的规则从一个数据接口转换成服务数据接口或者相反。
接入适配层屏蔽了数据的具体物理表示和组织，平台服务调度层只知道收到了一个服务请求要求处理，至于该服务请求是从哪个系统发起的，原始的请求数据是什么，和服务整合层没有关系，只和数据交换层有关。
接入适配框架提供可配置的定长、变长报文转换适配器，以及可扩展的接口可以适应各种不同格式的报文转换。
同时接入框架提供了MBSD元数据管理功能，能够方便的定义报文的元数据，为报文的转换以及应用的开发提供便利。
集成服务功能
4.1.服务治理
提供服务标准定义、服务封装、注册与发布等功能,提供位置透明性的服务路由和定位服务
ESB的服务接口规范应该基于对银行业务的理解，经过抽象、归纳形成，服务接口规范独立与现有系统的具体实现，接口规范具有较强的独立性、稳定性。
从而真正消除请求系统与服务系统之间的关联关系，实现服务的位置以及服务的具体实现与服务的访问过程无关。
我们提供MBSD规范落地实施的工具：
元数据管理，服务接口定义配置，导入导出工具（可以通过web页面形式和导出文件形式对外公布），服务规范适配的开发框架。
4.2.提供对出错服务的及时检测和隔离功能
ESB系统实时检测服务系统的服务状态，当服务出现异常时，能够及时发现，通过监控平台发出报警，通过人工手段或预先设定的规则，对状态异常的服务或服务系统进行迅速隔离，避免因故障导致服务阻塞，保证请求系统对其他服务的正常访问。
4.3.协议转换
支持外部系统通过TCP/IP、HTTP、SNA、FTP、MQSeries、JMS等协议和中间件与ESB平台通讯。
一般情况下，请求系统使用ESB系统提供的API，按照ESB系统的技术标准和服务规范进行服务访问，从而避免不必要的协议转换开销。
但是对于请求系统无法改造或改造成本过高的情况下，ESB系统应提供接入协议适配的功能，支持外部系统通过不同的通讯协议与ESB平台通讯。
但是应注意，ESB更多的情况下是为了适应服务系统的技术差异，才进行通讯的适配，从系统的规范化和易维护性角度考虑，不推荐被动的对请求系统进行通讯协议适
升级会员 