我们的项目旅程

成成

我们的项目旅程
本文来自Microsoft MSDN


概述：我们的旅程
技巧：为了成功，你需要了解什么？
行动方案：设计、开发、配置
设计：为理想绘制蓝图
Baus Coffee：一个实例
结论


概述：我们的旅程

你被要求为你的公司或者客户开发一个电子商务（e-commerce）平台。这是你一生的机遇，而且其中充斥着诸如此类难以理解的行话：关键任务（mission critical）、商业线（line of business）、高度可视（highly visible）、极端技术（bleeding-edge technology），还有，如果你幸运的话，你的作品将会被数以十万计的人看到。
但是，在我们可以沉醉于荣誉之前，请耐心一点，首先让我们向自己提几个基本的问题。在回答问题之前请确认你对自己是诚实的，因为这关系到你会成功还是失败。另外，这儿只有咱们俩，我又能告诉谁呢？

首先，你曾经设计、开发并且配置过一个经过关键任务容错为99.9%的应用程序吗？

你自信能设计和开发一个需要处理每天两万、三万甚至五万个事务的应用程序逻辑吗？

你知道如何开发一种性能评测手段来检验你的作品吗？

你能确认你的系统是百分之百的安全并且不会被黑客从外部攻破吗？

你知道如何管理诸如均衡装载（load balancing）、系统冗余（system redundancy）和主干集成（Legacy integration）这样的问题吗？

对这些问题，你的回答很可能大多数是"不"，如果不是全部的话。别灰心。你是在这样一种环境中，这里绝大多数软件开发人员和顾问也都面临同样的挑战和问题。事实上，我们中的大多数人也是直到最近才开始处理这些问题。

这篇文章是一个三部曲系列的第一部分。主要是介绍一些技巧性的东西，提供一些方便的参考，并且给你一个大概的行动方案。然后我们将集中到与设计一个电子商务平台相关的核心问题上。我们将通过示范设计一个大规模的电子商务平台来结束本文。在本系列的第二篇文章中，我们将集中到开发问题上，诸如代码优化（code optimization）、调试（debugging）、源控制（source control）、数据库设计（database design）、提高性能的技巧（performance tips）和其他一些问题。在系列的最后一篇文章，我们将讨论如何使我们的工作富于艺术并且怎样在一个产品环境中管理它。
本系列的目的是给你提供一个上述问题的基于真实世界的答案，以及你在设计、开发和配置一个电子商务平台的过程中可能会遇到的问题。我们将分析项目生命周期的每一个阶段，并且使你在短时间内使自己感觉像一个专家（当然，你还是需要一点时间的，但起码比你选择走上一条荆棘密布、错误百出的道路所花的时间要少得多）。我们在一起努力工作、付出辛勤的汗水，而得到的更多是趣味。现在需要提醒你的是，我在这里提供的信息不是来源于教科书、实验室，也不是来自教室，而是来源于实践的信息，我们是在一个真实世界场景下学习。我将同你在一起，并且分担那些看起来很不错但是最终会导致极大失误的令人尴尬的事情。带上你喜欢的饮料（我可不要，啊哈，我要开车啊），放上一盘好听的音乐，轰上油门，我们的旅程开始了！

技巧：为了成功，你需要了解什么？

我喜欢皮划艇、山地自行车、徒步旅行和雪板运动。这些运动都需要一定水平的技术来保证安全和享受成功。开发一个电子商务系统没有什么不同。如果你想要获得成功的话，你需要掌握一些核心的技术或者能明白你的开发小组使用的技术。

在这个部分，我要提供给你一张清单，列出了你的小组需要进行的基本任务。每一个任务都定义了在项目开始之前需要的技巧、知识和技术。小组的结构会因你所处的环境发生变化，但是如果你还没有一个框架的话，我强烈建议你看看Microsoft Solutions Framework。

建筑/设计：在一些组织中，这项任务也许是由项目经理、开发组长和技术组长来分担的。这项任务的目的是：将商业要求转化为可以被你的开发人员和质量保证（quality assurance，QA）小组利用的技术要求。这些人（指负责这项任务的人们）需要对基于Web的应用程序设计、Microsoft? Site Server商业版的体系，数据库设计以及备份和修复技术有着深刻的理解。根据项目的不同，他们也许还需要理解主干系统集成（Legacy system integration）的含义。

开发人员：电子商务系统通常需要两种类型的开发人员：Web或者前端开发人员和组件或者后端开发人员。Web开发人员必须非常熟悉ASP（Active Server Pages），Microsoft Visual Basic? Scripting Edition (VBScript)，HTML，JavaScript等技术，并且对组件对象模型（Component Object Model ，COM）有基本认识。小组中的Web开发人员要负责创建站点的外观和为站点的整体感觉定调，因此图形设计也许也是非常必要的。

