大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
用Terracotta实现的POJO消息架构
作者 Steven Robbins 译者 曹云飞 发布于 2008年3月7日
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过程。
查看英文原文： POJO Messaging Architecture with Terracotta
译者 曹云飞 从事软件开发多年，包括Web应用、桌面应用、前后端开发，热衷于计算机理论与应用技术的钻研，软件架构与敏捷开发。
没有回复
关注此讨论 回复