即便是功能很简单的应用,也会因为高访问和庞大数据量方面的负载而使系统面临的问题变得异常复杂。以公认的计算机互 联网技术领域的典范Google 为例,如果设计一个功能类似的小型搜索系统——只需满足几个人用(访问量被设定为很小的基数),数据保有量也局限于某个领域并且不超过百万条纪录,当然也 无须包含自动添加信息的爬虫工具。这种系统的编码工作量一个普通水平程序员很快就可以完成。然而Google 将其信息检索系统的用户扩展为数以亿万计的可以使用互联网地球人,将其所保有的信息数据扩展为大部分互联网的内容。这种看似相同的信息检索功能,在规模完 全不同的情况下计算体系也是天壤之别。所以Google 需要人数众多的技术团队,以及数以万计的服务器组成的计算平台来解决其成长所面临的问题。
每台计算机的运算和数据处理能力都是有极限的,而达到或超过负载极限的服务器不但不可能提供良好的 在线服务,而且还可能因为服务器过载导致系统问题而无法提供服务,甚至丢失关键数据。这种脆弱而不稳定的系统所造成的后果是严重的,最直接的影响之一就是 会把用户推向服务更稳定的竞争对手。在激烈的竞争环境里,这可能会使服务提供商之前的投入和努力付诸东流。
为了提供持久稳定和健壮的系统服务,就需要多台计算机可以协同工作,共同组成能对外提供统一服务的计算机集 群。当系统计算或处理能力不足时,通过增加计算机节点,使系统整体计算或处理能力得到提升;当集群中有计算机产生故障,可以无需停止服务而将故障计算机摘 除并增加替换者。要使系统达到这种能力,就需要在技术平台设计上合理运用负载均衡、高可用性、分布式计算与存储等技术的同时,使其具有可快速增加和替换集 群节点(集群中每个计算机被称为一个节点)的高扩展和伸缩能力。
facebook、Mixi等站点正是类似这样来设计和实现其高扩展性的越代技术架构体系的。而 Google 也正是通过其高扩展性的已经超过上万节点的超级集群(Google 的集群是由超过一万台计算机组成)和分布式计算机体系而成长为行业巨擘的。事实上,因为牵扯的技术纷繁庞杂,实现这种高扩展性的大型技术平台并不容易,需 要解决的问题也很多,涉及从硬件到软件、从宏观到局部、硬件网络、路由交换、负载均衡、高可用性、数据安全与容灾、分布式计算与存储、共享及局部缓存、操 作系统、编程语言、Web 服务器、数据库、文件系统、防火墙等各个领域及层面,并且还要顾及由各个领域及层面所决定的整体扩展性和伸缩性。所以,没有技术储备的公司在没有形成规模 化之前可能会因为好的设想和创意得以发展,但是在不久之后的规模化时将面对的无疑是巨大的风险。
当然,对于那些只服务于有限数量用户,只需要一、两台服务器,并且未来不打算增加服务器数量的小型公司,就无须担心这些了。
目前典型的大型应用网站(指庞大在线与高度交互服务的站点,这有区别于web1.0 新闻门户网站)技术平台体系从成本角度可分为两大阵营,一种是为快速适应成长需求而把一些基础硬件、软件或应用工具转移到微软、IBM、Oracle 等专业IT 产品供应商平台之上的网站;另一种是利用自有能力以及社区软件构建基础IT 设施的站点。前者的典型是代表是MySpace,当其技术平台一次次遭遇到成长规模化困难的时候,其领导人决定把平台迁移到微软的平台之上,事实证明这种 方案无疑是高成本的选择并不能直接带来高扩展性。如果你了解大型集成厂商关于相关领域正版软件授权方式及其成本的话,你就明白一个中型的计算机集群所需要 的资金就是个天文数字了。而这样的高成本并不能换来整个软件系统的横向扩展和伸缩性。这也就是为什么Amazon 的数据库和中间件使用Oracle 和IBM 的产品之后还要花大力气做自己的新一代的架构技术体系。
另一个阵营的代表则是Facebook 和Google 了。不仅是软件,Google 的硬件都自己做,Google 服务器的成本是IBM 服务器的10-100 分之一。上万的服务器,成本降低了多少?Facebook 也是LAMP 社区软件的坚定支持者。当然,随着Web2.0 的崛起,站在社区软件阵营的成功者远远超过了前一个阵营。即便是国内早期的三大门户,也都是站在这一边。毕竟节约的成本大大提高了投资回报率,同时社区软 件在稳定性、开放性和可方便扩展方面也已深得人心。
转载请注明:苏demo的别样人生 » 站点良好伸缩性、扩展性的实现