组件开发人员需要对基本的COM开发语言非常熟悉，像C++和VB。其中很重要的一点是：他们必须理解与COM相关的性能含义，因为一个错误的选择将会导致极大的性能差异。另外，他们还应该了解SQL事务。经常有人问我：为什么主要负责编写COM对象的组件开发人员还需要了解脚本编程（指SQL中的脚本编程）。答案很简单：通过编写客户端脚本，他们可以检验自己的代码并且节省宝贵的QA时间。

在Web开发人员和组件开发人员之间的分界线并不是一成不变的。Web开发人员一般是在站点的前端表现层上工作，这可能是经常需要改变，并且必须以高度动态的方式来思考问题。组件开发人员往往是集中在开发完成这些任务的组件上：与主干系统（Legacy systems）互动的组件，封装商业规则和商业逻辑的组件，访问后台数据库的组件，以及进行计算的组件。

质量保证：这往往是系统中最不受重视并且通常也是投资最少的部分。为了说明拥有一个强有力的QA资源是多么重要，下面有一个急智测验（quick quiz）：

顾客对买到的包装好的软件产品以及对一个电子商务系统的期望之间有什么差异？
顾客需要两者都是稳定的，否则他们将做另外的选择。两者都需要是可靠的并且提供正确的信息。两者都必须是经过彻底的测试以避免潜在的错误。到目前为止，你应该明白两者之间并无区别。这就是为什么在你的小组中应该有一些精通性能测试、测试客户端开发、开发测试计划和全面管理QA过程的人员的原因了
参考：在哪里能获得帮助
许多文章都是在结尾才向你提供资源和参考，我不知道为什么是这样的，但是现在是时候改变了。这儿有一个参考列表（而不是在本系列的末尾）。如果你现在正在进行开发工作，你可以在你最需要它们的时候得到一些帮助。如果你还没有开始你的工程的话，当你读到本系列的其余部分并且意识到你还需要在这个题目上深入发掘的时候，你也很容易回到这儿来寻求帮助。

Tuning High Volume IIS Sites

IIS and MTS 2.0

Commerce Topic Links

Site Server Home Page

行动方案：设计、开发、配置

这是一个很简单的事实："预则立，不预则废"，花时间来规划站点结构，考虑如何建设和构筑我们的平台，然后把钥匙交给新的用户。起码我们应该清楚在我们的电子商务平台的"设计、开发、配置"中包含的步骤。

我首先声明，对于电子商务平台开发来说，这个行动计划是一个普遍的指南，但不是一个非常详细的方案。在这里，我要提供给你一个大概的构架，这样你可以根据它来选择你的方案。

设计：通常情况下，站点的设计工作做的很不够。在一个电子商务平台的开发工作中，你需要分析所有各部分是如何联系在一起的，并且确保你已经和所有相关各方取得了一致。在其外观之下，电子商务平台是一个纯粹的分布式系统。在某些地方，你依赖于来自一个公司其他地方、商业伙伴或者第三方付费服务的数据。这些系统和服务之间的互动会对你的站点开发造成动态的影响。直接了解这些影响并且将其作为站点设计的依据是非常重要的。

注意：在最近的一个项目中，我要求每一个开发人员在开始编制代码之前做一份详细描述他们的组件设计的文档。这看起来有些过分，但是却使我们节省了大量的时间和金钱，因为我们能够直截了当的找到错误。在你的项目的生命期内，设计是一个持续进行的过程。

开发：系统的开发也许是你的项目中最有趣的一个阶段。是把你的想象变成现实的阶段。但也是绝大多数梦魇的开始--你发现事情并不是象你想的那样去做。在开发阶段你仍然需要继续设计工作，重新审视那些没能很容易的协同工作的地方。在这个阶段尽快开展QA工作也是很重要的。

配置：配置也许是最能使你的小组感到灰心失意的时期。这是你实际测试你付出的辛劳和汗水和检验你的设计的时机。

"设计、开发、配置"这三个阶段经常搅在一起。在项目中进行产品维护和继续审视设计阶段的工作是很重要的。当你从测试和QA处获得反馈时，你需要优化甚至重新编写代码。这是整个旅程的自然的组成部分，你应该事先做好计划而不是对此感到惊讶。

我们现在对项目需要哪些类型的人有了一定的了解，我们还获得了一个基本的参考，在我们的旅途中遇到困难时可以使用它们。接下来的部分，我们将介绍一些与项目相关的设计问题并且给出一些初步的解答。然后我们将通过构建一个大规模电子商务平台的方法来把我们学到的理论付诸实践。现在是你换一瓶饮料，吃块三明治，播放另一张你喜欢的CD的最好时间。


设计：为你的理想绘制蓝图

