博客园-江大鱼(江振宇)的BLOG

[转]大规模服务设计部署经验谈(中)

江大鱼 — Thu, 14 Aug 2008 09:51:00 GMT

转自程序员杂志2008/07

依赖管理
    在大规模服务中，依赖管理这个话题通常得不到应有的关注。一般的准则是，对于小型组件和服务的依赖关系，对于判断管理它们的复杂性来说，并不足以节约成本。在以下情况中，依赖关系存在重要意义：
    1．被依赖的组件在大小和复杂度上有重要价值；
    2．被依赖的服务在作为单一的中央实例时存在价值。
    第一类的例子有存储和一致性算法(consensus algorithm)的实现。第二类的例子包括身份和群组管理系统。这些系统的整体价值在于它们是一个单一且共享的实力，因此使用多实例来避免依赖关系就不是可选方案。
    假定要根据上面的标准判断依赖关系，那么用来管理它们的最佳实践有：
    ◆为延迟做好准备。对外部组件的调用可能需要很长时间才能完成。不要让一个组件或者服务中的延迟在完全不相关的领域中引发延迟；确保所有的交互都存在长度合适的超时时长，避免资源阻塞更长的时间。运营等幂性允许请求在超时后重启，即便这些请求可能已经部分或完全完成。确保所有的重启操作都得到报告，并给重启操作设定界限，从而避免反复故障的请求消耗更多的系统资源。
    ◆隔离故障。网站的架构必须能防止层叠的故障，要总是“快速失败(fail fast)”。当依赖服务出现故障时，把这些服务标注为停机，并停止使用这些服务，以避免线程因等待故障组件而阻塞。

◆使用已经交付的历经考验的组件。历经考验的技术通常总是要比大胆前卫地走在潮流尖端运行要好很多。稳定的软件要优于新版本的早期，不管新特性如何有价值。这条原则也适用于硬件。批量生产的稳定硬件，往往要比从早期发布的硬件所获得的些许性能提升要有价值得多。
◆实现跨服务的监控和警报。如果服务中有一个附属服务过载，那么被依赖的服务就必须了解这个情况，并且如果服务无法自动备份，那么必须发送警报。如果运营部门无法快速地解决这个问题，那么服务就得设计得能容易迅速地联系到两个团队的工程师。所有相关的团队都应当在附属团队中安排工程联络人。

    ◆附属服务需要同一个设计点。附属的服务和附属组件的生产者至少必须遵循与所属服务相同的SLA(服务水平协议)。
    ◆对组件解耦。在所有可能的地方保证在其他组件故障时，组件可以继续运行，可能在一个降级的模式中。例如，比起在每一个连接上重新验证，维护一个 Session键值，并且无论连接状况如何，每过N小时就刷新这个键值会更好些。在重新建立连接时，只使用现有的Session键值。这样的话在验证服务器上的负载就会更加一致，而且也不会在临时网络故障和相关事件之后的重新连接过程中出现登录高峰期的情况。
发布周期及测试
    在生产环境中进行测试是一件很现实的事情，必须成为所有internet级服务所必须的质量保证方式之一。在尽可能(可以掏得起钱)的情况下，绝大多数服务都应当有至少一个与生产环境相似的测试实验室，并且所有优秀的工程师团队应当使用生产级的负载，以反映现实的方式测试服务器。不过，我们的经验是，这些测试实验
室即便模拟得再好，也绝不可能百分之百的逼真；它们至少总是会在一些细微的方式上和生产环境有所差别。由于这些实验室在真实性上接近生产系统，因此相应的费用也呈渐进趋势，快速逼近生产系统的开支。
    与此不同，我们推荐让新的服务发布版本顺着标准单元测试、功能测试和生产测试实验室测试一路走下来，一直进入受限的生产环境作为最后的测试阶段。显然，我们不想让无法正常工作并给数据一致性带来风险的软件进入生产环境，因此这就不得不小心翼翼地实施。下面的原则一定要遵守：
    1．生产系统必须有足够的冗余，以保证在灾难性的新服务故障发生时，能够快速地恢复到原来的状态；
    2．必须让数据损坏或者状态相关的故障极难发生(一定要首先通过功能测试)；
    3．故障一定要能检测得到，并且开发团队(而不是运营团队)必须监控受测代码的系统健康度；
    4．必须可以实现对所有变更的回滚操作，并且回滚必须在进入生产环境之前经过测试。
    这听起来有点让人心惊胆战。不过我们发现，使用这个技术实际上能够在新服务发布时提升客户体验。与尽可能快地进行部署的做法不同，我们在一个数据中心中将一个系统放到生产环境数天。随后在每个数据中心内把新系统引入生产环境。接着，我们会将整个数据中心带入生产环境。最后，如果达到了质量和性能的目标，
我们就进行全局部署。这种方式可以在服务面临风险之前发现问题，事实上还可以通过版本过渡提供更优秀的客户体验。一锤定音的部署是非常危险的。
    我们青睐的另一种可能违反直觉的方式是，在每天正午而不是半夜部署。在晚上部署，出现错误的风险更高，而且在半夜部署时如果有异常情况突然发生，那么能处理这些问题的工程师肯定会少些。这样做的目标是为了使开发和运营团队与整体系统的互动最小化，尤其在普通的工作日之外，使得费用得到削减的同时，质量
得到提高。

    对于发布周期和测试的最佳实践包括：
    ◆经常性地交付。直觉上讲，人们会认为更频繁地交付难度要更大，而且会错误频出。然而我们发现，频繁的交付中突兀的变更数量很少，从而使得发布的质量变得更高，并且客户体验更棒。对一次良好的发布所进行的酸性测试，用户提供可能会有所变化，但是关于可用性和延迟的运营问题的数量应当在发布周期中不受改
