【weblogic】WebLogic Real Time简介

【shitiku.jxxyjl.com--BEA认证】

        摘要

　　bea weblogic real time (wlrt)服务器提供了一种基于java的基础架构来满足实时处理需求。这在java领域中是比较少见的：按照实时需求处理请求，而不是只要求j2ee服务器可运行且可靠即可。使新特性成为可能的关键组件是jrockit java virtual machine (jvm)。本文将介绍bea weblogic server与bea jrockit的完美结合，并提供一些实时计算的基础知识。在文章的末尾，我们将简要介绍与weblogic real time相关的用例。

关于实时

　　在开始讨论weblogic real time之前，我们必须首先思考一下该产品中的两个单词的意思：“real”和“time”。关于“实时”（real time），存在着许多种定义，许多文章也描述了不同的概念——第一个java specification request (jsr 1)甚至就是专门针对此主题的。然而，实时的定义并不是一成不变的。没有人可以给出一个确定的定义，说明到底什么是实时以及如何确定它，但是似乎大家都认为，如果看到实时，自己就会知道了。为了更好地说明实时的概念，我们将引入几个常见的定义。根据douglas jenson对实时的讨论，存在两种类型的实时：“软”实时和“硬”实时。

硬实时：定义了一个系统，其中所有可调度和不可调度的实体的执行都要遵守规定的完成时间约束。其它时间约束（也称为“上界”）可能也必须满足。实体的行为和运行时间是可预测的、确定的。 软实时：表示不属于硬实时的所有其它实时情况。所有时间约束都是软性的。基本上，这就意味着所有可调度和不可调度的实体都可能被优化以便以最佳状态执行，但是执行时间不可预测。

　　在一个硬实时系统中，必须遵守时间期限，否则计算结果就会无效。例如，考虑汽车中的嵌入式系统。如果您要加速，而电子加速器的响应延迟了，那么就会得到无法预料的行为。而如果刹车系统延迟了，就会导致可怕的后果。软实时系统中的定时约束没这么严格，甚至在超出了时间约束之后，计算结果也可能仍然有用。
音频流就是一个软实时系统的例子。如果一个数据包延迟或丢失了，音频的质量会降低，但是流可能依然有效。

　　为了保证满足实时系统的定时需求，底层计算系统的行为和计时必须是可预测的。一个可预测的定时系统，其所有操作所需的时间必须是有限制的。这意味着所有操作在最坏情况下的定时是已知的。实时系统通常都是用多个异步线程实现的。这是因为他们通常需要响应事件以及控制异步设备。

　　另一个常见需求是优先级。因为特定事件的紧急程度以及需要处理的事件的数目都不同，因此必须支持优先级的概念，以便确保时间关键型的任务不会由于非时间关键型的任务而被延迟。让非关键型的任务以与时间关键型的任务相同的优先级运行就有可能导致此问题。由于这种优先级倒置，任务需要具有互相通信的能力。因此，实时系统必须提供同步和通信功能。简而言之，实时系统必须以最小的开销实现可预测性。

　　实时计算还有许多其它的理论，比如调度理论，在“参考资料”部分包括有相关的链接。您可能已经猜到了，我们将讨论的wlrt是软实时系统。这种对“硬性”和“软性”的讨论是有价值的，可以帮助理解期望从产品中获得的特性以及产品所针对的用例。下面是一些在讨论weblogic real time相关概念时所使用的其它术语和定义：

实时是一种计算机响应等级，在这种等级下，用户可感知到足够快，或者计算机能够跟得上某个外部流程。 延迟是指系统花在从一个指定点传输数据到另一个指定点的时间。 抖动是延迟偏差。一个具有确定性的应用程序抖动应该较低。该术语基本上描述了一种度量确定性的方法。 吞吐量是计算机在给定的时间帧中所能处理的工作量。 确定性垃圾收集是一个执行概念，用于描述快速的、可预测暂停时间的内存堆垃圾收集。垃圾收集是从堆中清理废弃对象以便收回空间用于新对象的过程。 weblogic real time

　　weblogic real time server (wlrt)为事件驱动的应用提供了一个低延迟的轻量级基础架构。它旨在用于竞争性较高的环境中，在这种环境中，性能非常关键，每一毫秒都很重要。例如，特定的行业（比如电信或保险业）要求事务在给定的时间帧中以极低的延迟执行。然而，如果尝试用标准的java来实现，则很可能会因为由垃圾收集过程所产生的无法预测的暂停时间而失败。这就是wlrt的用武之地了。它结合了jrockit jvm，后者引入了一种确定性垃圾收集机制，提供了一个用于执行这些关键型应用的j2ee运行时。确定性垃圾收集确保程序执行期间的暂停时间非常短，而且挂起的请求会在定义的时间帧中得到处理——从而允许购建高性能和确定性的应用程序。