我假设你已经和你的小组一起做过一个项目规划以及技术要求文档。在这一部分，我们将提出一些问题和值得关注的地方，这些都是你应该理解的。我将在适当的地方提供可能的解决方案和建议。

范围：项目的大小
项目的范围是决定你的小组应该有多大，完成任务的时间，和商业上的要求是什么等几个问题的最重要的因素。在你设定项目的范围时请首先考虑以下问题：
你如何验证付款？
你是否需要支持法人信用卡？
你是否需要支持虚拟贸易和仓库？
你如何完成产品交付？
你是否需要一个non-cookie解决方案？
你需要什么样的安全等级？
你需要后台集成吗？如果是，怎么进行？它能够批处理吗？
你如何处理取消定单的要求？
你是否支持实时目录？
你如何管理退货？
你是否需要提供在线定单记录？
需要提供哪些进一步的支持？
你需要支持哪种检索机制？
你出售什么样的商品？这些产品是如何编组的？
是否支持定制价格或者折扣？
需要储存多少顾客的记录？
需要储存多长时间的在线事务记录？
你的产品目录有多大？
尽管这不是所有问题的完整列表，但仍然不失为一个好的开始。每一个问题都关系到你要花多长的时间来成功的配置你的电子商务站点。

时间：你有多少？
我所做过的或者听说过的电子商务项目看起来都是在昨天就应该发布了。一个值得考虑的问题是：把你的系统和无论主干（Legacy）或者第三方的系统集成起来要花多长的时间？如果你开发的是一个独立的电子商务平台，你就可以自由的决定一个强制性的时间表。我能给你最好的建议是：你要搞清楚，从你的项目一开始就存在着主干（Legacy）和第三方的资源。

提示：在商业部门结束规划以后就把项目要求和结构交给你的小组是一个好主意。这使得你可以使用自底向上逼近的方法来决定完成项目究竟需要多长的时间。

规格：成功的指示条
尽管我们花了很多时间来定义我们的要求，但还是没有足够的时间来指定与我们的要求相关的规格。电子商务系统通常需要三个评价标准：

可伸缩性（Scalability）：一般以平台能承受每天多少人或者多少次点击次数作为参考。
可靠性（Reliability）：这个标准经常用时间来度量，例如7x24。
响应速度（Responsiveness）：通常用系统把信息返回给终端用户所花费的时间来衡量。

这些只是基本的规格，你还需要考虑更多的东西，例如下面列出的规格。你需要通过在你和商业部门之间的谈判来确定对规格的定义。在签字以前，你必须清楚的了解你的项目的要求和范围。例如，如果要开发一个集成主干（Legacy）应用程序的系统，你一定要很仔细的定义什么是你要达到的标准。如果你声明"平均用户响应时间将少于五秒"，这究竟是只包括Web平台呢？还是在电子商务系统和三个路程段（hop）以外的网络上，并且同时用于电话销售系统的目录数据库之间的整个周期？

正如你看到的，清楚的定义每一条规格，并且将其量化是非常关键的。如何理解和定义你的规格将对系统开销，需要配置的结构和整个设计造成巨大的影响。在一个严格要求99.9%有效和一个马马虎虎能达到99.9%有效的系统之间，开销和设计是有着天壤之别的。设计电子商务系统时，你起码应该给出下列规格的清楚的定义：
在24小时周期内，峰值装载时间是什么时候？
一天所有通信量和峰值装载通信量之比是多少？
通信量是周期性的还是表现为随机的尖峰？尖峰的峰值范围是多少？
计划可以接受的系统关闭时间是多少？
目录和产品信息的更新或者改变的频率是多少？
搜索索引更新的频率是多少？
对以下事务要求的响应时间是多少：获得查询结果、向购物篮里添加一件商品、查看商品、确定付款信息、计算定单和验证目录级别？第三方和主干（Legacy）对这些活动的影响是什么样的？
如果系统失败，你需要多长时间转移到后备系统上？
在分析上面每一个问题时，你都应该考虑答案将如何影响你的设计。在达成每一个规格的确定目标之前，你应该给你的开发小组充足的时间来考虑与之相关的每一项开发问题。

平台考虑
我们谈的平台是指将作为系统基础配置的底层（包括硬件和软件）。在这里所做的选择将有助于我们了解如何接近设计，同时也与配置系统和将来对系统的管理有关。选择平台要考虑的三个问题是：安全性、服务器选择和可恢复性。

安全性
典型的，绝大多数人都关注"消费者到商业"过程的安全，并且实现了安全套接字层（Secure Sockets Layers，SSL）或者安全电子转账（Secure Electronic Transfer ，SET），以此作为事务的安全措施。但是我们的眼光要放开些，要理解电子商务系统是分布式的，我们必须注意到不同方面的安全性需要。