变。我们会喜欢三个月一次的交付，但也可以有支持其他时长的论调。我们从心底认为，标准最终会比三个月更少，并且有许多服务已经是按周交付的了。比三个月更长的周期是很危险的。
    ◆使用生产数据来发现问题。在大规模系统中的质量保证，是个数据挖掘和可视化的问题，而不是一个测试问题。每个人都必须专注于从生产环境的海量数据中获得尽可能多的信息。这方面的策略有：
    ◇可度量的发布标准。定义出符合预期用户体验的具体标准，并且对其进行持续监控。如果可用性应当为99％，那么衡量可用性是否达到目标。如果没有达到，发出警报并且进行诊断。
    ◇实时对目标进行调优。不要停顿下来考虑到底目标应当是99％、99．9％还是任何其他目标，设定一个可以接受的目标，然后随着系统在生产环境中稳定性的建立，让目标渐进式地增长。
    ◇一直收集实际数据。收集实际的度量，而不是那些红红绿绿的或者其他的报表。总结报表和图像很有用，不过还是需要原始数据用来诊断。
    ◇最小化“假阳性(faIse positive)”现象。在数据不正确时，人们很快就不再关注它们。不要过度警报，真是很重要的，否则运营人员会慢慢习惯于忽略这些警报。这非常重要，以至于把真正的问题隐藏成间接损害常常是可以接受的。
    ◇分析趋势。这个可以用来预测问题。例如，当系统中数据移动的速度有异于往常的时候，常常能够预测出更大的问题。这时就要研究可用的数据。
    ◇使系统健康程度保持高度透明。要求整个组织必须有一个全局可用且实时显示的系统健康报告。在内部安置一个网站，让大家可以在任意时间查看并了解当前服务的状态。
    ◇持续监控。值得一提的是，人们必须每天查看所有数据。每个人都应当这么做，不过可以把这项工作明确给团队的一部分人专职去做。
◆在设计开发上加大投入。良好的设计开发可以使运营需求降到最小，还能在问题变成实际运营矛盾之前解决它们。非常常见的一个现象就是组织不断给运营
部门增加投入，处理伸缩问题，却从没花时间设计一套可伸缩的可靠架构。如果服务一开始没有进行过宏伟的构思，那么以后就得手忙脚乱地追赶了。
    ◆支持版本回滚。版本回滚是强制的，而且必须在发布之前进行测试和验证。如果没有回滚，那么任何形式的产品级测试都会存在非常高的风险。回复到先前的版本应该是一个可以在任意部署过程中随时打开的降落伞扣。
    ◆保持前后版本的兼容性。这一点也是至关紧要的，而且也前面一点关系也非常密切。在组件之间更改文件类型、接口、日志／调试、检测 (instrumentation)、监控和联系点，都是潜在的风险来源。除非今后没有机会回滚到之前的老版本的可能，否则不要放弃对于老版本文件的支持。
    ◆单服务器部署。这既是测试的需求也是开发的需求，整个服务必须很容易被托管到单一的系统中。在对于某些组件单服务器无法实现的地方(比如说一个对于外部、非单箱的可部署服务)，编写模拟器来使单服务器测试成为可能。没有这个的话，单元测试会的难度会很大，而且不会完全覆盖到实际条件。而且，如果运行完整
的系统很困难的话，开发人员会倾向于接受从组件的角度看问题，而不是从系统的角度。
    ◆针对负载进行压力测试。使用两倍(或者更多倍的)负载来运行生产系统的某些小部分，以确保系统在高于预期负载情况下的行为得到了解，同时也确保系统不会随着负载的增加而瓦解。
    ◆在新发布版本之前进行功能和性能测试。在服务的级别上这么做，并针对每个组件这么做，因为工作负载的特征会一直改变。系统内部的问题和降级现象必须在早期捕获。
    ◆表象性且迭代地进行构建和部署。在开发周期中早早地把完整服务的骨架先搭建起来。这个完整服务可能几乎做不了什么，也可能在某些地方出现偏差，但是它可以允许测试人员和开发人员更有效率，而且也能让整个团队在一开始就从用户的角度进行思考。在构建任何一个软件系统时，这都是一个好方法。不对，对于服务
来说这尤为重要。
    ◆使用真实数据测试。将用户请求和工作量从生产到测试环境分门别类。选择生产数据并把它放到测试环境中。产品形形色色的用户，在发现bug的时候总是显得创意无穷。显然，隐私承诺必须保持，使得这样的数据永远不会泄漏回到产品环境中，这是至关紧要的。
    ◆运行系统级的验收测试。在本地运行的测试提供可以加速迭代开发的健康测试。要避免大量维护费用，这些测试应当放在系统级别。
    ◆在完全环境中做测试和开发。把硬件放在一边，在专注的范围内测试。作重要的是，使用和在这些环境中的生产条件下同样的数据集合和挖掘技术，以保证投资的最大化。●

[新闻]消息称MySQL创始人已向Sun提交辞呈

[转]大规模服务设计部署经验谈(上)

江大鱼 — Thu, 14 Aug 2008 09:47:00 GMT

转自程序员杂志2008/05

引言
本文就设计和开发运营友好的服务的话题进行总结，得出一系列最佳实践。设计和部署大规模服务是一个高速发展的领域，因而随着时间的流逝，任何最佳实践集合都可能成熟并完善。我们的目的是为了帮助人们：

   ◆快速交付运营友好的服务；
    ◆避免清早电话铃声的骚扰，帮助备受运营不友好的服务侵扰的客户尽量摆脱窘境。
   这篇论文是我们在过去的20年中在大规模以数据为中心的软件系统和互联网级大规模服务的智慧结晶，包括Exchagnge Hosted Services团队、Microsoft GIobal Foundation Services Operations团队以及Windows Live!平台多个团队的经验。这些贡献经验的服务中，有不少规模已经增长到拥有超过二亿五千万名用户。同时，本论文也大量吸取了加州大学伯克利分校在面向恢复计算(Recovery Oriented Computing)方面取得的成果和斯坦福大学在只崩溃软件(Crash一Only Software)方面的研究经验。 Bill Hofffman为本论文贡献许多最佳实践。此外，他还提出三条简单原则，值得大家在进入正题之前进行考量：
