 |
 |
产品 | 支持 | 搜索 | Microsoft指南 |
 |
 |
|
| 主页 | 活动&培训 | 订阅 | 中国微软 | 美国微软 | 关于站点 | | ||
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
  |
 Microsoft内幕新闻
操作microsoft.com
深入两个站点
解决方案/最佳实践
其他站点信息
内幕新闻档案
|
|
|
|
Mike Moore 是 microsoft.com 的开发工作组经理。他与程序员 Daniel Dumesh 和 Tarlochan Cheema 开发了最新版本的 Microsoft 内部发布工具，PubWiz 6.5。 在一个成功的 Internet 站点中发布大量的信息并不需要什么秘诀，而且，microsoft.com 站点的容量——大约 400,000 页——它足以容纳那些未经发布前商业规则测试的、质量较差的内容。这也正是我们开发新的发布工具，Pubwiz 6.5 的原因。它允许网络管理员按要求发布文件，并强制遵循商业规则以保证良好的站点性能。 我们认为，您大概愿意了解有关 microsoft.com 小组所开发工具的内幕消息，该小组的主要职能是保证发布的稳定性和可靠性，即使编辑人员利用它来完成在技术方面具有挑战性的工作，也是十分方便的。很快，那些使用 PubWiz 6.5 处理某项工作的发布者就可看到站点中一些新内容。过去，同样的工作过程需要长达 3 小时的时间。 不止如此，一旦文件在服务器中登台亮相——中间必须经过重要的一步——用一套统一的流程跟踪其能够保持在有效的全球广域 Microsoft Internet Information Server (IIS) 中进行重复接收的情况——功能强大的、用于传送网络内容至访问者的机器。该工具借鉴了 ActiveX、 Microsoft Internet Explorer、Microsoft SQL Server 7.0、Microsoft Transaction Server、XML、Visual Basic、多线程 C++ 编程、DCOM 以及最新创建的后端复制结构的优点。 这种工具受到网络管理员的热烈欢迎。如果您的工作是管理一个每天发布 25,000 个文件，总计一兆字节数据的网络，您就会需要像 Pubwiz 6.5 这样的工具作为业务的突破点。 第一幕：一个四层结构的工具 负责网站发布工作的人员可通过 nternet Explorer 访问公司内部网络中的一页来登录使用 PubWiz 工具。它将调用 Visual Basic 的客户应用程序，并将之作为 ActiveX 文档。与 PubWiz Server 组件通信需要 DCOM 协议，它存在于一个正在运行的可执行 Microsoft Transaction Server 中。这些组件使用连接合并以完成与 SQL Server 7.0 的高效通信。 另外一层位于表示层和业务逻辑层之间，它提供我们所需要的丰富的客户处理技术、提高速度并减少客户开销。几乎在一个实例（将在下面详述）中就可看到，数据在高效的变量数组中被打包和传输，其结果是使客户/服务器应用程序的运行和响应速度更快。 另外，来自服务器的数据在本地存储器中进行缓冲，而不是保存在硬盘中，因此，其速度很快而且只需很少的文件存储空间。实际上，您所需要仅仅是——大约占用 500K 空间的组件——它可在您第一次访问 PubWiz 的时候自动进行安装。它不需要在用户的硬盘中写入其他任何内容。其他的优点还包括通过内置于 Internet Explorer 的组件下载技术，及时完成升级工作。 现在让我们继续向前。首先用户会创建一项任务，为该任务指定一个 ID 号，并在 SQL Server 数据库中添加该任务的一个新记录（通过 Transaction Server）。然后，用户选择用于任务描述的文件。这里是变量数组数据包的特例。 PubWiz 利用内置于 Windows 的文件系统控制器，为编译服务器（文件在发布前在此处进行测试）提供一种类似于资源管理器的视图。一旦选中某些文件，就会进行快速权限检查，以确保用户拥有发布文件的权利，如果这样，还可将这些文件作为任务描述文件保存在内存中。用户单击一个按钮可继续下一步，通向升级服务器中文件的路径将被传递到 Transaction Server，该服务器再将它们添至 SQL Server 记录中。 如果某一任务描述包括了所有必要的文件，它就会被送往一个自动测试流程（商业规则层），它将比较带有有效服务器的文件和文件夹，从而决定某些特别的业务以及是否要添加、替换和删除某项业务。然后它将检查以保证所有 Microsoft 的链接都是有效的，并且符合所有商业规则（就像命令工具栏导航条）。 如果违反了规则，那么导致失败的文件将被标记出来，而且该任务不再继续，除非修复和删除了那些文件。用户单击某个按钮，可在记事本中打开问题文件以便进行快速修复。然后重新测试那些有问题的文件。一些有效的服务器页将被送入某一流程，在该流程中，这些页面将进入某一队列以便进行自动性能测试。用这种方法，我们可直观地进行站点应用程序代码的性能评估。 第二幕：复制 让我们假设任务已被批准。该任务已经可以马上发布出去，或者可以设定某个特定的日期或时间。首先，这些文件会复制到某个性能非常好的服务器（以下称为“金牌服务器”）中，该服务器位于测试服务器和复制过程之间。一旦文件复制到金牌服务器中，它们就可留在那里一直到设定的发布时间，但是这之后，网络编译器还可修改测试服务器中的文件。（如果发行人创建了另一项任务，其中包括了与还未就绪的、某个时间更早的任务中相同的文件，那么该文件的新版本将替换金牌服务器中的旧文件。） 现在事情变得实在是很有趣。多线程复制服务，并不是顺序处理这些任务，而是同时有 50 个线程一次性完成任务处理工作，它定期检查过去到期的任务（包括那些马上就要过期的任务），然后启动复制过程——首先到升级服务器，然后是位于三个国际地点的 39 个有效的服务器。世界范围内的升级服务器用作平衡美国的负载以及最大限度地提高国际站点的效率，因为文件在每个站点只需被传送一次，穿越大西洋两岸沿线以填充在伦敦和东京数据中心的多个有效的服务器。在文件中所添加、替换和删除的信息将从 SQL Server 中删除并以 XML 的文件格式复制并存储到本地升级服务器中。 该流程剩下的部分，就称为后端复制结构 (End-Point Replication Architecture)，它是由某个分层结构中的线程集合来管理的，这有些类似于赌场中赌博的运作过程，由一个人来控制后续过程。如果由于某种原因某个线程停止响应，那么其上的线程有权终止该线程的工作并启动一个新线程以完成整个流程。而复制控制器，将向系统级 NT 服务进行报告，并启动三个线程：复制管理器、队列恢复管理器以及清除/恢复。 复制管理器生成任务线程以管理复制任务。如果某个文件的目的地是位于 Redmond 数据中心的 www.microsoft.com 服务器，就会有 30 个有效服务器得到该文件。一个任务线程将创建 30 个机器线程以完成复制任务。现在，如果这些线程中的某一个停止了响应，比方说是因为某台机器脱机，则该任务将被传递给队列恢复线程，该线程将以后台方式周期性创建队列线程以检查停机的服务器。当服务器恢复联机后，所有队列文件将被快速复制和更新。清除线程的作用仅仅是在完成某项任务，并且在不再需要该任务的情况下，将 XML 数据文件从升级服务器中删除。 一个自然而然的过程 如何才能建立这种先进的发布模式呢？这不是一个晚上就能做到的。PubWiz 6.5 标志着对以前版本的发布向导的突破，一旦文件复制到了某个中间的“金牌”服务器（该服务器用于将文件传播至全球广域网服务器）中，它就不再对其进行监测。然后一个被称为二级复制的自动过程可将文件复制到有效的服务器中。如果有什么阻碍文件抵达目的地——经常会发生这种情况——那么直到有人发现自己的文件还未生效并且写信向 Microsoft 的帮助服务台抱怨的时候，我们才会注意到这种情况。 PubWiz 里程碑 Pre-PubWiz - 文件编辑/人工将文件复制到有效服务器中 PubWiz 1.0 - 附在 Microsoft Access 后端的首次出现的应用程序（1996 年 11 月） PubWiz 2.0 - 增加了报告和链接检查的功能（1997 年初） PubWiz 3.0 - 增加了商业规则检查功能（1997 年初） PubWiz 4.0 - 增加了对多 Web 簇的支持，例如，windows.Microsoft.com（1997 年初） PubWiz 5.0 - 移动到基于 SQL Server 的后端系统（1997 年 6 月） PubWiz 5.5 - 增加了多线程升级服务器复制功能（1999 年 2 月） PubWiz 6.0 - 增加了对下载程序中带符号编码文件的支持（1999 年 5 月） PubWiz 6.5 - 增加了后端复制和按需求发布的功能（1999 年 6 月） 在早期，microsoft.com 的 Web 发布者可在有效的 Web 服务器中直接编辑文件。可以想象，这会带来数不清的麻烦和质量控制问题，因为站点访问者经常会点击还未完成的页面。后来，雇用帐号管理员来负责将文件发布到有效的 Web 服务器的工作。网络管理员会通过电子邮件发送需要散发出去的文件列表，然后帐号管理员将在指定的时间，利用一种被称为 robocopy 的、基于 Windows NT 的工具，人工将文件复制到多个服务器中。 最后，在1997 年，我们开发了 PubWiz 的第一个版本，一种带有 Microsoft Access 后端的 Visual Basic 的应用程序，无数的 Microsoft 网站管理员利用它来自己完成发布文件的工作。这就解放了帐号管理员以便他们在我们的工作组中承担更重要的角色，而且还使得数百个 Microsoft 的 Web 发布者可在三个小时的时间间隔内，自由地完成站点的发布工作，而且不会妨碍其他任何人。 现在，我们完全摆脱了三个小时的时间限制，而且得到了前所未有的高可靠性。该工具可进行适当的调整，不论是用于完成大型和小型的任务，还是在快速的网络连接和糟糕的调制解调器连接的基础上。这都是一流的解决方案，但是不可能在一个晚上就能实现。 我们基本上完成了整个循环。利用 PubWiz，我们能够按需要发布文件，就像原来在有效的 Web 服务器中编辑文件一样方便。但是我们不会有与这种直接方法相关的一切负担，却可得到可扩展性和规则检查所带来的所有好处。 编辑须知： 我们非常关心您对本文的看法。请按以下地址与我们联系： homepage@Microsoft.com。主题：Backstage。 © 1999 Microsoft Corporation。版权所有。使用规定。 最近更新时间：1999 年 8 月 1 日
|
|
||||||||||||