Web安全性： SSL适于消费者和Web服务器的交互过程的安全要求，在我们的案例里，Web服务器是指Microsoft Internet Information Server （IIS）。为了加强适应性和便于管理，我的建议是利用站点服务器的签名和成员资格属性（Site Server Personalization and Membership ，P&M）。Site Server P&M提供了对SSL，cookie验证、分布式密码认证以及HTML表单的支持。并且通过映射到Microsoft Windows NT?安全性上的创建安全组的能力，提供了一个强有力的结构和管理的基础。请记住将来需要一个操作小组来管理这个电子商务平台，所以你需要向他们提供管理工具或者利用已有的工具，例如支持P&M的微软管理控制台（Microsoft Management Console，MMC）。

成成

组件安全性：利用微软事务服务器（Microsoft Transaction Server ，MTS）可以大大的简化COM组件的管理，它同时还提供了一种管理组件安全性的方法。我们可以向产品职员提供一种通过图形界面来管理安全性的工具，但是用不着我们自己编制，只要支持MTS就行了。

主干（Legacy）安全性：在我们的设计过程中永远都需要考虑同后台系统的集成，尤其是涉及到安全性时。我们需要了解如何取得对主干（Legacy）系统的访问权限以及我们需要支持什么样的政策。Microsoft SNA Server提供了针对IBM系统的集成的安全性。在非IBM系统上，例如UNIX，我们需要自己编写网关程序。也许你愿意考虑开发一种处理你的电子商务系统和主干（Legacy）环境的COM组件。

商业到商业的安全性：虚拟仓库、执行定单和交易都依赖于公司间的安全连接。这种交易必须通过一种安全的方式进行，利用加密技术是很有前途的。虽然我们可以自己开发一种机制来实现这个目的，但是最方便的是利用那些公开出售的验证技术。作为站点服务器商业版的一个组成部分，商业交换管道（Commerce Interchange Pipeline，CIP）提供了对加密、S/MIME和和DCOM，以及一种返回收条的机制一样的支持，后者是一种轻量拒付方式。

你已经看到，关于安全性有很多要考虑的事情，这些考虑将明显的影响设计工作。我们必须明白我们想要达到哪种安全性级别，我们所用的不同系统的安全性级别以及它们如何影响我们的要求。我建议你从安全性开始你的项目设计，并且在设计系统中的其他部分之前完成这项工作。当你的计划向前推进时，这将会提供一个你可以返回的基础，并且你可以决定在你的安全构架中是否需要其他的系统服务和系统特性。


服务器选择
一旦你理解了核心设计，也处理完了你的规格，并且对安全性问题也有一个良好的认识，你就需要开始认真考虑要用来运行产品的工具了。这可以归结为一个基本问题："我究竟需要多少台服务器？"这儿没有唯一的答案，如果我告诉你做决定所需要的知识对你更好一些。

如何计划你的服务器关系到你对规格的理解有多深刻。你理解得越深，准确预见你的需要的机会就越大。这儿有一些基本的提示，它们可以帮助你更好的开始：

开发用户原型：这将使你能弄清楚Web站点的用户在什么地方消耗他们的时间。如果你的用户在进行高级搜索上花去了80%的时间，你也许会愿意把这项功能转移到一台单独的服务器上。没有用户行为的精确数据，你是不可能在诸如此类的事情上做出决定的。

配置独立的数据库和Web硬件：甚至在最小的环境里，你也应该认真考虑把你的数据库和Web系统放置在不同的服务器上。Web服务器和数据库服务器，这二者要发挥最佳性能，需要做不同的调整，而其中的差异是非常巨大的。当你调好了一个，却会造成另一个的性能问题。同时，在数据库上，备份操作的负担通常只有在一台独立的服务器才能很好的解决。

把资源密集型的应用转移到独立服务器上：那些会造成密集的系统请求的操作应该转移到别的服务器上去。批处理、为目录编制索引、直接邮件操作，以及Web日志分析，这些都是应该仔细考虑是否要用专门的服务器来处理的内容。


可恢复性（Recoverability）
我们经常这样来考虑可恢复性，即在发生系统崩溃或者其他灾难的时候，我们怎样恢复系统。更常见的情况下，是指如何恢复系统服务。虽然这样说已经基本上够了，我们还是需要想得更广泛一点，应该把事务恢复也包括进去。

事务恢复是指把现在的系统状态恢复到前一个事务状态（耶！你在讲天书啊？）。让我们试试是否能把它变得更容易理解。电子商务系统的目的，就最基本和最原始的意义上来讲，是让我们可以买到东西。要达到这个目的，我们必须采取一种"要么全有，要么全无"的态度。也就是说，我们要么开展完整的交易，要么一点也不要做。为了方便，我们需要假设系统已经通过了ACID测试，我们在本系列的第二部分要讨论这种测试。