1．做好发生故障的心理准备。
2．保持简单化。
3．将所有的工作自动化。

这三条原则形成了贯穿后续讨论的主轴。
本文的十个小节涵盖了设计和部署运营友好服务所必须做到的各个方面。它们是：整体服务设计；以自动化和预置(Provisioning)为目标进行设计；依赖关系管理；发布周期及测试；硬件的选择和标准化；运营和容量规划；审核、监控和警报；体面降级和管理控制；客户及媒体沟通计划；以及客户自我预置和自我帮助。

整体服务设计
一直以来，人们都相信80％的运营问题源于设计和开发，因此本节关于整体服务设计的内容篇幅最长，也最重要。系统出故障时，人们很自然倾向于首先去审视运营工作，因为这是问题实际产生的地方。不过，绝大多数运营问题都可以归因于设计和开发，或者最适合在设计和开发中解决。

随后的内容凸显一个共识，即在服务领域，将开发、测试和运营严格分离不是最有效的方式。在环顾众多服务之后，我们发现了这样一个趋势——管理的低成本与开发、测试和运营团队间协作的紧密程度密切相关。

除了在这里讨论的服务设计最佳实践以外，随后一节“以自动化管理和预置为目标进行设计”对服务设计也有实质性的影响。有效的自动化管理和预置通常以一个受限的服务模型来实现。简单是高效率运营的关键，这是贯穿本文重复出现的主题。在硬件选择、服务设计和部署模型上的理性约束，是降低管理成本和提高服务
可靠性的强心针。

    在运营友好的基础原则中，为整体服务设计带来最大影响的几条包括：
    ◆设计时为故障做好准备(Design for failure)。在开发包含多个协同运作的组件的大型服务时，这是一条核心概念。这些组件会有故障发生，而且故障的产生很频繁。它们之间不会总是稳定地协作，也不会单独出现故障。一旦服务的规模达到1 0，000台以上的服务器和50，000块以上的磁盘，每天就会有多次故障发生。
如果一有硬件故障产生就得采取紧急措施来应对，那么服务就无法以合理的成本可靠地伸缩。整个服务必须有承受故障而无须人工干预的能力。故障恢复的步骤必须非常简单，而且这些步骤应当进行频繁测试。斯坦福大学的Armando Fox主张说，对故障恢复步骤进行测试的最佳方法，就是绝对不要用正常方式使服务停机，用粗暴的方式让它停转就可以了。乍听起来怎么做是违背直觉的，但是如果没有频繁使用故障步骤，那么它们在真正临阵时就可能溃不成军。
    ◆冗余和错误恢复(Redundaricy and fault recovery)。大型机模型是指购买一台价高块头大的服务器。大型机拥有冗余的电源供应，CPU可以热交换，而且总线架构也超平寻常，使得这样一个紧密耦合的系统能够有可观的I／O吞吐量。这样的系统，最明显的问题就是它们的成本；而且即便有了所有这些费用高昂的设计，它们仍然不够可靠。为了达到 99．999％的可靠性，冗余是必须存在的。实际上，在一台机器上实现4个9的可靠性都是相当困难的。这个概念在整个业界都耳熟能详，不过，将服务构建在脆弱而又非冗余的数据层之上的现象，到目前为止都屡见不鲜。
    要保证设计的服务其中的任何系统可以随时崩溃(或者因为服务原因被停止)但又仍然能符合服务水平协定(Service Level Agreement，简称SLA)，是需要非常仔细的设计的。保证完全遵守这项设计原则的严格测试(acid test)步骤如下：首先，运营团队是否有意愿并且有能力随时让任意一台服务器停机并且不会让负载
被榨干?如果答案是确定的，那么肯定存在同步冗余(无数据丢失)、故障侦测和自动接管。我们推荐一条普遍使用的设计方法，用于查找和纠正潜在的服务安全问题：安全威胁建模(Security Threat Modeling)。在安全威胁建模中，我们要考虑每一条潜在的安全威胁，并且相应实现恰当的缓和方案。同样的方法也适用于以错误
适应和恢复为目标的设计。
    将所有可以想象到的组件故障模式及其相应组合用文档记录下来。要保证服务在每个故障发生后都能继续运行，且不会在服务质量上出现不可接受的损失；或者判断这样的故障风险对于这样一个特定的服务是否可以接受(例如，在非地理冗余的服务中损失掉整个数据中心)。我们可能会认定某些非常罕见的故障组合出现的可能性微乎其微，从而得出确保系统在发生这种故障之后还能继续运行并不经济的结论。但是，在做这样的决定时请谨慎从事。在运行数以千计的服务器的情况下，每天都会有几百万种组件故障产生的可能，这时那些事件的“罕见”组合亮相的频繁程度，足以让我们瞠目结舌。小概率组合可能变成普遍现象。
    ◆廉价硬件切片(Commodity hardware slice)。服务的所有组件都应当以廉价硬件切片为目标。例如，存储量轻的服务器可以是双插槽的2至4核的系统，带有启动磁盘，价格在1，000至 2，500美元之间；存储量大的服务器则可以是带有1 6至24个磁盘的
类似服务器。主要的观察结果如下：
    ▲大型的廉价服务器集群要比它们替代的少数大型服务器便宜得多；
    ▲服务器性能的增长速度依然要比I／0性能的增长速度快很多，这样一来，对于给定容量的磁盘，小型的服务器就成为了更为稳定的系统；
    ▲电量损耗根据服务器的数量呈线性变化，但随系统时钟频率按立方级别变化，这样一来性能越高的机器运营成本也越高；
    ▲小型的服务器在故障转移(Fail over)时只影响整体服务工作负荷的一小部分。
    ◆单版本软件(Single—version software)。使某些服务比多数打包产品开发费用更低且发展速度更快的两个因素是：
    ▲软件只需针对一次性的内部部署。
    ▲先前的版本无须得到十年的支持——针对企业的产品正是如此。
    相对而言，单版本软件更容易实现，附带客户服务，特别是无须费用的客户服务。但是在向非客户人员销售以订阅为基础的服务时，单版本软件也是同样重要的。企业通常习惯在面对他们的软件提供商时拥有重要的影响力，并且在部署新版本时(通常是个缓慢的过程)，他们会习惯性想去掌握全部的控制权。这样做会导致他
