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
评论