|
你已经看到，关于安全性有很多要考虑的事情，这些考虑将明显的影响设计工作。我们必须明白我们想要达到哪种安全性级别，我们所用的不同系统的安全性级别以及它们如何影响我们的要求。我建议你从安全性开始你的项目设计，并且在设计系统中的其他部分之前完成这项工作。当你的计划向前推进时，这将会提供一个你可以返回的基础，并且你可以决定在你的安全构架中是否需要其他的系统服务和系统特性。项目管理者联盟
服务器选择项目管理者联盟
一旦你理解了核心设计，也处理完了你的规格，并且对安全性问题也有一个良好的认识，你就需要开始认真考虑要用来运行产品的工具了。这可以归结为一个基本问题：;我究竟需要多少台服务器？;这儿没有唯一的答案，如果我告诉你做决定所需要的知识对你更好一些。项目管理者联盟
如何计划你的服务器关系到你对规格的理解有多深刻。你理解得越深，准确预见你的需要的机会就越大。这儿有一些基本的提示，它们可以帮助你更好的开始：开发用户原型：这将使你能弄清楚Web站点的用户在什么地方消耗他们的时间。如果你的用户在进行高级搜索上花去了80%的时间，你也许会愿意把这项功能转移到一台单独的服务器上。没有用户行为的精确数据，你是不可能在诸如此类的事情上做出决定的。配置独立的数据库和Web硬件：甚至在最小的环境里，你也应该认真考虑把你的数据库和Web系统放置在不同的服务器上。Web服务器和数据库服务器，这二者要发挥最佳性能，需要做不同的调整，而其中的差异是非常巨大的。当你调好了一个，却会造成另一个的性能问题。同时，在数据库上，备份操作的负担通常只有在一台独立的服务器才能很好的解决。把资源密集型的应用转移到独立服务器上：那些会造成密集的系统请求的操作应该转移到别的服务器上去。批处理、为目录编制索引、直接邮件操作，以及Web日志分析，这些都是应该仔细考虑是否要用专门的服务器来处理的内容。blog.mypm.net
可恢复性（Recoverability）项目管理者联盟
我们经常这样来考虑可恢复性，即在发生系统崩溃或者其他灾难的时候，我们怎样恢复系统。更常见的情况下，是指如何恢复系统服务。虽然这样说已经基本上够了，我们还是需要想得更广泛一点，应该把事务恢复也包括进去。项目管理者联盟
事务恢复是指把现在的系统状态恢复到前一个事务状态（耶！你在讲天书啊？）。让我们试试是否能把它变得更容易理解。电子商务系统的目的，就最基本和最原始的意义上来讲，是让我们可以买到东西。要达到这个目的，我们必须采取一种;要么全有，要么全无的态度。也就是说，我们要么开展完整的交易，要么一点也不要做。为了方便，我们需要假设系统已经通过了ACID测试，我们在本系列的第二部分要讨论这种测试。项目管理者联盟
现在，我们只要相信我们已经有一种恢复事务的方法就行了。如果我们使用站点服务器商业版（SiteServer,CommerceEdition）带有的定单处理管道（OrderProcessingPipeline），我们就有一种简单而完整的办法来取消我们所做的改变或者确保改变已经生效。在我们需要和诸如CICS以及Oracle数据库这样的主干（Legacy）系统互动的时候，还需要提供对分布式事务的支持。使用MicrosoftTransactionServer就能满足这个要求。项目管理培训
如果我们所要做的全部工作就是事务恢复，那就太好了，但是我们仍然要明白在发生系统崩溃、数据库崩溃或者类似的问题时如何恢复我们的平台。下面列出了我们将在电子商务系统中遇到的一些问题：分布式恢复：多数电子商务系统是建筑在多层结构上的，这个结构包括表现层、商业层以及数据层。每一层都和不同的主干（Legacy）系统相互作用，并且需要有不同的恢复策略。项目管理者联盟
庞大的数据集合：视你的系统而言，你需要维护的数据库的规模从GB（230）到TB（240）不等。备份和重新装载这样的系统需要高速解决方案。请确认你已经参考过你的规格，知道有多少数据需要存储，以及这些数据是否必须总是处在能被访问的状态。如果需要数据来做商业报告，你也许愿意把这些信息转移到一台可以用来做分析的服务器上。这不仅将减少你的备份和重载时间，还将提高系统的性能。你还需要考虑巨大的数据集合对索引修复、DBCC操作以及维护工作的影响。MicrosoftSQLServer?7.0在这些领域提供了巨大的性能改善，你也许可以把它作为你的设计的一部分。项目管理者联盟
不间断的操作：提供一个能确保7x24操作的设计方案是一个很普通的要求。我发现这个要求的真正含义是你要能够处理那些妨碍实现真正的7x24操作的事情。稍后，我们将讨论如何使用MicrosoftMessageQueue(MSMQ)进行异步设计以使你能以最佳费效比来提供这项服务。项目管理者联盟
正如你看到的，事务和平台的恢复工作是一件很严肃的事情。每一项都将对你如何编写你的系统造成影响。你必须在转到开发阶段以前解决这个问题，因为这是你走向成功的关键。PgMp.mypm.net
关于性能项目管理者联盟
更大、更快、更强！这好像是今天各处的电子商务站点的;战争;口号。为数十万的用户服务、处理事务，以及增加商业收益的能力是任何电子平台成功的关键所在。在这一部分，我们的目标是了解如何设计一个能提供高性能、高可靠性以及高可伸缩性的系统。pmp.mypm.net
均衡装载和可伸缩性项目管理者联盟
在我讲演的时候，我经常向听众提问，我问他们，有多少人设计过一个可以同时支持几百个用户的高性能、满负荷、具有容错能力的系统。在平均大约５００个听众中，有２００只手举了起来。然后我问有多少人设计过一个类似的系统但是能同时支持１０００个用户呢？这回只有不到１００个人举手。最后，我问有多少人能设计一个可以同时支持１００００个或更多用户的系统时，一般都没有人举手。本节的内容将帮助你将来成为少数几个在我问到这个问题时能举起他们的手的听众中的一个。项目管理者联盟
虽然我也可以把均衡装载和可伸缩性分成两个独立的题目，但是我还是更愿意把它们作为一个整体来处理。因为这两个问题实质上是同一个问题：状态的维持。简而言之，维持状态与保持一致是一个意思。当我们维持状态时，我们就是有状态的，反之，我们就没有状态。如果在用户的每一个动作中间，你能记住他是谁以及他在做什么，你就是在维持状态。又比如，假设我登录到你的系统上，每一次我查询购物篮，你都可以把它显示给我而不需要采用cookie以及其他的客户端标志。你知道我的;用户代号;以及;购物篮代号;。这是因为你使用了Web服务器资源来跟踪我在做什么，我是谁，我去你站点上什么地方。维持状态受到我们的可伸缩性和均衡装载的限制。项目管理者联盟
均衡装载是通过循环DNS（域名解析），Cisco本地目录（CiscoLocalDirectors，属于硬件解决方案），或者是最近我特别推崇的，MicrosoftWindowsLoadBalancingServer等方案实现的。这些解决方案把客户端请求引导到被称之为;农场;的最小繁忙（least-busy）服务器上。一个Web;农场;主要是指一系列提供不同服务的服务器。例如，我可以有三个独立的Web服务器，使用上边介绍的其中一种解决方案，把客户装载分布在这三台服务器上。从理论上讲，如果每一台服务器能同时处理１００个客户的话，那么由三台服务器组成的Web;农场;就能同时处理３００个客户。这样做的好处是对客户端来说，他们看到的都是同一个IP地址或者域名。项目管理者联盟
如果客户A的第一个请求经由路由器后到了Web服务器１上，而第二个请求却到了Web服务器２上，这样会发生什么情况呢？在一个状态化的环境中，这将会是一个麻烦。如果我们第一次连接到Web服务器上，那么我们需要总是返回到Web服务器１上，因为我们是在这台服务器上建立了我们的状态或者说是身份。在一个典型的Web;农场;中，服务器之间是没有通信的，因此只有在你第一次连接到这台服务器上以后，它才能知道你是谁。设想一个客户在每一次点击一个超链接时都被要求登录一次，仅仅是因为她被导向了一个不同的Web服务器。最低限度说来，这也是会让人感到沮丧的。项目管理者联盟
均衡装载一般通过下面这种方式来解决这个问题，它实现一个路由表，该表追踪客户的IP地址并且总是把客户导向同一台服务器，除非客户断开连接或者该会话到期。这样做的结果是你必须维持状态并且要利用珍贵的服务器资源。针对大流量的站点有一种更好的方式，这种方法是和MicrosoftSiteServerP;M捆绑在一起的，并且是一种无状态的方式。在我们详细讨论这个方案之前，首先让我们把注意力转到另一个领域--可伸缩性上来。项目管理者联盟
我们已经确信，在Web服务器上维持状态将导致资源的占用，这将限制我们扩大规模的能力并且会降低整体性能。但是状态化的设计可能对平台上别的领域有利。假设每次我们想要查看某种产品，我们都要和一个同后台数据库对话的COM组件相互作用，当我们第一次使用该组件时，我们传递一个用户代号给它。以后每一次当我们想知道某种产品的信息的时候，我们就传递一个产品代号。依靠产品代号和早些时候我们传递的用户代号，系统就能提供我们一个包含定制价格的产品信息。说得更明白些，就是我们连接到该组件时同时建立了一个到数据库的连接。从理论上说，这样做比每次和该组件互动都建立该连接要节省一些时间。这象是个好主意，不是吗？好的，让我们回到那个伤脑筋的问题上：如果有１０，０００个用户同时连接会有什么事情发生呢？利用前面这种思路来解决问题，我们就需要维持１０，０００个COM组件和１０，０００个数据库连接。那么当规模扩大到１００，０００或者２００，０００甚至１，０００，０００个用户呢？显然这不是一个好的设计，就因为它是状态化的。更好一些的方案是使用无状态的组件和连接池（connectionpooling）。这样做并不难，而回报是巨大的。如果我们修改COM组件使得每次传递产品代号的同时也传递用户代号，这样做也能返回一个包含定制价格的产品信息。不同之处在于，一旦我们完成了任务，我们可以立即释放组件和数据库连接，因此也就释放了先前的系统资源。与管理连接和设计一个实现连接池的构架相比，更好的方式是在MTS中保存组件并且利用JIT（Just-in-time，即时激活）的优越性以及连接池。这个小小的改进将使我们很容易就把规模扩大到超过１０，０００个同步用户。bbs.mypm.net
如果我们现在回到均衡装载的情况，为Web;农场;提供状态无关性，我们也可以从同样的方式中获益。我们可以使用客户端cookie，HTML表单，或者将用户代号作为URL字串的一部分来传递。我们现在可以实现均衡装载机制了，方法就是将请求引导到Web;农场;里任何一台可用的服务器上。在设计和开发中使用这些技术可以给你提供超乎想象的可伸缩性。但是最终你还需要更为灵活的和可伸缩的设计，这样你才能利用每一点系统资源。项目管理者联盟
容错能力和可靠性（FaultToleranceandReliability）
在设计阶段的会话过程中，我经常耍这样一个小小的花招，我问：;这个系统是不是一定要7x24？;回答总是;是的。;然后我问：;我们是否需要和主机或者主干（Legacy）系统打交道？;答案当然还是;是的。;接下来我又问（这就是奥妙之所在了）;你的后台系统是否需要关机来进行维护呢？;通常我总是得到我想要的答案;每个星期六晚上;这时候我就会问;那么我们怎么能实现7x24呢？你的主机关机了，而我们又要靠它才能进行服务？;一般情况下，答案总是一片沉默。项目管理者联盟
对于这个佯谬，答案是使用异步设计。你的目标是希望在公司的主机被关闭以进行维护的时候能接受定单，而不是关闭系统。为了实现这个目的，你需要在设计中使用MSMQ。项目管理者联盟
把对异步的支持包含在设计中，就可以接受定单并且把定单代号发送到一个MSMQ队列中去。一旦后台系统又重新回到线上，系统就可以扫描这个队列取出定单代号并且继续处理它们。你只需要做一点点工作，就可以通过这项服务在你的商业层次上提供更高的智能。例如，如果后台系统在线上，你可以把定单请求直接传递给它并且立即将确认信息返回给顾客。如果它不在线上，你可以把定单发送到队列中去，并且通知用户对他的定单的确认将在一个钟头之内发给他。在任何情况下，你都要给你的用户提供一种可以追踪定单处理进程的方式。使用异步设计能够提供一个高度可靠的系统，并且可以降低总拥有成本（totalcostofownership，TCO），但是我们仍然需要处理那些传统的容错和可靠性方面的事务。我们已经在不知不觉中解决了一些这样的问题。项目经理博客
|