们的运营成本和支持成本急剧上升，
因为软件有许多版本需要得到支持。
    最经济型的服务是不会把对客户运行的版本的控制权交给他们的，并且通常只提供一个版本。要把握好单一版本软件的产品线，必须：
    ▲注意在每次发布之间不要产生重大的用户体验变更。
    ▲愿意让需要相应级别控制能力的客户可以在内部托管，或者允许他们转向愿意提供这类人员密集型支持服务的应用服务提供商。
    ◆多重租赁(Multi-tenancy)。多重租赁是指在同一个服务中为该服务的所有公司或最终用户提供主机服务，且没有物理上的隔离；而单一租赁 (Single—tenancy)则是将不同组别的用户分离在一个隔离的集群中。主张多重租赁的理由基本上和主张单版本支持的理由一致，且它的基础论点在于提供从根本上成本更低、构建在自动化和大规模的基础之上的服务。
    回顾起来，上面我们所展示的基本设计原则和思考如下：
◆设计时为故障做好准备
◆实现冗余和错误恢复
◆依靠廉价硬件切片
◆支持单一版本软件
◆实现多重租赁
我们约束服务设计和运营的模型，以此最大化自动化的能力，并且减少服务的总体成本。在这些目标和应用服务提供商或IT外包商的目标之间，我们要划一道清楚的界限。应用服务提供商和IT外包商往往人员更加密集，并且更乐于运行面向客户的复杂配置。设计运营友好的服务更具体的最佳实践包括：
◆快速服务健康测试。这是构建验证测试的服务版本。这是一个嗅探型测试，可以快速在开发者的系统上运行，以保证服务不会以独立方式出错。要保证所有的边界条件都被测试到，是不可能的，但如果快速健康测试通过的话，那么代码就可以检入了。
◆在完整的环境中开发。开发人员不但应当对他们的组件进行单元测试，而且还要对出现组件变更的整个服务进行测试。要高效实现这个目标，必须得有单服务器的部署，以及前一条最佳实践——快速的服务健康测试。
◆对下层组件的零信任。设想下层组件会出现故障，并且确保组件会有能力恢复并继续提供服务。恢复的技巧和服务相关，但常见的技巧包括：
▲在只读模式中依靠缓存的数据继续运转；
▲在服务访问故障组件的冗余拷贝的短暂时间内，继续向用户群一小部分的所有人提供服务。
    ◆不要把同一个功能构建在多个组件中。预见未来的交互是～件极其困难的事情，如果不慎引入冗余的代码，那么将来就不得不在系统的多处做修复。服务的增长和发展是很快的，稍不留神代码的质量就会很快恶化。
    ◆不同的集群之间不能互相影响。大多数服务由小型集合或者系统的子集群组成，它们之间相互协作，共同提供服务，其中每个小型集合都可以相对独立地运作。每个小型集合应达到接近1 00％的独立程度，且不会有跨群的故障。全局服务，甚至包括冗余，是故障的中心点。有时候，这样的问题是不可避免的，但还是要设法保证每个集群都拥有各自所需的资源。
    ◆允许(少量)在紧急情况的人工干预。常见场景是在灾难性事件或者其他紧急情况下移动用户数据。把系统设计成完全无须人工交互，但也要清楚小概率事件可能会发生，其中组合的故障或者未预期的故障都会需要人工交互。这些事件是会发生的，而在这些情况下，操作员的错误往往是导致灾难性数据丢失的常见来源。一名在半夜2点顶压工作的运营工程师可能会犯错误。将系统设计成一开始在多数情况下无须运营干预，但请和运营团队协作制定在他们需要进行干预时的恢复计划。比起将这些计划写进文档，变成多步骤易出错的过程，更好的办法是把这些规则写成脚本，并在生产环境中进行测试，以确保它们正常工作。没有经过产品环境试验的代码是不可行的，因此运营团队应当定时指挥使用这些工具进行“防火演习”。如果演习的服务可用性风险非常高，那么可以认为之前在工具的设计、开发和测试上的投资不足。
    ◆保持一切简单健壮。复杂的算法和组件交互会给调试和部署带来成倍困难。简单到近乎傻瓜式的结构在大规模服务中几乎总是更胜一筹，因为在复杂的优化工作交付之前，交互中故障模式的数量早就足以磨灭人们的信心。通常我们的惯例是，能够带来一个数量级以上改善的优化工作才值得考虑，而只有百分之几或者甚至于只是低系数级别的提升，就不值得了。
    ◆全面推进准入控制。所有良好的系统会在设计时开门见山地引入许可控制，这样符合一条长期以来为人们所认可的原则，那就是避免将更多的工作引入一个已经过载的系统，要比持续接受工作然后开始翻来覆去地检查好一些。在服务入口引入某些形式的节流或者准入控制是很常见的做法，但在所有的主要组件边界上都应
