ESB可用性和性能

ESB是一个企业内服务的集合点，他如果失去效能或者性能太差，都会影响到整个企业的所有应用的不正常，由此可见，ESB的可用性和性能有多么的重要。

      ESB在一般的情况应该是一个无状态的，如果在设计的时间一定要有状态的话，可以把状态，放入一个统一的分布式的cache或者JMS中去。这样做有一个 好处，可以使用多个实例来做负载均衡，使得ESB有能力做热备来提高应用的可用性。在我们现有的应用中，一般是使用了apache来做交易的分发。这样做 一点很大的缺点，他只能应对http的请求，而事实上ESB的应用不会只局现于http的协议。在实际的应用中，我们也有使用一些其他的自定义的传输协 议，他们因为没有办法使用apache的交易分发。在这种情况，我觉得ESB最好是能够使用传输层的交易分发，而不是使用七层应该用的交易分来做。使用传 输层的代理如果有能力的话，F5应该有这个功能，而且是硬件的可用性和性能都没有得说。如果没有条件的话，可以使用类式LVS这类的软件来实现。

      有时候，如果条件允许的话，我们会乐意看到，我们的endpoint能够植入到相应的应用中去。如果能做到这点的话，我相信我们也可以使用植入的 endpoint来实现apache或是F5的功能，而且可控性也大一点，必竟必码都是我们写的。具体的做法是这样的，当植入endpoint应用的启动 的时候， endpoint会在列表中的，一个或都多个的默认的ESB应用中请求一个路由表，我们使用这个路由表，能过不同的策略来路由到相对应的ESB应用中。如 果某一个实例要受到流控框架的报警，我们也可以向相应用的endpoint进行通知，让其能够路由到其他的实例当中去。

      上面我们提到了流控框架，一个ESB应该是一个可以治理的系统，为了，防止应用被突发的大交易量而压死，通过的一定的控制能够保证一些重要的交易能够正常 的进行，保证企业内的重要的系统能够正常的运行。流控框架还有一个作用，那就是保证下游的系统不会被交易给压夸，我们会在流控系统中为每个系统设定一此伐 值，而且，可以为这个系统配置多个的实例，流控系统会跟据这些伐值，和交易的响应情况对这个系统中的交易进行流控，从而一定程度上保护下由系统。