为网络做准备J2EE部署中的下一个冲击波(图)

　　摘要
　　
　　在九十年代，企业们发现最好是把存储当作基础结构来处理，而网络附加存储的理念在短短几年间从一个激进的观点逐渐成为一个主流的解决方案。如今，网络的增强处理——中间整合层的服务已经逐渐发展为小型池计算组件——较为均衡地将类似的管理及整合益处赋与了J2EE部署，从而减少开发、部署、管理及维护分布式J2EE的成本及复杂性，
　　
　　J2EE技术在最近几年已经获得了广泛的成功。但是维护、部署和管理J2EE应用对于许多企业来说已经成了个难题——几乎全部的服务系统必须被设置和管理，并对人员和有效的数据中心设备资源造成了沉重负担。而一项新的叫做网络增强处理的技术可以帮助应付这些J2EE开发中的整合和管理的挑战。
　　
　　我们成功的代价
　　
　　管理先驱Peter Senge曾经说“今天的难题都是来自昨天的解决方案”。当Senge在脑海里有了经济和政治上的决定他都会考虑到这一点，这个说法也同样适用于软件技术，而且软件更新的运动中快速的变化让我们能很容易看清这个真理。比如，九十年代的C/S技术革命旨在降低开发大型机的难度及成本，以使其更有效地解决较大的软件问题。
　　
　　但是世界并不会老老实实地跟随在革新的后面。随着对复杂的企业应用的要求不断提高，C/S的弊端逐渐显露。分布式对象、Web应用、应用服务器、面向服务体系（SOA）——每一种企业软件开发技术的产生都体现出前一代技术的一些缺陷，同时又使开发更复杂的应用成为可能。但是随着新的技术的产生，新的问题浮出水面，比如可伸缩性、可管理性以及开发的复杂性。
　　
　　作为开发人员，我们非常高兴看到这些技术的快速发展——它们提供了很多新的有趣的思想让我们来思考，以及新的技术让我们运用，使我们能通过所提供的预算资源来解决更大范围更复杂的问题，当然对我们的技能也提出了较高的要求。
　　
　　虚拟机和应用服务器的技术模式在发展中有个相同点：当它发展成为企业软件开发的主要形式时（Gartner 预言到2008年年底，百分之八十的新型电子商务应用服务都将建立在虚拟机的基础上），我们总是费尽心思地处理这个模式的成功所带来的一系列后果——部署的复杂性，能力管理和计划的挑战，以及要在一堆繁复的拓扑技术中寻求平衡的开发应用的难题。应用服务器减轻了其中一部分困扰，但还是很复杂。JAVA技术不仅仅证明了其在高效开发以及交互企业应用方面的价值，它同样成为了它自身成功的牺牲品。
　　
　　当今分布式应用面临的挑战
　　
　　现在的硬件配置的价格是难以置信的低廉——只需几千美元，你就可以买到远比过去的大型机先进得多的商品，安装支架，以及容错系统。但是现在的应用系统却比过去更加资源匮乏。我们用来加速软件开发、提高软件的可靠性，管理软件的复杂性的技术耗费了大量的计算盈余；不断提高的用户期待也消耗了所剩部分，等等。结果便是，大部分的企业应用由于太过于庞大而不能在某台低端服务器上运行，因而经常被分布部署在一堆廉价的主机中。J2EE分布式应用的软件技术已经投入使用，但反过来增加了附加资源耗费的开支，以及开发、分布和管理复杂性的开支。
　　
　　虽然分布式可以提供较高的有效性和容错性，但是如果为了达到理想的工作状况而必须在100台服务器之间采用分布式的话，可以肯定将会对设计、开发、调度等产生负面影响。（分布式应用的服务器支持一直在改进，但是不管它怎么改进，开发一个JVM上的应用仍然比开发分布应用简单。）所以，如果我们自信可以在一个简单的JVM上运行我们的应用，哪怕负载提高了，我们还是能省下很多开发、部署和管理上的精力，籍此以建立更强的应用。
　　
　　分布式还提出了一个明显的操作上的挑战。现在的数据中心往往拥有上百台应用服务主机（所以被叫做“服务蔓延”），意味着系统管理员必须管理、维护这些服务器并提供高效服务。随着处理要求的提高，操作员必须在不中断服务的前提下快速的增加容量和重新配置应用。或者，如果因扩容而部署的时间要超出要求的响应时间，则应该为了避免不必要的拖延而提前做好维护。当然，从管理的角度，应尽可能地将系统和数据库的管理员支出减到最低程度。
　　
　　因为较低运算能力的独立服务系统难以满足一个典型企业应用的要求，服务主机一般不横跨共享多个应用；一个应用会占用一个或更多的服务器，而这些服务器并非互不相关的。这种方法让很多企业开支可观，因为那些每个应用所分配的资源是按照应用的最高负荷来规划的（乘上安全边界需求），即使一般的需求远远低于最高负荷。如果一个企业拥有多个应用，而这些应用的负荷峰值的期间并无关系—这正是大数企业的状况，结果就是应用间的容量(参与成本，attendant cost)大量被浪费了。它的效用经常看起来像下表所列：
　　　
　　图1.每个应用基础所产生典型效率。
　　
　　这些普遍存在的维护方式，过于繁重的维护及在每个应用基础上对峰值所做的维护，导致了更高的硬件支出，更高的员工开支，并降低资源利用效率——其结果就会是降低IT投资的收益。
　　
　　利用网络联合处理降低管理和容量计划的复杂性
　　
　　企业很早就认识到网络附加存储（NAS: network attached storage）和存储领域网（SAN: storage area network）技术在降低改进服务质量和可靠性的方面的巨大价值。通过管理跨企业的存储能力替代基于个体系统上的管理，存储效率提高了；存储空间可以很方便的进行添加，分配，或者根据需要进行重新分配；关键数据可以更容易的拷贝和恢复；可以更容易的监视高峰和进行中央管理。
　　
　　NAS和SAN在1995年还是备受争议的，而今已成为解决存储问题的主流方案。这些问题实际上和我已经讨论过的服务维护相似——大量而且一直在增多的存储器需要管理；每个复合的存储器则都需要一个应用；存储器都要分配一个特定的应用，影响了效率；而且伴随着高额开支的重复维护资源要求有相应的模式变化。网络附加处理，这项新的技术在处理资源方面可以与NAS的存储处理相媲美，它对数据中心的管理就像一个专家。
　　
　　就像NAS的出现就伴随着庞大且不断膨胀的存储池，随后交给管理人员将存储块划分为虚拟存储盘，并自动设置资源利用方案，网络附加处理也伴随着一个巨大的计算机资源管理池，可以按照可定制资源管理方案来静态或动态地分配应用。
　　
　　Azul的网络附加处理解决方案：计算应用
　　
　　第一个（从时间上来说）发布网络附加处理方案的是加利福尼亚“群山视野”的Auzl系统，一个384处理器，11-U 可插槽的，带有256GB相关的统一通道的内存的计算器，利用定制的专为运行虚拟机的技术的处理器，利用硬件特性来加快垃圾回收以及并发性处理。
　　
　　利用SAN技术，这种计算机器可以被逻辑划分为复合的虚拟主机，CPU和内存资源都可以被自动分配给虚拟主机。这些虚拟主机被认为是“可装配计算池”，使得复合应用可以从企业应用的巨大范围内调用其计算功能。一个独立384通道的计算应用可以处理50个或更多的在虚拟机上的应用，而这些应用都有上千GB，包含着上千个线程。
　　
　　因为有如此多的应用都要依赖它们，计算池主机需要保证有更高可靠性和容错性。而Azul存储器具有一切所需的RAS(有效性、可用性、服务性)功能——在主存储器和高速缓存中的ECC（纠错代码），错误监视，以及即插式电源和风扇。高速读写的硬件设备保证了同步垃圾回收功能无停顿，响应时间可以更容易预知。当然，这项超酷的技术只是解决了一方面的问题——这项技术的全部目的就是降低J2EE应用的管理和部署开支。
　　
　　精简容量计划
　　
　　这个计算池的出现颠覆了容量原有的工序，使容量的规划能在整个企业平台上进行。不是在每个应用上都要安排硬件的获得与服务的管理，而是在计算池里给每一台虚拟主机分配应用，并且随着需求的增长，虚拟主机的资源分配也可以自动的增长。如果不断增长的复合应用共享一个计算器，当它增大到超出了计算主机的存储能力时，它（或者其他应用中的一个）会自然的被转换到别的计算器的剩余空间内，而不需要应用级别的重新配置。Azul的计算池管理软件允许资源分配和使用方案在所有计算器内可以被设置。
　　
　　更好的资源利用
　　
　　因为应用载入时间的高峰随着应用的不同而不同(比如发薪水的应用在月初最高，发劳保金的应用在开放注册时最高，等等)，管理企业基础上的容量可以获得更大的硬件利用效率，因为你再也不需要在应用的最大值时购买或供应额外的容量给服务应用——除了在所有应用的载入最大值的时候，而这时的值也比独立应用的峰值之和要小得多。（将应用层的处理整合进计算池，也简化了管理使用与规划容量的过程）。
　　
　　图2表示了图1中的5个应用在一个计算池里运行的效率（加上另外十个相似的应用）。结果表明：效率从3提高到了5，并且对应用重新分配资源的灵活性也改善了。
　　　
　　图2，使用计算池并带有相同级别计算资源的主机，可获得更多容量。
　　
　　向网络附加处理转移
　　
　　对于现有的应用，我们需要花很多精力来建立和部署它们。计算池的出现也许可以提供巨大的可伸缩性，但移植一个应用到另一个平台还是需要开支。对于网络附加处理，所需的开支就和从局部存储到网络附加存储的移植差不多——现有的软硬件配置都不需要做任何改变。不用把整个应用移植到计算设备上，只需转移计算部分——应用、存储、数据库还有安全配置都原封不动的保留在现有的服务器上。不同的是本地JVM将由一个代理JVM代替，代理JVM将通过搜索Azul计算池管理器找到一个可用的计算应