Mark Turansky 详细描述了采用Terracotta 和Java 5 实现的一个消息总线架构。Mark 没有使用基于MQ 或者JMS 的部署,而是采用了先进的 Terracotta 架构来创建他的 POJO 消息总线。这个架构为他的消息需求提供了一个整洁、简单并且不贵的基础架构解决方案。开发过程中留下了这么一则笔记:
我们的第二个实现……使用了 JMS(因为)ActiveMQ 也是开源的、成熟的,而 Camel 在各方面都非常酷,他们提供了一个针对在队列之间路由规则的小型领域特定语言。
由于在消息总线架构中 ActiveMQ 不能良好地工作,所以 Mark 团队开始研究使用 Terracotta。多亏了良好的设计,团队方便地用新的消息结构替换了老的消息结构:
所有与 JMS 相关的代码都被处理器 / 监听器接口隐藏了。我们的消费者逻辑不知道消息(我们自己的领域对象)从哪里来。处理器和监听器的实现由 Spring 注射进来。因此,仅仅花了 90 分钟就将老系统初步替换为使用 Terracotta 实现的队列和路由系统。然后我们清理了系统,让它更健壮,增加了商业可见性方面的功能,并且狠狠地做了负载测试。它工作得很棒。
消息系统的主要组件包括:
- 针对排队的 Java 5 并发 API(特别使用了 java.util.concurrent.LinkedBlockingQueue)
- 一些 Java 线程的知识
- 对长时间运行的 Java 进程的深入了解(得益于对 tomcat 的做法的研究)
- 对于类装载器以及如何命名类装载器的超过中等水平的理解
- 如何“排列”(“spool”)请求
架构的其他部分来自对于 Terracotta 如何与类装载器工作、在集群内存中的对象以及并发的调查与理解。Terracotta 本身提供了消息系统的脊柱和胶水:
最后但是也很重要,你需要一些队列,你需要多重 JVM 消费者,你需要不会因为一场灾难性故障而失去的持久性数据,你需要商业可见性来跟踪所有的队列和消费者的健康情况和状态,你需要将这些整合在一起。Terracotta 服务器非常好地处理了这些需求。
最终,Terracotta 允许使用 Java 5 并发 API 来提供“在内存中”的 POJO 消息队列,生产者可以向这些队列放置消息而消费者可以从中取得消息。通过使用引导装载器(bootstrap loaders )将消费者实现为长期运行的守护者进程,本架构使用简单的POJO 实现了网格计算能力。
Mark 还描述了该架构的开发者友好性:
(Terracotta)使得让我们可以制作一个在 IntelliJ 中漂亮运行的纯粹 POJO 系统。一个单独的“容器”类型主程序可以通过装载我们各种各样的 Spring 配置,在一个单独的 JVM 中运行我们所有的组件。开发者可以在他们的桌面,在他们的 IDE 中运行整个消息系统,在消息系统上运行他们的代码 。他们可以向一个在 127.0.0.1 监听的端点发送消息并且在消息系统中调试他们的消息代码。
该架构实现允许开发者以很小的代价拥有简单性、伸缩性和可靠性。Mark 还说这个简约的框架让他的团队在开发中获得很大的自由度和灵活性。他们可以避免被锁定到任何重量级的应用服务器 API 依赖之上并且保持一个非常小的内存负载(整个实现是一个 100KB 的 jar 文件)。
Terracotta FAQ 说他们不提倡用 Terracotta 代替 JMS ,但是 Terracotta, Inc 的 CTO Ari Zilka喜欢Mark 的言论。在相关的新闻中,Jonas Boner 详细叙述了如何使用Terracotta 集群Scala actor 来执行Fork/Join 或者Master/Worker 过程。
<pre id="line41"><strong> 查看英文原文:</strong> <a href="http://www.infoq.com/news/2008/03/terracotta-as-message-bus" id="utmb" title="POJO Messaging Architecture with Terracotta">POJO Messaging Architecture with Terracotta</a>
评论