ESB项目需求分析和方案设计浅谈.docx

如同其它IT项目一样，企业服务总线类项目的实施也要经历需求分析、方案设计、编码和测试、上线部署等阶段。下面我们将针对ESB项目的设计和实施过程中各个阶段要完成的主要工作内容和一些最佳实践跟大家作一些讨论，进而希望大家在企业ESB项目实施过程中借鉴科学的方法论的指导来保证其成功。   ESB的需求分析需求分析阶段是梳理项目中相关功能需求和非功能需求的重要步骤，它是整个项目成败的关键。在这个阶段我们将从企业业务需求出发，梳理端到端的跨系统业务流程；基于业务流程，依据科学的方法论进行服务鉴别；由服务列表出发，梳理服务的消费和提供关系；然后根据SOA的最佳实践，定义服务的接口，包括服务的Schema描述，字段的类型，编码的规则；依据服务的消费提供关系，梳理ESB中的服务映射和转换规则和策略。概括而言，我们需要从功能性和非功能性两个方面来进行ESB的需求分析。针对ESB的功能性需求，我们要侧重了解以下方面的问题：1. 梳理出要被集成的系统的名称，个数。2. 针对每个系统而言，要了解：该系统的对外接口是向外调用，被别人调用，还是二者都有； 接口的实时性要求，是实时的还是批量的，还是二者皆有？ 接口的调用方式，是同步的还是异步的，还是二者皆有？ 应用系统所运行的操作系统平台。 应用系统本身的编程语言？C/C+, Java. 这些系统现有接口的情况，是否已经可以提供对外接口，接口的方式是什么，包括接口的通讯协议是什么，HTTP/MQ/Socket/ 其它？接口的数据格式是什么，XML/ 自定义格式 / 其他行业标准格式？接口的编程语言是什么，Java/C/C+？如果本身不能提供接口，那么要做接口开发时有什么要求或限制条件？ 这些应用后台数据库的情况，数据库能否直接访问？ 每个应用跟其他应用交换数据时，源数据格式和目的数据格式，比如从文本格式转换为 XML 格式？ 交易特征：哪些处理要采用两阶段提交；是否需要多个消息组成一个交易；是否要保证消息之间的处理顺序； 适配器的情况：对于一些特殊系统，是否已经具备现成的适配器；适配器是单向的还是双向的； 消息通信的模式：是Send and Forget、Request/Reply还是Pub/Sub? 针对ESB的非功能性需求，我们要确认：1. ESB平台的扩展性和高可用性需求，包括HA和集群等；2. ESB平台的性能需求，主要包括系统间数据交换的频率，要交换的数据的大小 ( 消息大小将直接对效率造成影响 )；峰值时候对ESB数据吞吐量、响应时间的要求等；3. 哪些交易要保证数据传输的高可靠性；4. ESB平台的可管理性需求，如服务的生命周期管理，ESB 平台的维护和管理；如果企业已经设立了SOA管控方面的规范，那么要遵从规范的制约，比如要考虑是否有规定的命名规则，企业是否有企业级的数据规范和底层通讯协议的规范等；5. 安全性方面的要求：是否采用SSL传输加密，是否对消息进行加密/解密处理等；6. 错误处理和日志以及平台本身的运行监控等方面的要求等。ESB的方案设计方案设计的主要内容包括：ESB涉及IT应用环境分析，定义ESB与相关应用的接口模式； ESB架构概要设计，并定义架构原则； ESB相关产品选择，包括与外围系统的适配器选择和ESB产品选择； ESB组件模型设计，分解ESB的相关模块，满足SOA的分离关注点等架构原则； ESB运作模型设计，满足平台的非功能性需求； ESB平台的服务流设计，涉及路由、转换和映射等； ESB的同步、异步或者发布/订阅模式设计； ESB平台的接入渠道和数据接口设计，包括XML/JMS、SOAP/HTTP、EDI/MQ 等； ESB相关的适配器设计，包括技术适配器或者自开发的适配器； ESB平台的容错和重试机制设计，包括日志等的统一管理等；     图 1 是一个采用ESB整合的高层架构设计举例：图 1. ESB参考架构    如图 1 所示，ESB架构设计时主要要考虑通讯协议接入和转换、数据接入和转换、数据处理流程以及服务的注册和管理等方面的内容。其中通讯协议接入和转换是指对各种被集成的应用系统的通讯协议的支持和转换能力，例如HTTP、JMS、Socket、FTP等；数据接入和转换是指对各种被集成的应用系统提供的数据格式的支持和转换能力，例如XML、SOAP、自定义格式以及符合某些行业标准的专有格式（SWIFT、EDI、HL7 等）；数据处理流程是指路由、格式转换、数据库读写等对数据的各种处理；统一服务注册存储管理是指对服务的注册、发布、查询，以及对运营时服务的管控，并且提供服务运营状态的统计分析数据。ESB的组件模型图 2. ESB组件模型    图 2 给出了一个ESB组件模型的示例，其中包含的各主要组件及其功能如下：1. Message Broker Runtime组件提供消息路由、格式转换、消息日志等操作的运行时环境。该运行环境由IBM Message Broker提供；2. Messaging Broker Instance组件是处理基于MQ消息业务请求的容器。它是作为一个Broker实例运行在Message Broker Runtime上的。该实例提供了MQ消息的业务请求处理器、服务日志、服务定位等功能的运行容器；3. Web Service Broker Instance组件是处理基于Web Service的业务请求的容器，它是作为一个Broker实例运行在Message Broker Runtime上的。该实例提供了Web Service的业务请求处理、服务日志、以及服务定位等功能。4. Event Broker Instance组件是平台内部处理Pub/Sub事件的容器。它是作为一个Broker实例运行在Message Broker Runtime上的。该容器提供了Event Handler组件的运行环境，将基于MQ/JMS的事件分发到不同平台组件的目标队列上。5. Message Handler组件是处理基于MQ消息的业务请求，包括消息解析、格式转换，服务鉴权与认证、服务路由、服务日志等功能。Message Handler组件处理MQ消息的典型流程如下：首先对MQ消息进行解析，对解析后的业务请求进行分析，之后通过Authentication 与 Authorization组件判断该请求者的业务请求是否可以进行后续处理； 通过Service Locating组件对该业务请求进行服务定位与路由； 将基于MQ的业务请求消息转换成Web Service的业务请求消息； 通过Service Logging组件对整个业务请求进行日志记录； 返回业务请求处理结果给业务发起者，如果失败，返回错误消息。 6. Web Service Handler组件是处理基于Web Service的业务请求，与Message Handler组件功能类似，也包括消息解析、格式转换，服务鉴权与认证、服务路由、服务日志等功能。Web ServiceHandler组件处理Web Service请求的典型流程如下：首先对Web Service请求消息进行解析，对解析后的业务请求进行分析，之后通过Authentication与Authorization组件判断该请求者的业务请求是否可以进行后续处理； 通过Service Locating组件对该业务请求进行服务定位与路由； 通过 Service Logging 组件对整个业务请求进行日志记录； 返回业务请求处理结果给业务发起者，如果失败，返回错误消息。 7. Event Handler组件实现对Pub/Sub的处理。8. Service Locating组件负责根据业务请求定位具体的服务提供者。Service Locating通过对服务目录的查询选择适合的服务进行后续的调用，该查询工作可以通过实时的服务目录查询获得结果。9. Service Logging组件负责记录整个业务请求处理过程中的情况，该组件的实现可以通过文件或者数据库的方式。10. Authentication组件负责对业务请求者进行鉴权，判断该业务请求者是否可以访问平台服务，该鉴权的工作在企业服务总线的外部进行，Authentication组件只是调用外部功能完成。11. Authorization组件判断业务请求者是否具备访问某特定服务的权限，该验证权限的工作在企业服务总线的外部进行，Authorization 组件只是调用外部功能完成。以处理基于MQ消息输入为例，ESB的组件交互图如图 3 所示：图 3. ESB组件交互图    ESB方案设计时的最佳实践根据我们以往项目设计和开发时的一些经验，我们建议进行ESB的方案设计时要遵循下述最佳实践：确定标准的使用：使用与否、使用到什么程度； 确定在ESB上实现的业务逻辑：ESB是一个服务路由和转换中心，而不是一个应用服务器，因此它并不能取代应有服务器。复杂的消息解析和转换相比简单的路由操作所需消耗的成本要高的多，因此在ESB上应该主要考虑路由、格式转换、服务调用等问题，而对于数据本身的处理应该交给相应的应用来完成； 确定消息格式：从标准化的角度而言，XML当然是首选，但是从解析 / 处理性能、行业标准以及对现有应用的最大兼容性的角度而言，可能会采用某些特定格式，例如EDI、SWITF、平文本或者自定义格式等； 区别消息头和消息体：把数据的Meta-data，例如：安全相关的信息、日志的等级、请求端的标识等放在消息头中，而不要放在消息体中。这样可以很容易地改变其内容及其对其的处理逻辑。在ESB中只处理消息头，避免对消息体的解析； 设计时参考ESB相关的成熟Patterns； 使用服务注册库：如需要服务Endpoint的查找：推荐从服务注册中心进行查找，这样的好处在于：服务提供者可以容易地发布新的服务，服务提供者和ESB之间的耦合度可以更低，通过关于服务本身的Metadata来进行服务的查找和路由； 注重性能和高可用性的考虑； 在必须的情况下考虑交易完整性； 适配器的采用：应用系统通过适配器实现与 ESB 的双向交互，适配器主要分为技术适配器、应用适配器两种，适配器的物理部署可以与EIS部署在一起、或者与ESB部署在一起，也可以单独部署，在适配器设计时要考虑通信协议和消息格式两个方面； 多 ESB 的设计：ESB 也是一个逻辑的组件，在一个企业里可能需要多个ESB，例如：企业内部ESB连接企业内部各个系统，外部ESB实现企业与合作伙伴等的外部连接；再如：企业内部可能存在若干个部门级ESB和一个全企业ESB； 确定服务版本控制策略； 确定端到端的QoS准则； 注重安全性； 确定IT部门ESB平台的负责主体，长期的投入。 ESB的安全性考虑对于ESB的安全性考虑，主要有两种方式，第一种方式是通过ESB内部的Mediation节点来进行服务请求者的认证 / 授权；另一种是调用一个外部服务进行服务请求者的认证 / 授权，如图4所示，图中给出了这两种方式的示意图，具体实施时可以进行选择。图 4. ESB的两种安全实现方式    运行在ESB平台上的服务的管理和监控当一个企业开始它的SOA之旅时，开始阶段通常会选取一个具体的项目进行 SOA 的尝试，然后便会逐步走向全企业采纳，这时，大多数企业都会面临一个问题，那就是服务越来越多，对这些服务目录的管理出现了很多问题，例如：所有与服务相关的信息是如何被管理的，包括存储、管理、维护、存取等？服务请求者如何决定使用哪个服务？服务请求者如何定位服务的 Endpoint？当服务信息发生改变时如何得到通知？因此我们建议用户在尽可能早的情况下考虑服务注册中心的建设，所谓服务注册中心是一个企业范围内的服务信息的存储库，该存储库存储了企业中注册的服务和服务相关的信息，它的主要功能包括：采用集中的方式来管理服务相关的信息，为服务元数据同时提供“注册中心”功能，允许用户存储、管理和查询包含服务描述的服务元数据构件； 提供服务的治理功能，实现整个服务生命周期的管理； 提供服务间依赖、包容关系的管理； 提供分类和版本控制等功能； 提供服务发现和通知等能力等。 除了服务注册中心的考虑之外，我们还要考虑对服务的管理。服务不仅具有特定的功能，还应该满足一些诸如性能、可用性、安全性等QoS指标。服务响应的快慢、什么时间可用、可以被谁调用、在某个时间段里能被调用多少次、哪些事件要记录日志，这些都是服务管理要考虑的问题。通过服务注册中心和服务监控平台的有机配合，我们可以根据服务的响应时间、服务可用与否等策略来实现对服务的动态访问。让我们来看一个例子：图 5. 使用服务监控平台之前ESB的服务请求和响应图 6. 使用服务监控平台之后ESB的服务请求和响应    如图 5 和图 6 所示，我们可以利用服务监控平台对服务进行监控和统计分析，从而使ESB平台可以根据服务提供者的性能优劣来动态地绑定和调用高性能的服务，其过程如下：服务请求者请求“PurchaseOrder”服务 服务注册库查找到服务提供者 服务注册管理平台第一次调用了Proder1提供的服务 Provider1的性能被监控工具监控到 随着时间的推移，Provider1的性能越来越差 监控软件监控到这一现象，就会停止使用Provider1提供的服务 当下一次服务请求者再次请求此服务时，服务注册管理平台将调用Provider2，请求来自Provider2提供的服务。 ESB的开发和测试在ESB开发和测试阶段要完成的工作主要包括：基于eclipse工具的模型驱动的快速开发； ESB集成流程的开发； ESB路由、消息处理逻辑的开发； ESB数据映射和转换的开发； ESB外围适配器的开发和配置； 单元测试：基于模块的测试，包括适配器的测试，路由的测试，BO的测试等； 集成测试：ESB与其他服务提供者和服务消费者的集成测试，重点关注服务接口； ESB平台的性能测试以及系统测试，即整个ESB涉及到的端到端业务场景的测试等。 进行基于WebSphere Message Broker平台进行ESB开发时，通常要考虑以下一些方面的最佳实践，例如：通用的错误 / 例外处理、通用的日志 / 管理机制、子流程设计、交易完整性和消息永久性、ESQL的使用等。