该有准入控制。工作性质的变更最终会导致子组件的过载，即使整体服务仍然运行在可接受的负载级别。总体的惯例就是尝试采用优雅降级的方式，而不用在统一给所有用户低质量服务之前进行硬停机并阻断服务的入口。
    ◆给服务分区。分区应当可以无限调整，并且高度细粒度化，并且不受任何现实实体(人、集合等)的限制。如果按公司分区，那么对于大的公司，就有可能超过单个分区的规模；而如果按名称前缀进行分区，那么例如所有以P打头的最终一台服务器就可能会装不下。我们推荐在中间层使用一张查询表，将细粒度的实体，通常是用户，映射到其数据相应被管理的系统上。这些细粒度的分区随后就可以自由在服务器之间移动。
    ◆理解网络的设计。提早进行测试，了解机柜内的服务器之间、跨柜的服务器之间以及跨数据中心之间有哪些负载。应用程序开发人员必须理解网络的设计，且设计应当尽早交给来自运营团队的网络专员审核。
    ◆对吞吐量和延迟进行分析。应当对核心服务的用户交互进行吞吐量和延迟的分析，从而了解它们的影响。结合其他运营操作，比如定期数据库维护、运营配置(加入新用户，用户迁移)和服务调试等，进行吞吐量和延迟的分析。这样做对于捕捉由周期性管理任务所带动的问题是颇有裨益的。对于每个服务，都应当形成一个
度量标准，用于性能规划，比如每个系统的每秒用户访问数，每个系统的并发在线人数，或者某些将关联工作负载映射到资源需求的相关度量标准。
    ◆把运营的实用工具作为服务的一部分对待。由开发、测试、项目管理和运营所产生的运营实用工具应当交给开发团队进行代码审查，提交到主源码树上，用同一套进度表跟踪，进行同样的测试。最频繁出现的现象是，这样的实用工具对于任务有至关重要的影响，但几乎都没有经过测试。
    ◆理解访问模式。在规划新特性时，一定要记得考虑它们会给后端存储带来哪些负载。通常，服务模型和服务开发人员与存储抽象得非常开，以至于他们全然忘记了它们会给后端数据库带来的额外负载。对此的最佳实践把它作为规范建立起来，里面可以有这样的内容：“这项功能会给基础结构的其他部分带来什么样的影响?” 然后在这项特性上线之后，对它进行负载的测量和验证。
    ◆让所有工作版本化。做好在混合版本的环境中运行的准备。我们的目标是运行单版本的软件，但是多个版本可能会在首次展示和生产环境测试的过程中并存。所有组件的n版和n+1版都应当能够和平共存。

    ◆保持最新发布版的单元／功能测试。这些测试是验证n一1版本的功能是否被破坏的重要方法。我们推荐大家更进一步，定期在生产环境中运行服务验证(后面会详细介绍)。
    ◆避免单点故障。单点故障的产生会导致整个服务或者服务的某些部分停工。请选择无状态的实现。不要将请求或者客户端绑定在特定的服务器上，相反，将它们负载均衡在一组有能力处理这样负载的服务器上。静态哈希或者任何静态的服务器负载分配都会时不时遭受数据和／或查询倾斜问题的困扰。在一组机器可以互换时，要做到横向伸展是非常容易的。数据库通常会发生单点故障，而数据库伸缩仍然是互联网级大规模服务的设计中最为困难的事情之一。良好的设计一般会使用细粒度的分区，且不支持跨分区操作，以在多台数据库服务器之间进行高效伸展。所有的数据库状态都会进行冗余存储(至少在一台)完全冗余的热待机服务器上，并且在生产环境中会频繁进行故障转移测试。自动管理和预置
    许多服务编写的目的是为了在故障时向运营部门发出警报，以得到人工干预完成恢复。这种模式凸显出在24 x 7小时运营人员上的开支问题；更重要的是，如果运营工程师被要求在充满压力的情况下做出艰难的决定，那么有20％的可能他们会犯错误。这种模式的代价高昂，容易引入错误，而且还会降低服务的整体可靠性。
    然而，注重自动化的设计会引入明显的服务模型约束。比如说，当前某些大型服务依靠的数据库系统，会以异步方式复制到次级备份服务器，因为复制以异步方式完成，在主数据库无法服务请求后，故障转移到次级数据库会引起部分客户数据丢失。然而，不把故障转移到次级数据库，则会引起数据被储存在故障服务器上的
用户面临服务停工。在这种情况下，要自动化故障转移的决策就很困难了，因为这个决策依赖于人为判断，以及对数据损失量和停机大致时长相比的准确估计。注重自动化设计出的系统会在延迟和同步复制的吞吐量开销上付出代价。在做到这一步以后，故障转移变成了一个很简单的决策：如果主服务器宕机，将请求转到次服务器上。这种方式更适用于自动化，而且被认为更不容易产生错误。
    在设计和部署后将服务的管理过程自动化可能是一件相当具有难度的工作。成功的自动化必须保证简单性，以及清晰并易于确定的运营决策；这又要依靠对服务的谨慎设计，甚至在必要时以一定的延迟和吞吐量为代价作出牺牲，让自动化变得简单。通常这样的折中方案并不容易确定，但是对于大规模服务来说在管理方面的节约可能不止数量级。事实上，目前根据我们的观察，在人员成本方面，完全手动管理的服务和完全自动化的服务之间的差别足足有两个数量级。

    注重自动化的设计包含以下最佳实践：
    ◆可以重启动，并保持冗佘。所有的操作都必须可以重新启动，并且所有持久化状态也必须冗余存储。
    ◆支持地理分布。所有大规模服务都应当支持在多个托管数据中心运行。我们所描述的自动化和绝大多数功效在无地理分布的情况下仍是可行的。但缺乏对多服务中心部署方式的支持，会引起运营成本显著提升。没有了地理分布，很难使用一个数据中心的空闲容量来减缓另外一个数据中心所托管的服务的负载。缺乏地理分布是一项会导致成本提高的运营约束。
    ◆自动预置与安装。手动进行预置和安装是相当劳民伤财的，故障太多，而且微小的配置差异会慢慢在整个服务中蔓延开来，导致问题的确定越来越困难。
    ◆将配置和代码作为整体。请确保做到：
    ▲开发团队以整体单元的形式交付代码和口酉己置；
    ▲该单元经过测试部门的部署，并严格按照运营部门将会部署的方式；
    ▲运营部门也按照整体单元的方式部署。
    通常说，将配置和代码作为一整个单元处理并且只把它们放在一起修改的服务会更可靠。
    ◆如果配置必须在生产环境中变更，那么请保证所有的变更都要产生审核日志记录，这样什么东西被修改，在什么时候被谁修改，哪些服务器受到影响，就一目了然了。频繁扫描所有的服务器，确保它们当前的状态与预期状态相符。这样做对捕获安装和配置故障颇有裨益，而且能在早期侦测到服务器的错误配置，还能找到未
