www.microsoft.com 摘要 我们将向您展示我们是如何充分利用软件，如何合理组织硬件使 www.microsoft.com 以最佳效率稳定工作的。此处是关于站点的庞大性和复杂性的一些简要说明。站点： 流量 每天浏览六千万页 每天三亿次点击 每天四百一十万来访者 每月两千五百万用户 每天成功下载六万多亿字节 增长 在 98 年 7 月至 99 年 7 月间页面查阅增长了百分之二百零五 在此 12 个月间用户人数增长了百分之一百四十二 内容 32 GB 的内容 417,000 HTML 或 ASP 文件 434,000 GIF 或 JPG 图像文件 大约 50 GB 可下载文件 在世界范围内，随时进行内容更新。硬件 八个 100 兆比特容量的内部以太网 2 条 OC12 向 Internet 提供 1.2 兆比特的容量 运行于 Compaq Proliant 5500s 和 Dell PowerEdge 6300s 平台上，它们都具有 4 个 Pentium III 处理器以及 512 兆字节 (MB) 的 RAM。 软件 Microsoft Windows 2000 Advanced Server Microsoft Internet Information Server (IIS)5.0 Microsoft Site Server 3.0 Microsoft SQL Server 7 其他 Microsoft 工具和应用程序功能强大的解决方案www.microsoft.com 在 1994 年起步阶段，只以一台机器就足以应付处理每天一百万次点击。 这在现在看起来似乎有点可笑。仅在设于华盛顿州雷得蒙得 (Redmond, Wash.) 的数据中心每月就要受到多达三亿次的点击。 那么在硬件费用维持在最低限度的前提下,该站点是如何应付其爆炸性的增长的呢? 它是如何管理世界最大的数据库之一的呢? 它是如何面对分散发布环境的挑战的呢? 而它又是如何使站点的有效利用率达到百分之百的呢? 据站点的工程师们介绍，答案在于所使用的得力软件。整个站点构架于 Microsoft Windows 2000 Advanced Server、IIS 5.0 和 SQL Server 7 等软件之上。 “我们的站点充分显示了 Microsoft 技术，”系统操作经理 Todd Weeks 说，“我们每天都在向世人证明我们可以通过百分之百使用 Microsoft 技术来建立并维护世界最大的站点之一。” 挑战www.microsoft.com 不仅是一个拥有几十万页内容的庞大站点；不仅要受到每天数百万次的点击；也不仅仅具有持续不断的增长速度。站点工程师们认为这些都只不过是相对容易应付的挑战。 最为有趣的挑战是 www.microsoft.com 工作在分散式的发布环境之下。为站点提供信息的 300 余名撰稿人和开发员分布在世界上 51 个地点。这些内容提供者每小时都可更新 www.microsoft.com。事实上，站点上的内容每天都有百分之五至百分之六的内容被更新。 当您想到位于雷得蒙得的 110 台内容服务器包含了组成 www.microsoft.com 的 420,000 页信息，是否会觉得发布环境的复杂性的确令人望而生畏。但最终结果是 www.microsoft.com 上的信息总是当前的并且总能得到及时更新。 一个每班八人，三班轮换的工作组不间断地工作以确保 www.microsoft.com 每周七天，每天二十四小时都能正常运转。“我们的目标是保持站点在百分之九十九点八的时间内都可被用户访问。”Weeks 说。 那么我们如何达到百分之九十九点八的有效利用率呢？这可是一个很高的目标啊。（百分之零点二的停机时间是用于进行日常维护，这是不可避免的。） 首先，在硬件方面 www.microsoft.com 背后的物理结构看起来出人意料的平常。三十五台服务器用来管理一般性的 Web 内容；四十五台服务器用来管理 SQL；十二台用来响应查询；十六台负责提供下载服务；另外三十台在分布式数据中心；还有三台管理 FTP 内容。位于海外的另外的服务器处理一些国际工作量。 服务器通常运行得非常稳定。它们被设定最多同时接待 6,000 位用户，平均起来每台只需轻松运载 1,000 至 1,500 名用户。处理器的占用率通常在百分之四十至五十之间。 硬件的组织是以保证最终用户获得快速可靠的服务为目标的。每台集线器、路由器、交换机都采取了相应的备份措施，用以确保即便是在机器出现问题的时候，站点也能继续正常工作。“多台服务器分布在多个局域网上，这就确保了硬件方面的万无一失。”Weeks 说。 另外，许多 SQL 服务器具有热备份能力。“我们拥有许多随时备用的硬件，仅仅是为了以防万一。”Weeks 说。即便是用来备份的 SQL 服务器，也被充分利用上了。每天一次，联机服务器上的内容被复制到备份服务器上，后者按需要对信息进行组织分类。这意味着联机服务器全天均可提供服务。 “这极大地减小了负荷，”Weeks 说，“分配过程对服务器的处理器来说强度是很大的，并将减缓每秒的请求次数。” 为了保证速度和可用性，8 个以太网每秒可向数据中心服务器提供 600 兆比特的容量。两条 OC12 线将 www.microsoft.com 连至 Internet 骨干网上，每条每秒可提供 1,200 兆比特或 150 MB 的容量。 从长远来看，以上的容量可传输存储在 3 GB 的硬盘上的所有信息——相当于标准 PC 至 Internet 20 秒间的传输量。 那么 Microsoft 何不购买更多的服务器来处理站点上爆炸式的增长呢？答案非常明确。站点性能的改善并非简单地依靠在出现问题时就频繁地更换硬件。问题的关键在于软件方面。 有关软件方面 www.microsoft.com 是一个庞大的站点。这需要可靠的软件运行在可靠的硬件之上稳定地发挥性能。但同时，还需要合理规划、独创性和创造性的战略。 下面将向您介绍我们是如何充分利用软件的。破解谜题所有服务器运行于 Windows 2000 Advanced Server。IIS 5.0 服务于 Web 内容。另外，每分钟接到 150 次请求的搜索服务器还要运行 Microsoft Site Server 3.0。用来处理超过 500 种应用程序，并且在商业高峰时间需要同时支持 400 个连接的数据库服务器，还需运行 SQL Server。 “协同工作的软件就象一道谜题中环环相扣的各个部分，”站点数据库系统经理 Robb Mitchell 说，“它们相互配合得如此之好，以致于构成了一个天衣无缝的环境。” 软件能够工作得如此之好的原因之一在于所有的应用程序均可交互式地与其他软件协同工作。“为 Windows NT 或 Windows 2000、IIS 和 SQL 量体裁衣地设计 Web 页面并非难事，”Mitchell 说，“这几乎是很自然的。” 例如，如果正在使用 Windows NT 或 Windows 2000 和一个数据库，SQL 可帮助您将其完全同 Web 页面工具和向导相集成。配置不同程序使其协同工作易如反掌。 假设正在使用 Microsoft FrontPage（一种 Web 页面生成工具）并想插入一个数据调用。FrontPage 具有帮助设置页面同 SQL 以及现有数据库进行交互的向导。不错，您拥有一个为 Web 站点工作的数据库。 另一个例子是“开放式数据库连通性 (ODBC)”，即在应用程序间传递数据的虚拟通道。ODBC 基于 Windows NT，可自动配置同其他应用程序协同工作的状态。“不必担心进行安装，也完全不必应付对 ODBC 的配置。”Mitchell 说。“所有部分都能非常好地协同工作——只要说一句‘生成 SQL 调用’，平台就会自动生成。”Mitchell 解释道。 Windows、SQL 以及 IIS 所带来的乐趣从许多方面来讲，Mitchell 都可以称得上是处在 www.microsoft.com 的最前沿。他的工作组负责维持世界范围内的 170 个数据库在联机状态下的正常运转，而其中目前处于联机状态下的内容占用了 8 万亿字节的空间。每台 SQL 服务器大约需要每秒进行 200 次处理。 Mitchell 需要借助软件；几乎没有出错的机会。“我们有大约 100 台 Web 服务器每天 24 小时用于 SQL 联机服务，”他说，“它们必须保持每周七天，每天 24 小时连续运转。” 处理这方面的任务，IIS 服务器，事实上的 Web 服务器，使用所谓的“连接统筹”以保持稳定性及效率。 IIS 服务器由每台 SQL 服务器获得连接，并保持其有效性——这不失为一种占用服务器资源较少的解决方案。称作“连接-断开”的连接在处理结束后断开连接，增加了服务器的工作。Mitchell 说。 IIS 的优点之一是极易安装，Weeks 说。使用其基本配置即可完成从极小的操作到构建世界最大 Web 站点的任何事情。“不必做过多的调整，”他补充说，“即可适应各种用户的要求。” IIS 同时允许管理者运行“过程外”应用程序。这意味着如果设计了有时会导致违规错误和失败的对象，IIS 可隔离该程序使其继续运行而不会影响站点的其他部分。 由于拥有超过 40,000 页的 ASP 页面，www.microsoft.com 有许多 SQL 内容——事实上是，两亿行联机内容。“这意味着站点可以变得更大、更好、更具动态效果。但是，有时技术组件如果当初开发得很糟糕将会更难于维护。”研发部经理 Todd Wanke 说道。 保持 www.microsoft.com 性能稳定的最大障碍，也是站点管理员在研究事件日志和性能监视器时最耗费精力的因素——那就是单个页面上的内容。 “在访问率很高的站点上，如果含有编码糟糕的页面将会带来负面效应，”Weeks 说，“这将影响站点的可用性，同时也是我们在发布内容之前一定要对其进行测试的重要性所在了。” 例如，如果某个 ASP 页面每秒要接受二十个访问请求，但其只能响应其中的十个，即使使用最快的硬件，额外的请求也将被遏制。 “低水准的内容将会影响整个站点的性能，这样即便是将服务器的数量增加一倍，也无济于事，”Weeks 说，“所有关于内容的需求必须尽可能地立即执行，不容任何拖延。” 那么管理者应当如何处理问题并进行维护呢？ “SQL 的优点之一就在于，”Mitchell 说，“管理者在联机状态下即可完成所有必要的维护工作。不必影响服务器的正常工作，管理者即可管理数据堆栈以及一致性检查。即在联机状态下，可检查数据库是否存在错误，如果有也可立即修复。” MSData，一个用来处理整个公司联机注册业务的、容量高达 70 GB 的庞大数据库，便是一个合适的例子。任何来到 www.microsoft.com 的已接受 cookie 来访者，在去任何其他地方之前总会首先点击 MSData。“SQL Server 使我们能够在数据库仍处于联机状态下时对其进行更新。”Mitchell 说。 为了适应不同的需求，也可自定义 SQL。应用程序预先设定了数据类型，例如文本、日期和时间，但也可创建自己特定的配置文件。例如，使用 SQL,可自定义默认值和规则。假设需要创建带有地址域的窗体。如果用户在邮政编码域中输入了 98052，可自定义数据库分别在城市和州域中自动添入雷得蒙得，华盛顿。 但为何要使用 SQL 呢? 只使用保险的 HTML 和 ASP 又有何不可呢? “有些内容仅对数据库引擎才有效，”Mitchell 说，“可以在 HTML 或 ASP 中放置许多数据,但这样做会使页面的体积过于庞大，以致于无论从时间或是空间上考虑都是不允许的。SQL 具有极为出色的响应时间——我是说那将是毫秒级的。” Mitchell 进一步说：“使用 Windows 2000 和 SQL 建立一个 Web 站点是行之有效的方法。我们已经证明了这是非常稳定并且堪当重任的。我们每天处理一亿九千万次点击并且还在不断增加，这个事实是很显著的。” 创造性的战略 这样以来，已经是软硬件皆备了。如何使之充分被利用呢？ 我们已经发现这一平台有极大的可扩展性和灵活性，以致于可以量体裁衣地根据需要对其进行调整。以下是我们用于 www.microsoft.com 站点上的一些创造性的战略。 单一 IP 地址解决方案服务器错误往往给用户带来极坏的经历，而 Web 站点的管理员们也会对此愁眉不展。www.microsoft.com 的工程师们尽其所能地避免用户在访问www.microsoft.com 站点时遇到这样的问题。 一项独到的战略是“单一 IP 地址解决方案”。最初，Internet 上每台服务器都拥有其唯一的 IP 地址。在“以往”，当用户希望访问 www.microsoft.com 时,他们的浏览器将使用一个唯一的属于 www.microsoft.com 上某一台服务器的 IP 地址。如果该服务器恰巧被关闭了，那就太糟糕了。即使 www.microsoft.com 所有其他的服务器都运行良好，那位用户也将被告之以令人望而怯步的服务器错误信息。 单一 IP 地址解决方案则完全改变了这种情况。每个正在使用中的 IP 地址均可代表整个站点。当有请求时，将被送往一台处于联机状态的服务器。处于关闭状态的服务器将被忽略。该过程需要一个叫做 HTTPmon 的 Microsoft 应用程序参与，其作用是检测服务器的有效性及状态，Wanke 解释道。 结果: 达到对外部用户的百分之百的可用性。 将内容分类www.microsoft.com 还采用了一种叫做“按簇分类 (Clustering)”的策略来维护站点上内容的可用性。按照所在的不同机器，从物理角度将站点上大量的内容分类，或按服务器的名称从逻辑的角度将站点上的内容分类。以此方式，站点工程师们将确保用户可以访问到他们所需的内容。 按照这种方式，如果一台服务器无法使用，同一组别中其他的服务器将承担起它的任务。并且这将避免造成站点上其他内容一起失效。 “如果任何服务器无法工作，将不会影响 Internet 上的服务，用户也不会察觉。”Weeks 说。 IIS 的好处之一是不同服务器上的运行时间（在一台服务器“超时”之前的一段时间其客户可被其他服务器接管）可进行不同的调整。分类利用这一点，区别对待使用静态 HTML 页面的站点（只需较短的超时值）和使用大量“应用程序强化”页面的站点（需要较长的运行时间可能拥有较大的超时值）。 “静态环境可被置于前方，”站点的总经理 Tim Sinclair 说，“地址 www.microsoft.com 是 Web 站点的介绍——来到站点的人总是首先见到该页。” “对于像注册、支持、事件以及奖金之类任务要求苛刻的服务，均属于应用程序强化类型，可按各自的服务器进行分类。因为这些站点对于用户很重要（同时应用程序也属于数据库强化类型），所以我们将此类应用程序分布在独立组别的服务器上以更加准确地构建性能模型。”Sinclair 说。 站点工程师还按产品的类别将一些 www.microsoft.com 站点上的内容进行了分类。Windows、Office 和 BackOffice 都保存在 www.microsoft.com 下各自的子域中。“随着 Microsoft 产品不断地发展，我们的 Web 站点从许多方面来看正在变成这些产品在支持和功能增强方面的重要补充。”Sinclair 说。他间接提到了在未来的产品中，用户只需点击按钮即可接受产品的支持以及进行增强功能的下载。 未来的发展方向是什么呢？站点工程师们计划指定一组专门针对不同层次用户的服务器。例如，MSDN 和 SiteBuilder——针对开发者的兴趣——将按各自的组别分类。 进行试运行www.microsoft.com 提供了一个很好的模拟测试 Microsoft Internet 产品的机会。可以这样认为，如果我们的产品在世界第三大 Web 站点毫不费力地经受住了严峻的流量及技术要求的考验，它们多半可以工作在任何地方。难道还有比将产品置于世界上最繁忙的信息高速路上进行试运行更好的改进产品的办法吗？ 新产品在 microsoft.com 实验室环境下按照标准测试周期进行彻底的测试。然后再移至 Intranet 上，最终再转移至 www.microsoft.com 中任务要求不十分苛刻的服务器上。 但是由于再现站点上极其繁重的流量几乎是不可能的，即便是站点中不很关键的服务器上的内容也将面临其在真实环境下最严峻的考验。 测试并监视站点的工作情况www.microsoft.com 的管理员们仔细地对站点进行测试，验证其是否能够以最高的效率传递信息。测试的内容分为三大功能性职责：ASP 测试和代码检查、当前下部结构测试以及新技术测试和实施。 通过 ASP 测试及代码检查可以看到所有运行在站点上的代码。在其处于联机状态之前，www.microsoft.com 开发组使用 Visual Basic 编制了一个叫做“PubWiz”的内部工具用来检查链接引用的情况和编程的类型。在有 350 多人向 www.microsoft.com 发布内容的分散式发布环境下，PubWiz 是一个举足轻重的质量保证工具。 当前下部结构测试主要侧重于改进当前的 www.microsoft.com 站点性能。测试人员工作在一个实验室中的站点模拟环境中。该环境使用几台客户机来模拟服务器负载。用来进行模拟的工具叫做 WebCat，由 Windows NT 4.0 Resource Kit 提供。 我们以两种方式监视 www.microsoft.com 的性能。 从全世界不同的地点监视站点同 Internet 的连接，有助于确定 Internet 上的瓶颈。同时对数据中心中不同组别的服务器进行监视。我们的兴趣之一是查看通过服务器连入 Internet 的网络是否处于过载状态。 www.microsoft.com 的未来目前所走的这条路在我们面前还要延伸多远？Internet 将如何继续对我们的硬件、软件以及创造性带来新的挑战？ 在虚拟化的进程中没有速度极限。在站点的飞速发展中保持其正常运转，至少我们可以从中体会到不断增长的乐趣。 但是我们已经得到了许多帮助。 幸运地及时发布了新产品，这使我们能够有条不紊地进行调整和增长。 并且通过倾听我们已经学到了很多。我们认真对待用户的反馈意见，尽可能及时地向着新方向做出反应。 我们衷心希望本文能够使您获得有关更好地管理 Web 站点的新的启发，不管是大企业站点还是个人站点。通过展示站点的结构，我们希望我们已经向您证明了 Microsoft Internet 产品的良好可扩展性以及出色的性能。
