模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。
作者 Gavin Terrill 译者 郭晓刚 发布于 2007年10月7日 下午4时2分
“可伸缩性(Scalability)”是软件厂商常常在新闻稿中用到的一个词(也是人们站在饮水机旁谈论的一个词),但这个词在很多情况下都被误解了。例如,很多人说起可伸缩性的时候其实指的是性能和高可用性。Royans K Tharakan试图回答“什么是可伸缩性”这个问题,他说:
可伸缩性,简单来说,是以更大的规模来做你现在所做的事。伸展一个Web应用的规模在于让更多的人使用你的程序。如果你没法找出方法在伸展规模的同时提高性能,没关系。而且只要你可以伸展规模来处理更大数量的用户,那么有几个单点故障(single point of failure)也没关系。
Royans解释说如今我们在面对规模伸展的时候有两个选择:
- 纵向的可伸缩性——在同一个逻辑单元内增加资源来提高处理能力。这样的例子包括在现有服务器上增加CPU,或者在现有的RAID/SAN存储中增加硬盘来提高存储量。
- 横向的可伸缩性——增加更多逻辑单元的资源,并令它们像是一个单元一样工作。大多数集群方案、分布式文件系统、负载平衡都是在帮助你提高横向的可伸缩性。
架构师们都在为达到线性的可伸缩性而挣扎,目的是让系统产出的增长与系统中投入资源的增长保持稳定的比率。然而,增加资源会导致一般耗费(overhead)的额外增长,因此难以达到线性的可伸缩性。Royans将之称为“伸缩性因子”,并用它来区分各种类型的伸缩能力:
- 如果在你扩大规模的时候伸缩性因子保持为常数,这种叫做线性伸缩性。
- 但很可能有些组件并不像其他组件那么适应规模的增长。小于1.0的伸缩性因子叫做次线性伸缩性。
- 话说回来,也可能因为增加更多组件而获得更佳的性能(在RAID系统中跨多个磁盘的I/O,当磁盘越多,性能越好)。这种叫做超线性伸缩性 。 不过类似情况很少见。
- 如果应用程序没有专门为可伸缩性而设计,有可能当规模扩大的时候情况会变糟。这种称为负伸缩性。
跟软件开发中的许多事物一样,这里也没有适合一切情形的银弹可以解决你的伸缩性问题。Royans建议说,“如果你急切需要可伸缩性,向纵向发展可能是最容易的”,但注意“不幸的是纵向伸展会随着你的规模增长而越来越昂贵”,而且“无穷的横向线性伸缩性只是难以达到,而无穷的纵向伸缩性绝不可能”。他继续说:
从另一方面来说,横向可伸缩性并不要求你购买越来越昂贵的服务器。它的本意是用普通的存储和服务器方案来实现规模伸展。不过横向可伸缩性也不便宜。应用必须从建造的最底层就加以考虑才能在多台服务器上运行得像一台服务器一样。
Royans最后建议应该考虑所有的层次才能解决可伸缩性问题:
对于一个成功的Web应用,所有的层次都要同样能够应付规模的增长。包括存储层(集群文件系统、S3等)、数据库层(分区、联合)、应用层(memcached、scaleout、terracota、tomcat clustering等等)、Web层、负载平衡、防火墙等等。比如,如果你没办法实现多个负载平衡控制器来处理未来的网络流量,不管你在Web层的横向伸缩性上扔下多少钱,都不会有什么效果。你的流量始终被限制在一个负载平衡控制器能够承受的程度。
查看英文原文:Think you know what scalability is?
本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。
项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。
在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。
Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。
Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。
1 条回复
关注此讨论 回复