企业服务总线需求说明

企业服务总线需求说明

Enterprzise Service Bus

1 ESB的主要作用

ESB主要解决多终端多系统的相互调用问题，减少系统间的耦合，添加可维护性。



2 ESB的核心需求

ESB的核心需求主要包含：服务调用与数据适配、服务管理、服务安全、服务监控。

2.1 服务调用与数据适配

支持系统间进行相互的服务调用，系统间数据协议相互独立，通过数据适配可以自己主动实现系统数据与ESB数据的传输转换。





支持单个服务调用，多个服务调用(组合服务)。

2.2 服务管理

服务管理功能主要包含服务的注冊、公布、版本号控制以及服务信息维护功能。



2.2.1 服务的属性

业务系统须要与其他业务系统之间进行通信，是由ESB平台提供数据接口的服务进行，业务系统在使用服务前必需先进行注冊，并在服务有效的期间内。

2.2.2 服务的注冊

服务必须先进行注冊，记录具体的服务描写叙述信息。

服务由管理员来统一行进管理，服务的功能包含：添加（注冊）、改动（变更）、删除、查询。

2.2.3 服务的公布

服务公布后，才干提供外部訪问。

服务通过改动状态来控制是否向外公布，也可以通过时间段来控制服务的有效期（这个主要是针对平台向第三方公司提供的时效性服务）。

2.2.4 服务的版本号控制

支撑同一服务多个版本号的控制。

因为业务系统的开发进度等其他原因，引起数据接口版本号的数据结构或数据源不同。服务的版本号由管理员来控制，版本号名称由管理员填写。服务版本号的功能包含：添加、改动、删除、查询。

2.2.5 服务规则缓存

为了提高效率，系统初始化时，从数据库的路由关系表中读取路由关系，通过定义缓存接口，将其路由关系表信息写入缓存。

当路由关系表信息发生变更时，手动发送路由关系改动通知到改动缓存，又一次读取服务路由关系表，刷新服务路由缓存。

2.2.6 服务信息管理

服务信息的增删改查功能，以及信息的分类管理。

服务信息分类可以是多级分类结构的树结构

2.3 协议转换

不同业务系统之间的数据交换

不同的业务系统可能会使用不同的协议传递消息，ESB平台提供不同的接口类型以适应不同的入口协议或者出口，协议的转换在ESB平台的内部封装完毕，不须要在接入系统做相关改动。该平台支持的协议包含WEBSERVICE和HTTP等。

2.4 服务安全

建立良好的安全訪问机制，保证安全性。

以服务数据作为基础，构成业务系统须要的数据流转的路由，每一个请求都须要推断所发起的请求是否合法，否则应反应相应的代码说明“不同意该请求”。请求接入时要进行的验证。

2.4.1 验证流程



訪问授权验证

对URL參数_lic值的有效性进行验证，_lic和_valid通常是服务处理方提供，相当于用户/password的概念。

參数签名验证

对URL參数_sign值的有效性进行验证，用于防止传输数据过程中被拦截篡改，_sign的生成校验规则请看下文。

业务数据验证

具体业务级别的验证，依据服务路由规则的配置，读取服务路由关系验证。

2.5 服务监控

监控每一个服务的调用，写入监控日志，为日后的服务调用分析、调优提供数据支撑。

服务监控，记录每一个服务调度的过程相关的属性，以便以后系统的升级改造等提供可靠性的数据分析。

2.6 非功能性需求

2.6.1 高性能

支撑高訪问量的服务调用请求，建立良好的缓存、队列等机制。

组建一个高性能的数据调度的队列。定义作业调度的队列(List<WorkItem>)，利用新线程进行分配资源，避免堵死。可视化设置队列的等待的数量或等待数量自己主动适应(Auto)。

针对不同服务的业务要求，设置是否须要开启缓存，并统一设置缓存的生命周期。依据服务的调度的条件，把须要缓存的数据记录到一个缓存组(以Hastable)类型存储，有利于提高索引的效率。

2.6.2 扩展性

具有良好的扩展性，为日后的功能控制提供支撑。

2.6.3 可维护性

提供可视化、灵活的配置管理。

建立ESB控制台，用来控制整个ESB平台的功能。

3 通用功能组件

ESB的为服务的统一接入提供良好的支撑，在ESB上进一步接入封装很多其他的通用功能组件可以较少各个系统反复功能的开发。

3.1 系统日志

3.1.1 业务日志

支持多系统、多业务，依据数据量自己主动进行数据分表（按月或按日）。

3.1.2 维护日志

支持多系统、多业务，依据数据量自己主动进行数据分表（按月）。

3.1.3 错误日志

支持多系统错误日志记录，依据数据量自己主动进行数据分表（按年）。

3.2 计划任务

支持由周期时间或指定时间驱动的任务调度，触发运行指定的服务。

支持计划任务的可视化配置管理。

比如：

每月1号调用报表服务生成月运营报表。

3.3 事件管理

可以监控制定的业务类型，当发生业务时自己主动产生相应的事件，触发指定的服务。

支持事件的可视化配置管理。

比如：

当新审核通过一个学生档案的新增时，自己主动调用服务，为该学生开通会员账号。

收集各业务系统的业务需求，确定须要制订的事件，兴许再进行事件开发。事件以组件方面作为功能扩展实现，并添加事件触发时所产生的过程记录，方便以后统计管理及问题排查。