现在，我们只要相信我们已经有一种恢复事务的方法就行了。如果我们使用站点服务器商业版（Site Server, Commerce Edition）带有的定单处理管道（Order Processing Pipeline），我们就有一种简单而完整的办法来取消我们所做的改变或者确保改变已经生效。在我们需要和诸如CICS以及Oracle数据库这样的主干（Legacy）系统互动的时候，还需要提供对分布式事务的支持。使用Microsoft Transaction Server就能满足这个要求。

如果我们所要做的全部工作就是事务恢复，那就太好了，但是我们仍然要明白在发生系统崩溃、数据库崩溃或者类似的问题时如何恢复我们的平台。下面列出了我们将在电子商务系统中遇到的一些问题：


分布式恢复：多数电子商务系统是建筑在多层结构上的，这个结构包括表现层、商业层以及数据层。每一层都和不同的主干（Legacy）系统相互作用，并且需要有不同的恢复策略。

庞大的数据集合：视你的系统而言，你需要维护的数据库的规模从GB（230）到TB（240）不等。备份和重新装载这样的系统需要高速解决方案。请确认你已经参考过你的规格，知道有多少数据需要存储，以及这些数据是否必须总是处在能被访问的状态。如果需要数据来做商业报告，你也许愿意把这些信息转移到一台可以用来做分析的服务器上。这不仅将减少你的备份和重载时间，还将提高系统的性能。你还需要考虑巨大的数据集合对索引修复、DBCC操作以及维护工作的影响。Microsoft SQL Server? 7.0在这些领域提供了巨大的性能改善，你也许可以把它作为你的设计的一部分。

不间断的操作：提供一个能确保7x24操作的设计方案是一个很普通的要求。我发现这个要求的真正含义是你要能够处理那些妨碍实现真正的7x24操作的事情。稍后，我们将讨论如何使用Microsoft Message Queue (MSMQ)进行异步设计以使你能以最佳费效比来提供这项服务。

正如你看到的，事务和平台的恢复工作是一件很严肃的事情。每一项都将对你如何编写你的系统造成影响。你必须在转到开发阶段以前解决这个问题，因为这是你走向成功的关键。

关于性能
更大、更快、更强！这好像是今天各处的电子商务站点的"战争"口号。为数十万的用户服务、处理事务，以及增加商业收益的能力是任何电子平台成功的关键所在。在这一部分，我们的目标是了解如何设计一个能提供高性能、高可靠性以及高可伸缩性的系统。


均衡装载和可伸缩性
在我讲演的时候，我经常向听众提问，我问他们，有多少人设计过一个可以同时支持几百个用户的高性能、满负荷、具有容错能力的系统。在平均大约５００个听众中，有２００只手举了起来。然后我问有多少人设计过一个类似的系统但是能同时支持１０００个用户呢？这回只有不到１００个人举手。最后，我问有多少人能设计一个可以同时支持１００００个或更多用户的系统时，一般都没有人举手。本节的内容将帮助你将来成为少数几个在我问到这个问题时能举起他们的手的听众中的一个。

虽然我也可以把均衡装载和可伸缩性分成两个独立的题目，但是我还是更愿意把它们作为一个整体来处理。因为这两个问题实质上是同一个问题：状态的维持。简而言之，维持状态与保持一致是一个意思。当我们维持状态时，我们就是有状态的，反之，我们就没有状态。如果在用户的每一个动作中间，你能记住他是谁以及他在做什么，你就是在维持状态。又比如，假设我登录到你的系统上，每一次我查询购物篮，你都可以把它显示给我而不需要采用cookie以及其他的客户端标志。你知道我的"用户代号"以及"购物篮代号"。这是因为你使用了Web服务器资源来跟踪我在做什么，我是谁，我去你站点上什么地方。维持状态受到我们的可伸缩性和均衡装载的限制。

均衡装载是通过循环DNS（域名解析），Cisco本地目录（Cisco Local Directors，属于硬件解决方案），或者是最近我特别推崇的，Microsoft Windows Load Balancing Server等方案实现的。这些解决方案把客户端请求引导到被称之为"农场"的最小繁忙（least-busy）服务器上。一个Web"农场"主要是指一系列提供不同服务的服务器。例如，我可以有三个独立的Web服务器，使用上边介绍的其中一种解决方案，把客户装载分布在这三台服务器上。从理论上讲，如果每一台服务器能同时处理１００个客户的话，那么由三台服务器组成的Web"农场"就能同时处理３００个客户。这样做的好处是对客户端来说，他们看到的都是同一个IP地址或者域名。