架构

　　要了解该新产品，我们需要详细看一下整个产品组合。wlrt是一个依赖于jrockit jvm中的新特性的weblogic server，它使用集成的bea spring framework支持轻量级编程：

bea weblogic server 9.1是实时应用程序的j2ee服务提供程序。 bea jrockit 5.0 r26为确定性垃圾收集提供了基础。 bea spring framework 1.2.6是轻量级的编程模型。

　　下面我们将逐一详细介绍这3个组件。

bea weblogic server 9.1 sp4

　　weblogic server 9.1是bea有着良好口碑的著名企业java应用服务器的最新版本。除了完全实现了j2ee 1.4规范外，它还提供了一组标准的api，用于创建可以访问各种服务（比如数据库、消息传递服务以及其它与外部企业系统的连接）的分布式java应用程序。借助于weblogic server，企业可以在一个健壮、安全、高度可用且可伸缩的环境中部署任务关键型的应用程序。所有这些都可以使用一组集群化、管理和监控特性在给定的基础架构中实现。作为wlrt的一部分，weblogic server是事件驱动的低延迟应用程序的服务提供程序。

jrockit

　　垃圾收集对java性能有着很大的影响。在full垃圾收集期间，java进程会完全停止。当垃圾收集完成后，进程才会继续。从堆中清理废弃对象以及为新对象释放空间的过程需要进行高度优化，以便确保有效的内存管理。

　　jrockit可以使用一种动态的“确定性”垃圾收集优先级(-xgcprio:deterministic)。该策略被优化以确保暂停时间非常短，并限制定义良好的时间帧（也称为“滑动窗口”（sliding window））中的这些暂停的总次数。这对特定的应用程序来说很有用，尤其是对事务延迟有严格要求的应用程序。然而，即使较短的确定性暂停时间也不一定能保证较高的应用程序吞吐量。确定性垃圾收集的目标是降低在执行垃圾收集时运行的应用程序的延迟。与常规垃圾收集相比，确定性垃圾收集产生的暂停时间会短得多。通过在jrockit 5.0 r26中引入确定性垃圾收集优先级，可以保证以下的事务延迟：

在99%的情况下，在任何50ms的滑动窗口中，每周由垃圾收集引起的总暂停时间不超过30m。 在任何130ms的滑动窗口中，由垃圾收集引起的总暂停时间不超过100ms。

　　对于具有1 gb堆以及在收集时平均30%或更少的活动数据的应用程序，这些目标很容易实现。wlrt文档声明，这已经在以下硬件上得到了验证：

2 x intel xeon 3.6 ghz，2 mb level 2缓存，4 gb ram 4 x intel xeon 2.0 ghz，0.5 mb level 2缓存，8 gb ram

　　在具有不同堆大小且/或者有更多活动数据的更慢的硬件上运行可能会破坏这一确定性行为。在这种情况下，可能需要使用-xpausetarget选项增加暂停时间目标。确定性垃圾收集只作为wlrt的一部分可用。如果没有相应的许可文件而试图启用该功能，则会在服务器控制台上出现警告。

weblogic spring framework

　　wlrt的最后一部分是用于bea weblogic real time的spring framework 1.2.6。作为一个轻量级的应用程序开发框架，它的开发工作比起传统的j2ee开发有了极大的简化。实践证明，它非常灵活、易用，并且能够运行在具有高度的延迟敏感性的环境中。通过将plain old java object (pojo)用作ejb的替代方案，spring framework仍然能够访问weblogic server的所有可靠性特性。此外，它实施了模块化和可重用的编码实践。它还包括基于javabean的配置、一个aop框架、声明式事务管理、jdbc支持和一个web mvc框架。它在weblogic server上得到了认证（从9.0版本开始）。可以从weblogic real time产品下载页面下载受bea支持的spring版本。关于该框架及其与weblogic server集成的更多信息，请参见spring与weblogic server的集成（中文版，dev2dev，2006年3月）。

将各组件组合起来

