首页 » 漏洞 » ESB服务总线架构设计思考(8.13)

ESB服务总线架构设计思考(8.13)

 

本篇主要谈下基于Oracle SOA 12c套件进行的ESB服务总线平台搭建过程中的架构设计思考。对于Oracle SOA 12c中OSB,MFT等已经在博客前面诸多文章都有谈到,因此这篇重点还是基于架构设计的关键内容展开来谈下对于关键点的思考。

由于ESB服务总线偏一个中间件的技术平台,同时又采用了Oracle OSB标准套件产品,因此对于架构设计的重点将放在基础架构搭建和对集成业务场景的分析和应对上面。

ESB服务总线架构设计思考(8.13)

部署架构

对于Oracle SOA套件包括了SOA Server(BPEL),OSB,BAM,ODI,MFT,JMS等多个子系统和组件。因此在部署架构规划的时候要考虑是一同部署,还是按不同的组件分开部署。在大型的项目中,我们建议还是分开独立部署,减少各个组件相互间的影响,特别是ODI和MFT,虽然并发不大,但是对于网络流量要求很高。

部署架构设计的一个重点就是没有任何的单点故障,对于数据库我们可以采用RAC或HA架构,而对于应用服务器层可以采用Weblogic Cluster集群,同时对于Admin节点也必须HA架构部署防止单点故障。对于Cluster集群所有节点又接入到上层的负载均衡,即通过硬件能力来实现请求分发,而Cluster集群重点是心跳检测和日常部署管理等方面的内容。

对于硬件负载均衡,启用七层负载均衡,虽然会降低性能,但是可以配置Http监听地址信息,防止OSB服务器节点出现假死等现象。

对于大的OSB集群,如果接入的服务数量相对大,我们还可以对OSB集群进一步的进行逻辑分域,可以按服务的提供系统进行分域,也可以按SLA等级水平等进行分域,分域后对于不同的逻辑分域启用不同的端口号来区分。分域的主要目的仍然是防止单服务出现故障后影响到所有的服务运行。在Weblogic 12c推出了租户和分区隔离,是否能更进一步实现资源池隔离还需要确认。

对于部署架构可以采用云化资源池的虚拟机进行部署,但是必须提供共享存储能力,对于数据库仍然是建议采用物理机部署。如果是采用虚拟机部署数据库,需要尽早的对虚拟机的IO能力进行性能测试。


不同的业务需求和集成场景,采用不同的集成技术来实现,这是ESB服务总线在进行企业集成中必须要考虑的问题,并基于不同的场景梳理不同的集成原则。比如对于OSB总线,如果用来进行大数据传输往往可能直接导致OSB性能瓶颈和内存溢出,这些都是由于服务实现设计不当导致,而不是OSB产品本身缺陷。

OSB服务总线接入服务最适合的场景就是各种业务服务的封装和接入,这类服务的最大特点就是并发量大,偏实时服务访问和调用,但是每次服务消费传递的消息数据量却很小,这是OSB的处理长项。

对于大数据集成和传输,仍然建议采用类似ODI子产品来解决,即ETL+OSB的组合集成技术,这样既通过ETL实现了数据集成和传输,又通过OSB实现了服务访问的管控和接入。同时ETL传输的大数据不需要在传输到OSB管道和内存中,极大的减少了对OSB本身的压力。

对于大文件集成,在SOA 12c套件中增加了MFT子产品可以实现文件的端到端传输,通过在传输过程中增加了全流程监控,数据加密和安全,可视化设计,OSB服务集成等诸多内容。

如果是异步消息分发场景,消息发布订阅场景,需要服务消费和提供方彻底解耦的场景,建议采用Weblogic JMS来实现消息的集成和管理,作为企业级的消息中间件,完全能够满足需求。在使用JMS消息中间件的过程中建议对于消费方仍然进行WS服务适配,发布WS服务,而对于消息接收方直接开发JMS接收端。

虽然OSB服务总线增加了服务轻量编排能力,对于常见的路由,分支判断,数据映射,异常处理等都可以在OSB的Pipeline中完成,但是对于复杂的多个服务的组合仍然不是OSB的强项。对于对于多个服务的组合,包括流程编排仍然建议采用BPEL组件来完成。

在OSB 12c版本中,对于Rest API服务接口的接入支持的更好,而对于Rest接口仍然是建议在技术服务的接入和能力发布中使用,对于这类服务一方面的是高性能要求,一方面是太强的服务契约格式要求。


基于不同的业务集成场景,采用不同的集成技术和方法本身就是为了提升性能,对于其他性能思考包括。

对于OSB服务总线,特别是对于大并发访问的查询服务,启用OSB总线中的缓存设置,同时设置相应的缓存管理策略和缓存失效时间可以极大提升性能。但是要注意,采用缓存设置后本身也会消耗JVM内存,因此不适合对于所有服务都启用该设置。

对于OSB服务集成,前面有文章谈到过,可以启用Steam流传输方式来提升性能,即对于传输的消息体不进行解析,不进行消息的序列化和反序列化操作,但是经过测试性能改善并不太明显。如果是数据量较大的服务仍然是WS服务接入了OSB,我们还可以对查询或导入类服务进行分页处理,通过分页来提升单次服务访问的性能。这本身和应用功能开发中的分页是一个道理。

在OSB服务设计中,增加了Split/Join功能,即可以对输入的大消息流进行纵向或横向拆分,拆分为多个子消息流然后并行进行传输和处理,最后再进行合并。例如对于1个1000行数据的导入,我们可以拆分为10个100行数据的导入并行处理,提升效率。经过测试可以提升3-5倍的性能。

安全方面的设计

对于OSB 12c在安全方面的功能相当完善,基本覆盖了访问安全,数据安全,传输安全多方面的内容。同时可以灵活的定义安全策略,然后将安全策略配置到对应的服务中。

对于访问安全,可以启用相应的消息头Username/Password验证,同时还可以启用基于IP的访问控制策略,这些都可以灵活配置。如果涉及到外网访问,还可以启用Https安全传输,包括企业数字证书等。


支持重试是OSB服务接入设计中的一个重要内容,在OSB服务封装中,这是一个可选的灵活配置项,即可以配置服务是否支持重试,已经重试的次数。这对于网络闪断或者目标服务器临时中断无法访问等都是很好的可靠性保证手段。

资源隔离是可靠性的另外一个重要保障,在前面部署架构已经谈到过,最好是根据服务提供方系统或者服务SLA水平等多服务进行多个逻辑分域部署,各个域之间保证逻辑隔离,减少相互之间的影响。

流量控制是可靠性设计中的另外一个重点,在OSB中提供了消息入口和消息出口的双向流量控制能力,通过流量控制可以保障高SLA等级的服务资源不被占用,同时又对于个别服务大并发异常访问抢占资源的情况进行隔离。在企业流量控制的时候,最好还和监控预警策略进行整合,在出现预警的时候即使通过的管理员。

在企业JMS消息中间件功能的时候,还需要考虑消息持久化机制,可以采用文件进行消息持久化,也可以采用数据库进行消息持久化,通过持久化机制最大程度保证消息不丢失。

部署架构中的RAC,HA或集群架构设置都是为了保障整个基础架构无任何的单点故障。

原文链接:ESB服务总线架构设计思考(8.13),转载请注明来源!

0