如果客户A的第一个请求经由路由器后到了Web服务器１上，而第二个请求却到了Web服务器２上，这样会发生什么情况呢？在一个状态化的环境中，这将会是一个麻烦。如果我们第一次连接到Web服务器上，那么我们需要总是返回到Web服务器１上，因为我们是在这台服务器上建立了我们的状态或者说是身份。在一个典型的Web"农场"中，服务器之间是没有通信的，因此只有在你第一次连接到这台服务器上以后，它才能知道你是谁。设想一个客户在每一次点击一个超链接时都被要求登录一次，仅仅是因为她被导向了一个不同的Web服务器。最低限度说来，这也是会让人感到沮丧的。

均衡装载一般通过下面这种方式来解决这个问题，它实现一个路由表，该表追踪客户的IP地址并且总是把客户导向同一台服务器，除非客户断开连接或者该会话到期。这样做的结果是你必须维持状态并且要利用珍贵的服务器资源。针对大流量的站点有一种更好的方式，这种方法是和Microsoft Site Server P&M捆绑在一起的，并且是一种无状态的方式。在我们详细讨论这个方案之前，首先让我们把注意力转到另一个领域--可伸缩性上来。

成成

我们已经确信，在Web服务器上维持状态将导致资源的占用，这将限制我们扩大规模的能力并且会降低整体性能。但是状态化的设计可能对平台上别的领域有利。假设每次我们想要查看某种产品，我们都要和一个同后台数据库对话的COM组件相互作用，当我们第一次使用该组件时，我们传递一个用户代号给它。以后每一次当我们想知道某种产品的信息的时候，我们就传递一个产品代号。依靠产品代号和早些时候我们传递的用户代号，系统就能提供我们一个包含定制价格的产品信息。 说得更明白些，就是我们连接到该组件时同时建立了一个到数据库的连接。从理论上说，这样做比每次和该组件互动都建立该连接要节省一些时间。这象是个好主意，不是吗？好的，让我们回到那个伤脑筋的问题上：如果有１０，０００个用户同时连接会有什么事情发生呢？利用前面这种思路来解决问题，我们就需要维持１０，０００个COM组件和１０，０００个数据库连接。那么当规模扩大到１００，０００或者２００，０００甚至１，０００，０００个用户呢？显然这不是一个好的设计，就因为它是状态化的。 更好一些的方案是使用无状态的组件和连接池（connection pooling）。这样做并不难，而回报是巨大的。如果我们修改COM组件使得每次传递产品代号的同时也传递用户代号，这样做也能返回一个包含定制价格的产品信息。不同之处在于，一旦我们完成了任务，我们可以立即释放组件和数据库连接，因此也就释放了先前的系统资源。与管理连接和设计一个实现连接池的构架相比，更好的方式是在MTS中保存组件并且利用JIT（Just-in-time，即时激活）的优越性以及连接池。这个小小的改进将使我们很容易就把规模扩大到超过１０，０００个同步用户。 如果我们现在回到均衡装载的情况，为Web"农场"提供状态无关性，我们也可以从同样的方式中获益。我们可以使用客户端cookie，HTML表单，或者将用户代号作为URL字串的一部分来传递。我们现在可以实现均衡装载机制了，方法就是将请求引导到Web"农场"里任何一台可用的服务器上。 在设计和开发中使用这些技术可以给你提供超乎想象的可伸缩性。但是最终你还需要更为灵活的和可伸缩的设计，这样你才能利用每一点系统资源。 容错能力和可靠性（Fault Tolerance and Reliability） 在设计阶段的会话过程中，我经常耍这样一个小小的花招，我问："这个系统是不是一定要7x24？"回答总是"是的。"然后我问："我们是否需要和主机或者主干（Legacy）系统打交道？"答案当然还是"是的。"接下来我又问（这就是奥妙之所在了）"你的后台系统是否需要关机来进行维护呢？"通常我总是得到我想要的答案"每个星期六晚上"这时候我就会问"那么我们怎么能实现7x24呢？你的主机关机了，而我们又要靠它才能进行服务？"一般情况下，答案总是一片沉默。 对于这个佯谬，答案是使用异步设计。你的目标是希望在公司的主机被关闭以进行维护的时候能接受定单，而不是关闭系统。为了实现这个目的，你需要在设计中使用MSMQ。 把对异步的支持包含在设计中，就可以接受定单并且把定单代号发送到一个MSMQ队列中去。一旦后台系统又重新回到线上，系统就可以扫描这个队列取出定单代号并且继续处理它们。你只需要做一点点工作，就可以通过这项服务在你的商业层次上提供更高的智能，。例如，如果后台系统在线上，你可以把定单请求直接传递给它并且立即将确认信息返回给顾客。如果它不在线上，你可以把定单发送到队列中去，并且通知用户对他的定单的确认将在一个钟头之内发给他。在任何情况下，你都要给你的用户提供一种可以追踪定单处理进程的方式。 使用异步设计能够提供一个高度可靠的系统，并且可以降低总拥有成本（total cost of ownership，TCO），但是我们仍然需要处理那些传统的容错和可靠性方面的事务。我们已经在不知不觉中解决了一些这样的问题。 在Web服务器和组件设计中采用状态无关的设计，使我们不再把可靠性的要求押在一台特定的服务器上。想想在一个状态有关的设计中，如果客户A被定向到服务器１上而服务器１在处理两个请求之间崩溃了。对于第二个请求，客户A将得到一个错误信息。如果我们采用的是状态无关的均衡装载机制，在这种情况下，我们将服务器１从路由表中清除，并且把客户A重定向到另外一台服务器上。由于我们的系统是状态无关的，所以系统可以应付流量的增加（因为Web"农场"中别的机器必须处理原本由那台崩溃的机器完成的工作，所以单台服务器的流量增加了）。因此状态无关使我们拥有扩展的能力，高可用性以及简单、有效的容错能力。 还有一种方法可以增强我们修复错误的能力，这就是使用Microsoft Cluster Server。我的建议是使用双节点容错方案来集群化数据库。这将使你能确保产品环境中持续的轻量输出。 现在我们已经解决了要面临的最关键的设计挑战。希望你对如何规划你的项目、规格的重要性、关键平台考虑、以及它们如何影响你的设计、如何处理与性能相关的问题等等都有了较好的认识。下一步，我将提供给你Baus Coffee案例分析，这是本系列第二篇文章的结构基础。 #Baus Coffee: 样本结构 Baus Coffees是一个假想的公司名字，但是这个案例分析来源于一个实际的电子商务平台。这部分的目的是给你提供一个包括本文前面所讨论的那些信息的电子平台的概览。 逻辑结构（Logical Architecture） 为了满足设计要素，我们决定采用一种基于下列逻辑层次的多层系统： 表现层（Presentation Layer）：本层向用户提供系统的外在表现，该层分为两个部分：消费者界面和管理界面。消费者将能通过本层的消费者界面浏览目录、管理自己的成员资格、下定单。管理工具为Baus中的两个小组提供了一种以安全和结构化的方式访问系统的能力。这两个小组分别是市场营销和产品小组。市场营销小组拥有一系列图形化的工具来进行交互式销售规则的开发、管理广告活动、显示和创建定制的站点报告，以及其他功能。产品小组也有一系列图形化工具。这些工具使他们能维护目录、管理系统、能够预见带宽以及容量要求、以及其他功能。 商业层（Business Layer）：商业层是这样一个逻辑层，它使公司能够把商业逻辑和规则从数据或者用户界面中分离出来。通过商业逻辑的分离，Baus能够更好的管理那些必须在系统级别实现的商业上的变化。进一步说，商业层可以用来提供多客户和多目的服务。例如，存在于此层中的商业逻辑不仅可以处理来自电子商务站点的定单，将来还能处理来自电话定货系统的定单。 数据层（Data Layer）：数据层是用来捕获和提供系统所需要的数据的逻辑层。数据层与别的层是独立的，也不需要依赖其他层的存在。将来如果用来实现本层的技术有改变，不会使前面那些层有什么大的改动（如果有改动的话）。 早些时候我们说过，这些层是从逻辑意义上考虑的。在实际操作的时候，我们可以把不同的层并入到同一个硬件之中。事实上，有一些层被合并在一起以提供更好的响应和可伸缩性。 物理结构（Physical Architecture） 我们设计Baus Coffee的结构的目标是开发一个很容易扩展的系统。因此，我们决定采用如下的结构： 表现服务器（Presentation Servers） 表现服务器将逻辑上的表现和商业两层集成到一个物理系统中。服务器运行Windows NT Server 4.0以及Internet Information Server、Site Server、Microsoft Transaction Server/Microsoft Message Queueing和轻权目录协议成员目录（Lightweight Directory Access Protocol，LDAP）。该表现服务器将通过100-MB以太网同Microsoft SQL Server 6.5数据库相连。 为了提供均衡装载，表现服务器还将和Microsoft Windows Load Balancing Server相连。这使得在一个"农场"中可以有多台表现服务器。该"农场"由两个WLBS服务器以及多个表现服务器和两个热点交换服务器组成。系统的扩展可以通过增加表现服务器以及／或者增加网络带宽来实现。 每一个表现服务器将包括商业组件（封装了来自商业层的逻辑）、目录、Web页面所需要的图片。 数据服务器（Data Servers） 数据服务器将为电子商务站点提供数据并且捕获来自电子商务站点的数据。这些服务器将运行SQL Server 6.5。数据服务器将使用MSCS集群。数据服务器不是Web"农场"的一部分。虽然数据服务器也连在同一个网络上，但该机器是一个独立的，大功率的机器。 内容段服务器（Content Staging Server） 这种服务器使得内容可以被分成几段并且QA可以在它发布之前进行检查。建议只有市场和那些必须更新、编辑以及创建Web目录的小组可以获得访问该服务器的权限。产品小组可以在任何时候把它拷贝到产品系统中去。这样，QA过程就可以被流程化，也就不会阻碍商业要求了。 热点交换服务器（Hot Swap Servers） 热点交换服务器是一台可以在有机器失败时代替该机器的服务器。我们推荐两种热点交换服务器--dbHotSwap和presHotSwap，dbHotSwap可以接替崩溃或者离线的数据服务器。DbHotSwap既可以是在线数据服务器的一个复制客户，也可以通过使用磁带恢复系统来生成。PresHotSwap是表现服务器的镜象。只要表现服务器发生了更新或者改变，presHotSwap也必须进行同样的改变。 管理控制台工作站（Management Console Workstation） 管理控制台是一个Windows NT工作站，在控制台上可以对电子商务站点的一部分进行管理以及与其相互作用。例如，可以用Management Console Workstation (MCW)来获取表现服务器的性能统计或者使用SQL Server 6.5企业管理（Enterprise Manager）来在数据服务器上运行DBCC。 搜索服务器（Search Server） 查询服务器将管理查询请求。服务器将为目录和信息建立索引并且自动维护该索引。我们设想使用多个查询服务器来满足预计的站点要求。 Membership Server成员资格服务器 成员资格服务器将会维持一个SQL-Server 6.5数据库，该数据库充当所有成员信息的中心仓库。服务器将和其他服务器组成一个集群以提供较高的容错能力和冗余。 图一，Baus Coffee网络布局 网络简述 图一提供了Baus Coffee网络设计的一个图形表示。系统将有两个WLBS服务器以满足容错的要求。系统基于运行在100MB以太网上的专门的Windows NT域。网络结构的细节将通过计划会议加以明确，将遵循功能要求的管理方法。计划该站点是基于高速和高冗余的物理网络。数据服务器将采用集群技术。我们还要求每一台服务器都采用双网卡设计以提供容错能力，并且要采用RAID 5 SCSI驱动。我们强烈建议采用简单网络管理协议（Simple Network Management Protocol，SNMP）以有助于全面的网络管理，同时也有利于得到微软产品对SNMP的本地支持。 Baus将承担一项完整的灾难恢复计划的调查和展开。这还包括一个地理上远离你的主要站点的安全场所，使你的站点不会受到自然灾害的影响。 可伸缩性和安全性 可伸缩性是通过在网络上增加服务器和增加带宽来实现的。设计的中心思想是使扩展整个系统的消耗最小。我们的方法是开发一个基于CD的定制安装程序，这使得操作小组在需要配置新的服务器时只需要运行CD上的安装程序就可以了。CD将会安装系统需要的全部组件。 例如，如果要在网络上增加另外一台表现服务器，产品小组可以运行"PS-Setup"CD，该CD将安装IIS、 MTS、 MSMQ、 Site Server和所有的电子商务组件以及应用程序。同时将从分段 服务器上复制目录。以后开发的电子商务平台的版本将产生升级CD，将使升级站点的操作变得简单快捷。 所有的事务都将通过安全的HTTP。如果需要的话，该结构在将来还可以支持安全电子转账（SET）。Baus还计划采用X.509认证，这就需要再增加一台认证服务器，商业对商业（business-to-business ，B2B）的电子商务操作需要该服务器的支持。 主干（Legacy）集成 该体系将使用COM组件和一台主干（Legacy）网关服务器来把数据复制到相关的后台服务器上。 商业到商业的支持 为了满足商业到商业的需要，例如电子数据交换（Electronic Data-Interchange，EDI），价值链initiatives（VCI），以及其他的传统的initiatives，系统将支持商业交换管道，这是Site Server商业版的一个组成部分。如果需要支持EDI，Baus将采用第三方的组件。 结论 我提供的行动方案将给你自己的行动方案提供一个起动。Baus Coffee案例分析说明了如何处理一个大型电子商务站点的设计中的核心问题。检查你的资源，你可能会有不同的想法，毕竟每一个电子商务站点的设计计划都有其独特的需要，应该根据你同消费者之间做生意的方式来设计你的站点。休息一下，然后我们将转入系列的下一部分，这部分将集中讨论开发，优化和调整等问题。 关于作者 John Gomez是MCS/New Jersey的管理顾问，在分布式系统、电子商务以及智能代理方面有着丰富的经验。空闲的时候，他喜欢和孩子们讨论沙滩排球的复杂性。