Terracotta提供一种 JVM 集群方案，可让单节点、多线程的应用变成分布式、多节点的应用，而无需修改一行代码。InfoQ 之前报道过，得到 VC 支持的 Terracotta 在 2006 年底转向开源，从那以来已经有了很大的进展。最近的新进展包括 2.4 版支持 Websphere 和 Hibernate，以及 Terracotta 获得了大量用户的接受，如 PartyGaming（PartyPoker.com 的制造者）。InfoQ 就开源转变以及 Hibernate/Websphere 支持访问了 Ari Zilka。
据 Ari 说，这一年中成长速度大大加快，夏天的时候论坛贴子数量翻了一番，网站每周的访问量达到几千，超过 100 个客户部署了他们的产品。“与开源产品和框架如 Jetty、Geronimo、Spring 和 Tomcat 集成用的 Terracotta 集成模块起到了加速的作用”。至于转向开源对公司的成长有何影响：我们相信开源是重要的催化剂，有两个原因。首先，它降低了用户接受的成本，也降低了我们公司的销售成本。顾客现在自己完成整个概念验证过程，看过 Terracotta 在他们的应用中的使用效果，然后找我们谈企业购买的事情。这非常有助于我们保持较低的开销。这对顾客也很好，因为他们只需要投入一点时间就可以得出价值命题的结论。第二，开源是一个强烈的信号——开放源码是表明自身可靠程度的强列信号，表明你知道自己的产品是优秀的，并且可以经受住详尽的技术检查。我们相信在引入像 Terracotta 这样一种全新概念的时候，开源的影响会特别有价值。
从由 VC 支持的商业收入模型转向开源模型：
我们和顾客双方的交易成本都降低很多，这也加速了顾客的接受过程，对我们和用户社区都是巨大的利益。不过实际上转变过程并没有人们想象的那么戏剧性。公司的核心工作是制造出能增值的产品，然后想法把产品换成金钱。赚钱这个基本任务并没有改变，更不会消失。开源有利于产生好的产品，但决不是不花钱的。最大的变化是你的首要对手变成了自己，你必须找到方法去支持你的社区同时又赚到钱。我们同样认为这对顾客是很好的事情，因为 Terracotta 不能只提供支持，还被驱使着去发现更多创造性的价值增长点。在未来的几个月中，社区就会明白我们的意思。
Terracotta最近公布了一些值得注意的新客户，包括在线赌博公司 PartyGaming、实时 RIA 框架 Kaazing，以及开源 CMS 开发商 Liferay。PartyGaming 经营 PartyPoker.com、PartyCasino.com、PartyBets.com 和 PartyBingo.com。他们的 Terracotta 部署包括几百台游戏服务器组成的集群。PartyGaming 的 CEO 说，“Terracotta 有能力组建数百台服务器的集群，同时网络使用率比其他方式低很多，由此带来的高性能是 PartyGaming 最主要的考虑。”
在今年夏天，Terracotta 2.4 加入了对 WebSphere 和 Hibernate 的支持。Ari 介绍说，Hibernate 支持包括了两种方式：
- 用集群化的 EHCache 在 Hibernate 底下完成二级缓存的工作。如果现有的应用只打算用集群化数据库缓存的方式降低数据库负载，就采用这种方案。
- 在集群和 Hibernate Session 之间无缝地断开连接以及重新连接 POJO，以此来实现 Hibernate 的 POJO 缓存。我们的 POJO 集群化成了 Hibernate 的代理……这很适合新的应用（或者改造现有应用），因为 POJO 集群化通过细致的字段级更新，能达到更高的性能。
Terracotta 的字段级更新检测 / 缓存，比 Hibernate 的机制有何优点：
在 POJO 集群化的方式中，发送的数据比较少，调用 Hibernate 和数据库的频率也比较低，因此伸缩性好一点。它也好过散落在代码中的 Hibernate 的 load() 和 store() 调用……对于二级缓存，如果你在程序的其他部分为 Session 和 POJO 使用了 Terracotta，使用 Terracotta + EHCache 的主要好处是获得单一的集群化提供者。否则 Hibernate 二级缓存基本上是对数据库行的定制序列化，一个字段对应到缓存里就成了一整行——所有缓存提供者都是这样的（顺便一提，这个例子说明了在缺少 DSO 的情况下，人们——在这里是 Gavin King——被迫做什么样的变通）。
Terracotta 2.4 还支持 java.util.concurrent 中的再入（re-entrant）读写锁：
在 2.4 之前，Terracotta 在集群中的锁机制，比线程在单个 JVM 中所能支持的锁机制更加智能。由于 JVM 的锁语义是悲观和排他的，因此当把协调关系放到 Terracotta 中实现，我们就能够在集群中提供更多的支持。如果开发者想让线程池的范围从单机扩展到集群，抑或只想实现有些线程读有些线程读写的业务逻辑，再入（re-entrant）读写锁将会以纯粹 POJO 的风格，提升集群中每个 JVM 的速度。concurrentHashMap 与 hashmap 的对比就是一个例子。java.util.concurrent 中的集合的并发性是通过再入读写锁实现的，现在已经得到 Terracotta 2.4 的原生支持。性能又提高了！
Ari 仿照 Network Attached Storage 的说法（或Azul所说的 Network Attached Processing），把 Terracotta 定位成“Network Attached Memory”。Ari 说：
这是有意的。NAS 的意图是简化文件 I/O 的编程，以及支持透明地注入高可用性（HA），还有运行时可伸缩的存储能力。Terracotta 设计时就考虑了全面的 HA（n+m 冗余度——你可以有任意多的备份，不停机的持续升级，等等）。其重要性在于，虽然应用各有不同，HA 和伸缩性必须以一致的方式来达成，这样 IT 部门才能为业务部门提供低成本的稳固的应用。换言之，HA/ 伸缩性是一种全局的需要，而 Terracotta 就正好是设计来为 Hotspot 和 IBM JRE 提供这样的能力。
Terracotta的更多信息可以查阅 InfoQ 以往的新闻报道和技术文章：http://infoq.com/terracotta。
查看英文原文：Catching up with Terracotta: Transition to Open Source, Adoption, Hibernate Support
注册/登录 InfoQ 发表评论