经审核的服务器配置变更。
    ◆管理服务器的角色或者性质，而不是服务器本身。每个系统的角色或性质都应当按需要支持尽可能多或少的服务器。
    ◆多系统故障是常见的。请做好多台主机同时发生故障的准备(电源、网络切换和首次上线)。遗憾的是，带有状态的服务必须得注意它们的拓扑分布。有相互联系的故障一直以来都是不可避免的。
    ◆在服务级别上进行恢复。在服务级别处理故障，相比软件底层来说，其中的服务执行上下文更加完整。例如，将冗余纳入服务当中，而不是依靠较低的软件层来恢复。

    ◆对于不可恢复的信息，绝对不要依赖于本地存储。保证总是复制所有的非瞬时服务状态。
    ◆保持部署的简单性。文件复制是最理想的方式，因为这样能带来最大的部署灵活性。最小化外部依赖性；避免复杂的安装脚本；避免任何阻止不同组件或者同一个组件不同版本在同一台机器运行的情况。
    ◆定期使服务停转。停掉数据中心，关闭柜式服务器，断掉服务器电源。定期进行受控的关闭操作，能够主动暴露出服务器、系统和网络的缺陷。没有意愿在生产环境中测试的人，实际上是还没有信心保证服务在经历故障时仍能继续运转。此外，若不进行生产测试，在真正出事时，恢复不
一定能派上用场。■

[新闻]消息称MySQL创始人已向Sun提交辞呈

解决FileSystemWatcher事件多次触发的方法

江大鱼 — Wed, 23 Jul 2008 13:55:00 GMT

摘要: 博客园已有几位同学发表了关于FileSystemWatcher事件多次触发的解决方法的文章，很好地解决了事件多次激发的问题。主要方法有： 1.延迟激发法。 http://www.cnblogs.com/dragon/archive/2008/07/04/filesystemwatcher.html 原理是延迟调用事件的代理，将多次事件合并为一次,从而很好的解决了此问题，唯一的缺憾是时间激发不及时，不适用于实时性较高的系统。 2.临时禁用法. 3.检查最后更新时间法. 阅读全文

[新闻]谷歌Chrome浏览器即将更换LOGO颜色？

Windows Live Writer for Windows Server 2003 and Windows Server 2008

江大鱼 — Tue, 22 Jul 2008 23:28:00 GMT

可在windows server 2003 or windows server 2008 下直接下载安装

下载页面:

http://windowslivewriter.spaces.live.com/blog/cns!D85741BB5E0BE8AA!1508.entry

直接下载地址:

http://download.microsoft.com/download/8/0/9/809604cd-bd08-42c8-b590-49c332059e64/writer.msi

[新闻]谷歌Chrome浏览器即将更换LOGO颜色？

Base64 encode/decode large file

江大鱼 — Sun, 20 Apr 2008 13:48:00 GMT

摘要: The class System.Convert provide two basic methods "ToBase64String()" and "Convert.FromBase64String()" to encode a byte array to a base64 string and decode a base64 string to a byte array. It is very good to use them to encode and decode base64. But in some case, it is a disaster. For example, if you want to encode a 4 gb file to base64, the code above must throw an OutOfMemory exception., because you must read the file into a byte array. So we need to look for another way to e 阅读全文

[新闻]淘宝网合并阿里妈妈专家称阿里巴巴或有新战略

UrlRewite之后postback地址被还原的问题的解决方法

江大鱼 — Thu, 20 Dec 2007 05:36:00 GMT

很多人用ActionlessForm来解决这个问题，可是把每个form都改成ActionlessForm的工作量确实太大。

如果你的系统中已定义了叶面基类，那么问题可就简单的多了:

首先在重写时把原始url记录在Context.Items["OriginalUrl"]中,

然后在页面基类中重写下面方法:

  protected override void OnLoadComplete(EventArgs e)
  {
   string originalUrl = Context.Items["OriginalUrl"] as string;

   if (!string.IsNullOrEmpty(originalUrl)) //So this page have been urlrewriten, after the page onloaded, rewrite the url of this page to original url
   {
    string query = string.Empty;
    int pos   = originalUrl.IndexOf('?');
    if(pos>=0)// check if has query parameter
    {
     query  = originalUrl.Substring(pos+1);
     originalUrl = originalUrl.Substring(0, pos);
    }
    Context.RewritePath(originalUrl, string.Empty, query);
   }
   base.OnLoadComplete(e);
  }

LoadComplete之后再把地址重写回来就够了。

[新闻]微软研究院发布 AutoCollage - 整理并融合照片

[New Book]Flex第一步 -- 国内第一本关于Flex的书籍

江大鱼 — Thu, 22 Nov 2007 04:52:00 GMT

这是国内第一本Flex开发的书（新书已上市）

作者：邱彦林（第1-15章）王磊（第16、17章）

      《flex第一步》全书共分为17章。内容包括：Flex简介、Flex的安装和开发环境的建立、MXML 语法简介、使用容器控制界面布局、使用组件处理数据和交互、使用行为对象和动画效果、ActionScript 3.0编程知识、Flex的事件机制、数据绑定、组件的使用、Flex 2.0新特性实例开发、Flex与外部的数据通信、Flex程序设计等。

       书中包括四个大型应用开发实例：Flex数据库留言本、Flex产品展示系统、Flex投票系统、Flex天气预报系统。除此之外，书中还贯穿了大量Demo级小例子，让技术不再抽象，帮你快速掌握Flex开发的关键。

       作者深入浅出，从理论到实践，从基础知识到实践项目把Flex的技术阐述得相当到位，堪称国内Flex图书的开山之作。

更多相关内容，请浏览 http://www.flex9.cn/