　　在了解了组成wlrt的所有单个组件之后，接下来就是要把它们放在一起考虑了。图1展示了所有组件协同工作的方式。其中，必要的构件块是具有新增的确定性垃圾收集功能的jrockit jvm。比起其它jvm，它保证了极短的垃圾收集时间。只有在高性能容器的基础上构建应用程序，才可以获得这样的结果。对于wlrt 1.0来说，这是指weblogic server 9。但是在完成时，高性能且可靠的应用程序的关键是您自己的代码。wlrt尊重这一点，它只将spring framework作为一个架构组件进行集成，但并不强制用户使用它。只不过它是一个构建模块化的、可重用的、高性能的应用程序的良好起点。如果使用它来开发应用程序，就很容易遵循常见的用于优化资源访问和灵敏性环境中的其他关键因素的著名模式。

图1. weblogic real time服务器架构

实时用例

　　了解了wlrt的所有组件之后，我们需要看一下相关的用例。weblogic real time可以使用响应灵敏的应用程序为高性能环境提供解决方案。即使wlrt并没有附带相关的示例应用，我们也很容易想到一些。

向套利交易商提出挑战的衍生工具交易

　　一家大型零售银行的投资工具提供了欧洲证券的衍生工具交易。它是一个柜买中心(over-the-counter，otc)请求报价和执行系统（但是不提供结算和清算服务）。经纪人提交一个报价请求，并包括了证券代码和数量。系统接受报价并应用特定的业务规则。根据证券代码和市场形势，请求被转发到特定的第三方做市商（market maker），然后做市商会计算并提供该衍生工具的出价和叫价。响应会通过otc交易台返回给经纪人。然后经纪人可以通过一个后续请求执行该衍生工具的交易，该请求会通过otc交易台转发给相应的做市商。

　　该场景的复杂性在于，银行的otc交易基础架构处理报价请求的短暂等待延迟可能会被套利交易商所利用。在瞬息万变的证券市场上，在这个延迟发生期间，该衍生工具的价格就可能发生了变化。这为套利交易商提供了一个利用交易所的低效率的空子，并将投资银行暴露于其无法承受的风险中。因此投资银行需要一个性能驱动的软件基础架构来交付具有极低延迟的otc交易。具体来说，为了抵制套利交易商，交易所基础架构的延迟必须比套利交易商的基础架构的延迟短。这样，套利交易商的数据就在交易所的数据之前失效，因此就不可用了。

网上购物平台：beay

　　beay为用户提供了一个销售商品的系统。除了常规的购物功能外，用户还可以利用系统的一部分进行商品的竞拍。卖家为出价者设置竞拍期限（几周或几个小时）。到期限结束时出价最高的顾客会被接受。成功的关键是要尽可能多地出价，但是不要比前一个最高出价高出太多。越接近竞拍期限的尾声，做出正确的出价就愈发显得具有时间关键性。

　　假如说有两个用户在争最高出价，并且它们都在最后5秒中提交了一个报价。其中出价较高的那个正好遇上了系统延迟（可能是由于运行了垃圾收集），因此出价较低的那个用户就会在竞拍期限结束后被接受。这样，购物系统操作员错过了可能的更高利润份额，卖家错过了更高出价，而顾客则失去了对该系统的信任。因此，beay需要一个具有极低延迟的高性能基础架构，以便确保在适当的时间期限内，所有顾客都拥有使他们的出价被接受的同等机会。

结束语

　　weblogic real time 1.0最近刚刚发布，该产品包应该能够启用一些支持实时应用程序的新特性。虽然这首个版本并没有提供所有的实时概念，但是以后还将出现更多的新特性。下一个wlrt版本（预计会于今年年中发布），将会提供补丁以及进一步优化的确定性垃圾收集功能。以后的wlrt版本应该会进一步精化实时服务，比如实时线程和调度程序，以及高分辨率计时器。还可以期待wlrt会解决一些与事件流处理和分布式缓存相关的问题。

　　wlrt适用于任务关键型环境，并支持低延迟和性能关键型应用程序的运行。在这个新的企业java领域，它还只是迈出了第一步。虽然并不是人人都需要实时特性，但是它填补了企业java领域中以前阻碍此类应用程序开发的鸿沟。weblogic server、jrockit和spring轻量级应用框架的组合为我们打开了一个令人兴奋的开发空间。

参考资料weblogic real time下载页面 weblogic real time documentation——产品文档 performance analysis of the weblogic real time 1.0 "trader" application，tom barnes (dev2dev，2006年4月) spring与weblogic server的集成，andy piper等（中文版，dev2dev，2006年3月）——对weblogic spring framework的很好的介绍 jsr 1: real-time specification for java——对实时java的很好的介绍 对douglas jenson所描述的实时概念的很好的介绍

本文来源：https://shitiku.jxxyjl.com/bearenzheng/4144.html