怎么卸载oracle esb,关于ESB的一些看法

本帖最后由 efsca 于 2013-9-9 18:18 编辑

ESB的理念起源于交换系统，此后为成为各种应用系统的连接枢纽，而又需免除各应用系统自身的改造工作，就逐步发展成支持多种通信协议、多种报文格式的一种增强了适配能力的交换系统，再后来融入综合前置和SOA的理念，支持服务的封装与集成。与此发展过程相对应，业内实施的ESB也可分为3个层级：

1)        原型(交换系统型)

2)        适配增强型

3)        服务集成型

第3层级的ESB——服务集成型ESB——融合了综合前置系统的功能，因此必须考虑服务集成模式中常见的一致性问题，同时，还不能丢失交换系统的本质——服务集成应用必须以异步方式(请求和应答的处理分开，由不同的线程/进程执行)工作，而不能像传统的综合前置系统那样，以同步方式(发出请求的线程堵塞等待被集成的服务系统的应答)工作，因此，技术实施的复杂度非常高。

构建ESB首先应有一个比较明确的定位，即构建第几层级的ESB。

其次，如果将其定位成“所有”或“很多”应用系统的连接枢纽，则该ESB在整体架构中将处于一个极为关键的位置，因此，系统的性能、稳定性、吞吐能力、是否支持集群部署等方面也需极为关注。

在ESB是否应成为“所有”或“很多”应用系统的连接枢纽的问题上，不同银行有不同的回答。为便于讨论，我们为ESB临时定义一个术语——枢纽化程度，即经过ESB完成调用的应用系统接口数量÷应用系统接口总数。ESB的枢纽化程度与一家银行的应用系统的异构化程度往往是密切相关的。几十年来，4大国有商业银行依靠其在应用开发能力上的巨大投入，不断追求一种理想的架构——同构、集中的应用系统架构，对于这类银行而言，ESB的枢纽化程度很低，应用系统之间接口的调用大多是在一个线程内完成的；而大量的中小银行并不具备4大银行的条件，银行越小，其应用系统的建设就越依赖外部产品和应用开发服务商，异构化程度就越高，那么它们对于ESB的枢纽化程度的要求也就越高。

考察ESB的性能主要是看一个接口的完整处理过程在ESB上的消耗时间，这个时间通常应低于1秒才算达标。

考察ESB的稳定性主要是看系统能否在达到并保持极限处理能力的情况下，在一个较长的时间段(比如48小时)内平稳运行——系统CPU和内存资源消耗曲线保持平直。

考察ESB的吞吐能力主要是看一个时间段内ESB有效加以处理的请求报文的数量。对于枢纽化程度要求较高的ESB而言，这个指标至关重要。实际上，业内有些ESB项目就是在这个指标上达不到要求，而不得不反过来降低其对ESB枢纽化程度的设定，严格来讲，这些项目都是失败的。吞吐能力不能单独考核，而必须结合压力与稳定性测试，在一个较长的时间段内判定吞吐能力指标。

吞吐能力和单个接口的处理性能有一定的关系，但更主要的决定因素是应用的工作方式。异步的工作方式能够在数量有限甚至固定的进程/线程资源上达到极高的吞吐量，而同步的工作方式就必须要通过创建大量进程/线程才能在某个时刻达到一个较高的吞吐量，但由于线程大量、反复的创建与销毁极大地消耗系统资源，导致系统资源消耗曲线不平、不直，因此其高吞吐量不可持久，且会极大地影响系统的稳定性。

ITPUB论坛上有这样的看法：“在国内银行业来讲，ESB真正实施成功的案例应该是没有的”。我们认为这个看法某种程度上是成立的，大多数ESB项目最终不得不在定位上退缩——降低层级的设定，以及降低对枢纽化程度的设定——才得以上线或继续运行。第3层级的枢纽化程度较高的ESB的成功案例是没有的。甚至绝大多数定位成第2层级的ESB，枢纽化程度也未能达到预期——原因在于构建这些ESB的技术源自某种综合前置系统，而非交换系统！2010年，我们在给**银行做的架构规划咨询中就发现，该行当时引入的某家厂商提供的宣称是专用于构建ESB的技术平台，继承了综合前置系统的设计模式，其运行效果可想而知——仅完成了计划中不到30%的接口封装，两台小型机处理能力即已到达极限，不得不停止其余接口的封装工作。该技术平台据说还是中小银行用以构建ESB的主流平台！

最后，由于在ESB上有大量的接口封装工作，这些工作不能指望全部由高水平的开发人员完成，因此，ESB支持更加直观的，基于配置，甚至图形化的配置进行二次开发也是很有必要的——这能让大量较低水平的开发人员也能参与到接口封装工作中，并保证工作成果的品质。