[新闻]2008年9月5日科技博客精选

ASP.NET 2.0 二级域名Forms验证模式下共享登陆状态

江大鱼 — Sat, 22 Sep 2007 16:04:00 GMT

在asp.net 1.1中, 二级域名Forms验证模式下共享登陆状态的方法请参考下面文章:

http://www.cnblogs.com/caomao/archive/2005/07/05/186606.html

而在asp.net 2.0中实现方法更为简单，只需修改web.config文件即可，修改方法如下:

<authentication mode="Forms">
<forms name=".ASPNETFORM" domain="yourdomain.com" loginUrl="/login.aspx" defaultUrl="/default.aspx" protection="All" timeout="30" path="/" requireSSL="false" slidingExpiration="true" enableCrossAppRedirects="false" cookieless="UseDeviceProfile" />
authentication>

注意forms节点的domain属性, 如果你的主域名和子域名是www.abc.com, 123.abc.com, .....,那么此domain属性你应该填abc.com即 domain="abc.com".

很简单吧，祝你实现成功！

[新闻]SNS网站风靡影响工作效率公司下令封杀

Expert ASP.NET 2.0 Advanced Application Design

江大鱼 — Thu, 06 Jul 2006 09:29:00 GMT

Microsoft has been working on version 2.0 of the.NET Framework and Visual Studio 2005
for a number of years now. Between the bits that were handed out at the PDC in 2003 and the
release candidate handed out at the PDC in 2005, there’s been an unusually long period of
time for curious developers to play around with the new functionality, picking out their
favorites, and pining for the day they can be used in a production application. Over that same
period of time the features have changed quite a bit. It was also an unusually long period of
time for Microsoft’s customers to provide feedback about what worked and what didn’t, and
what should be changed or preserved before putting the bits into production. What has
resulted is an impressive set of functionality that should be a boon to any development effort.
Because of the long period of time that some version of “Whidbey” (as it was code-named
during the development process) has been available, many folks have been able to play with
the features of this new version, and even more have seen demonstrations of these features at
conferences, in magazines, and online. At its time of release, the development environment
provided by the .NET Framework version 2.0 and Visual Studio .NET 2005 might be the most
broadly familiar “new” product ever released.
Many features of the .NET Framework version 2.0 will be very important as we move forward
into the new platform provided by Windows Vista and its tangential technologies. These
features go much deeper than the wizards and “configurators” that have been added to Visual
Studio .NET; they even go deeper than many of the flashy new controls that have been shown
to awestruck crowds at conferences and developer events over the last couple of years.
And so in designing this book we decided that we did not want to do the standard “new
feature march.” This book is not a general introduction to version 2.0 of the ASP.NET Framework.
Instead, this book focuses on designing distributed applications using the .NET
Framework as your platform. With this as our focus, we treat ASP.NET not as an environment
for the generation of HTML, but rather as an application hosting environment, one capable
of servicing requests not just for Web Forms, but also for Web Services, for distributed objects
via Remoting, even for your own custom application hosting needs. By treating ASP.NET as an
application server instead of as a web application development environment, our field of view
is dramatically increased. Web Forms become just a single piece of a larger, more complex
puzzle, the puzzle of distributed application design. This book does not cover the presentation
tier of an application. While there is some discussion of maintaining state and communication
between a web browser and a web server, a detailed discussion of the presentation tier is conspicuously
absent. Instead, we focus on the middle and data tiers of a layered application, and
the communication that occurs between these tiers.
In writing this book, we assume you have used a 1.x version of ASP.NET. We assume you
are versed in ADO.NET, at least enough to use data readers, create DataSets, and use a data
adapter to update your database data. This book is designed to expand on that base of knowledge,
by simultaneously introducing you to the full range of servers and technologies available
for you to leverage in distributed application design while showing you the enhancements in
xix
version 2.0 of the .NET Framework in each of the different layers and tiers of these applications.
This combination is designed to give you a broader understanding of your choices of
technologies during application design, while at the same time show you how version 2.0
improves upon the existing technologies in these tiers. By taking this approach, this book
might not be your first choice as an introduction to the flashiest of features in ASP.NET 2.0, but
the depth of detail and range of technologies covered will make this book continue to be relevant
long after you’ve forgotten a time when you didn’t know the subtle nuances of the Smart
Tag of the GridView control.
There are many “moving parts” in a distributed application, and many different technologies
can come to bear on the different pieces of a solution. We wanted to write a book that
addressed this complexity, a book on application design—not a blow-by-blow iteration of
Framework features, but a discussion of how you can put the different packages and servers
available together across different tiers of a distributed application and how they can meet
your real-world requirements. The timing was such that it made no sense to write it on
version 1.x of the Framework, as it was soon-to-no-longer-be the latest-greatest. Instead of
getting swept up in the rush of feature-enumerating titles that have hit the scene with the
fanfare of a parade, we just went ahead and wrote a book on application design. We simply
incorporated the features of 2.0 while doing so.
You may have already built a full-blown n-tiered application using ASP.NET. If this is the
case, then chances are you can glance through the table of contents and pick out a few technologies
that you’ve used in the past. This book will round that knowledge out, and enable you
to make more informed decisions about how to design distributed applications, using the features
currently available in .NET 2.0, and anticipating the infrastructure that will be available
when Windows Vista arrives. Throughout the entire treatment of the topics that follow, we
keep an eye on the coming release of Windows Vista and Windows Communication Foundation.
Our guidance and advice on how to build applications today will prepare you for many
of the technologies and strategies that will be ubiquitous in these new environments. This
way you can expand your application design toolset today, while at the same time get ready
to create the applications of tomorrow.

Free download here

[新闻]《孢子》正式发布

Programming .NET Components, Second Edition

江大鱼 — Thu, 06 Jul 2006 09:20:00 GMT

摘要: Brilliantly compiled by author Juval Lowy, Programming .NET Components, Second Edition is the consummate introduction to the Microsoft .NET Framework--the technology of choice for building components 阅读全文

