谈ESB服务总线改进

jopen 7年前
 

对于消息中间件部分进行单独剥离,即讲服务设计和ESB协议转换和适配部分同消息中间件分离,对于消息中间件部分初步考虑采用RabbitMQ 或zeroMQ来实现,其中zeroMQ由于用c语言实现,相当来说更加轻量和高性能。但是RabbitMQ本身更适合做一个企业级的消息系统,其在集群,持久化,高可用性和分布式可扩展性方面往往更加有优势。相当来说RabbitMQ往往是更好的选择。

对于消息中间件的使用,主要需要实现几个方面的内容,一个是传统MQ的基本功能,即基于消息的异步通讯机制,其次是实现消息发布订阅模式,最后是一个重要功能,即用做ESB内部的消息存储和异步日志记录,通过MQ的异步功能对于日志进行异步持久化以实现ESB层本身的高性能,而不会影响到服务本身调用性能。

对于数据库可以看到,主要是包括两个方面的内容,其一是对于服务元数据管理部分的内容,其二是对于服务运行实例的持久化内容。其中可以看到对于服务运行实例完全可以采用独立的分布式数据库来存储,由于这种实例运行记录本身就类似key-value的存储模式,因此可以考虑采用mongoDB或 redis库来实现这部分数据的存储,个人对于这块倾向于选择redis库来实现即可。

对于服务总线的管控和治理平台建议是和ESB服务总线进行分离,管控平台部分的核心功能主要还是服务元数据管理,服务目录库,服务运行监控分析,服务安全和访问控制,服务全生命周期管理等基础内容。管控平台数据库可以用结构化的数据库,数据库本身不会有太大的性能瓶颈。

对于服务设计部份可以引入可视化的服务设计和服务组合,其中核心主要是实现适配器,数据映射转换,日志和异常管理,安全管理,外部接口调用,路由,消息发布订阅等基础设计能力。对于适配器是一个核心基础功能组件,主要需要实现对数据库,SOAP和rest WebService的接入,HTTP服务的接入,JMS消息的适配,FTP文件的适配等基础功能。同时在适配处理过程中实现大数据和大文件传送组件的集成。

进一步加强服务监控和预警功能,包括对详细SLA服务等级和策略的订阅,对预警策略的定义,能够实现准实时的服务监控和预警。同时在服务视图静态展现上增加服务预警和调用异常的动态实时展示,以帮助管理员更加实时的发现服务运行中的异常。同时增加对ESB服务总线集群的管理功能,其中包括对集群各个节点的监控,对服务部署实现集群化的动态部署,包括服务的热部署能力支持。以提升ESB平台本身的高可用性和可伸缩性。

可以参考Dubbo服务框架的实现模式,在服务目录库中引入两种服务接入方式,即一种是由ESB来实现服务代理,同时实现服务数据传输映射和运行日志审计;对于其它大数据调用服务为了提升技能,则服务目录中心仅仅是返回可使用的服务调用地址,由服务消费方和提供方进行直接的消息传输通讯。通过两种方式的结合可以更好的兼顾ESB总线的常规能力同时又提升服务总线的性能。

可以考虑通过本地SDK开发包的引入,进一步来简化服务提供和消费端的代码开发,该模式下虽然整个服务开发和消费过程更加简单,但是本身对业务系统有一定的侵入性,因此也需要慎重采用。

进一步加强对服务流量控制功能的设计和开发,即根据SLA服务策略可以更加详细的定义服务流量控制策略,包括服务在单位时间的调用次数,服务传送的数据量,同时也包括对于任何一次调用服务本身的数据量控制和预警等,通过服务流量控制一方面是减轻下游接收系统的系统压力,一方面也可以更好的屏蔽和发现各种非法调用。

可以考虑进一步加强对服务运行日志记录的分析,通过服务运行数据的采集和转换,结合前期总体的业务系统集成架构蓝图规划。可以通过服务消费记录更好的欢迎业务系统间业务系统的情况,这个一方面可以利用来实现业务单据的跨系统传递监控,同时也可以更好的用来实现后续规划的端到端流程监控上。