为ESB平台设计关键应用

　　企业越来越把对业务的关键应用放到ESB上，这些应用要求较高等级的服务质量。这些非功能需求要求可靠性、可用性、伸缩性和性能（缩写为RASP：Reliability, Availability, Scalability 和 Performance）。
　　
　　可靠性是指系统按设计那样执行的能力，对于ESB，对两类可靠性感兴趣：
　　
　　" 可靠的消息：即使在故障事件中，系统递交消息的能力。
　　
　　" 可靠的处理：系统以一种可靠的方式处理消息的能力。
　　
　　可用性是在故障事件中继续处理请求的能力，这包括硬件和软件的故障。一般通过硬件的冗余来避免任何单一的故障点。
　　
　　伸缩性是通过添加硬件资源来处理逐步增加的负荷的能力，有两种形式：
　　
　　" 垂直延伸是指改进单一计算机的能力。比如，增加内存或升级CPU。
　　
　　" 水平延伸是指将负荷分配给附加的计算机。
　　
　　性能是迅速地处理请求的能力，这是对系统响应时间的度量。相关的吞吐量的概念是性能和系统能处理的最大请求并发数的结合。
　　
　　(1)ESB平台:
　　
　　客户机=》消息队列=》（BPEL引擎）（消息存储）（BPEL缓存）=》可靠RDBMS
　　
　　BPEL引擎提供一个可靠的处理环境来进行处理。随着一个业务过程的每个实例被执行，与之关联的状态自动地保持到BPEL数据库。在某个服务器故障时，就能够从数据库中恢复此状态，处理实例的执行跟平常一样的继续。较低反应时间恢复策略减少了恢复所需的时间。使用告诉相关引擎来执行消息递交给合适的处理实例（即相关性），确保随着实例数的增加消息递交仍然高效。在集群环境中，BPEL引擎为处理实例实现了服务器亲合模型。这就确保了每个"飞行"处理实例在任何给定的时间只缓存在一个服务器上。倾向于"飞行"处理实例的消息自动地前往正确的服务器上。
　　
　　消息存储确保传输提供的服务质量继续未被中断进入BPEL引擎，将传输层提供的可靠消息与BPEL引擎提供的可靠处理链接起来。在数据库不可用时，消息存贮自动停止从可靠传输检索消息，来确保没有丢失消息。
　　
　　BPEL引擎集群内的多个服务器可以协作来提供负载平衡。在集群内进行消息的相关，确保消息可以到达集群内的任何一个服务，并仍然被正确地处理。某个服务器离开集群就会自动触发恢复，这就确保了所有的处理实例仍然在集群内运行。
　　
　　BPEL缓存最小化了BPEL引擎所需的数据库访问的数量，从而改进性能。
　　
　　(2)RASP最先步骤:
　　
　　在服务器集群中使用ESB平台的特性是满足RASP需求的第一步。另外要作很多部署环境方面的很多决定，如：
　　
　　使用可靠的传输：消息必须在可靠的传输上交换，可以通过WS-RM或很多JMS供应商的一个。我们或许早就使用了基于队列的消息系统，可以通过JMS接口来访问此系统。尽早的应用设计的早期做出使用这样的传输的决定。
　　
　　很多基于Internet的应用使用原始的HTTP作为传输，也确实有这样的场所最适合使用。所以问题就成为在架构中哪些适合HTTP，哪些不适合。如果用户通过WEB浏览器与系统交互，HTTP是最合适的传输。此时，错误发生时，使用人员可以采取适当的行动，如放弃事务或重试。然而，在很多情况下，如在线零售，存在一个用户完成事务并离开的点，处理事务的后台系统必须以可靠的方式进行。一旦接受了支付，放弃订单是不可接受的。这时，就必须引入可靠传输和处理的使用。
　　
　　使用更高可用性的数据库：BPEL引擎使用数据库来保持一致的所有信息。这就使用数据库的选择以及如何配置对于系统递交的服务整体质量是一个重要的因素。要求为BPEL引擎和消息存储使用更高可用性的数据库。
　　
　　排除单点故障：为了创建一个即使在故障时可以继续可用的系统，我们必须具备至少两件事情：意味着路由器，服务器，数据库和别的。这是相对容易理解的方法，使用此方法编写如何实现高可用性的WEB站点。即使处理从WEB浏览器的HTTP请求不同于ESB上的消息，准则仍然是一样的。
　　
　　过剩设计：服务器集群提供了负载平衡和故障排除。我们必须考虑这些需求如何彼此相关。在故障时，系统必须故障恢复到余下的硬件上。为了系统继续成功运行，余下的硬件必须有能力去处理负荷。也就是说，我们必须对系统过剩设计。
　　
　　计划定期维护：易管理的概念是与可用性相关的。这是在定期维护时，保持系统运行的能力。对于一个需要14/7可用的系统，提供可用性的系统冗余可以用来允许维护。维护包括硬件的前置替代，以及软件部件的升级和维护。当选择合适替代硬件时，必须考虑故障之间的平均时间。
　　
　　先调查和持续测试：构建在ESB上的大多数应用包含一些与遗漏系统或已有系统之间的交互，这些系统将部分工作来满足RASP需求。在项目的计划阶段就要对这些已有系统进行评估和测试，目的是识别需要进行哪些纠正措施。测试RASP的所有方面必须贯穿项目的生命周期，并与开发平行进行。
　　
　　知道自己的目标：从一开始就要知道RSAP的需求，这点很重要。这些需求必须软件设计和硬件规格。不要浪费时间在优化不能处理负荷的系统：我们必须扩展系统或修改应用架构。
　　
　　(3)应用设计
　　
　　识别RA和SP的正确的平衡：可靠性和可用性是相关的，伸缩性和性能是相关的。有时候更好的可靠性和可用性意味着更少的性能和伸缩性。要为每个应用找到合适的平衡。或许最明显的决定是在使用BPEL时。
　　
　　BPEL引擎提供的可靠性在处理消息时成为强迫的选择，特别是在需要保存状态的地方。然而，一个业务处理的某些部分或许不需要任何状态被管理。在很多情况下，可以使用BPEL来对过程建模，并管理相关的状态，但是调用Java服务来执行很多处理。可以实现BPEL的可靠性和Java性能之间的合适的平衡。
　　
　　使不可用的影响局部化-使用异步消息：在同步系统中，任何部件的不可用将引起错误，并迅速传遍系统。要消除所有的单点故障是不可能的，特别是在使用遗留应用的地方。这会引起很严重的问题，需要确保修复时间最小化。在可靠的传输之上使用异步消息能够确保随着处理的延迟感知到此事故，而不是拒绝请求。
　　
　　使任何不可靠性的影响局部化：ESB通常被放在将已有的（有些遗留）应用暴露为WEB服务的角色。这些应用和他们使用的传输或许不能提供可靠性保证。为了连接到这些应用，ESB支持多个传输。大多数这些传输不提供可靠性保证。
　　
　　确保高效地管理资源-使用异步消息：异步消息的使用与系统的可用性相关。这对于系统如何伸缩也是很重要的因素。在通过HTTP调用请求/响应风格的操作时，处理请求时连接仍然保持打开。这会在客户机和服务端消耗有价值的资源。当负荷增加时，处理请求的时间会增加，导致越来越多的连接仍然打开。这会导致恶性循环，明显限制系统的伸缩性。异步消息的使用避免了不得不保持连接打开的问题。
　　
　　通过从内存驱逐处理实例，BPEL缓存能主动地管理其自身的内存消耗。处理实例可以从数据库中得到给集群中的不同的服务器。
　　
　　容忍服务内的故障：在可能的情况下，服务可以容忍故障的发生，但是不能传回给客户机。诸如"资源未能获取，请随后重试"不应该是SOA的部分。如果简单的存贮请求并随后重试是合适的，那么应该是服务本身去做而不是将此请求推给客户机。对于不能自动处理故障的地方，可以考虑给予报警请求进行人工干涉，而不是将故障传递给客户机。这就确保了故障就近处理。当然有时候需要将故障报告给客户机，此时故障与服务的业务逻辑相关，而不是IT层次的问题。
　　
　　选择合适的消息粒度：粒度对于SOA的成功是基础。理想情况下，一个服务必须接收单一的包含一切所需的文档来完成任务。
　　
　　选择正确的粒度是困难的，依赖于对业务需求的良好的理解。聚焦在任务上是良好的开始。识别业务需要实现的任务，然后设计包含足够信息的消息来完成，而无需多次交换。
　　
　　为了处理单一的事务，计算交换的消息数：性能不是只靠硬件就能解决的。好的性能需要良好的软件设计。在SOA中，系统设计的一个重要的考虑是交换的消息数。在进行应用设计中与性能相关的评审时，计算交换的消息数作为从客户机接收单一请求的结果。这对系统的性能和伸缩性都有影响。
　　
　　始终如一地使用特性：集成已有系统的需求导致不同RASP等级的互相连接。