[新闻]《孢子》正式发布

.NET 2.0 的压缩功能

江大鱼 — Tue, 23 May 2006 08:23:00 GMT

在.net 1.1中我们要实现压缩这一功能，一般都是用open source的SharpZipLib 或者调用J#类库。
现在在.net 2.0中增加了压缩功能，名字空间为 using System.IO.Compression;

以下是使用示例：

压缩字符串

public static string ZipString(string unCompressedString)
        {

            byte[] bytData = System.Text.Encoding.UTF8.GetBytes(unCompressedString);
            MemoryStream ms = new MemoryStream();
            Stream s = new GZipStream(ms, CompressionMode.Compress);
            s.Write(bytData, 0, bytData.Length);
            s.Close();
            byte[] compressedData = (byte[])ms.ToArray();
            return System.Convert.ToBase64String(compressedData, 0, compressedData.Length);
        }

解压缩字符串

public static string UnzipString(string unCompressedString)
        {
            System.Text.StringBuilder uncompressedString = new System.Text.StringBuilder();
            byte[] writeData = new byte[4096];

            byte[] bytData = System.Convert.FromBase64String(unCompressedString);
            int totalLength = 0;
            int size = 0;

            Stream s = new GZipStream(new MemoryStream(bytData), CompressionMode.Decompress);
            while (true)
            {
                size = s.Read(writeData, 0, writeData.Length);
                if (size > 0)
                {
                    totalLength += size;
                    uncompressedString.Append(System.Text.Encoding.UTF8.GetString(writeData, 0, size));
                }
                else
                {
                    break;
                }
            }
            s.Close();
            return uncompressedString.ToString();
        }

压缩文件

public static bool AddZip(string srcFilename, string zipFileName)
        {
            if (!File.Exists(srcFilename))
                return false;
            bool result;
            FileStream fs = null, output = null;
            GZipStream zipStream = null;
            try
            {
                fs = new FileStream(srcFilename, FileMode.Open, FileAccess.Read);
                byte[] buffer = new byte[fs.Length];
                fs.Read(buffer, 0, buffer.Length);
                fs.Close();
                if (!File.Exists(zipFileName))
                {
                    output = File.Create(zipFileName);
                    zipStream = new GZipStream(output, CompressionMode.Compress);
                    zipStream.Write(buffer, 0, buffer.Length);
                    result = true;
                }
                else
                {
                    result = false;
                }
            }
            catch(Exception)
            {
                result = false;
             }
            finally
            {
                if (zipStream != null)
                {
                    zipStream.Flush();
                    zipStream.Close();
                }
            }
            return result;
        }

[新闻]微软CFO:仍对收购雅虎搜索业务感兴趣

Pro C# 2005 and the .NET 2.0 Platform, Third Edition for free download

江大鱼 — Tue, 28 Mar 2006 03:05:00 GMT

Download Address:

http://www.drivehq.com/file/ShowFolder.aspx?G=1&shareID=43383

In the Folder named "DotNet"

Please Open it!

C# 2005 has changed the .NET 2.0 landscape. To name just a few improvements, C# now supports generics, partial types and nullable types when your are coding. And the Framework boasts improved speed, data access, security, and scalability.

This book has been written to help you assimilate all this new information and realize its potential to make your coding life easier. It will keep you ahead of the curve. To make it easy for you to access this information, the book has been loosely grouped into five sections:

1. Introducing C# 2005 and the .NET 2.0 Platform explains the mechanics of .NET programming and the philosophy that lies behind it
2. The C# Programming Language outlines everything you need to know to start using C# 2005 quickly and efficiently. Object lifetimes, exception handling, generics梚t抯 all here
3. Programming with .NET Assemblies deals with one of the most important aspects of .NET programming: reusing code. This book shows you how to capture your code in reuseable external assemblies that you can call upon throughout your applications
4. Programming with the .NET Libraries guides you through them. Of course you抮e not expected to write every function yourself. The .NET Framework provides a vast array of .NET Libraries containing functionality that allows you to do everything from opening a file-stream to rendering graphical data to the screen
5. Web Applications and XML Web Services concludes the book by taking you away from console-based C# applications and investigating the myriad possibilities that become available when you blend C# 2005 with ASP.NET 2.0 to launch your applications onto the Internet

Author Information

Andrew Troelsen

Andrew Troelsen is a partner, trainer, and consultant at Intertech-Inc., and is a leading authority on both .NET and COM. His book Pro C# 2005 and the .NET 2.0 Platform won the prestigious 2003 Referenceware Excellence Award and is now in its third edition. Also of note are his earlier five-star treatment of traditional COM in the bestselling Developer's Workshop to COM and ATL mirrored in his book, COM and .NET Interoperability, and his top-notch investigation of VB .NET in Visual Basic .NET and the .NET Platform: An Advanced Guide. Troelsen has a degree in mathematical linguistics and South Asian studies from the University of Minnesota and is a frequent speaker at numerous .NET-related conferences. He currently lives in Minneapolis, Minnesota, with his wife, Amanda, and spends his free time investigating .NET and waiting for the Wild to win the Stanley Cup.

[新闻]SQL Server2008十月亮相标榜智能数据平台

ASP.NET中实现二级或多级域名(修改UrlRewrite)需要注意的问题

江大鱼 — Mon, 20 Feb 2006 05:29:00 GMT

摘要: 本文背景： http://jzywh.cnblogs.com/archive/2005/09/29/246650.html

网上很多朋友看到我这篇文章，按照我的方法做了，但是还是没有得到想要的效果，其实有些问题需要注意一下，我上篇文章也只是提出了解决这一问题的办法的最核心的内容，有些朋友可能在实际运用中可能会碰到一些问题其实可以根据自己的经验作出相应处理应该可以解决，我在这里帮大家列出几点以帮助大家快速解决问题。阅读全文

[新闻]淘宝将与阿里妈妈合并大淘宝战略启动