Terracotta 实战示例——集群 RIFE

Terracotta 的 Jonas Bonér最近详述了他和Geert Bevin（最近被Terracotta 招至旗下）如何群集RIFE Web 应用框架。这篇文章提供了RIFE Continuations 实现的颇有价值的深入见解和集群RIFE 这样一个不凡应用框架遇到的挑战。

Bonér 从介绍 RIFE 如何实现 Continuations 开始：

RIFE 的 Continuations 的目标是以通用库的形式，用纯 Java 形式支持 continuations[…] 它使用字节码方法（基于 ASM）来生成代码重定义 Class，以最高效的方式支持 Continuations 的实现。它不依赖于 Java 的序列化（Serialization）机制，而是把对象分拆成原始类型并把数据存储于执行栈中（类似 Terracotta 的方法）[…]Continuations 以树的结构连接在一起，可以任意访问不同的执行步骤。这意味着你可以任意回退或前进，很灵巧的解决了浏览器回退按钮的问题——如果在 Web 应用环境下使用的话。 在内部，RIFE 将 Continuations 存储于普通的java.util.HashMap中。

群集 RIFE 的第一个障碍是线程安全地访问这个 HashMap。RIFE 初始的实现，基于性能的考虑，只设计使用一条线程来访问 Map。在群集环境下，会由多个 JVM 并发访问。

第二个挑战是关于 Class Loader 的，就如应用服务器和 Web 框架的常见情形，RIFE 实现了自己的 Class Loader 来实现一系列特征，就像 Java 的系统 Class Loader 一样，这些 Class Loader 对于 Terracotta 不是现成可见的：

Terracotta 需要可以唯一的定义一个 Class Loader 的原因是它需要一个方法，在任意时刻任意节点，获得已载入了特定 Class 的 Class Loader 实体，以在群集范围内维护对象标识。

Bonér 和 Bevin 面对的最大挑战是如何群集 RIFE 模板引擎的动态。RIFE 可能在运行时动态的按需生成类。在节点崩溃时，在节点上生成的类就需要复制到接手处理请求的节点上。解决方案是构造一个 HashMap，实现群集范围的字节码仓库，RIFE 的 TemplateClassloader 被修改为指向这个仓库。

查看英文原文： A Real World Example of Using Terracotta: Clustering RIFE